[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Fwd: Re: Problem with desktop file spec not allowing @modifier in
From: Waldo Bastian <bastian () kde ! org>
Date: 2003-06-06 9:37:28
[Download RAW message or body]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Since KDE is commited to implementing the desktop-entry-spec it would be nice
if the klocale experts could give some feedback on this.
- ---------- Forwarded Message ----------
Subject: Re: Problem with desktop file spec not allowing @modifier in locale
naming
Date: Thursday 05 June 2003 22:59
From: Jonathan Blandford <jrb@redhat.com>
To: Christian Rose <menthos@gnome.org>
Cc: Naba Kumar <kh_naba@gmx.net>, GNOME I18N List <gnome-i18n@gnome.org>,
xdg-list@freedesktop.org
Christian Rose <menthos@gnome.org> writes:
> This problem with the desktop file spec should be fixed upstream, so
> that conformant parsers can respect the @modifier syntax. So I've cc:d
> xdg-list@freedesktop.org to get some input on the issue.
How about this as a start for a fix to the desktop-entry spec?
Thanks,
- -Jonathan
- -------------------------------------------------------
- --
bastian@kde.org -=|[ SuSE, The Linux Desktop Experts ]|=- bastian@suse.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE+4GDZN4pvrENfboIRAjsZAJ9YYnsK04q171oiX6Mtnujcxg0/4gCfZDan
lMSa+U838a6dd2vffcnX3Uw=
=LRoW
-----END PGP SIGNATURE-----
[" " (text/x-patch)]
? desktop-entry-spec
? desktop-entry-spec.junk
Index: desktop-entry-spec.sgml
===================================================================
RCS file: /home/freedesktop/desktop-entry-spec/desktop-entry-spec.sgml,v
retrieving revision 1.3
diff -u -r1.3 desktop-entry-spec.sgml
--- desktop-entry-spec.sgml 24 Aug 2002 20:33:13 -0000 1.3
+++ desktop-entry-spec.sgml 5 Jun 2003 20:50:50 -0000
@@ -116,42 +116,105 @@
<sect1 id="recognized-keys">
<title>Recognized desktop entry keys</title>
<para>
- Keys may be postfixed by [<replaceable>locale</replaceable>], where \
<replaceable>locale</replaceable> is the LOCALE type
- of the entry. <replaceable>locale</replaceable> 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.
+ Keys may be postfixed by [<replaceable>LOCALE</replaceable>],
+ where <replaceable>LOCALE</replaceable> is the locale type of the
+ entry. <replaceable>LOCALE</replaceable> must be of the form
+ lang[_COUNTRY][.ENCODING][@MODIFIER], where _COUNTRY, .ENCODING,
+ and @MODIFIER may be omitted. If a postfixed key occurs, the same
+ key must be also present without the postfix.
</para>
<para>
When reading in the desktop entry file, the value of the key is
selected by matching the current POSIX locale for the LC_MESSAGES
- category against the <replaceable>locale</replaceable> postfixes of all \
occurrences of the key,
- with the .ENCODING part stripped. (The .ENCODING is used when the
- Encoding key for the desktop entry file is Legacy-Mixed, see
- <xref linkend="legacy-mixed">.)
+ category against the <replaceable>locale</replaceable> postfixes
+ of all occurrences of the key, with the .ENCODING part stripped.
+ The .ENCODING field is used only when the Encoding key for the
+ desktop entry file is Legacy-Mixed, (see <xref
+ linkend="legacy-mixed">.)
</para>
<para>
- The matching is done as follows: if the current value of
- LC_MESSAGES is
- <replaceable>lang</replaceable>_<replaceable>country</replaceable>.<replaceable>encoding</replaceable>@<replaceable>modifier</replaceable>,
- then, if a key for
- <replaceable>lang</replaceable>_<replaceable>country</replaceable>
- is present, it will be used. Otherwise, if a key for
- <replaceable>lang</replaceable> 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.
+ The matching of is done as follows. If LC_MESSAGES is of the form
+ <replaceable>LANG</replaceable>_<replaceable>COUNTRY</replaceable>.<replaceable>ENCODING</replaceable>@<replaceable>MODIFIER</replaceable>,
+ then it will match a key of the form
+ <replaceable>LANG</replaceable>_<replaceable>COUNTRY</replaceable>@<replaceable>MODIFIER</replaceable>.
+ If such a key does not exist, it will attempt to match
+ <replaceable>LANG</replaceable>_<replaceable>COUNTRY</replaceable>
+ followed by
+ <replaceable>LANG</replaceable>@<replaceable>MODIFIER</replaceable>.
+ Then, a match against <replaceable>LANG</replaceable> by itself
+ will be attempted. Finally, if no matching key is found the
+ required key without a locale specified is used. The encoding
+ from the LC_MESSAGES value is ignored when matching.
</para>
<para>
+ If LC_MESSAGES does not have a <replaceable>MODIFIER</replaceable>
+ field, then no key with a modifier will be matched. Similarly, if
+ LC_MESSAGES does not have a <replaceable>COUNTRY</replaceable>
+ field, then no key with a country specified will be matched. If
+ LC_MESSAGES just has a <replaceable>LANG</replaceable> field, then
+ it will do a straight match to a key with a similar value. The
+ following table lists possible matches of various LC_MESSAGES in
+ the order in which they are matched. Note that the
+ <replaceable>ENCODING</replaceable> field isn't shown.
+ </para>
+ <table>
+ <title>Locale Matching</title>
+ <tgroup cols=2>
+ <thead>
+ <row>
+ <entry>LC_MESSAGES Value</entry>
+ <entry>Possible Keys in Order of Matching</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry><replaceable>LANG</replaceable>_<replaceable>COUNTRY</replaceable>@<replaceable>MODIFIER</replaceable></entry>
+ <entry>
+ <replaceable>LANG</replaceable>_<replaceable>COUNTRY</replaceable>@<replaceable>MODIFIER</replaceable>,
+ <replaceable>LANG</replaceable>_<replaceable>COUNTRY</replaceable>,
+ <replaceable>LANG</replaceable>@<replaceable>MODIFIER</replaceable>,
+ <replaceable>LANG</replaceable>,
+ Default Value
+ </entry>
+ </row>
+ <row>
+ <entry><replaceable>LANG</replaceable>_<replaceable>COUNTRY</replaceable></entry>
+ <entry>
+ <replaceable>LANG</replaceable>_<replaceable>COUNTRY</replaceable>,
+ <replaceable>LANG</replaceable>,
+ Default Value
+ </entry>
+ </row>
+ <row>
+ <entry><replaceable>LANG</replaceable>@<replaceable>MODIFIER</replaceable></entry>
+ <entry>
+ <replaceable>LANG</replaceable>@<replaceable>MODIFIER</replaceable>,
+ <replaceable>LANG</replaceable>,
+ Default Value
+ </entry>
+ </row>
+ <row>
+ <entry><replaceable>LANG</replaceable></entry>
+ <entry>
+ <replaceable>LANG</replaceable>,
+ Default Value
+ </entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <para>
For example, if the current value of the LC_MESSAGES category
- is de_DE, and the desktop file includes:
+ is sr_YU@Latn and the desktop file includes:
</para>
<programlisting>
Name=Foo
- Name[de]=Foo auf Deutsch</programlisting>
+ Name[sr_YU]=...
+ Name[sr@Latn]=...
+ Name[sr]=...</programlisting>
<para>
- Then the value used for the name key will be 'Foo auf Deutsch'. However,
- if a value is specified for Name[de_DE], then that will be used
- instead.
+ then the value of the Name keyed by "sr_YU" is used.
</para>
<para>
Case is significant. The keys "Name" and "NAME" are not equivalent.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic