[desktop entry spec] new FullName key

[Luca Ferretti]

> > The solutions you propose add clutter to the menus, in the form of
> > > parens or dashes, just to cover up the fact that there is no good way to
> > > combine the two fields that does not cause translation problems.
> >
> > If you don't like parens or dashes, use the more modern two-line solution,
> > with the name on the first line and the genericname on the second line.
>
> Ok, maybe I should have mentioned newlines as yet another workaround.
>
> Why is it so hard to acknowledge that if you want to show a piece of
> text as one unit in the interface, it needs to be presented as one unit
> to the translators ?
>

As translator, proofreader and coordinator of translation team, I don't
agree so much.

First, most translators don't know what they have to do with those "Name
GenericName" strings. We are forced to explain to new members what those
translatable messages are and how should be translated.

Second, some languages, such as French or Italian, don't follow the same
layout. "Name GenericName" could sound like a grammar error in Italian,
so we have to switch the order to "GenericName Name"[1]. This is a task
that we have to manually perform and check, and we can't ensure that all
translations will follow this rule, at least not for applications
outside git.gnome.org (yes, some "amateur" translators strictly follow
English rules in Italian...)

So, as GNOME translator and coordinator, I could really appreciate a
single "%1$s %2$s" translatable message in glib or gnome-menus to choose
the default order and layout for Name and GenericName, once and for all.
The (localized) FullName label could be programmatically composed,
trusting that all labels will appear the same.

But I agree that i18n/l10n is a crazy stuff, so a hardcoded FullName
translatable string could be needed. For example, if you have

  Name=Epiphany
  GenericName=Web Browser
  Name[it]=Epiphany
  GenericName[it]=Web browser

and you programmatically compose them using Name + GenericName, you'll
have

  [it] -> Epiphany Web browser

This is an error in Italian language, it should be "Epiphany web
browser" (see the case of Web/web). This is just a fictional example,
just to show that the programmaticall approach couldn't be good for some
languages (I repeat, some language, and it's just a personal
hypothesis).

Summarizing: to have an homogeneous inteface, the proposed FullName key
is a menace :)
I suggest to check how many languages are not confortable with
programmatical approach before adding it. For Italian language, the
programmatical approch is fine (and desired) if you provide us a "%1$s %
2$s" to choose the order.

[1] to be honest we adopted the "Name - GenericName" approach in Italian


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Nicolas Mailhot]

Le dimanche 02 août 2009 à 17:17 +0200, Luca Ferretti a écrit :

> This is an error in Italian language, it should be

This is the same in French

> Summarizing: to have an homogeneous inteface, the proposed FullName key
> is a menace :)
> I suggest to check how many languages are not confortable with
> programmatical approach before adding it.

It does not work for French and Italian which are “easy” Western
European languages. I don't see how it could possibly work with
languages that us more complex grammar rules such as cases. The
programmatical approach is an English-only approach that only works
because English is a very simple language that lets you collate words
without changes in pretty much any order and get valid sentences
nevertheless.

--
Nicolas Mailhot


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Albert Astals Cid-2]

A Diumenge, 2 d'agost de 2009, Luca Ferretti va escriure:

