The most basic use case that falls under i18n is the ability to specify a language/region code and an identifier which represents a resource (text or some other structure) which is suitable for the language code. The system needs to resolve the best match of language/region code.
@bryanforbes has worked on a concept of using ES Observables which provide subscribers with the current language codes resources. If the language code is changed, the observables will publish the changed resources and the consumer reacts to that change. While this is an elegant solution, I wonder how this scales when you have a significant amount of subscriptions and does the frequency of changes during a lifecycle of a loaded page. For example, would if a region change that required a page reload be too limiting of a use case in order to simplify how the mechanism would work.
In Dojo 1, the resources are loaded using the AMD plugin mechanism. The long term disadvantage to requiring that for Dojo 2 means that the only way to get that functionality would be to use an AMD loader. The plugin architecture also looks like it might run into issues when the ES Module Loaders finally arrive natively, as they are unlikely to provide a "plugin" type interface, though the debate is currently ongoing.
So given all these considerations, this issue it to lay out a proposal of creating resource bundles, loading them and offering them up to a consumer.
Summary of a discussion between @matt-gadd and myself...
Since the larger Dojo 2 Widget system is generally a pull system, it is logical that the i18n system be a lazy loaded pull system. The flow would be something like this:
A consumer requests a named resource (name + module?) from i18n
The i18n offers up the resource:
If it needs to resolve the resource async, it needs to return a "placeholder" value and then .invalidate()s the consumer when resolved.
If it has already resolved the resource, it offers it up sync.
If the resource changes during the lifecycle, i18n invalidates the consumer
i18n only needs to resolve resources when they are requested (lazy loading)
mwistrand
commented
7 years ago
@kitsonk commented on Wed Jul 06 2016
The most basic use case that falls under i18n is the ability to specify a language/region code and an identifier which represents a resource (text or some other structure) which is suitable for the language code. The system needs to resolve the best match of language/region code.
@bryanforbes has worked on a concept of using ES Observables which provide subscribers with the current language codes resources. If the language code is changed, the observables will publish the changed resources and the consumer reacts to that change. While this is an elegant solution, I wonder how this scales when you have a significant amount of subscriptions and does the frequency of changes during a lifecycle of a loaded page. For example, would if a region change that required a page reload be too limiting of a use case in order to simplify how the mechanism would work.
In Dojo 1, the resources are loaded using the AMD plugin mechanism. The long term disadvantage to requiring that for Dojo 2 means that the only way to get that functionality would be to use an AMD loader. The plugin architecture also looks like it might run into issues when the ES Module Loaders finally arrive natively, as they are unlikely to provide a "plugin" type interface, though the debate is currently ongoing.
So given all these considerations, this issue it to lay out a proposal of creating resource bundles, loading them and offering them up to a consumer.
@kitsonk commented on Wed Jul 06 2016
Summary of a discussion between @matt-gadd and myself...
Since the larger Dojo 2 Widget system is generally a pull system, it is logical that the i18n system be a lazy loaded pull system. The flow would be something like this:
.invalidate()s the consumer when resolved.@kitsonk commented on Thu Jul 07 2016
Actually further discussion with @matt-gadd and @agubler clarified something that would be a better pattern that fits into the Dojo 2 Widget system:
.setState(), providing the registered resources.setState()for all registered consumers.