Thread:Talk:Requests for comment/HTML templating library/KnockoutProposal/About i18n/reply


 * 1) (Syntax): i18n can look like data-bind="i18n: messageName". The advantage of using a single attribute is performance and simplicity. Those attributes can be formatted across multiple lines.
 * 2) (Variables): The syntax trivially and generically supports passing both arrays and objects to messages, but we can be more selective about what we accept in the i18n binding.
 * 3) (Message API): At first sight it looks like we can define an interface that can remain unchanged even if we swap out mw.message against another backend later.
 * 4) (Message formats): Much of this would normally be handled by automatic escaping and compilation from the input format. The input formats of messages are properties of the messages themselves, so should not be specified by a user. The escaping needed depends on where in the DOM a message is used, which is handled by the templating system.
 * 5) (RL): It is fairly easy to extract a list of all messages that could possibly be used in a template if message names are not dynamically constructed from input data. Optimizing the bundles of messages could be done based on usage statistics, with the common messages all delivered in one bundle and additional messages loaded on demand. This is a longer-term optimization opportunity.
 * 6) (Live updates): With native knockoutjs this can be solved by making the translations observable. This allows dynamic updates of both data *and* messages, and re-rendering is handled transparently by KnockoutJS. If we use just quicktemplate, then one option is to simply re-render the template with new messages set in the model. Another could be to implement an i18n-specific pass that only re-expands i18n nodes, although the difficulty there would be getting the data scoping right.