[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:

> 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





Reply to: