I18n and Localization

[mareklibra]

How will be the application translated? Consider REST API error messages.

[jelkosz]

The API message translations require:

• https://github.com/oVirt/ovirt-web-ui/issues/110
• https://bugzilla.redhat.com/show_bug.cgi?id=1435704

[mareklibra]

Let's contemplate options for i18n/l10n.

In general, Zanata seems to be a good choice for the actual translation, so let's consider all bellow in its context.

There are plenty of choices how to i18n a JS application. When considering the viable ones, let's focus on:

• limited amount of boilerplate code
• nothing over-sophisticated, easy to understand by newbies (just JS developers?)
• once set, low maintenance cost (scriptable)
• Zanata-ready format or just simple transformation required
• limited or no use of id-referencing, the English defaults shall be used throughout the code
• simple process of merging translations over time

Nice to have:

• format allows simple and reliable reuse of existing translations from ovirt-engine
• locale-specific data loaded on demand

So far, following approaches meet the criteria:

• "Home-made" text extraction

  • wrap all strings to something like __("My string to translate")
  • use 'sed' to extract
  • generate whatever format is needed
  • Pros:
  • full control over format and merging process
  • works fine for simple (basic) needs (do we really need more?)
  • probably lowest amount of boilerplate code
  • still supports formatted messages
  • simple to implement, simple to understand and maintain
  • Cons:
  • complicated for multi-line strings
  • a lot from l10n would not be supported (eg. time or plurals)

• gettext / Jed

  • Pros:
  • standard
  • Zanata-ready format
  • already used in cockpit-ovirt or Cockpit
  • Cons:
  • complicated to setup
  • JS support is an add-on
  • no matter gettext is standard, its use is not clear for everyone

• react-intl

  • https://medium.freecodecamp.com/internationalization-in-react-7264738274a0
  • Pros:
  • clean JS approach
  • based on JS standards
  • Cons:
  • quite a lot of boilerplate code
  • no experience so far
  • resulting format needs to be transformed to/from Zanata

I slightly prefer the react-intl. Any real-project experience?

Please comment/suggest. @jelkosz , @vojtechszocs , @gregsheremeta , @jniederm , @matobet , @bond95

[jelkosz]

Even though the first option is tempting it would get a bit more complicated to implement things like: ___("Maximum allowed memory is {} MiB", someValue) which we will need. From quick look I liked the react-intl too.

[mareklibra]

@jelkosz , I think this would not be an issue: __("Some formatted {value} in MB").format(someValue)

[jelkosz]

Ah, right, the messages themselves would contain the {value} string. But still, the react-intl looks nicer to me.

[sjd78]

ovirt-engine-dashboard is currently using a bit of react-intl on the message format and string storage side of things. We're not using it for date/time or number formatting. Standard ECMA-402 Intl is used in those cases. We're also not using react-intl straight in the jsx code - the messages are wrapped up in function accessors similar to the way GWT handles things. So maybe the dashboard isn't a good example for pure react-intl use in JSX.

However, I do have the react-intl messages well integrated to zanata. The process used is documented in [1]. Essentially there is a nice little package to transform from react-intl json to a gnutext pot file that gets pushed to Zanata. Once translated, the same package takes the .po files and creates the json. The README reasonably explains the whole workflow.

At least you can crack the Zanata nut by using the dashboard setup.

[1] - https://github.com/oVirt/ovirt-engine-dashboard/blob/master/README.adoc#internationalization-and-localization

[jniederm]

• react-intl
  • I like it for plurals, relative times, variable replacements
  • cons
  • I find it a bit too verbose
  • I find keeping original (en) strings outside source code better to simplify their reuse
  • I don't understand why there is a key and id in definition of strings (example)
• zanata supports following formats: XML_DOCUMENT_TYPE_DEFINITION[dtd], PLAIN_TEXT[txt], IDML[idml], HTML[htm,html], OPEN_DOCUMENT_TEXT[odt], OPEN_DOCUMENT_PRESENTATION[odp], OPEN_DOCUMENT_GRAPHICS[odg], OPEN_DOCUMENT_SPREADSHEET[ods], SUBTITLE[sub,srt,sbt,vtt], GETTEXT[pot], PROPERTIES[properties], PROPERTIES_UTF8[properties], XLIFF[xml] (despite doc) claiming also json support).
  Based on the list above I suggest to use properties files for communication with zanata and storing data in repo and convert properties files to an appropriate json in build time. I find properties file the best since it's simple, there is probably no need for extra features of pot format.

[jniederm]

Done in #309, #310, #335 and related fixes.