Theppitak Karoonboonyanan

iostream String Formatting Considered Harmful

Fri, 22 Aug 2008 07:24:51 GMT

When learning to code in C++, I was convinced by the advantage of iostream over C printf, such as better type checking. C++ syntactic features have been used to devise the stream operators and manipulators to match what printf provides. But one important thing is missing: format string localization.

Some examples are shown in GNOME #548950 for Ekiga trunk.

For example, to print how many users are found online, with printf and gettext we get (plural form is omitted here for simplicity):

  printf (_("%d users found\n"), nUsers);

But with iostream we get:

  std::cout << nUsers << " " << _("users found") << std::endl;

In printf case, translators are free to reorder words according to different grammars. For example, in case of Thai, it can be translated like:

  msgid "%d users found\n"
  msgstr "พบผู้ใช้ %d คน\n"

(Literally, the Thai msgstr reads "found users %d persons".)

But this is impossible for iostream case. One must end up with very weird language usage like:

  msgid "users found"
  msgstr "ผู้ใช้ถูกพบ"

(Thai msgstr here literally reads "users are found".)

And "3 ผู้ใช้ถูกพบ" sounds weird and unnatural to Thai readers. That is, with iostream, word orders in messages are tied to English.

I don't know how to solve this with iostream. It seems beyond what C++ syntax can achieve.

When combined with another case I found when working with POSIX file descriptor, for which fstream constructor has been dropped from C++ standard library, using iostream is simply a wrong decision in the first place. And the solution is to migrate the file manipulating codes to plain stdio C library.

Lesson learned: Don't use C++ iostream unless you really have limited use cases.

What aspects to consider if a language is "supported"?

Mon, 14 Mar 2005 07:03:14 GMT

FOSS is great. It allows any interested party to join and modify software to serve their needs, including local language supports.

In many cultures, including Thai, people are happy reading English messages in applications, but require applications to allow creating and editing "contents" in their own languages. For these cultures, language supports in infrastructure for text input, text rendering and printing, and some internal operations like sorting and text analysis, are essential, while message translation is optional.

So, when asked if Thai is supported by GNOME, I'd answer yes, because, through many development efforts in the past, you can now:

Type Thai text in GNOME applications, with input sequence checking, and even correction (with Thai XIM and GTK+ im-xim bridge).
See Thai text with quality rendering, with even OpenType font support (thanks to the Pango project).
Read Thai text with proper line wrapping, or even word selection, despite the fact that Thai words are not delimited by spaces nor any punctuation marks (thanks to the LibThai project, with the wise API provision by Pango itself).
Sort Thai words in applications according to the standard dictionary, as well as other cultural conventions such as date/time format (thanks to the Thai Locale project).

Unfortunately, Thai message translation in GNOME 2.10 is still far from complete. So, it's not listed as a "supported" language. But the fact is that many Thai people just don't care about message translation.

Nothing to complain here. Just a notice that my definition of "language support" might be different from the official one. :-)

Welcome to my blog

Fri, 11 Mar 2005 16:23:08 GMT

Welcome to my live journal. This is a first post.
ยินดีต้อนรับสู่ blog ของผม นี่คือการทดสอบ (จาก drivel)