Re: sr@Latn vs desktop files



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]