> > > The solutions you propose add clutter to the menus, in the form of
> > >
> > > > parens or dashes, just to cover up the fact that there is no good way
> > > > to combine the two fields that does not cause translation problems.
> > >
> > > If you don't like parens or dashes, use the more modern two-line
> > > solution, with the name on the first line and the genericname on the
> > > second line.
> >
> > Ok, maybe I should have mentioned newlines as yet another workaround.
> >
> > Why is it so hard to acknowledge that if you want to show a piece of
> > text as one unit in the interface, it needs to be presented as one unit
> > to the translators ?
>
> As translator, proofreader and coordinator of translation team, I don't
> agree so much.
>
> First, most translators don't know what they have to do with those "Name
> GenericName" strings. We are forced to explain to new members what those
> translatable messages are and how should be translated.
>
> Second, some languages, such as French or Italian, don't follow the same
> layout. "Name GenericName" could sound like a grammar error in Italian,
> so we have to switch the order to "GenericName Name"[1]. This is a task
> that we have to manually perform and check, and we can't ensure that all
> translations will follow this rule, at least not for applications
> outside git.gnome.org (yes, some "amateur" translators strictly follow
> English rules in Italian...)
>
> So, as GNOME translator and coordinator, I could really appreciate a
> single "%1$s %2$s" translatable message in glib or gnome-menus to choose
> the default order and layout for Name and GenericName, once and for all.
> The (localized) FullName label could be programmatically composed,
> trusting that all labels will appear the same.
>
> But I agree that i18n/l10n is a crazy stuff, so a hardcoded FullName
> translatable string could be needed. For example, if you have
>
>   Name=Epiphany
>   GenericName=Web Browser
>   Name[it]=Epiphany
>   GenericName[it]=Web browser
>
> and you programmatically compose them using Name + GenericName, you'll
> have
>
>   [it] -> Epiphany Web browser
>
> This is an error in Italian language, it should be "Epiphany web
> browser" (see the case of Web/web). This is just a fictional example,
> just to show that the programmaticall approach couldn't be good for some
> languages (I repeat, some language, and it's just a personal
> hypothesis).

That's an error on how you use Name and GenericName, nowhere in the
speficication says you can team them up to get a meaningful string.

But adding FullName to solve that is not a good idea either, Name is already
FullName.

Fix your software instead of breaking the specification.

Albert
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Emilio Pozuelo Monfort]

Albert Astals Cid wrote:
> But adding FullName to solve that is not a good idea either, Name is already
> FullName.

No, it's not. In the above example, Name would be Epiphany, and GenericName
would be Web Browser. FullName would be Epiphany Web Browser. So Name != FullName.

Emilio



_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Luca Ferretti]

2009/8/2 Albert Astals Cid <aacid@...>:

>>
>> This is an error in Italian language, it should be "Epiphany web
>> browser" (see the case of Web/web). This is just a fictional example,
>> just to show that the programmaticall approach couldn't be good for some
>> languages (I repeat, some language, and it's just a personal
>> hypothesis).
>
> That's an error on how you use Name and GenericName, nowhere in the
> speficication says you can team them up to get a meaningful string.
>
> But adding FullName to solve that is not a good idea either, Name is already
> FullName.
>
> Fix your software instead of breaking the specification.

_MY_ sofware??? How _I_ use Name and GenericName??

As I said I'm only a translator: someone asked feedback for i18n/l10n
so here I'm to report my experience on current labels in GNOME sofware
and to expose what could be good or useful to have.

And it was a _fictional_ example, using existing application name. If
you preferr, assuming

 Name=Dolphin
 GenericName=File Manager
 Name[it]=Dolphin
 GenericName[it]=Gestore file

in Italian language a raw "Dolphin Gestore file" is wrong (not ugly, wrong).

It should be "Gestore file Dolphin" or "Dolphin - Gestore file", but
you need to provide msgid "%1$s %2$s" as esplained before for
programmatical approach, or "Dolphin gestore file" (this is not wrong,
but really ugly), but you need to add FullName key.

Now, what about other languages? I suppose this is the point. How many
languages _really_ need FullName? How many languages are fine with
programmatical apporach (with/without positional msgid)?
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Luca Ferretti]

2009/8/2 Nicolas Mailhot <nicolas.mailhot@...>:
> The
> programmatical approach is an English-only approach that only works
> because English is a very simple language that lets you collate words
> without changes in pretty much any order and get valid sentences
> nevertheless.

Chauvinist!!! :D
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Albert Astals Cid-2]

A Diumenge, 2 d'agost de 2009, Luca Ferretti va escriure:

> 2009/8/2 Albert Astals Cid <aacid@...>:
> >> This is an error in Italian language, it should be "Epiphany web
> >> browser" (see the case of Web/web). This is just a fictional example,
> >> just to show that the programmaticall approach couldn't be good for some
> >> languages (I repeat, some language, and it's just a personal
> >> hypothesis).
> >
> > That's an error on how you use Name and GenericName, nowhere in the
> > speficication says you can team them up to get a meaningful string.
> >
> > But adding FullName to solve that is not a good idea either, Name is
> > already FullName.
> >
> > Fix your software instead of breaking the specification.
>
> _MY_ sofware??? How _I_ use Name and GenericName??

Calm down dude, your as in plural others, not as in singlular you. Put a
"their" there if you like it more.

> As I said I'm only a translator: someone asked feedback for i18n/l10n
> so here I'm to report my experience on current labels in GNOME sofware
> and to expose what could be good or useful to have.
>
> And it was a _fictional_ example, using existing application name. If
> you preferr, assuming
>
>  Name=Dolphin
>  GenericName=File Manager
>  Name[it]=Dolphin
>  GenericName[it]=Gestore file
>
> in Italian language a raw "Dolphin Gestore file" is wrong (not ugly,
> wrong).

As i said, the problem is that trying to use the two keys to create a third
one is wrong and software that does that should be fixed not to.

> It should be "Gestore file Dolphin" or "Dolphin - Gestore file", but
> you need to provide msgid "%1$s %2$s" as esplained before for
> programmatical approach, or "Dolphin gestore file" (this is not wrong,
> but really ugly), but you need to add FullName key.
>
> Now, what about other languages? I suppose this is the point. How many
> languages _really_ need FullName? How many languages are fine with
> programmatical apporach (with/without positional msgid)?

No, the question is not if Name and GenericName can be used to form a new
entity, the obvious answer to that is no, you can't, and whoever is doing that
needs to stop doing it.

The question is, do we REALLY need a new key? What's the use case? Menus only?
If it's menus, can't we just work out our menus better like for example KDE
KickOff does[1] to avoid making translators have even more work than the one
they have?

Albert

[1] http://gambitchess.org/wordpress/wp-content/uploads/2009/03/kfav.png
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Nicolas Mailhot]

Le dimanche 02 août 2009 à 18:48 +0200, Luca Ferretti a écrit :
> 2009/8/2 Nicolas Mailhot <nicolas.mailhot@...>:
> > The
> > programmatical approach is an English-only approach that only works
> > because English is a very simple language that lets you collate words
> > without changes in pretty much any order and get valid sentences
> > nevertheless.
>
> Chauvinist!!! :D

Well, it's true, that's one of the peculiarities of the English
language. It made early American computer science easy but it also makes
it a very poor choice to base i18n decisions on.

--
Nicolas Mailhot


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Luca Ferretti]

2009/8/2 Albert Astals Cid <aacid@...>:
>
> As i said, the problem is that trying to use the two keys to create a third
> one is wrong and software that does that should be fixed not to.

[cut]

> The question is, do we REALLY need a new key? What's the use case? Menus only?
> If it's menus, can't we just work out our menus better like for example KDE
> KickOff does[1] to avoid making translators have even more work than the one
> they have?

The use case (i.e. the need to expose in the UI Name+GenericName) that
come in my mind is File -> Open with $Application in file manager (and
any other method to "link" file type and application). I suppose the
KickOff approach is inapplicable here.

Let me assume that both KDE and GNOME are installed, choosing to use
only Name, we'll have (html file, for example)

  Open with Firefox
  Open with Konqueror
  Open with Gedit
  Open with Kwrite
  Open with Emacs
  Open with OpenOffice.org Writer

This way doesn't explain what the application does, users have to know
this in advance.

Choosing to use only GenericName

  Open with Web Browser
  Open with Web Browser
  Open with Text Editor
  Open with Text Editor
  Open with Text Editor
  Open with Word Processor

Icons are needed to differentiate applications,  and users will have
to associate application icon and name (really really really bad for
visually impaired people)

