Re: [errai-dev] Pull Request: i18n support
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
Attachments:
- attachment.html (text/html — 5.2 KB)