Translations do not work in a multi-language environment with model "everywhere"

[jschwender]

When lpadmin gets called to set up an everywhere printer, it adds translations according to LANG environment variable to the ppd file in the config directory. This translation gets used when the browser requests this specified language (Accept-Language). In a multi-language environment different users with different language settings access the web page. Now, if the browser specifies another language than the one during setup, then the translation works only for the web page content, but not for all the options. As long as PPD files were used by cups, it was possible to install a PPD file with a number of languages. In my location here i always need 4 languages and had PPDs prepared with these. This way, not only the web page was translated in the requested language, but also the options were properly translated. Now, since i use model everywhere, that does not work. In my opinion, this is a bug, or i just don't know hot it works. There should be a way to tell lpadmin to add a number of translations to the PPD that it creates, like for example: -t de,fr,es,it

[michaelrsweet]

We can probably update the PPD generator to load all of the languages that are supported by the printer, which may or may not match up with your needs. Beyond that maybe we can include the installed CUPS languages (the ones that we have localizations for) but the localizations for those will be spotty.

In any case, if applications would just adopt the "new" (10 years old now) CUPS APIs instead of using the old (long deprecated) PPD APIs they could ask for localized versions of any option or value and get the best localization for a given printer... :(

[jschwender]

Sounds like the model everywhere does not use CUPS API, as it creates a PPD? Anyway, currently i workaround the problem by installing each printer with different name for each language, then grep translations out of the created ppd files and attach those to one of them, then i delete the other printers. Works for me, but i think this is not a good concept. IMHO it would be great if lpadmin would load those languages from the printer that are installed on the print server, like the output of "locale -a ".

[michaelrsweet]

@jschwender The CUPS API I am talking about was designed for user-facing applications. The PPD generator is a lower-level bit of code that talks directly to the printer to get its localizations.

As for using the output of "locale -a" (or the equivalent), that is what I was suggesting in addition to the languages that the printer explicitly supports.

[michaelrsweet]

OK, so I added support for adding additional printer-supplied localizations, still need to finish copying them (right now I am just storing the URLs in the PPD)

[michaelrsweet]

Change list (for tracking my development of this feature on the l10n branch):

• [x] Drop _ppdCreateFromIPP2 and update _ppdCreateFromIPP to download all of the printer's strings files and embed the strings in the generated PPD files.
• [x] Update cups-files.conf with a new Languages directive to list the languages/locales that should be extracted; the default is the current/default locale.
• [x] Update cupsd to extract the localization strings from all PPD files and create .strings files for every language the admin is interested in.
• [x] Update cupsd to serve up the strings files under "/strings/FOO.strings"
• [x] Update cupsd to report the corresponding values for "printer-strings-languages-supported" and "printer-strings-uri"