[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debian-devel:12897] Bcc: Re: I18n of Packages files



--- Begin Message ---
Hi.

In <20000921005928.B14642@xxxxxxxxxxxxxxxxxxxxxx>,
  on Thu, 21 Sep 2000 00:59:29 +0200,
    on Re: I18n of Packages files,
 Marcin Owsiany <porridge@xxxxxxxxxxxxxxxxxxxxxxx> 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 <20000919204950.C5086@xxxxxxxxxxxxxxxxxxxxxx>,
  on Tue, 19 Sep 2000 20:49:50 +0200,
    on I18n of Packages files,
 Marcin Owsiany <porridge@xxxxxxxxxxxxxxxxxxxxxxx> 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: <kgh12351@xxxxxxxxxxx>


--- End Message ---