On Thu, 21 Sep 2000, Marcin Owsiany wrote:
> On Thu, Sep 21, 2000 at 11:55:08AM -0400, Steve Robbins wrote:
> > On Thu, 21 Sep 2000, Marcin Owsiany wrote:
> > > 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.
Yes. But when you said
Of course the program in question should display gettextized
fields names :-)
I took this to mean that the higher-level tool should display the
translated field names to the user. Invoking 'dpkg --standard-field-names'
gives only the English version, so how would you display the translations
other than having them known to the high level tool?
-S
