Re: I18n of Packages files
On Fri, Sep 22, 2000 at 05:55:29PM +0200, Javier Fdz-Sanguino Pen~a wrote:
> 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.
That way you would have to install this dpkg-LANG package before you use
e.g. dselect for the first time. This would be doable with what the -boot
team plans for woody (no base system tarball, debs unpacked to a fresh
filesystem).
On the other side, in the setup I proposed, there also is an easy way to
show the description when it is up to date: dpkg-deb should include the
particular translation if it is up-to-date.
However with the solution based on gettext, _every_ change to the English
Description the translation would be hidden. I guess the most common changes
in Descriptions are only typo fixes or wording changes. IMNSHO the
translation should _not_ be hidden if only such minor changes are made. It
is very important for the user to just get the idea what the package does,
even if the translation of the description slightly differs from what it
should be like.
In the setup I proposed, it would also be trivial to create a tool to let
translators know of any change of Descriptions - for example a perl script
to parse the current and old Packages* files and report changes.
> This would benefit the translators (they know when to update them),
This is also doable in the setup I proposed
> the users (they are only shown the newest translation if available)
This is not good in fact, as I suggested above
> 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).
What do you mean? Isn't that possible with what I suggested?
> 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.
As long as people use dpkg directly, it should be fully i18n-ed.
> > 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.
> >
> 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.
It would be easy for packages' descriptions - package management tools will
download only these language-specific Packages* files the user wants.
regards
Marcin
--
+--------------------------------+ The reason we come up with new versions
|Marcin Owsiany | is not to fix bugs. It's the stupidest
|porridge@pandora.info.bielsko.pl| reason to buy a new version
+--------------------------------+ I ever heard. - Bill Gates
Reply to: