I am procrastinating learning object-oriented javascript by thinking about different i18n options for karma
Here are just a few of the key requirements for i18n in karma 1. Support inline text in the html <div>This text should be captured</div> 2. Support in code translation document.write(_("This text should be translate")); This is pretty standard use of gnu gettext and is well-supported 3. Grab inline text with inline markup <div>This text should be captured, even the <strong>inline markup</strong> </div> 4. Whatever solution we use, it shouldn't invalidate the html against an html5 validator, as the suggested solution for XML in GNOME would http://www.gnome.org/~malcolm/i18n/marking-strings.html#xml So I only see two possible solutions at this point 1) Using a client-side micro-template, similar to a server-side template http://ejohn.org/blog/javascript-micro-templating/ advantages: could be very powerful and very flexible drawbacks: this could be slow and could invalidate the markup. It could also make the markup hard to read. It could also cause problems accessing karma lessons from web servers that mistake the <% ... %> as a server-side include. <div><% This text should be captured %></div> 2) using the data-* collection of author-defined attributes in html5 http://www.whatwg.org/specs/web-apps/current-work/#custom-data-attribute conceivably, we could add the attribute data-k-translate="true" to every element we want translated advantages: doesn't invalidate the html, makes use of html5 drawbacks: verbose, might not be very flexible, we would have to add the attribute to a lot of elements We could possibly use the attribute data-k-translate-children="true" to specify that all child elements w/ text should be translated. Conceivably, we could also use data-k-translate-children="false" to turn off translations for all children. I could also use <html data-k-translate-children="false"> to turn off translations for the entire document. I haven't yet discussed i18n for the .css. In fact, I haven't really thought hard about it. Ideas from smart folks would be much appreciated. Regards, -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel