Re: sr@Latn vs desktop files

[Danilo Segan <dsegan gmx net>]

Owen Taylor wrote:

>On Mon, 2003-05-19 at 10:48, Martin Norbäck wrote:
>  
>
>>mån 2003-05-19 klockan 16.10 skrev Danilo Segan:
>>    
>>
>>>I'd say that this is just Plain Wrong. I consider it a bug in desktop 
>>>file specification. Also, I believe Keld mentioned that there's a work 
>>>on new POSIX locale specifier format which would include the script as 
>>>additional field, but I'm not sure how's that going. Also, "modifier" is 
>>>already part of the locale specifier, right?
>>>      
>>>
>
>Well, sort of. Actually, according to POSIX, LANG=sr_YU@Latn is illegal;
>modifier can only be used on the individual categories - the
>example used is LC_COLLATE=de_DE@dict.
>
>It wouldn't violate POSIX to have 
>
> LANG=sr_YU LC_TIME=sr_YU@Latn LC_MESSAGES=sr_YU@Latn
>
>But it definitely seems to violate the intent of the spec. 
>
What would the effect of LC_ALL=sr_YU@Latn be? Doesn't is also imply 
LANG? (I'm not quite sure on this)

>The reason,
>if I recall, that I wrote the specification of matching as:
>
> ...
>
>was partly to not have to deal with the rules for matching on modifier;
>according to POSIX, @modifier seems less significant then country, but
>the only usage was no_NO@bokmal where @bokmal was in effect specifying
>a different language (Since fixed to nb_NO)
>  
>
I see: that was a practical compromise. Now, that the practice has 
changed ... :-)

>Now, that being said, even if LANG=sr_YU@Latn is dubious according
>to POSIX, that doesn't mean it can't be used. In fact, GLIBC seems
>to have currently have sr_YU@cyrillic and sr_YU ... so it does
>the same thing, but backwards from what you have (!) KDE also seems
>to use 'sr' for latin-encoded Serbian.
>
>That's probably even more of a problem than the desktop file spec...
>  
>
KDE translation team does not have a cyrillic translation ready as of 
yet, but they have agreed to use the same codes we're using (I talked to 
them). I believe someone mentioned that this code assignement was 
performed by Anton Zinoviev. I'm planning to raise this question for the 
glibc too, since these choices are much more sane (eg. the official 
script for the goverment is cyrillic, latin is allowed in jurisdictions 
of national minorities, etc.).

>>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.
>>    
>>
>
>GNU libc generally has fairly nice facilities for doing transliteration
>on the fly; I think they should be investigated before we spend more
>time on the question of how to name two separate translations.
>  
>
Yes, it does have nice facilities, but they're not always applicable. At 
this time, we *are* doing a conversion automatically, but it won't 
neccessarily be so in the future. I can imagine someone using 
latin-script translation to want to see the "w" in "web" instead of 
"veb" ("w" is not present in Serbian language as letter), or as Pablo 
already pointed out "Linux" instead of "Linuks". These are the changes 
that would have to be hand crafted, and thus, not automatable.

As I already said, Keld Jo/rn Simonsen <keld@dkuug.dk> mentioned that 
there are some ideas on introducing a script identifier into the locale 
specifier. Should we maybe look into it and use the current proposal 
(hoping it will become official)?

Finally, should we keep the current state of afairs until this is 
resolved (meaning, I'll continue uploading translations with the codes 
"sr" and "sr@Latn"), or is there any other *practical* solution?


Cheers,
Danilo