Re: new proposal: Translating Debian packages' descriptions
On Tue, 11 Sep 2001, Martin Quinson wrote:
> On Tue, Sep 04, 2001 at 05:51:38PM -0500, Steve Langasek wrote:
> > Only if the implementation is poor. The accuracy of a translation can be
> > verified in the process of assembling the file that is to be made available to
> > user machines (whether that file is Packages.gz, or debian-descs.mo, or
> > whatever). Obviously the /inputs/ used to create this file must include
> > mappings of English string -> translated string, but these mappings need not
> > be retained in the output file. We only need to make sure once that the
> > translation is up-to-date, not every time the user runs dpkg, because each
> > version of each package can have only one untranslated description associated
> > with it -- it's a unique key, by definition.
> > If nothing else, perhaps you would consider that a .mo file containing
> > [untranslated string -> translation] mappings will on average be almost twice
> > as large as a .mo file containing [(package name,version) -> translation]
> > mappings. :)
> The problem is that you wont have to do a little wheel engineering, but a
> lot of. Think, you will have to design:
> - the extracting tool control -> po file
> ok, that's true for all solutions ;) I'm working on a patch against
> gettext so that it can handle text following rfc822.
As you say, this is common to all solutions.
> - a mechanism to help the translator finding which text have to be
> translated in the po file.
> With your solution, the translator will face something like
> msgid "dpkg-1.9"
> msgstr ""
Not at all. I never suggested that anyone, translator or maintainer, would
directly manipulate a .po file that looks like this. The .po files should
look exactly as you would expect them to. It's only /after/ these .po files
have been submitted to the archive that they would be automatically processed
and matched up with actual packages in the archive, so that the resulting .mo
file (or file in another format) contains only the relevant translations.
> - a mechanism to produce the mo file, or what ever. If you stick to the po
> format, you can reuse msgfmt, through.
So, msgfmt is one option, yes. Other solutions to parse and merge text would
not be difficult to implement.
> - an output mecanism, including the fallback to original if the translation
> is outdated. You have either to rewrite msgfmt to do this job at previous
> step, or design a new function in dpkg, apt, grep-dctrl, and all programm
> using the translated descriptions.
The end-user tools would never have to deal with outdated translations if the
".mo" file is assembled ahead of time in a central location. Match up the
translations, insert them into the distilled .po file using the package
name/version as the key, and you're done.
> If you change any tool of the gettext mechanism, you lost advantages from
> the translator point of view, like compendium, containing standard
> translations for reuse, or user-friendly tools like kbabel for translating,
> (including ispell possibility, which is implemented in kbabel, and some
> others)
I'm not suggesting replacing the format that translators will work with. I'm
just disagreeing that standard .mo files are the best solution to be
integrated into dpkg and apt.
> For what gain ?
> A lookup less ? But gettext is cached, and well optimized. I think the
> change and redesign is too much, regarding to the small speedup you can
> expect...
> Smaller resulting po files ? Come on, the woody+1 release will come on 6 CD
> or more, and you are speaking about saving a few Mb... These data will be
> well compressed, as any natural text, so that a minor problem, in my point
> of view.
More direct lookups. Smaller .po files. Better integration with existing
tools, instead of grafting a new arm onto our existing /var/lib/dpkg
structure.
Steve Langasek
postmodern programmer
Reply to: