GNOME Bugzilla – Bug 114322
Desktop file spec does not allow @modifier locale naming (sr@Latn)
Last modified: 2005-01-05 14:49:00 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.
*** Bug 120050 has been marked as a duplicate of this bug. ***
Is any work going on to clarify this in the spec?
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.
Can we close this bug then?
Sure, closing it.