This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: locale for Uzbekistan


On Thu, Sep 25, 2003 at 07:49:05PM +0200, Mashrab Kuvatov wrote:

> > > Since there is no required format for the @xyz part on the part of the
> > > locale name that part better be description.  We use @euro, we used
> > > @bokmal.  There is no reason whatsoever to use anything but @cyrillic.

There never was "@bokmal" but "@nynorsk"

> > I won't take a position here ... I'm just trying to convince people
> > to agree on something.
> Like I said in my previous email, it is fine if libc's convention for cyrillic
> script locale is @cyrillic. I do not think it is a big deal to change @Cyrl
> to @cyrillic for existing translations. What do you think Pablo ?

I think if a standard exists to name scripts it is better to follow it.

using "Cyrl" instead of "cyrillic" as *identifier* is better for the
same reasons that using "uz" is better than using "Uzbek".

> Pablo: Please have a look at
> to catch up with discussion. Sorry, I did not think of CCing you from the
> beginning.

Mmh, "@cyrillic" was only used for "sr_YU@cyrillic".
with "sr_YU" being in latin.
Which is contrary to local use for Serbian (cyrillic is the preferred
writting method; it should be "sr_YU" in cyrillic, and "sr_YU@latin"
or "sr_YU@Latn" for latin).

XFree86 didn't had "sr_YU@cyrillic" anyway; it had "sr_YU" and "sp_YU" (non
standard) for latin and cyrillic respectively.

So, I used "sr" for Serbian latin, and "sp" for cyrillic.

But recently, Serbian translators raised the concern that "sp" was nonstandard
and wrong; a discussion took place in gnome-i18n ml, and finally Serbian
translators choose to use "sr" for cyrillic, and "sr@Latn" for latin,
the "Latn" being taken from the scripts ids.
Some asked if "sr@Cyrl" shouldn't be used too; but the answer was that
cyrillic being the default, then "sr" would be enough.

When sometime after, the same concern about cyrillic/latin happened for
Uzbek language, I follow the same path as done by Serbian translators,
as the problem was exactly the same; only that for Uzbek the official
script is latin, so cyrillic is the variant: "uz" and "uz@Cyrl";
and I also made a locale "uz_UZ@Cyrl" so the date could be in cyrillic too
(most other things are common with uz_UZ)

IMHO it would be much easier to make the glibc follow the standardization
settled by translators than the other way (as there are tons of Serbian
translations in particular); also, sr/sr@Latn is more correct that
sr@cyrillic/sr, which should be changed to sr/sr@latin at least; so,
why not use sr/sr@Latn instead ?

Using ISO-15924 allows also to know in advance what to use for any future
need to distinguish scripts (for latin and cyrillic it is quite easy;
but what about the need to distinguish between arabic and some indic script;
"arabic" or "persoarabic" or other? and what about the canadian syllabics
script? would it be "cree", "inuit", "inuit-cree", "canadian_syllabics",
"canadiansyllabics", "uca",...

using "@cyrillic" and "@latin" may seem simple right now; the same way
as using "english" or "french" was seen as simple in old times (I saw a lot
of old documentation telling to set LANG=french for example); but as more
and more languages get supported, it gets complex, and divergent
interpretations arise.
Sticking to a standard that define identifiers is much better than using
words tied to a given language/culture; imho.
> > But, I think the reasoning is that ISO-15924 is a standard for names for
> > scripts, and a script name was wanted, so the ISO-15924 name was used.
> Exactly.

Ki ça vos våye bén,
Pablo Saratxaga		PGP Key available, key ID: 0xD9B85466
[you can write me in Walloon, Spanish, French, English, Italian or Portuguese]

Attachment: pgp00000.pgp
Description: PGP signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]