[ 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 Julia-i18n/Gettext.jl#1 (comment), 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]

Julia-i18n/Gettext.jl#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.)