Topic on Talk:Requests for comment/HTML templating library/Knockoff - Tassembly

1. (Syntax) I was secretly hoping for data-i18n kind of syntax used by jquery.i18n, but I can live with this new syntax as well. Have to say though, that is looks extremely verbose, meaning that we should figure out a sensible convention for splitting tag openings into multiple lines.
2. (Variables) It looks like this syntax supports passing variables to messages. Does it accept array of values like current message functions? Or perhaps an object with keys as variable names as well (it divers from our current practice, but named variables are not a bad thing).
3. (Message API) I'm not sure the current mw.message is a thing we want to integrate too tightly. Perhaps we can abstract the integration a bit so that it can be replaced. mw.message is MediaWiki specific and there are wishes to either create a standalone library based on it or replace it with another library. Having said that, using mw.message right now makes sense.
4. (Message formats) Further thought is needed to figure out what we do with the different output formats of mw.message. Do we give the control to the user? Or do we automatically select suitable format based on the context?
5. (RL) Are we able to preprocess the templates in such a way that we can see what messages are used in it, and load those automatically? The current thing of having to specify what messages to load is quite annoying. There are also messages used only in the JS, so perhaps this won't solve the problem entirely. Another option is that people might start splitting messages to different files per template, and then just load all messages defined in that file.
6. (Live updates) It was not mentioned clearly in the proposal, but I assume we are able to update the strings into different language "live" as we can do with jquery.i18n.

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.

This sounds great.