Re: sr@Latn vs desktop files
- From: Danilo Segan <dsegan gmx net>
- To: Alexander Larsson <alexl redhat com>
- Cc: "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 16:10:04 +0200
Hi,
Alexander Larsson wrote:
I just noticed the new sr Latn locale when i was building rpms of
Nautilus 2.2.4. It results in this line in the desktop file:
Name[sr Latn]=LiÄ?ni direktorijum
We've had discussions on choosing the code for the Serbian language in
latin script on gnome-i18n list earlier in the April. As a team
coordinator for Serbian language, I was instructed that this (sr Latn)
or similar (sr latin) is the best choice, instead of using the
non-existent language code "sp" for that purpose.
When run through the pedantic parser in desktop-file-utils it says:
Error on file "/usr/share/applications/nautilus.desktop":
Error in section Desktop Entry at line 40:
Invalid characters in locale name
And reading the desktop file spec this seems invalid:
Keys may be postfixed by [locale], where locale is the LOCALE type of
the entry. locale must be of the form lang[_COUNTRY][.ENCODING], where
either _COUNTRY or .ENCODING may be omitted. If a postfixed key occurs,
the same key must be also present without the postfix.
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?
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.
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)?
Cheers,
Danilo
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]