Open cburschka opened 8 years ago
(Also, note that the whole thing could use a refactoring along the lines of visual.{formatText -> renderTemplate}
, visual.{format->render}
.
Maybe even visual.{renderTemplate->render.template}
, and give it a single object argument {template: ..., variables: ...}
.
Because yo dawg, I heard you like templates, so I put a template in your template so you can render while you render.
... dammit, that should be its own issue.
Info messages are run through a template engine, and the templates themselves are localized strings.
This means that by the time they're shown on the screen, the translation is finalized, and unlike the rest of the UI, they won't be affected by the language setting. Changing this would, as mentioned in #324, be
The latter part isn't entirely unfeasible. We could have
visual.formatText
wrap elements in an additional<span class="string-variable-{unique}" data-variable="{key}">
. Then wrap the emitted template in<span class="string-template" data-template="key.to.template.string" id="{unique}">
. (The unique key is needed to clearly assign variables to their parent template in case templates are nested, because variables need not be the immediate descendant of the template element.)Then, on changing the language, something like:
Where replaceTemplate would work like formatText, but would skip running the variables through visual.format.* since they're already rendered.
Obviously, this change would require variable rendering to yield dynamically translatable markup as well.