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 |[EMAIL PROTECTED]| reason to buy a new version +--------------------------------+ I ever heard. - Bill Gates
