Re: sr Latn vs desktop files

[Owen Taylor <otaylor redhat com>]

On Mon, 2003-05-19 at 10:48, Martin Norb� wrote:
> m�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. The reason,
if I recall, that I wrote the specification of matching as:

> > >and:
> > >The matching is done as follows: if the current value of LC_MESSAGES is
> > >lang_country encoding modifier, then, if a key for lang_country is
> > >present, it will be used. Otherwise, if a key for lang is present, it
> > >will be used. If both of these are missing, the required key without a
> > >locale specified is used. The encoding and modifier from the LC_MESSAGES
> > >value are ignored.

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)

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...

> > Is there a solution anyone can think of? How are we to differentiate 
> > between two scripts?
> > 
> > The "solution" of removing latin-script translation completely is 
> > unacceptable, since there are many who'd prefer to use it (some would 
> > actually only opt for it). As you could probably notice, the difference 
> > between "sr" and "sr Latn" is significant, so it's not reasonable to 
> > enforce one over the other.
> > 
> > Should we instantly update the desktop utils to resolve this "bug", or 
> > if not, maybe revert to the old "broken" state (sp and sr as codes)?
> 
> 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.
> 
> It seems that the @modifier wasn't meant to separate at this high level.
> 
> 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.

Regards,
                                                 Owen