O/H Thomas Thurman έγραψε: > Ysgrifennodd Alan Cox <[EMAIL PROTECTED]>: > >> Sort order, comparisons, printing, string lengths when using locale aware >> functions, and no doubt a few more that for the moment have escaped me. >> >> Use the tools to spec and you get reliable predictable results, do >> otherwise and it all gets sloppy and buggy. Would you rely on undefined C >> behaviour in Gnome code ? >> > > I'm surprised that it's been a whole day and nobody's jumped out > saying "Non-ASCII encodings for source strings in gettext files are > broken? Why, what a perfect opportunity to switch to xliff!" > xliff support to the gettext level could require a gyoc program (google year of code).
I made a blog post on the non-ascii issue which received a few comments, http://blogs.gnome.org/simos/2008/05/14/should-ui-strings-in-source-code-have-non-ascii-characters/ My view from all comments goes like this, a. The canonical way to deal with UI messages in the source code is to keep them simple (ASCII), and put any variations in the appropriate locale. For en_US, use the translation files for en_US. In localisation terms, a single change in a message in the source code affects over 60 languages, so UI messages in the source code should stay simple and not change. b. Going for (a) would entail quite some work that we do not appear to have people to do. Any en_US translators? Probably not. c. It appears that the GNOME apps do not fail miserably if there are UTF-8 strings in the source files. Such strings have been there since GNOME 2.20, and possibly earlier. However, these were high level applications (evince, epiphany, etc), which means that we do not know for sure yet if someone who works directly with glib, gtk+ user would be affected (for example, in embedded systems). The easy way to figure out if they are affected is to add a UTF-8 character in some message in glib, then wait and see ;-). Simos _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
