add a rule to generate Scanner.h - #22

…mule-project#22)

aMule installs its translation catalogs under
${CMAKE_INSTALL_PREFIX}/share/locale/<lang>/LC_MESSAGES/amule.mo
(po/CMakeLists.txt -- DESTINATION ${CMAKE_INSTALL_LOCALEDIR}).

For system installs that build the binary and wxGTK against the
same prefix (typical Debian/Fedora/Arch packages), libintl's
baked-in default lookup matches and translations work without
explicit help.

In a Flatpak however, the bundle installs under prefix=/app while
the wxGTK shipped inside the GNOME runtime was built against
prefix=/usr -- so libintl looks for amule.mo under
/usr/share/locale, and our catalogs sit at /app/share/locale,
untouched. Net result: every gettext() lookup misses and the UI
runs in English regardless of LANG / LC_*.

Fix: extend the existing InitLocale() AddCatalogLookupPathPrefix
block (which currently only fires on macOS/Windows for bundle-local
catalogs) to also register ${install_prefix}/share/locale on
Linux/*BSD. On Flatpak this resolves to /app/share/locale -- where
our catalogs actually are -- and on system installs it overlaps
with libintl's default lookup so it's a harmless no-op there.

DaRkViVi (Fedora 44) reproduced the path mismatch in amule-project#18:

  $ flatpak run --command=sh org.amule.aMule -c \
        'ls /app/share/locale | head'
  de es fr hu it pt_BR ...                # catalogs present

  $ flatpak run --command=sh org.amule.aMule -c \
        'ls -la /usr/share/locale/it/LC_MESSAGES/amule.mo'
  No such file or directory               # libintl can't find them

  $ LANG=it_IT.UTF-8 LC_ALL=it_IT.UTF-8 flatpak run org.amule.aMule
  # opens in English even with System Language = it

…sion (amule-project#25)

flatpak-builder's default behaviour splits translation catalogs out of the main app into a sibling <app-id>.Locale extension. For aMule's install layout that split produces a non-standard nested path inside the extension (<lang>/share/<sub-lang>/LC_MESSAGES/amule.mo) that libintl can't reach with any single bindtextdomain prefix — so even when the .Locale extension is installed (which happens automatically on Flathub but never with our single-file .flatpak bundle), wxLocale loads English and silently ignores translations.

Set separate-locales: false in both manifests to keep the .mo files in the main app at the canonical share/locale/<lang>/LC_MESSAGES/amule.mo path. wxLocale + the install-prefix lookup registered in amule-project#22 then find them reliably.

Verified end-to-end on Linux ARM64: bundle ships 38 .mo files at the canonical path; amulecmd --locale=it_IT loads Italian.

Trade-off: bundle size grows ~8 MB.

The Language dropdown in Preferences only showed the user's active
glibc locale plus en_US / en_GB when running inside Flatpak (cardpuncher
on the 3.0.0-151-g78f62c053 flatpak-x86_64 build, amule-org#18
follow-up). Root cause: the picker probe at Preferences.cpp gates each
candidate language behind wxLocale::IsAvailable() and a
locale_to_check.IsOk() check, both of which require glibc-locale data
for that language to be present in the runtime. The GNOME Flatpak
runtime ships only the user's preferred locale via the
org.freedesktop.Platform.Locale extension; every other language fails
the probe even though our amule.mo catalogs are bundled correctly at
/app/share/locale/<lang>/LC_MESSAGES/amule.mo (verified via ostree on
the .flatpak bundle).

glibc-locale-data is only needed for LC_NUMERIC / LC_TIME formatting,
not for translation lookup. wxLocale can apply the amule.mo catalog
via the install-prefix path registered in InitLocale (PR amule-project#22) without
glibc-locale-data for the target language.

Add a HasAMuleCatalogForLanguage() helper that checks for our .mo file
under the same lookup prefixes InitLocale registers
(GetResourcesDir/locale on Mac/Windows, GetInstallPrefix/share/locale
on Linux/*BSD). Accept that as an additional positive signal in both
gates of the probe so languages whose catalog file is on disk surface
in the picker regardless of sandbox glibc state.

On system installs where glibc has the locales the behaviour is
unchanged: the existing checks pass first and the file-existence test
is never reached.