Re: Menu system rewrite update (Aug 6 2002)
On Aug 09, Denis Barbier wrote:
> I disagree with you when you say "it's up to logic to decide whether
> translating particular entries should be done or not", because it
> prevents accurate automatically generated stats.
> Consider a .desktop file in which maintainer adds a non-standard
> translatable entry. There is few chance translators catch it if
> this file is already marked 100% translated. OTOH if Mozilla's
> maintainer refuses to include
> in order to save lots of space, mozilla.desktop will never reach
> 100% and translators will submit patches. If you think I am
> paranoid, have a look at http://people.debian.org/~branden/#debconf ;)
> There is nothing personal here against Branden, the problem is that
> Debconf does not provide a machinery similar to the
> X-Debian-LozalizedFields I would like to see adopted.
Someone is going to have to explain to me the actual value of
X-Debian-LocalizedFields; your examples don't mean anything to me.
What is a "non-standard localized entry"? All fields that are
localestring (defined in the specifications) are fair game for
translation; all fields that aren't localestring aren't (in general).
For example, I suppose you could localize Exec, but I'm not entirely
sure what that would accomplish - particularly since Exec must be in
ASCII, so you couldn't use a UTF-8 filename or arguments. I suppose
you could run something different for each locale, but really the
application should use $LANG instead.
Furthermore, I'm leery of adding lots of Debian-specific stuff to
.desktop files. If this is something that is actually important for
translation in general, the place to take it up is the XDG working
group; however, KDE and GNOME seem (IMO) to take translation
seriously, and they have not proposed such a header, so it appears
they manage very well without it.
Chris Lawrence <email@example.com> - http://www.lordsutch.com/chris/
Computer Systems Manager, Physics and Astronomy, Univ. of Mississippi
125B Lewis Hall - 662-915-5765