[errai-dev] Pull Request: i18n support

[Jonathan Fuerth]

On 2013-04-08, at 2:40 AM, Erik Jan de Wit wrote:

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

I expect this would work well in the majority of cases, and maybe that's all that matters.

My concern with this approach is that it moves us from the place where there is a very simple rule ("unless I say otherwise, every textual fragment under a non data-field element is translatable") to a place where we have to list the special exceptions to the rule. Check out the list of inline HTML 5 elements (under the heading "Text-level semantics" here: https://developer.mozilla.org/en/docs/HTML/HTML5/HTML5_element_list

I suppose you could argue we've already broken the ice on special exceptions for placeholder and title attributes.. but this is a much longer list.

What does everyone else think?

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

Turns out this is already working, I was already using it, and I hadn't even noticed. :)

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

Yeah, that sounds like a reasonable approach too, especially if the "live DOM update" behaviour gets put into TranslationService.setCurrentLocale().

-Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/errai-dev/attachments/20130408/5160e3d5/attachment.html