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_______________________________________________
errai-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/errai-dev
