This requires the changes from the FLUID-6148 line of work, and should likely also wait on the FLUID-6420 work to before implementing.
Suggestion from Antranig in the [fluid-work channel today|http://irc-logs.fluidproject.org/%23fluid-work/%23fluid-work.2019-12-18.log:]
Right now there are two ways of using ResourceLoader resources - the "dynamic path" involves referring to them regardless of whether they have loaded, via a model reference or a messageResolver reference, etc.
And the "static path" involves the pattern that we generally use in UIO since its usage of ResourceLoaders is based on the legacy system, whereby you explicitly wait for the onResourcesLoaded event to fire
In the static path you simply get the value of the resource as it has loaded and don't get the benefit of any dynamic updates
So every UIO panel has one of these attached: https://github.com/fluid-project/infusion/blob/master/src/framework/preferences/js/Panels.js#L74
It gets its "messageBase" via this distribution: https://github.com/fluid-project/infusion/blob/master/src/framework/preferences/js/Panels.js#L82
Now all of these messageBase values get baked into the component via the AuxBuilder here: https://github.com/amb26/infusion/blob/FLUID-6145/src/framework/preferences/js/AuxBuilder.js#L474
Although there seems to be some confusion here since it looks like these panels separately inherit directly from the parent bundle via the prefsEditorConnections grade: https://github.com/fluid-project/infusion/blob/master/src/framework/preferences/js/Panels.js#L655
I think the best thing to do would be to hoist an actual test case demonstrating relocalisation into the core framework, which would then be more than a "demo" : p
My suspicion that the best way of fixing this is to improve the strategy in the AuxBuilder which implies some core work by Justin_o
Probably the most direct approach is to create a kind of "dynamic path" cut-through that resolves the root message bundle dynamically and early, and then rewire all the references to bind into that, so that even if the current rendering model makes the components look as if they have to wait for the I/O to finish, they can bind to another component that doesn't
This involves the least upheaval, I think, and lets us keep our existing clunky "strings" model that the old renderer relies on