Bug 443151

Description Mark Macdonald 2014-09-02 18:34:06 EDT

Orion's current story for i18n relies on the plugin registry to contribute translations [1]. This has some advantages, but they are outweighed by the downsides:

 - Complex, hard for developers to understand
 - Service APIs are polluted with i18n-related properties: descriptionKey, nameKey, etc
 - Limitations: for example, we can't translate the login page [2]
 - Scatters a cross-cutting concern (loading message bundle) through the codebase [3]

It would be preferable to rely only on the RequireJS i18n plugin, and allow any module (both plugins and pages) to load i18n! modules directly.

Opening this bug for discussion. In particular we'd need to determine how to ship translations that are not plugin-based, and what sort of build-time changes would be needed.



[1] https://wiki.eclipse.org/Orion/Internationalization
[2] See bug 400637
[3] When dealing with translated plugins, we cannot rely on the AMD loader to fetch the required bundles during normal dependency resolution, since the set of required bundles is unknown until other service data is fetched, typically deep into the UI code. This has caused #getMessageBundle() calls to infest many UI widgets, sometimes forcing async functions into interfaces where they do not belong just to enable translation.

By relying purely on the loader, we can handle message bundles like any other AMD dependency, across the codebase.