Hi. In <[EMAIL PROTECTED]>, on Thu, 21 Sep 2000 00:59:29 +0200, on Re: I18n of Packages files, Marcin Owsiany <[EMAIL PROTECTED]> wrote:
> If dpkg's output is read by some other programs (i.e. is some kind of a > protocol after all), then probably there should be two interfaces - one for > humans, the other for parsing by programs, if Debian really wants proper > i18n. just use with "LANG=C" when invoking from other tools (used as a protocol). If that tool (ex. dpkg) is correctly gettexized, then it will output the "standard" message (in fact, english one) with "LANG=C". For human reading, one can use their locale settings to get the message in their language. Sure, this requires additional work on other tools which use the output of dpkg, but I think it is of worth. Field name is a kind of message from dpkg, so just gettextize dpkg is enough for this purpose. Description is more hard, since there are awfully much packages in Debian. We, Debian JP Project, had been doing the work for translation of description for hamm, and slink. For slink, it may be about more than 60% of descriptions are translated, I suppose (don't know the detail). In <[EMAIL PROTECTED]>, on Tue, 19 Sep 2000 20:49:50 +0200, on I18n of Packages files, Marcin Owsiany <[EMAIL PROTECTED]> wrote: > I suggest the following ($lang means two-letter language code): > > - creating Description-$lang field > > - creating control-$lang, containing only Package and Description-$lang > fields > rationale: > putting several encodings in a single files makes editing harder > some - editor(s) seem to mangle some characters > > - creating Packages-$lang files, containing only Package and > Description-$lang fields > rationale: > - putting all translations into main Packages file would cause it to > grow enormously > - putting all fields to Packages-$lang would cause the fields to be > repeated as many times as many languages there will be, and > inconsistencies if not all packages' descriptions are translated > > - adding support for all this to dpkg, apt etc... > > well, this is just a rough proposal, please comment on it I agree that "putting all translations into one file would cause various problems". At least, it should be in source package for ease of maintaince. Even when we can use unicode (i.e., all langs in one character encoding), it may be easy to maintain one's own langage file to match the main (english) one for translaters, because of the similarity and the order in that file. If many langs are written in one files, the description at the middle of the file is harder to be updated because the translater must find his part before to start his work. If he does the work for many packages (likely, since translators are not so many), then this should not be ignored. -- Taketoshi Sano: <[EMAIL PROTECTED]>