This repository was archived by the owner on Jan 23, 2023. It is now read-only.
Russian language not working in Flatpak on ArchΒ #297
Description
Describe the bug
The Russian translation doesn't appear to be working in the Flatpak builds, but does in native (Arch AUR) builds.
To Reproduce
Steps to reproduce the behavior:
- Install the Flatpak
flatpak run --env=LC_ALL=ru_RU.utf8 uk.co.ibboard.cawbird- Wait for Flatpak Cawbird to load
- Install from native package repos (e.g. OBS or AUR)
LC_ALL=ru_RU.utf8 uk.co.ibboard.cawbird- Wait for native Cawbird to load
Expected behavior
Cawbird has a Russian language translation (now at ~100% completeness) and should show in Russian when opening the Flatpak (step 3), not just the native build (step 6)
Screenshots
https://twitter.com/GrawlCore/status/1351827193035452416
System details:
- OS: Arch
- Version: 1.3.2
- Package type: Flatpak
Additional context
https://gist.github.com/Grawl/71a3eb980deffdc86f010b910a160e54
Activity
IBBoard commentedon Jan 20, 2021
@p1u3o @CodedOre - any ideas?
Interestingly, there's an old ticket about Corebird(!) and problems with languages in that Flatpak (flatpak/flatpak#1504). But I don't know why it would need custom commands to set up the language. Isn't Flatpak supposed to be user-friendly and just do that kind of thing?
CodedOre commentedon Jan 20, 2021
So, this is what I can say for now:
Flatpak only loads the languages you use, not anyone. You can set that
flatpak configto check it andflatpak config --set extra-languagesto add languages.That is at least the theory. Tried to check this here on my system, but it surprisingly worked only in the terminal and in the GTK-Inspector, not in Cawbird itself.
I suspect the error is on my and not on flatpak's side, as other flatpaks shown the same behavior and flatpak did load the language packs, so I do a try with a virtual machine set to Russian to confirm...
IBBoard commentedon Jan 20, 2021
But they're saying that it works for other apps, which suggests that they should have Flatpak set up right for their language? https://twitter.com/GrawlCore/status/1351823236435214336
(Why it can't just be like "lang" packages, which have all the languages and load the right ones, I don't know!)
CodedOre commentedon Jan 20, 2021
Well, because you only use a few languages normally and why load a language set you don't use anyway? But you could activate all languages with
flatpak config --set languages all.Alright, here is the result of my Russian VM:
Can confirm that the flatpak fails to load the translation. But it seems to install and run the right languages, as seen with the terminal. Also checked with my real system again and noticed that it not used my system language (which is German).
So somewhere in Cawbird it fails to load the languages when it is sandbox. At least I suspect that it has to do with the sandbox, given that the native packages works.
IBBoard commentedon Jan 21, 2021
Okay, that's interesting. At least we know it's consistent!
Who knows about Flatpak language handling and why we might not be loading them correctly? Is it because or languages are all ".po" whereas some systems have "/app.po" or similar? Or is it something we're not specifying correctly (or are specifying correctly, but Flatpak doesn't handle correctly)?
CodedOre commentedon Jan 21, 2021
@alexlarsson and @barthalion, you are working on Flatpak, maybe you can help with this issue?
And I hope you don't mind I mentioned you here...
Grawl commentedon Jan 25, 2021
Hello, I am here as translator and bug reporter from twitter.
Last time I work with translations on Transifex I cannot save one of pluralized items, even if I copied original text to translate. Now its translated and does not show me an error. But in last time, I checked other translations for similar errors and found them. I don't remember all of them but one of them was in the similar item I cannot save in Russian translate.
Maybe this info will be helpful.
IBBoard commentedon Jan 25, 2021
Thanks for the comment. It's not the Transifex problem that is causing this. I fixed that and we have the full Russian translation available, but Flatpak doesn't appear to be loading any translations correctly.
(The translation problem was that we didn't have "%d" in the singular translation, but Transifex wasn't making it clear that that's what the problem was. I removed the "%d" for just the singular and it worked).
barthalion commentedon Feb 26, 2021
Does it happen only with Cawbird or other apps too? What does
localeandlocale -areturn for you on the host and in the sandbox? (The latter can be tested withflatpak run --command=bash --filesystem=/etc/tlp.d org.freedesktop.Platform//20.08.)CodedOre commentedon Feb 26, 2021
If you look at the image of my previous test with the "russian VM", there I installed Cawbird and Lollypop as Flatpak, with Lollypop using the right language and Cawbird not.
Will try to give you this data soon...
CodedOre commentedon Feb 26, 2021
Alright, on my system the output of
localeis that it is set to german, andlocale -areturns a bunch of languages that are installed on Fedora.localeunder the Freedesktop Runtime returns the same, withlocale -aonly the languages I set to install, as expected...Maybe @Grawl as the original bug reporter could try this out as well, but I doubt it will show different results. The interesting thing is that the Cawbird flatpak does use localization in the shell, but not in the app itself...
IBBoard commentedon Feb 26, 2021
I'm wondering whether it's to do with us having all of our language files as just
po/lang.po. I've seenpo/lang/appname.poin other apps. But I can't find any good references for how to get xgettext to work that way.It should be equivalent to have them named as we do, and it works fine outside Flatpak, but it's the only obvious difference that I can see.
barthalion commentedon Mar 1, 2021
Good catch, that must be it. Flatpak splits locales into extensions by matching files' names and paths. @IBBoard can you try adding
separate-locales: truein the manifest? It's a top level key.17 remaining items
IBBoard commentedon Mar 3, 2021
Huzzah!
I guess it makes sense that we need to pass it a path, since the GLib docs show it passing a path and the bindtext docs say it returns the path, which suggests that it's important.
I'm guessing that using
Config.DATADIR + "/locale"for bindtextdomain wouldn't work (which is what was supplied to setlocale) π I'll work something out with some changes to config and meson and extra build options.Thanks for all of the debugging and finding the examples in other apps π I think those pointers have been the key bits to something that's thoroughly under-described and seemingly easy to get wrong with no immediately obvious problems!
Re #297: Use locale dir from meson config
IBBoard commentedon Mar 3, 2021
Okay, I think that works.
The only problem at the moment is that I've got to run
meson build -Dprefix=/usrto pick up the package-installed language files. Which feels ugly. But I don't know how to make it just pick up the local files (which it seemed to do with "null").CodedOre commentedon Mar 3, 2021
Can't say for sure, but I think this is "working as intended", as you could run meson and ninja for a local build (which would result in
~/.localbeing the prefix?). I saw at least some apps who said "add--prefix=/usrfor installing it globally...Not sure about this though...
IBBoard commentedon Mar 4, 2021
I think it is working as intended, because it would be fine once I installed it. But it's annoying that "intended" means that you've got to install it to run it and can't just run it with translations from the build dir. We've found the workaround for making schema changes work without installation. I might have to put an override switch in to meson for local language loading for when you're debugging.
Re #297: Add a "localtextdomain" option for debug
IBBoard commentedon Mar 5, 2021
Can someone test the Flatpak builds with the latest changes? It seems to work with native builds. If we're happy that it works then I can merge it and (hopefully) ship an update soon!
CodedOre commentedon Mar 5, 2021
A local build worked flawless, but I would test a flathub-build as well.
Alright, testbuild on it's way: flathub/uk.co.ibboard.cawbird#5
CodedOre commentedon Mar 5, 2021
Testbuild is complete, the flathub packages provide translation as well!
From the translation standpoint we should be clear.
Re #297: Move language initialisation outside app
Re #297: Use locale dir from meson config
Re #297: Add a "localtextdomain" option for debug
IBBoard commentedon Mar 6, 2021
Okay, that's all merged now. Thanks for all the debugging and testing π