Hey everyone, We merged PR 42 as-is into master yesterday afternoon. I've spent today doing two things: 1. I renamed the attribute data-i18n-skip=true to data-role=dummy, and added tests 2. I tried applying the resulting i18n framework features to the grocery list demo Look here to see what I had to change: https://github.com/errai/errai/commit/ce881d05b61406c8fe4f02691c8f899cae6... So far, I think this has been my best experience with an i18n system. It's really low-drag compared to anything I've done before! I think we're on to something. Here are my nitpicks and suggestions: a. Eric suggested a heuristic for omitting certain elements from the auto-generated translation bundle: if an element has a data-field attribute, we should disregard even if its contents are text only. In GroceryList, this heuristic was correct everywhere except <button> elements. A workaround (not super-awesome, but it does work) is: <button data-field="fooButton"><span>Button Label</span></button> Better suggestions? b. There were a number of elements with mixed content (text and subelements) where the text parts needed to be translated. Here's what I ended up doing: BEFORE: <div class="moreInfo"> Added <span data-field="addedOn">3 Days Ago</span> by <span data-field="addedBy">jfuerth</span> </div> AFTER: <div class="moreInfo"> <span>Added</span> <span data-field="addedOn">3 Days Ago</span> <span>by</span> <span data-field="addedBy">jfuerth</span> </div> There may be a less verbose solution to the problem, but I have to say this solution strikes me as elegant. There's a real magnetism to such a simple rule: "every non data-field element containing only text will be a candidate for translation." I suppose an equally elegant alternative would be to settle on the rule: "every text fragment within a non data-field element will be a candidate for translation." Perhaps that is better after all... c. What about eliminating the @Bundle annotation? We could search for bundles either in the same package as the @Templated class, or in the same package as the HTML template it points to. d. Long bits of text with a little bit of markup in the millde are problematic. Consider this example: <p> When it comes to solving a business problem in code, once is <em>more than</em> enough! As compelling as the autonomous AJAX based client architecture is, when your client code is in JavaScript and your server code isn't, you're now committed maintaining two apps in parallel, and keeping them up-to-date in lock step. In the above, the only i18n key that gets extracted is "more than". The rest remains untranslatable. If we went with the rule "every text fragment within a non data-field element will be a candidate for translation," we'd be in better shape, but still not amazing shape. This is really /one/ translatable thought, not three. Maybe this: <p> When it comes to solving a business problem in code, once is <em data-i18n=inline>more than</em> enough! As compelling as the autonomous AJAX based client architecture is, when your client code is in JavaScript and your server code isn't, you're now committed maintaining two apps in parallel, and keeping them up-to-date in lock step. And then allow HTML markup in translation values? We could treat them as SafeHtml... e. I think we should automatically consider placeholder and title attributes as translatable. Perhaps there's a case for allowing end users to override this default in ErraiApp.properties or in an attribute of the @Bundle annotation if we keep it. I'm mostly thinking of custom data-* attributes as a motivation for this. f. It would be kind of us to include a reusable language chooser widget with well-documented CSS classnames. Seems like everyone is going to need one of these. g. The default strings are already in the templates themselves. Is it really actually useful to restate them in a default messages file? The "fallback to default language" mechanism of "leave it alone" ought to be sufficient. This widget (or TranslationService.setLocale()) should also take care of translating the existing live DOM contents to the new language. h. Bug: it seems the i18n keys that get truncated aren't actually applied within the templates. Probably need a new test case for this. You can see the problem in the three paragraphs at the bottom of the Grocery List welcome page. i. Bug: the i18n key scanner picked up "Declarative is Good" as a keys in the following: <h3><i class="icon-thumbs-up"></i>Declarative is Good</h3> But the i18n translator did not apply the translation from the bundle. Based on the current rules, the scanner was in error. Based on the new rule I'm proposing, the scanner was correct but the runtime translator was in error. :-) j. I *love* the _missing JSON file that appears under .errai. Brilliant! -Jonathan On 2013-04-03, at 4:23 PM, Eric Wittmann wrote:

Nice work, Jonathan. Thoughts inline... On 04/05/2013 06:38 PM, Jonathan Fuerth wrote: +1 - awesome As long as there is an i18n attribute that takes precedence (e.g. data-i18n-key="blah") I don't see why we couldn't exclude certain elements from the heuristic. That said, once Errai supports id and css based @DataField, the heuristic won't work as well. I'm all for this. The @Bundle annotation is really more of a holdover from when I was trying to implement this as a decorator. If you add 'data-i18n-key="my-custom-key"' to the <p> element of that single thought, then the entire thing will get translated - mixed content or no. In addition, I'm setting the innerHtml, so any mixed content in the translation will work. Sort of the opposite of your suggestion of a data-inline attribute. I believe placeholder and title attributes are already being picked up as translatable. +1 +1 - the default translation file is especially less useful if the @Bundle annotation goes away (which I think it should). +1 - I hadn't considered live-updating the DOM with the new language. But there's certainly nothing stopping this. I suspect this is a jtidy issue. I believe jtidy will do all kinds of shennanigans with the HTML. Perhaps there are some flags that will minimize that. :)