RIP proposal, new proposal (was: RFD: translated description with dpkg)
On Thu, Aug 30, 2001 at 04:37:24PM -0400, Joey Hess wrote:
> Michael Bramer wrote:
> > > I think that splitting mo files out of debian packages and distributing
> > > them seperatly would be insane[3]. I think it would create a level of
> > > confusion and mess that would make me very glad I am a mere mono-lingual
> > > 'merkin.
> >
> > sorry, we proposed:
> > !The ddts can provide po files with all translated packages and build
> > !own deb packages with this file.
> >
> > We propose to make a description-translation-de.deb, a
> > description-translation-ja.deb etc. and you can download it (per ftp,
> > per apt, receive it per mail, ...) and install it. After this you have
> > translated descriptions...
>
> I misunderstood that in your original message. I still have qualms about
> how this is supposed to really work in practice. By introducing this
> special set of packages holding translated descriptions, you effectively
> require those packages to be upgraded *before* a user views package
> descriptinos in dselect or other frontends. Otherwise they will not see
> all the available translations. It doesn't seem technically sound.
Well, you're right, this argument seems to be the real killer of our
proposal.
RIP proposal. What about a new one ? ;)
> > If you will make apt-cache show or apt-cache search or if you will use
> > dselect you need all package description. Now we use the Package file
> > with this. But what is _your_ proposal with translated description?
> >
> > - should we put all translations in the package controll file (with
> > the tag 'Description-XX:'?)
>
> Yes, we certianly should. I think that doing this in conjunction with
> using translated Packages-XX files like you all have set up now (but
> getting the translations for the Packages files out of the debs when the
> Packages files are created, with the possiblity of overrides) is a lot
> cleaner than what you have suggested, and will scale much better.
I think we were wrong, and you are right. Putting the translation somehow in
the control file is a better approach. In my point of view, there is several
possibility:
- put the translation in Description-XX_YY fields and let the maintainer
keep it uptodate.
This seems a bad idea to me since it will be really hard to keep track of
translations accuracy. Translators should be warned when their work gets
outdated, and users should not see outdated translations.
- Centralize the translation work in something like the ddts, and generate
overide files to store them in the final package.
The main point against it is that the maintainer is out of the loop. I
think this can be corrected with notification mails, but I may be wrong.
It can even be on a volunteer basis (ie, a maintainer can register to the
system to not have to worry about translation stuff)
This does not help for external package outside of Debian. They still have
to handle the translation accuracy problem.
- Same as the formal, but instead of overide files, a dh_ like script search
out available translations.
Same problems than the formal, plus the fact it requiers a connexion at
build time. I personnally have a dialup modem at home, and won't like it.
- Put all translations in the package using the gettext family.
1/ The control file of the source package is not modified
2/ We create a po subdir in the debian one
3/ We put all debian specific translation in there (ie package description
for now)
4/ At build time, the control file is enhenced with accurate translations
All package managing tools (and the policy) have to be modified to handle
this new field, but the problem as hard as I first thought.
It does not help the maintainer to delegate the translation work to
specialized teams, or at least making possible for the maintainer to get a
review of native speaker about new translations.
All solution have pros and cons. We may implement all solutions, and leave
the decision of the system to the maintainer, but I think that's a bit
overkill. In fact, the problem is not dpkg specific at all, but applies to
all kind of material, as Joey said. That's why I decided to keep -dpkg in
peace for now, and crosspost to -i18n.
Here are some solutions about special problems I can think about:
- Against the rotting translations in the BTS, let's tag them 'l10n' to help
NMU party when release comes.
- Against the need of developpers getting review of a translation, let's
create some more debian-l10n-XX languages.
http://www.debian.org/intl/l10n/l10n-rank gives some stats about which
languages are represented in Debian regular po files. The top ten (of more
than 100 languages) is: German, French, Spanish, Swedish, Danish, Japanese
Russian, Dutch, Italian, Hungarian.
AFAIK, German, Swedish, Danish and Hungarian have no l10n list. I think
that translators of these (and all other existing one, of course) teams
should get organized.
- To help maintainer delegate the translation work, well, for the moment,
ddts seems ok to me. the dh_ script which retrieves the translation,
coupled with the debian/po directory seems to be the better solution I can
think. But as last days show, it is quite probable I'm wrong ;)
Please keep thinking about ways to enhence the translations of Debian, I
think so sad to see such a technical quality, and so few translations...
Bye, Mt.
Reply to: