[ JULEP ] Add Internationalization (i18n) and localization (l10n) support. (WIP)

[Ismael-VC]

Julia i18n & l10n

Implementation:

• [ ] C/C++: gettext.h

  • [ ] pre-processor macros to determine if gettext.h and derived functionality should be used.
  • [ ] wrap translatable strings with _() AKA gettext().
  • [ ] Add i18n string catalog generation to build scripts.

• [ ] Femtolisp: Port srfi#29/localization

  • [ ] Integrate localization bundles with gettext translation workflow.

• [ ] Julia: Port Python gettext implementation to Julia (currently there is Gettext.jl but uses PyCall, also Gettext should be a standard library in order to localize julia itself, not just external packages).

Configuration

• [ ] Makefiles should handle opt-in functionality to compile with i18n support, default is no i18n.

  • [ ] make.user configuration variable.

• [ ] Runtime argument flag, needed to bypass LANG and other environment variables, when calling julia?

  • [ ] julia --LANG es_MX or LANG=es_MX julia.

Translation

• [ ] Set up Transifex to host generated i18n string catalogs.
  • https://www.transifex.com/julialang-i18n/public

Documentation

• [ ] Document usage of Gettext.jl module.

Testing

• [ ] Add tests.
  • [ ] C/C++
  • [ ] Femtolisp
  • [ ] Julia

[garrison]

• Julia: Port Python gettext implementation to Julia (currently there is Gettext.jl but uses PyCall, also Gettext should be a standard library in order to localize julia itself, not just external packages).

As suggested at https://github.com/Julia-i18n/Gettext.jl/issues/1#issuecomment-868492149, an alternative to porting the Python implementation would be to depend on libintl directly. (This might not make sense if the julia maintainers explicitly avoid depending on LGPL code -- I am not sure of the latest policy on this, especially with regards to things that are optional at compile time.)

[stevengj]

https://github.com/Julia-i18n/Gettext.jl/pull/5 links to libgettext directly, eliminating the Python dependency.

I don't see why an LGPL (not GPL!) dependency should be a problem?

(In principle we might gain some efficiency by a pure-Julia implementation, since we can avoid allocating new String objects on each call. I'm skeptical that micro-optimizing performance is important in i18n settings, however.)