Is /usr/share/qgis/i18n/qgis_de.qm available on your system?

I'm not the reporter, but we conversed on discourse. Reproducer (on F39 host in my case, so I wouldn't need all specified arguments):
```
toolbox create ‐‐distro fedora ‐‐release f39 qgis
toolbox enter qgis
sudo dnf install qgis
rpm -ql qgis|grep qgis_de.qm
# /usr/share/qgis/i18n/qgis_de.qm
ls -l $(rpm -ql qgis|grep qgis_de.qm)
# ls: cannot access '/usr/share/qgis/i18n/qgis_de.qm': Datei oder Verzeichnis nicht gefunden
```

Side note: When I first tried to debug this, I looked at the output of `rpm -ql` only and failed to notice the missing files. Interestlingly,

```
rpm --verify qgis
```

reports success.

I have not tried outside the toolbox (because of the ton of dependencies), but this indicates that something is wrong with the packaging, or with the interaction between the package info and the toolbox rpm/dnf. In my case, the host environment is de_DE.UTF-8 already, so there is no LANG switching involved here.

(In reply to Sandro Mani from comment #1)
> Is /usr/share/qgis/i18n/qgis_de.qm available on your system?

no its not, only english here!

Okay my temporary fix (probably very stupid) is just to copy the languages from the broken OpenSuse QGIS to the Fedora one

```
distrobox-enter OpenSuseDistrobox
mkdir ~/QGISlang
sudo cp /usr/share/qgis/i18n/qgis_de.qm ~/QGISlang/
exit
distrobox-enter Fedora39
sudo cp ~/QGISlang/* /usr/share/qgis/i18n/
exit
```

And then in QGIS I need to manually change the language because of something.

So in the Fedora package only the english language is included, in the Opensuse one all languages are there

So, RPM is configured to only installed the desired language packs.  Usually this is configured with /etc/rpm/macros.lang, but the macro could be defined in any rpm macro file.  An example:

%_install_langs   en:en_US:C

I suspect your toolbox image has that defined.  If I change mine to:

%_install_langs   en:en_US:C:de:de_DE

and install qgis I end up with:

$ ls /usr/share/qgis/i18n
qgis_de.qm  qgis_en_US.qm

If this is indeed what is going on, I guess this would be a bug in toolbox.

What OS are your running toolbox on?

Interesting. I didn't know that's how it works, and I find it confusing to have `rpm -ql` differ from what what is installed.

In my case, I am on F39 and have a stock F39 toolbox, and you are right: /etc/rpm/macros.image-language-conf has %_install_langs en_US

So I guess this is yet another pitfall of toolbox:  We drag in the full env, pollute $HOME/.config, but don't even respect $LANG.

More interesting: /etc/rpm/ is empty on my host - so why does the toolbox container come with that setting?

I tried creating the F39 toolbox image on my Rawhide machine.  The only %_install_langs macro I found was:

/usr/lib/rpm/macros:%_install_langs     all

I installed qgis on that and it installed all the lang packs:

$ ls /usr/share/qgis/i18n
qgis_ar.qm  qgis_bs.qm  qgis_da.qm     qgis_es.qm  qgis_fa.qm  qgis_gl.qm  qgis_it.qm  qgis_ky.qm  qgis_nl.qm     qgis_pt_PT.qm  qgis_sc.qm  qgis_tr.qm  qgis_zh-Hans.qm
qgis_az.qm  qgis_ca.qm  qgis_de.qm     qgis_et.qm  qgis_fi.qm  qgis_hu.qm  qgis_ja.qm  qgis_lt.qm  qgis_pl.qm     qgis_ro.qm     qgis_sk.qm  qgis_uk.qm  qgis_zh-Hant.qm
qgis_bg.qm  qgis_cs.qm  qgis_en_US.qm  qgis_eu.qm  qgis_fr.qm  qgis_is.qm  qgis_ko.qm  qgis_nb.qm  qgis_pt_BR.qm  qgis_ru.qm     qgis_sv.qm  qgis_vi.qm

so not sure what is happening on your image, but I suspect something to do with %_install_langs

Thanks a lot for researching this!

So what to do now? If this issue is solved in toolbox, will the toolbox app read it from the host and add it to the containers?

Or is this a preset the images should follow?

I think just installing the needed langpacks makes a lot of sense.

So maybe it's the image. Mine is:

a6a0534168cd  registry.fedoraproject.org/fedora-toolbox:39  4 weeks ago

So I podman-pulled a current one (toolbox does not offer this in cli, bummer) to get:

35f981983e47  registry.fedoraproject.org/fedora-toolbox:39  5 days ago

And indeed, that one does not have any /etc/rpm/macros.image-language-conf.

And of course dnf installs all langpacks there, and qgis uses them.

So, while the current image is fixed and we can close this bug, there are few bummers here:

- rpm -ql differing from what is installed (and still rpm --verifying) is utterly confusing.
- toolbox neither indicating an outdated image nor how to update it is not helpful.

This is made worse by the fact that - especially on atomic variants - users tend to make cozy $HOMEs in a toolbox which they carry around for ages, potentially across distro upgrades. That is not what containers are made for, and in particular they are running their containers off images old even if they updated the images after creating the container.

I think we need to really improve both tooling (image update, container stop) and defaults (separate .config and shell histories) and "education" around toolbox to this technology as useful (and harmless) as it can be - and it can indeed be really useful!

Fedora-user: You would need to

podman pull registry.fedoraproject.org/fedora-toolbox:39

to get a current image and then create a new toolbox from that image.

So a

sudo echo "%_install_langs   en:en_US:C:de:de_DE" | tee -a /etc/rpm/macros

should fix it? I have rstudio with the same problem.

But after adding this macro, a dnf update didnt pull in any more languages.

(In reply to Fedora-user from comment #12)
> So a
> 
> sudo echo "%_install_langs   en:en_US:C:de:de_DE" | tee -a /etc/rpm/macros
> 
> should fix it? I have rstudio with the same problem.
> 
> But after adding this macro, a dnf update didnt pull in any more languages.

If you want to keep the old container then you need to reinstall whatever should pick up the new rpm settings. But I'd rather think of containers as short-lived or snapshots.

(In reply to Michael J Gruber from comment #10)
> This is made worse by the fact that - especially on atomic variants - users
> tend to make cozy $HOMEs in a toolbox which they carry around for ages,
> potentially across distro upgrades. That is not what containers are made
> for, and in particular they are running their containers off images old even
> if they updated the images after creating the container.

Note that this was a regression in a fedora-toolbox:39 image before Fedora 39 got released.

*** This bug has been marked as a duplicate of bug 2244503 ***