Closed dkosovic closed 4 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?
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:
[CGI] lang=\"en_US.UTF8\", locale=\"/en_US\"...
[CGI] lang=\"en_GB.UTF8\", locale=\"/en_GB\"...
[CGI] lang=\"en_AU.UTF8\", locale=\"/en_AU\"...
In the Chromium Preferred Languages settings, the Chromium default on (Australian English) Ubuntu and Fedora is:
I can manually add "English (Australian)" to the preferred languages after which it shows the CUPS language translations for the PPD.
Basically the same as Chromium, i.e. :
On (Australian English) Ubuntu 22.04 and Fedora 38 the Firefox web page languages default is:
On (Australian English) Alma Linux 9 (and presumably RHEL9) the Firefox web page languages default is:
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.
Correctly uses en_AU and shows the CUPS language translations for the PPD.
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 :( .
@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.
@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)?
@zdohnal We check whether a country-specific localization exists and revert to the actual language used ("en" in this case).
@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.
@zdohnal No, libcups is smart enough to fall back on the non-country-specific language identifier.
OK, it sounds like this issue can be closed as resolved. If I am mistaken we can reopen...
Describe the bug The CUPS web interface seems to use
en_US.UTF8
for the language anden_US
for the locale, while thelpadmin
command in my case picks upen_AU
for the language translations in the generated PPD file, resulting in theen_AU
language translations not being used in the CUPS web interface.To Reproduce Steps to reproduce the behavior:
en_AU.UTF-8
) :lpadmin -p everywhere-test -v "ipp://192.168.178.26/ipp/print" -E -m everywhere
Behavior e.g. Generated IPP Everywhere PPD snippet with
en_AU
localeA 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
Translations not working in "Set Default Options" for a IPP Everywhere print queue in the CUPS web interface![translations-broken](https://github.com/OpenPrinting/cups/assets/2002761/36d1f788-8d4a-4bce-8b8c-43fc113bf032)
After applying the aforementioned![translations-working](https://github.com/OpenPrinting/cups/assets/2002761/25fc5623-13fb-4109-88f6-ae708f877fec)
sed
workaround, the translations are working :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. :