Move handling of translations (itext) to the client?

[MartijnR]

Only after client XPath performance has been improved dramatically.

This makes sense for the following reasons:

• the current mechanism has bugs because extracting the itext id from a string is not done well (since don't have a regexp functions at our disposal in enketo-transformer)
• often option lists are used multiple times and currently copied multiple times which can cause the # of DOM elements to explode in some forms.
• the current mechanism is not XForms-spec-compliant, because you cannot use itext in a calculation for example (it's not implemented as an XPath function)
• XSLT transformation could be up to 85% quicker, which would have a noticeable impact on loading long forms for the first time and for loading previews (although the latter could be cached too, if it is likely previews are loaded multiple times without form changes in between). However, this impact would depend on whether the client can handle itext faster (I think it can, especially if the native XPath processor can be used).
• ~~because of the first point it would become easier and more elegant to add support for external instances (itemsets).~~

Not a priority.

Client initial loading performance may be an issue, though reducing the # of DOM elements would have a somewhat positive impact.

Language switching will become slower as well, but that's no big deal at all.

[MartijnR]

Not sure if point 3 is true, because itext cannot really be used in conjunction with external data, or can it?

Update: it would likely have to be a new function (currentLang() e.g.) for external data. However, it work very similar to itext(), unlike the current situation.

Using the native XPath evaluator is possible by rewriting the itext() expression to a simple path (just like instance() and current()

[alxndrsn]

Would this allow jr:itext() evaluation in e.g. <bind> elements' calculate attribute?

[MartijnR]

Yes, it would. It would be just like any other XPath expression and could be used anywhere.

[MartijnR]

https://github.com/enketo/enketo-xslt/issues/53

• [ ] take out all the ugly translations code from enketo-xslt and replace with itext references (e.g. data-itext attribute.
• [ ] let enketo-xslt copy the <itext> element
• [x] let enketo-transformer replace lang attribute values with IANA subtags (it may already do this)
• [ ] change langs.update function from toggling the "active" class to performing itext Updates
• [ ] call itext update function upon load and upon language-switching-action
• [ ] test all widgets that create new DOM elements that use XForm strings

[MartijnR]

problem is with any translations that include a variable as part of the text string

[MartijnR]

This work would also be a prerequisite for implementing https://forum.getodk.org/t/proposal-customize-name-and-label-columns-in-selects-from-external-data-in-xlsform/27265/9