Implementing a pluggable translation provider architecture

I would like to propose and, if approved, offer to implement a simple pluggable translation provider architecture for the I18n extension.

With the current implementation of the I18n extension:

translation items are stored in an in-memory plain object that does not natively support advanced functions such as callbacks, caching, and persistence;
calls to t() and add() cannot be easily redirected to a different service, such as the application's back-end or a third-party translation service;
the only variants currently supported are pluralization rules, while many languages present variants based on often partially inter-related grammatical genders, functions, persons and tenses.

A pluggable translation provider architecture would bring the following benefits:

allow versatile handling and storing of translation items;
allow various and even concurrent sources of translation items;
support multiple grammatical variants, and even non-grammatical variants such as polite forms, and greeting forms that depend on the time of the day (for example, English and Spanish greetings vary between morning and afternoon, while French and German have morning, "beforenoon" and afternoon greetings over the same time period; we could then have something like i18n.t('user.login.greeting', { name: user.name, gender: user.gender, time: Date.now() })) with two variants in English, four in Spanish and six in French and German).

This update would implement the following changes to the I18n extension's API:

add an options parameter to the I18n constructor for preventing expensive early setup of the i18n instance in a way that must then be overriden when a different provider is wanted;
add methods setTranslationProvider() and getTranslationProvider() to the I18n class;

Backward compatibility would be maintained by:

making the currently integrated translation system the default provider;
defining default values for the I18n constructor's options parameter that correspond to the currently hard-coded values;
having methods add(), t() and clear() currently part of the I18n API proxy the new translation provider's API;
method setPluralizationRule() would also proxy its homologous, now generalized setVariationRule() method, while outputting to the console a warning message prompting implementers to update their code.

Tests and documentation would be updated accordingly.

ficusjs / ficusjs-i18n