search

OpenPrinting / cups

OpenPrinting CUPS Sources
https://openprinting.github.io/cups
Apache License 2.0
1k stars 178 forks source link

lpadmin IPP Everywhere PPD generation locale issue #793

Closed dkosovic closed 4 months ago

dkosovic commented 11 months ago

Describe the bug The CUPS web interface seems to use en_US.UTF8 for the language and en_US for the locale, while the lpadmin command in my case picks up en_AU for the language translations in the generated PPD file, resulting in the en_AU language translations not being used in the CUPS web interface.

To Reproduce Steps to reproduce the behavior:

  1. Add IPP Everywhere queue on the command-line using lpadmin and use a non-US or non-C locale (in my caseen_AU.UTF-8) : lpadmin -p everywhere-test -v "ipp://192.168.178.26/ipp/print" -E -m everywhere
  2. Go to "Set Default Options" for the print queue in the CUPS web interface.
  3. See that the translations are not being used.

Behavior e.g. Generated IPP Everywhere PPD snippet with en_AU locale

*OpenUI *Duplex: PickOne
*OrderDependency: 10 AnySetup *Duplex
*en_AU.Translation Duplex/2-Sided Printing: ""
*DefaultDuplex: None
*Duplex None: "<</Duplex false>>setpagedevice"
*en_AU.Duplex None/Off (1-Sided): ""
*Duplex DuplexNoTumble: "<</Duplex true/Tumble false>>setpagedevice"
*en_AU.Duplex DuplexNoTumble/Long-Edge (Portrait): ""
*Duplex DuplexTumble: "<</Duplex true/Tumble true>>setpagedevice"
*en_AU.Duplex DuplexTumble/Short-Edge (Landscape): ""
*CloseUI: *Duplex

A workaround for non-US en locales to correct the generated PPDs so translations are shown correctly in the CUPS web interface is to do something like the following: sudo sed -i -e 's/en_AU en/en/' -e 's/en_AU/en/' /etc/cups/ppd/everywhere-test.ppd

Screenshots

System Information:

Additional context Not sure if a correct fix for the PPD generation would be to include the original en translation explicitly in the PPD along with the translation for the locale lpadmin detected, e.g. :

--- original
+++ modified
@@ -1,12 +1,12 @@
-*OpenUI *Duplex: PickOne
+*OpenUI *Duplex/2-Sided Printing: PickOne
 *OrderDependency: 10 AnySetup *Duplex
 *en_AU.Translation Duplex/2-Sided Printing: ""
 *DefaultDuplex: None
-*Duplex None: "<</Duplex false>>setpagedevice"
+*Duplex None/Off (1-Sided): "<</Duplex false>>setpagedevice"
 *en_AU.Duplex None/Off (1-Sided): ""
-*Duplex DuplexNoTumble: "<</Duplex true/Tumble false>>setpagedevice"
+*Duplex DuplexNoTumble/Long-Edge (Portrait): "<</Duplex true/Tumble false>>setpagedevice"
 *en_AU.Duplex DuplexNoTumble/Long-Edge (Portrait): ""
-*Duplex DuplexTumble: "<</Duplex true/Tumble true>>setpagedevice"
+*Duplex DuplexTumble/Short-Edge (Landscape): "<</Duplex true/Tumble true>>setpagedevice"
 *en_AU.Duplex DuplexTumble/Short-Edge (Landscape): ""
 *CloseUI: *Duplex
michaelrsweet commented 11 months ago

Would be useful to get a debug error_log file showing the language the browser is sending - run cupsctl --debug-logging to enable debug logging, and then try loading the web interface.

Also, what browser and OS are you using to access the web interface, and what are its language settings?

dkosovic commented 11 months ago

Looks like the issue is if Australian English is selected for the operating system, it doesn't necessarily mean it will also be set as the preferred language for the web browser.

Depending on the web browser and OS, I was seeing one of the following in the CUPS error log:

Chromium

In the Chromium Preferred Languages settings, the Chromium default on (Australian English) Ubuntu and Fedora is:

  1. English (United Kingdom)
  2. English (United States)
  3. English

I can manually add "English (Australian)" to the preferred languages after which it shows the CUPS language translations for the PPD.

Chrome (Windows and macOS)

Basically the same as Chromium, i.e. :

  1. English (United Kingdom)
  2. English (United States)
  3. English

Firefox

On (Australian English) Ubuntu 22.04 and Fedora 38 the Firefox web page languages default is:

  1. English (United States) [en-us]
  2. English [en]

On (Australian English) Alma Linux 9 (and presumably RHEL9) the Firefox web page languages default is:

  1. English (United Kingdom) [en-gb]
  2. English [en]

Although the Alma Linux 9 Firefox uses en_US until I go to its language settings and it then defaults to en_GB by itself, think that it is a bug.

On the mozilla.org Firefox download page, the following English versions of Firefox are available to download for Windows, macOS and Linux:

With any of the above Firefox versions I can manually add English (Australian) [en-au] after which it shows the CUPS language translations for the PPD.

Safari (macOS)

Correctly uses en_AU and shows the CUPS language translations for the PPD.

zdohnal commented 10 months ago

It looks CUPS web interface uses the settings from the browser environment where it runs, which looks correct to me. lpadmin takes the settings from terminal environment - those two environments can be different, so the results are different too. @dkosovic IIUC you do get the correct result once you set the language in the browser, right? It does not sound as libcups issue to me :( .

dkosovic commented 10 months ago

@zdohnal It seems a bit odd how en_AU is used in the generated PPD instead of en since the CUPS PPD spec states :

  • A generic language translation ("ll") SHOULD be provided with country-specific differences ("ll_CC") provided only as needed

Also, there is a cups_en.po file, but no country specific files like cups_en_AU.po, cups_en_US.po, cups_en_GB.po, etc for English.

I'm happy with continuing to do the following : sudo sed -i -e 's/en_AU en/en/' -e 's/en_AU/en/' /etc/cups/ppd/everywhere-test.ppd

Which is more friendly than a web browser install of the missing en_AU language which is a per user install rather than a system one.

In my previous message I confirmed that I get the correct results when the missing en_AU language is installed in the various browsers.

zdohnal commented 7 months ago

@michaelrsweet "en_AU" gets into PPD via LANG env variable from cupsGetLang() - should we cut the _XY if LANG contains it, since we don't provide any country specific locale, and use the basic one (with exceptions to zh_CN and pt_BR)?

michaelrsweet commented 7 months ago

@zdohnal We check whether a country-specific localization exists and revert to the actual language used ("en" in this case).

zdohnal commented 7 months ago

@michaelrsweet Ok, so the fact is that libcups is able to find the country-specific locale on the machine, but not the browser. Even if we don't have country specific file in our locale dir?

If we can use country specific locales which we don't have locale files in our project, then it sounds as issue of the browser.

michaelrsweet commented 7 months ago

@zdohnal No, libcups is smart enough to fall back on the non-country-specific language identifier.

michaelrsweet commented 4 months ago

OK, it sounds like this issue can be closed as resolved. If I am mistaken we can reopen...