Re: sr@Latn vs desktop files
- From: Owen Taylor <otaylor redhat com>
- To: Martin Norbäck <d95mback dtek chalmers se>
- Cc: Danilo Segan <dsegan gmx net>, Alexander Larsson <alexl redhat com>, "desktop-devel-list gnome org" <desktop-devel-list gnome org>, gnome-i18n gnome org
- Subject: Re: sr Latn vs desktop files
- Date: 19 May 2003 12:07:09 -0400
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]