Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Prior to DSpace 7, the DSpace XML and JSP User interfaces had different catalogs of interface messages. Unified on a single user interface, the DSpace community is transitioning to a widely adopted web standard for the translation of interface messagessingle catalog of interfaces messages and better tools for translators.

Originating in the Linux world, the GNU gettext tools and the PO file format is also the backbone of localization support in Wordpress, django and Drupal

...

At the time of writing, 2019-06-01, the NGX-Translate implementation of the support of po files that DSpace is relying on, actually prevails the translations from being rendered correctly if a msgctxt is also part of the entry. This means that right now, we can only have a single translation for a single string. This is also why the catalog and the en.po translation file don't contain msgctxt entries.

What happened to the objective to leverage .po and gettext as new standard?

The Angular i18n framework we use, NGX translate, has a 3rd party PO file loader: https://github.com/biesbjerg/ngx-translate-po-http-loader 

Even though the community was initially very optimistic about its potential and the transition to .po and gettext, the major deal breaker was the absence of support for gettext message context (msgctxt), that would allow a translator to translate a key like "Home" into different words in the target language, depending on the context.

The initial ambitions to use the English string as the key itself, and abandon intermediate keys, was also problematic, as we hit a big number of areas in the code where keys were built up programmatically.

As a result, the community settled for:

  • JSON6 as the format for the message catalog
  • Reverting to a flat list of keys, instead of a hierarchical tree. This now makes it possible again to search on a particular key, which was not possible anymore in the hierarchical format.