@DaRkViVi — first, thanks for the Fedora 44 confirmation on the flatpak — that lines up with the Alpine confirmation in #13, so we have solid signal that the libbfd fix solved the launch failure on both distros.

On the English-only side: very likely a real flatpak-specific NLS bug (separate from the libbfd issue). Working hypothesis: the .mo translation catalogs ship inside the flatpak at /app/share/locale/<lang>/LC_MESSAGES/amule.mo, but the GNOME 49 runtime's bundled wxGTK / libintl are compiled with --prefix=/usr so they only look under /usr/share/locale/.... Path mismatch → every gettext() lookup misses → English fallback. The runtime locale-init at src/OtherFunctions.cpp:1096-1111 only adds an explicit lookup prefix on macOS/Windows; Linux falls through to libintl's defaults, which is what bites us here.

If you're willing to run three commands, we can confirm or refute that cleanly before we ship a fix. From a regular Fedora terminal:

1. Are the translation catalogs actually shipped inside the bundle?

flatpak run --command=sh org.amule.aMule -c 'ls /app/share/locale | head -20'

Expected output (if catalogs ARE present): de es fr hu it pt_BR .... Empty / No such file or directory → different bug (catalogs not even built into the flatpak).

2. Is the catalog where libintl looks for it?

flatpak run --command=sh org.amule.aMule -c 'ls -la /usr/share/locale/it/LC_MESSAGES/amule.mo 2>&1'

Expected output (if path-mismatch theory is right): No such file or directory. That confirms wxGTK / libintl is looking at the GNOME 49 runtime's /usr/share/locale and our amule.mo isn't there — it's at /app/share/locale from step 1.

3. Rule out a stale language preference in aMule's own config:

LANG=it_IT.UTF-8 LC_ALL=it_IT.UTF-8 flatpak run org.amule.aMule

And in Preferences → General → Language, set to System default (not a specific language picked from the list). If still English with the catalog physically present at /app/share/locale/it/LC_MESSAGES/amule.mo, that's strong confirmation of the path mismatch.

If all three match the predicted output, the fix is small and well-scoped — ungating the AddCatalogLookupPathPrefix(GetResourcesDir() + "/locale") call so it also runs on Linux (it currently only runs on macOS/Windows). Same shape as the existing block. We'll file that as a separate issue once we have your confirmation.

Uh oh!

Flatpack binaries issues on Alpine and Fedora #18

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions