After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 114322 - Desktop file spec does not allow @modifier locale naming (sr@Latn)
Desktop file spec does not allow @modifier locale naming (sr@Latn)
Status: RESOLVED FIXED
Product: general
Classification: Other
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: Unknown User
Unknown User
: 120050 (view as bug list)
Depends on:
Blocks: 122935
 
 
Reported: 2003-06-03 08:33 UTC by Christian Rose
Modified: 2005-01-05 14:49 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Christian Rose 2003-06-03 08:33:12 UTC
This problem is appearing all over GNOME as we get more sr@Latn
translations. I'm filing it here so we have at least one place in GNOME
bugzilla to track it, while I intend to also bring it up on
xdg-list@freedesktop.org to get the spec fixed upstream.

The problem is that the current desktop file specification, and hence
spec-conformant parsers, does not allow locales to be named 'sr@Latn' or
similar, i.e. having a so called '@modifier' syntax. This is what the spec
has to say:

  "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."

The last sentence should rather read:

  "locale must be of the form lang[_COUNTRY][.ENCODING][@modifier],
  where either _COUNTRY, .ENCODING or @modifier may be omitted"

This optional @modifier seems to be supported by most other specifications
and locale-handling routines, including libc and POSIX. The only case where
this has reportedly caused a problem so far is with the desktop file spec,
which seems to completely ignore the @modifier syntax. 

The reason we need a @modifier here is that the Serbian language is
typically written and accepted in not only one but two different scripts:
cyrillic and latin script. Automatic transliteration from one to the other
is not completely possible since there is no exact one-to-one matching in
all cases, and there's also a performerance aspect of runtime transliteration.
So we need to distinguish two different Serbian translations.
Distinguishing by using a different custom language code for one of the
scripts, as was used in GNOME previously, is out of the question as that
instead violates the ISO 639 language code standard. Since both the scripts
are used simultaneously in the same geographic regions (typically YU),
altering the REGION would also be causing problems. That leaves us with the
free-form @modifier, that is designed for these cases: To allow for
distinguishing locales that cannot otherwise be properly distinguished
through their naming.
Comment 1 Benjamin Otte (Company) 2003-08-17 20:20:35 UTC
*** Bug 120050 has been marked as a duplicate of this bug. ***
Comment 2 Kjartan Maraas 2003-09-22 10:39:21 UTC
Is any work going on to clarify this in the spec?
Comment 3 Danilo Segan 2003-09-28 22:00:12 UTC
AFAICS, this is already fixed in 0.9.4 version of the draft specs:
http://www.freedesktop.org/standards/desktop-entry-spec/0.9.4-onehtml/#recognized-keys

Hope it's now time to also fix 122935.
Comment 4 Kjartan Maraas 2005-01-05 00:21:01 UTC
Can we close this bug then?
Comment 5 Danilo Segan 2005-01-05 14:49:00 UTC
Sure, closing it.