The third solution is use FullName

  Open with Firefox Web Browser
  Open with Konqueror Web Browser
  Open with Emacs Text Editor
  Open with Kwrite Text Editor
  Open with Gedit Text Editor
  Open with OpenOffice.org Writer Word Processor [1]

or programmatically collate Name and GenericName

  Open with Web Browser (Firefox)
  Open with Web Browser (Konqueror)
  Open with Text Editor (Kwrite)
  Open with Text Editor (Emacs)
  Open with Text Editor (Gedit)
  Open with Word Processor (OpenOffice.org Writer)

Any other use case?

[1] so long, I know :(
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Jannis Pohlmann-3]

On Sun, 2 Aug 2009 20:40:25 +0200
Luca Ferretti <elle.uca@...> wrote:

> 2009/8/2 Albert Astals Cid <aacid@...>:
> >
> > As i said, the problem is that trying to use the two keys to create
> > a third one is wrong and software that does that should be fixed
> > not to.
>
> [cut]
>
> > The question is, do we REALLY need a new key? What's the use case?
> > Menus only? If it's menus, can't we just work out our menus better
> > like for example KDE KickOff does[1] to avoid making translators
> > have even more work than the one they have?
>
> The use case (i.e. the need to expose in the UI Name+GenericName) that
> come in my mind is File -> Open with $Application in file manager (and
> any other method to "link" file type and application). I suppose the
> KickOff approach is inapplicable here.
>
> Let me assume that both KDE and GNOME are installed, choosing to use
> only Name, we'll have (html file, for example)
>
>   Open with Firefox
>   Open with Konqueror
>   Open with Gedit
>   Open with Kwrite
>   Open with Emacs
>   Open with OpenOffice.org Writer
>
> This way doesn't explain what the application does, users have to know
> this in advance.
>
> Choosing to use only GenericName
>
>   Open with Web Browser
>   Open with Web Browser
>   Open with Text Editor
>   Open with Text Editor
>   Open with Text Editor
>   Open with Word Processor
>
> Icons are needed to differentiate applications,  and users will have
> to associate application icon and name (really really really bad for
> visually impaired people)
>
> The third solution is use FullName
>
>   Open with Firefox Web Browser
>   Open with Konqueror Web Browser
>   Open with Emacs Text Editor
>   Open with Kwrite Text Editor
>   Open with Gedit Text Editor
>   Open with OpenOffice.org Writer Word Processor [1]

Well, according to the GNOME HIG, applications are supposed to have
their Name set to e.g. "Epiphany Web Browser" or "Nautilus File
Manager" [1]. (It doesn't explicitely say that, but if you want
"Epiphany Web Browser" to be displayed in menus, setting Name to this is
the only way. Obviously concatenating Name and GenericName doesn't make
any sense at all).

I haven't been following the discussion in every detail, but I'm quite
confused about the intent of the original FullName proposal. Is it
really that desireable to split application entries in menus into two
lines (with Name in the first and GenericName in the second)? I mean,
it uses more vertical space (of which e.g. netbooks don't have too
much) and it doesn't provide more information than using Name the way
the GNOME HIG recommends. Is it really worth breaking so many
applications by adding FullName and changing the meaning of Name?

If anything is to be added to the spec, I think something like
ShortName (e.g. ShortName=Epiphany, Name=Epiphany Web Browser,
GenericName=Web Browser) would make more sense than to change the
meaning of Name. That way we'd at least maintain backwards
compatibility (by not changing the meaning of Name). But I'm not sure
this is really needed.

  - Jannis

[1] http://library.gnome.org/devel/hig-book/stable/desktop-application-menu.html.en#menu-item-names


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Luca Ferretti]

2009/8/2 Jannis Pohlmann <jannis@...>:
> Is it really worth breaking so many
> applications by adding FullName and changing the meaning of Name?

Well, the meaning of Name, as per Desktop Entry Spec is

   Specific name of the application, for example "Mozilla".

while GenericName is

   Generic name of the application, for example "Web Browser".

The GNOME habit to use "Mozilla Web Browser" as Name was/is wrong, at
lease debatable.
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

Jannis Pohlmann wrote:


> Well, according to the GNOME HIG, applications are supposed to have
> their Name set to e.g. "Epiphany Web Browser" or "Nautilus File
> Manager" [1]. (It doesn't explicitely say that, but if you want
> "Epiphany Web Browser" to be displayed in menus, setting Name to this is
> the only way.

Isn't that more because GNOME doesn't support GenericName at all?  (I'd love
to be wrong)

-- Rex


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Matthias Clasen]

On Sun, 2009-08-02 at 16:48 -0500, Rex Dieter wrote:

> Jannis Pohlmann wrote:
>
>
> > Well, according to the GNOME HIG, applications are supposed to have
> > their Name set to e.g. "Epiphany Web Browser" or "Nautilus File
> > Manager" [1]. (It doesn't explicitely say that, but if you want
> > "Epiphany Web Browser" to be displayed in menus, setting Name to this is
> > the only way.
>
> Isn't that more because GNOME doesn't support GenericName at all?  (I'd love
> to be wrong)

Not sure what you mean with 'supporting GenericName', but the current
GNOME HIG recommendations are the way they are precisely because of the
translatability concerns of combining Name and GenericName
programatically. GNOME decided to (mis)use the Name field to have the
same meaning that the newly proposed FullName field would have.

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

On 08/02/2009 05:26 PM, Matthias Clasen wrote:

> On Sun, 2009-08-02 at 16:48 -0500, Rex Dieter wrote:
>> Jannis Pohlmann wrote:
>>
>>
>>> Well, according to the GNOME HIG, applications are supposed to have
>>> their Name set to e.g. "Epiphany Web Browser" or "Nautilus File
>>> Manager" [1]. (It doesn't explicitely say that, but if you want
>>> "Epiphany Web Browser" to be displayed in menus, setting Name to this is
>>> the only way.
>>
>> Isn't that more because GNOME doesn't support GenericName at all?  (I'd love
>> to be wrong)
>
> Not sure what you mean with 'supporting GenericName',

supporting GenericName as in by providing it in .desktop files and using
it's value accordingly.

-- Rex
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[John Tapsell-3]

> Not sure what you mean with 'supporting GenericName', but the current
> GNOME HIG recommendations are the way they are precisely because of the
> translatability concerns of combining Name and GenericName
> programatically.

Could someone give an example where programmatically combining would
fail, if the combining was done as  i18n("%1 %2")  or even i18n("%1 -
%2")  ?
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Patryk Zawadzki]

On Sun, Aug 2, 2009 at 8:40 PM, Luca Ferretti<elle.uca@...> wrote:

> Let me assume that both KDE and GNOME are installed, choosing to use
> only Name, we'll have (html file, for example)
>
>  Open with Firefox
>  Open with Konqueror
>  Open with Gedit
>  Open with Kwrite
>  Open with Emacs
>  Open with OpenOffice.org Writer
>
> This way doesn't explain what the application does, users have to know
> this in advance.
>
> Choosing to use only GenericName
>
>  Open with Web Browser
>  Open with Web Browser
>  Open with Text Editor
>  Open with Text Editor
>  Open with Text Editor
>  Open with Word Processor

That's not really point of the discussion but I believe we should be
aiming at something closer to:

View in web browser (Epiphany)
View in web browser (Firefox)
Edit in text editor

...where actions have meaningful names and you only see the app name
when there's more than one candidate.

--
Patryk Zawadzki
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Colin Walters]

2009/8/2 Nicolas Mailhot <nicolas.mailhot@...>:

