Re: I18n of Packages files
On Thu, Sep 21, 2000 at 11:55:08AM -0400, Steve Robbins wrote:
> 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.
What do you mean? What I proposed above allows programs to see _only_ the
plain old English approved field names. The only thing that would change in
such programs is adding the "--standard-fields-names" option to the dpkg
command line.
[...]
> 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.
Why? Can't the program simply specify that it wants to see the standard
English field names?
Marcin
--
+--------------------------------+ The reason we come up with new versions
|Marcin Owsiany | is not to fix bugs. It's the stupidest
|porridge@pandora.info.bielsko.pl| reason to buy a new version
+--------------------------------+ I ever heard. - Bill Gates
Reply to: