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