I don't understand the purpose of your comment. OK so perl is great. This article isn't about Perl...it's about the semi-obscure and commonly underestimated Tcl (which is also a great language).
The purpose of the comment seems clear enough to me: to point out two claims made by the article that seem implausibly optimistic:
1. That i18n "just happens", which as fuzzix says is surely impossible unless Tcl includes magical machine translation facilities.
2. That "encodings are not a problem - they just work", which would require Tcl to tell by some ingenious means what encoding is used by any given file -- something that Perl, despite being exactly the sort of language that doesn't mind the kind of heuristic complexity it would take to do this well, and being generally acknowledged to do a good job of handling Unicode, punts on).
If I open an ISO-8859-15 or UCS-2 file in a Tcl program, how is this handled? Does it seamlessly detect encoding and translate to UTF-8 or is there more to this issue than what's stated in the article? Also, are the strings stored in a canonicalised form? If not, how simple is it to perform normalisation?
I brought up Perl because it's my experience of a language with excellent encoding support and helps make the point that the issue is probably more complex than just how strings are stored and manipulated internally.
Perl's unicode support is excellent now. In 2006 5.10 wasn't out yet, and anything before 5.8.5 had all sorts of odd unicode bugs.
Or: Tcl got there significantly before we did.
To be clear, I'm not arguing against using Tcl in favour of Perl or anything else. It's just that my experience with a language with great encoding support doesn't jive with what's claimed here.