Re: Quotation marks: Using “” instead of ""

[Simos Xenitellis <simos lists googlemail com>]

O/H Thomas Thurman έγραψε:
> Ysgrifennodd Alan Cox <alan lxorguk ukuu org uk>:
>   
> > 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