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

Re: I18n of Packages files



On Thu, 21 Sep 2000, Marcin Owsiany wrote:

> Hmm... this is getting complicated... I guess that only setting the locale
> is not enough to let dpkg know what it should display. Let's summarize what
> we want:
> 
>  * Ussuming user has her usual locale environment set to her national
>    language.
> 
> 	- when she uses dpkg in a usual, direct way (starts it from shell),
> 	  she wants to see BOTH the fields names and the description
> 	  translated.
> 
> 	- when she uses dpkg in an indirect way, i.e. uses some higher-level
> 	  package management tool, which in turn uses dpkg, she wants to see
> 	  the Description translated, but the program has to see the fields'
> 	  names printed by dpkg in "C" locale.
> 
> 		  In this situation, if the program sets locale to C before
> 		  invoking dpkg, the user would get the description in
> 		  english, which is probably not what she wants
> 
> 
>  * Thus there are two ways:
> 
> 1) The higher-level program translates the fields' names as well as chooses
> the description in proper language _on its own_. 

  [ ... ]

> 2) Do what Piotr suggested, namely provide some additional switch(es) in
> dpkg. I suggest using another switch, though (see below). This should be
> done in such way, that
> 
>  - invoking 'LANG=C dpkg -s hello' produces fields' names as well as
>    description in English.
> 
>  - invoking 'LANG=pl_PL dpkg -s' hello produces fields' names as well as
>    description in Polish.
> 
>  - invoking 'LANG=pl_PL dpkg --standard-field-names -s hello' produces
>    fields' names in English, but description in Polish.
> 
> Then every program that parses dpkg's output should invoke it with
> "--standard-fields-names", and would get field names in format acceptable
> for parsing and description acceptable for the user. (Of course the program
> in question should display gettextized fields names :-))

Er, supporting your parenthetical requirement would be burdensome.
Each higher-level tool must then know all the fieldname translations.
 
> Comments?

There is a third way.

As you explained above, there are two clients for the output of dpkg:
humans and other programs.  The humans always prefer to see *both* field
names and field values in their native language, regardless of whether
they invoke dpkg directly or indirectly.  Other programs, of course, may
need to parse constant fieldnames.

Having dpkg output only one fieldname is *never* going to satisfy both
customers.  You need to produce *both* a machine-readable fieldname, *and*
a human readable one.

One option is to borrow the trick from telnet/ftp/smtp protocols, and
output a numeric code before the fieldname, e.g.

	01-Package:
or	01-Pakiet:

-S





Reply to: