Re: sr@Latn vs desktop files
- From: Danilo Segan <dsegan gmx net>
- To: Martin Norbäck <d95mback dtek chalmers se>
- Cc: 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: Mon, 19 May 2003 17:39:49 +0200
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]