Re: sr@Latn vs desktop files

[Danilo Segan <dsegan gmx net>]

Martin Norbäck wrote:

>The specification for LC_* values doesn't mandate that the codes used
>must be ISO language and country codes, even though that seems to always
>be the case in glibc. So maybe it's better to encode the fact that a
>different script is used into the COUNTRY (or territory as it's called
>in the specification).
>
>Something like sr_YUlatin and sr_YUcyrillic? I don't know the
>implications on other things, like fallbacks to sr_YU and sr.
>  
>
This seems to me to break the idea of both "territory" and "country", 
since cyrillic and latin edition are used interchangeably (I mean, 
whoever prefers the latin, uses it, I have a few friends from the same 
"territory" [if don't count a household as "territory" :-)] who prefer 
other choices). There's no territory dependance, and I'm also not sure 
how this would effect fallbacks to more simpler codes.

>It seems that the @modifier wasn't meant to separate at this high level.
>  
>
Yes, it does seem so, at least in desktop files specification. According 
to what was said by Alexander, even encoding is not used in the case of 
desktop files (which seems reasonable, but there may be problems for 
some languages I have no idea about), so it seems best to fix them now 
to allow for all the generality. Since this should be a 
one-time-write-use-everywhere function for reading the .desktop data, I 
guess it's not unreasonable requirement.

Also, one may think of a modifier like "coloquial" ("hey bro, ya have 
fsckd up here" for an error message :-)), where some translation would 
have a locale specifier of "lang_territory.encoding@coloquial" to 
provide a translation with coloquial expressions (which is independent 
of territory and encoding). If we're to suppress this generality now, 
many of the problems I didn't even think of will probably arise sometime 
in the future.

>BTW, is there an automatic translation from one script to the other? If
>that's the case, maybe it could be built into the system somehow.
>  
>
Yes, there's a one to many mapping from cyrillic to latin (it's mostly 
one-to-one, except in a case of few letters). I can provide with a 
mapping table, but I think this is more trouble than it's worth.

Also, special casing a single language is probably what many would like 
to avoid in Gnome code. If Pango would support transliteration in 
"intuitive" way (meaning, easy to specify, and general enough to work 
for many cases, maybe working through some already established 
mechanism), I guess that would be sufficient, even if more CPU time 
would be required. This would also bring the advantages of being able to 
read cyrillic when it's not present on the system (eg. like Lynx 
transliterates to ASCII).

Though, this might provoke problems with other software (notably, if and 
when glibc is switched to use the same codes; actually, glibc already 
sporadicaly uses the form "sr_YU@cyrillic", so it will cause problems 
right away, at least for users who want to use it as locale specifier).

Though, performance issues are still to be raised, compared to the 
simple and easy inclusion of generated translation in static form.

Cheers,
Danilo