[errai-dev] Pull Request: i18n support

[Erik Jan de Wit]

Hi,


> 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…

One possible solution would be to define elements that are to define that some elements are always treated as inline instead of needing to declare them by hand.
<em> (emphasized text)
<strong> (important text)
<mark> (marked/highlighted text)
<cite> (the title of a work)
<dfn> (a definition term)
<i> tag is usually displayed in italic
<b> tag is usually bold
And maybe even span, although that can be a scary one.

> 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.


+1 placeholder and titles need translation 99.99% of the times in my experience.

> 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.

Or at least a way to get a list with the available translations. That way one can wrap them into a template and have them output as a select or a list of links. And when a language is added there is no need to change anything on the client.

for example:

@Inject
private List<String> supportedLocales;

and then have a template render it.

@Inject @DataField ListWidget<String, LanguageSelectWidget> langaugeSelectList;

Cheers,
	Erik Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/errai-dev/attachments/20130408/405909b9/attachment.html