> Le dimanche 02 août 2009 à 18:48 +0200, Luca Ferretti a écrit :
>> 2009/8/2 Nicolas Mailhot <nicolas.mailhot@...>:
>> > The
>> > programmatical approach is an English-only approach that only works
>> > because English is a very simple language that lets you collate words
>> > without changes in pretty much any order and get valid sentences
>> > nevertheless.
>>
>> Chauvinist!!! :D
>
> Well, it's true, that's one of the peculiarities of the English
> language. It made early American computer science easy but it also makes
> it a very poor choice to base i18n decisions on.

Nicolas, if the GNOME panel was adapted for a multi-line approach as
Albert suggested, do you think that would work in most locales?
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Colin Walters]

On Sun, Aug 2, 2009 at 8:26 PM, Jannis Pohlmann<jannis@...> wrote:
>
> If anything is to be added to the spec, I think something like
> ShortName (e.g. ShortName=Epiphany, Name=Epiphany Web Browser,
> GenericName=Web Browser) would make more sense than to change the
> meaning of Name. That way we'd at least maintain backwards
> compatibility (by not changing the meaning of Name). But I'm not sure
> this is really needed.

I think you may be right here; backwards compatibility is important,
and while we could debate forever whether GNOME's <= 2.26 decision to
set Name="FullName" was right, the result of that discussion doesn't
change the fact that it shipped and is widely used.

If we change the Name field now, concretely it will be a huge pain for
application writers because if their app is used on older GNOME
releases it will fail.

Concretely what I suggest is this:

o GNOME 2.28 panel is adapted to have multiple lines (default
GenericName/Name?  Dunno...my take would be Name/GenericName in North
America given that most Name is only meaningful in English, reverse
outside)
o If writing a *new* .desktop file, and you don't care a lot about
older OSes, set Name=Epiphany, GenericName=Web Browser
o If writing a new .desktop file, and you DO care, well...kind of a mess =/
o For an existing .desktop file which has Name=Epiphany Web Browser,
add a new entry ShortName=Epiphany  (maybe we call it AppName?)
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Shaun McCance-2]

On Mon, 2009-08-03 at 09:41 +0300, John Tapsell wrote:
> > Not sure what you mean with 'supporting GenericName', but the current
> > GNOME HIG recommendations are the way they are precisely because of the
> > translatability concerns of combining Name and GenericName
> > programatically.
>
> Could someone give an example where programmatically combining would
> fail, if the combining was done as  i18n("%1 %2")  or even i18n("%1 -
> %2")  ?

In languages that have case declensions, "%1 %2" and "%1 - %2"
could involve the GenericName being written differently.  So
you might write "Epiphany - Web Browser", but "Epiphany Webo
Browsero".  (Completely made up example, of course.)

You can't reliably translate GenericName to fit into one or
the other, because different implementations might decide to
display things differently.

--
Shaun


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Nicolas Mailhot]

Le lundi 03 août 2009 à 13:32 +0000, Colin Walters a écrit :

> 2009/8/2 Nicolas Mailhot <nicolas.mailhot@...>:
> > Le dimanche 02 août 2009 à 18:48 +0200, Luca Ferretti a écrit :
> >> 2009/8/2 Nicolas Mailhot <nicolas.mailhot@...>:
> >> > The
> >> > programmatical approach is an English-only approach that only works
> >> > because English is a very simple language that lets you collate words
> >> > without changes in pretty much any order and get valid sentences
> >> > nevertheless.
> >>
> >> Chauvinist!!! :D
> >
> > Well, it's true, that's one of the peculiarities of the English
> > language. It made early American computer science easy but it also makes
> > it a very poor choice to base i18n decisions on.
>
> Nicolas, if the GNOME panel was adapted for a multi-line approach as
> Albert suggested, do you think that would work in most locales?

That's one possibility. Don't really know how well it would work in
menus though, and trying to concatenate the two lines as I'm sure
someone will try to will result in the usual i18n disaster.

Anyway, the main requirement for i18n is to stop playing games and
"saving" translator time by composing keys to generate other keys. If
you want to display a sentence put the sentence as-is as a translatable
resource and let translators take care of translating.

--
Nicolas Mailhot


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg