Re: I18n of Packages files
On Wed, Sep 20, 2000 at 11:52:59AM +0200, Marcin Owsiany wrote:
> On Wed, Sep 20, 2000 at 10:06:15AM +0200, Peter Makholm wrote:
> >
> > Their suggestion (they all rpm-users in some way) was to based package
> > localization om gettext. Im not sure I see the actual bennefits of it
> > when we're talking translating files and not just lines of output from
> > an ordinary program.
>
> Do you mean that they wanted to make po files for, let's say, dpkg that
> would contain descriptions from 'Packages' files?
The benefit of using gettext is the ability to check easily when
translations are out of date. That is, *what* was really translated. The way
gettext works, you could have a po distributed along Debian's dpkg (call it
a dpkg-LANG package , with LANG being the given language) that would include
translations for packages), or you could distribute a translated Package's
file clearly marking what they were translation.
This would benefit the translators (they know when to update them),
the users (they are only shown the newest translation if available) and
developers (they can easily reuse translations if, for example, they are
breaking packages or changing names since they know the exact translation of
a given string to another language).
>
> > 1. What is the goal?
> >
> > Should every package description be translated or is it enough that
> > the base system is translated and language dependend packages (like
> > dictionaries).
> >
> > (I think that RedHat only ``supports'' a language if the distribution
> > is fully translated into a language (installer and
> > package-descriptions).)
>
> I guess the best way is to create the necessary infrastructure, ie. support
> in dpkg etc. for the translated fields, that would allow fallback to
> original Description: if description for the chosen language for the
> particular package didn't exist.
or if the translation was out of date.
BTW we should not only be talking about dpkg here, we should be talking
about any frontends using dpkg, and other of Debian tools, for example dwww.
>
> This would allow translators to translate the descriptions of the packages
> they find most important (they'll probably begin with base packages, anyway
> :-)).
>
> I don't think delaying the support for a language until it is complete is
> sane. Translations will always lag behind the originals, especially when you
> rely on volunteers. Maybe in RH it is different, it is a company, not an
> organization, after all.
RH is none different. They have somethings internationalised.
As far as I know, RH's rpm structure allows for XXX-LANG tags which
are used if available.
There's a thing I would not like to see in Debian but, hopefully,
due to the way Debian works (i.e. easily accepting contributions from
outsiders) would rarely happen. I've seen about four spanish distributions
of RedHat (Eurielec Linux, Esware, Hispafuentes, and official RH) which have
all made, without cooperation, the work of translating packages description
(i.e. you might have four different translations of the same description).
>
> > 2. What kind of infrastrucktur is the optimal?
> >
> > Should translations be made on package time or could thay be included
> > in the distribution in some other way?
>
> I translated a few Debian-specific packages, and personally have never had
> problems with maintainers accepting it. (Quite the opposite, in fact :-)
>
> The Descriptions don't change very often, and if including of translations
> will look like I described it (ie. copy one file to your packages 'debian'
> directory), then I don't think we need any special way to include the
> translations.
>
> regards
> Marcin
>
I agree with you here. But we need some way for users that do *not*
want translations of some languages, not be hindered by them. This problem
currently exists with the packages in the way they include gettextized
information, you might not want other languages besides, for example,
english and spanish, but you have to have disk to install them all.
Regards
Javi
Reply to: