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/ce881d05b61406c8fe4f02691c8f899cae6e4380

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