Investigate gettext-based i18n

[BrunoO]

Summary

Investigate using GNU gettext for internationalizing the FindHelper UI, and document pros/cons versus a custom key-based catalog.

Context

We discussed gettext as a primary option for localizing the app, and compared it with alternatives (Boost.Locale/ICU, custom string tables, platform-specific resources). Key points to capture in this issue:

• gettext workflow: mark strings with _(), extract msgids with xgettext, translate .po files, compile to .mo with msgfmt, load them at runtime with libintl (bindtextdomain/textdomain/setlocale).
• Runtime behavior: .mo catalogs are loaded once per domain/locale and cached in memory; subsequent gettext()/ngettext() calls are fast in-memory lookups (hash/binary search), not repeated file I/O.
• Licensing:
  • Runtime library (libintl, gettext(), ngettext(), etc.) is LGPL (v2.1+), which is compatible with an MIT-licensed app as long as we respect usual LGPL terms (ideally dynamic linking, preserve notices, allow relinking).
  • Tools (xgettext, msgfmt, etc.) are GPL but only used in the build/translation toolchain, so they don’t affect the app’s MIT license.
• Alternatives considered:
  • Boost.Locale / ICU for formatting and locale-aware behavior, typically combined with our own catalogs.
  • Custom key-based catalogs (e.g. "search.button.label" → localized string in JSON/TOML), potentially plus a lightweight plural/parameter system.
  • Platform-specific resource systems (Windows .rc/.resx, macOS .strings), which are more complex to integrate with our cross-platform ImGui code.

Platform notes (what we’d need to install)

• macOS (dev)

  • Use Homebrew:
  • Add bin/include/lib to PATH/CPPFLAGS/LDFLAGS for CMake.

• Linux (Ubuntu-like)

  • Install runtime + tools, e.g.:
  • Rely on system libraries at runtime; ship only our .mo files.

• Windows (main target)

  • Use vcpkg: and integrate via the vcpkg CMake toolchain.
  • Ship if dynamically linking, plus our locale/LL/LC_MESSAGES/domain.mo tree.

Open questions / decisions

• Do we want gettext as a hard dependency, or prefer a custom key-based catalog (no external libs, easier to keep C++17-only) with optional ICU for formatting later?
• If we do adopt gettext, do we require dynamic linking to libintl on Windows/macOS, or allow static linking but document the LGPL implications clearly?
• How do we want to expose i18n in code: string-based keys ("search.button.label") or use English msgid as key via _() macros?

Proposed next steps

1. Prototype a minimal gettext integration on macOS (single domain, one extra locale) and measure overhead in our ImGui render loop.
2. In parallel, sketch a lightweight key-based LocalizationManager API so we can compare ergonomics and complexity.
3. Decide on the long-term strategy (gettext vs custom catalogs) before wiring translations throughout the UI.