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