What command from the appstream workflow enables localizations?

I made a Gramps flatpak file available at the upstream repository for archival purposes as well as pushing the update faster to users who wanted to test the update. Release Gramps flatpak 5.2.0-0 · gramps-project/flatpak · GitHub

It has come to my attention that the flatpak I linked above does not allow localizations, in this case changing the locale to French. 5.2 flatpak "No valid locale settings found" - Development - The Gramps Project (Discourse Forum & Mailing List)

However, the older versions of Gramps available at flathub (5.1 series) apparently followed system locales. I am guessing that the workflow I made is missing a command that enables the resulting flatpak to use system locales. Is there a command I can add to flatpak/.github/workflows/main.yml at main · gramps-project/flatpak · GitHub to enable the gramps-project flatpak archives to use system locales?

The biggest reason I want an archive of a prior version of this flatpak, is that several changes were made to the Gramps 5.2 release. User database information has to be updated regardless of whether they installed Gramps from repo, source, or flatpak. Furthermore, changes were also made to the flatpak, including the restriction of directory access from full home access down to specific xdg directories, and also the dropping of an old version of BSDDB3 that does not require Oracle’s manual license agreement. Before Oracle acquired BSDDB3, Gramps used to use BSDDB3 as the default database. Even though Gramps switched to SQLite as the default database years ago, the developers have been trying to phase users over to SQLite for a long time (apparently SQLite is also less prone to corrupting user files). However, there are still old files from the BSDDB3 days that users still try to restore, and users who for whatever reason did not switch over. Since it has been so long since there was an update to pre-Oracle versions of BSDDB3 it probably has all kinds of security holes, and since including that BSDDB3 to the gramps flatpak adds extra compile time and download size, I have wanted to drop BSDDB3 from the flatpak for a long time. However much we might discuss or warn users to switch over to SQLite, of course most users don’t actively follow the discourse or read ChangeLogs at the Github. This is especially relevant to people who aren’t proficient in English, since many discourse posts are in English and the ChangeLog is in English. That is why I especially want an archive of the old 5.1.6 Gramps flatpak capable of using system locales at the gramps-project github, to help people who didn’t know about the changes for 5.2 despite developer efforts and were not ready for it.

The only possible solution I can think of is to get the github workflow (Ubuntu) to install every single language pack possible, and then list every single language pack in the flatpak build command. There has to be a better way, right?

This is:

The only way to make this work is to set separate-locales: false in your manifest.

I’ll also note that it is possible (though inconvenient) to install old versions of an app from Flathub: Tips and Tricks - Flatpak documentation

1 Like

Thank you, I am testing the separate-locales command now.

So if I understand correctly, it is not the flathub appstream commands during compiling that cause flatpaks from flathub to use different languages. Rather, flathub sends a Locale file with the appropriate runtime to match the user’s computer’s locale?

Would it be possible to give a “flatpak install (locale)” command that would allow the archived gramps.flatpak file to use other languages than English? In this case, the locale for Gnome Runtime 44 for Gramps 5.1.6.

—edit— setting “separate-locales: false” in the manifest worked in forcing the archive to use the system locale. Thank you.

By default, flatpak-builder splits out your app’s locale data into an extension with the suffix .Locale. On installation, flatpak only downloads and installs the system language subset from that extension.

The bundle still used a runtime from Flathub with its own Locale extension, so the locale definitions should have been present, just not the application-specific message catalog.

1 Like