[root@rocky8 ~]# dnf repoquery -l thunderbird | grep -i fr
Last metadata expiration check: 3:08:24 ago on Tue 11 Oct 2022 14:01:39 CEST.
is there perhaps a setting you need to go into in Thunderbird to manually change it. Just curious if it’s because of this rather than an auto-detect thing.
I know Firefox did have issues, for example, when the language list had English in first place, and then other languages lower down, so not sure if French is appearing below these in Thunderbird, and just needs bumping up to first place perhaps?
I just checked Thunderbird on Rocky9, so in Settings there is a Languages section where languages can be chosen. Does only English appear here, or can you select French?
I just checked. So my desktop running Rocky Linux 8 with KDE has quite a lot of apps. All show up in french according to my main system locale. Only thunderbird fires up in english. And when I go to the settings section in Thunderbird, I only get to choose english. So this is clearly a bug in the package.
For the record, I’ve been using RHEL clones since CentOS 4.x and this kind of thing (e. g. localizations having to be potty-trained from scratch in Firefox and/or Thunderbird) happened from time to time.
Not a big deal when you’re the only user on a system. Very annoying - if not a showstopper - if you have more than 100 users (as is my case here).
What now ?
PS : I just checked some more. In the default configuration, Thunderbird language packs all seem to be present, but they’re all greyed out and marked as “disabled”, and there seems to be no way to enable them. Which leaves me clueless.
If you add the language manually, it works. If you are expecting it to automatically find the language, and if you find that you can also replicate in RHEL, then the correct place would be to raise the bug with Red Hat on their bugzilla. If however, it only occurs in Rocky, then it would be a bug for Rocky to address.
You can add the language in seconds, set it as the first language, or even remove English altogether, and the problem is gone. This is like 10 - 30 seconds. Otherwise, it would require testing RHEL8 installation to see if the problem occurs or not, and if not, then it would also require making a Rocky 8 install with the default Gnome Desktop (not KDE) to see also if the problem occurs or not (since RHEL does not have KDE). That then works out about an additional 1 hour minimum to make two desktops as identical as possible with Thunderbird installed.
Does Thunderbird also auto-detect languages on other systems like Fedora/CentOS Stream? If fixed upstream then at some point it should trickle down into RHEL and then Rocky, etc.
The greyed out thing isn’t related to it though. This is because they are installed with the package. If you install addons manually yourself, then they are options that you can then remove etc. The same if you download Firefox/Thunderbird manually from Mozilla, and then add the languages as addons. Then they are removable.
If the language was disabled, you wouldn’t be able to add it in the interface as I showed in my screenshots. The problem is that if no Thunderbird profile exists, and the initial one is being created (when running Thunderbird for the first time), it should be choosing the language based on the system locale rather than defaulting to English.
I’ve been using Thunderbird since the first 0.99alpha version back in 2003. I’ve also packaged it for my personal Slackware-based distribution back then. And I’m regularly setting it up in schools, town halls, public libraries, etc. So you can trust me when I say this is a bug.
When no profile exists, the setup dialogue is displayed. Well, normally this dialogue should show up in french on a french system. Only this time it doesn’t. Setup dialogue is in english, and when the profile is created, the interface still shows up in english.
On a side note: I’m the guy doing all the french translations for the Linux Professional Institute, and I’ve noticed more than once that english-speaking people have a hard time acknowledging missing translations as a problem and/or bug. Check out my bug report for detailed information on why it is a bug and how to reproduce it.
Yeah, I’m not disagreeing with you, what I was saying is the addons section is a red-herring, they are disabled to stop you removing them because they are part of the Thunderbird package.
This is what I hinted at in my last message here, that the problem is relating to auto-detection of language based on system locale.
Not saying I’m not ackowledging it, I’m trying to clarify where it exactly lies, and it’s not the addons being greyed out (as explained earlier part of the package and so not removable for a reason). Especially since you can manually select the languages and add them. If they had been disabled, then it wouldn’t be possible to add the languages manually.
Did you test running RHEL8 to see if the problem exists there? Because whilst opening a Rocky bug is fine, if the problem is upstream, eg: RHEL, then the bug would need to be fixed in RHEL. Otherwise it means fixing it again and again when the sources are pulled from Red Hat. But I’m sure the Rocky team will check/verify that anyway.
You’ll also find a difference with the package, than compared to Debian. Eg:, Rocky has one single package for Thunderbird which includes all the translations (as shown from the dnf command in my first post).
Debian, has multiple packages, the main thunderbird package, and also thunderbird-l10n-xx where xx is language, eg thunderbird-l10n-fr for French. Thus, in Debian, you only see the languages that you installed with Thunderbird, and again, they are greyed out as you cannot remove them via Thunderbird interface - you have to remove the package that was installed.
Enabling the ability to remove languages from Thunderbird when they were installed via apt/yum/dnf or whatever would be silly.
When I type LANG=fr_FR.UTF-8 thunderbird on an up-to-date RL 8.6, Thunderbird’s assistant greats me in French. Just for the fun of it, I’ve also tried with LANG=zh_CN.UTF-8. Looks all Chinese to me. So maybe the problem is on your end, not with the package.
sorry for being late to the show and if this is of no help, but… I had similar problems in the past (wrong language “detection”) when I erratically installed from SNAP or FLATHUB (either of them, can’t remember) instead of from a “native” repository.
However, that was back in the Fedora (or was it PopOS?) days of mine and it also might have been a temporarily issue with the provided packages but anyway, probably worth checking out if this is a factor to be considered in your case.
Again, sorry if that is of no help. Cheers, Thomas