Alright, so I've started looking at this (thinking, mostly) and have
some comments. At this point I think the most important thing (in terms
of getting me going on this) is the bundle file itself. Need some
decisions on that score.
Where should the message bundle be located, and how should it be pulled
into the app?
I think we're all leaning towards i18n being a feature of Templating
specifically (at least for the first impl). In that case, I think we
should either have one message bundle per module *or* one message bundle
per template.
Any votes? I think I favor the former.
Should I be bringing in the bundle the same way the template itself is
included? I don't know what that is yet, but I assume it's some sort of
GWT resource. Alternatively it could be pulled down dynamically in some
way. Are there concerns that doing the former will result in *all*
bundles (each language) being pulled down by the browser? Or is there
some way to make sure that doesn't happen?
Thoughts?
Other random thoughts from me:
1) If we allow the i18n key to be specified in an annotation in Java
then, since templates *may* be used by multiple classes, there exists
the possibility that the same data-field in the template would result in
multiple keys to translate. Maybe not a big deal - sounds like a
"Doctor, it hurts when I..." situation.
2) If we don't allow data-i18n in the template, then we would need to
@Inject a data-field just to change the i18n key name.
3) Not sure how easy it will be to generate the translation report @
compile time - though I agree it's a great feature.
-Eric
On 03/01/2013 06:33 PM, Jonathan Fuerth wrote:
Hi all,
Eric Wittmann has volunteered to implement proof-of-concept
internationalization features in ErraiUI. To get things going, he asked
me to sum up the conversation we had on a GitHub pull request[1]. Here's
my summary, as I understand it.
Goals:
* Must not compromise on 'designer templates:' the template must be
100% valid HTML5 and render properly in a browser as-is.
* Aim for least possible amount of boilerplate in the common case: if
I18N is invisible on 80% of the fields it affects (both Java side and
HTML side) then we're winning.
* At compile time, we'll generate reports on the state of each
translation: for each language, which translations are missing and which
are orphaned? If this is summarized numerically in a .properties file,
it's trivially easy to track in Jenkins with the Plot plugin[2].
* Must be able to substitute different images based on user's language
* Ability to translate both text within an element as well as
attribute values in tags
* Should accommodate simple HTML markup within messages (eg. anything
SafeHtml would allow)
* Support user selection of language independent of what the
accept-language header says
Non-Goals:
* We're not attempting to define something that works outside of Errai
UI templates and @Templated classes
* We're not considering the ability to define structurally different
page layouts based on locale (Android can do this with its resources system)
* We're not talking about reacting to anything except the user's
language preference (again, Android's resource system supports varying
resources based on screen size, resolution, language, country, and lots
more besides)
Open Questions:
* Should we use GWT's message resource file format?
* When/if we specify a key, should it be in the template file (eg, as
a data-i18n="message.key" attrbute) or in the Java class (as an
@I18n("message.key") annotation on the @DataField)? ewittmann originally
proposed the attribute-in-template approach, and okrasz and w0mbat
expressed a preference for that too.
* How will we handle interpolation into messages (for example Hello
{name}. Pleased to meet you!)? Most importantly, where do the values
come from?
* (How) do we handle special numeric formatting like $0.00 in the USA
vs. 0,00€ in Europe? It seems we may need a mechanism to call out to
GWT's number formatting classes
Based on all that, here's a strawman proposal to get us started (lifted
from Eric's comment):
Java:
@Templated
public class MyPage extends Composite {
@Inject @DataField("field1")
private Label contentBecomesKey;
@Inject @DataField("field2") @I18n("mypage.description")
private Label keySpecifiedInAnnotation;
@Inject @DataField("field3") @I18n(value="mypage.input",
attributes={"placeholder", "title"})
private Text inputBoxWithTranslatedTooltipAndPlaceholder;
// I don't think this will actually work well. It's just here for the
sake of argument.
@I18nParams
private Map<String, SafeHtml> messageKeys;
}
Template:
<div data-field="templateId">
<div data-field="field1">MyHeader</div>
<div data-field="field2">This is a lengthy description that I
don't
want becoming an i18n key.</div>
<input data-field="field3" type="text" name="field3"
placeholder="Enter
a value here" title="Use this data entry field to enter a valid value..."
/>
<div>Innocent Bystander</div>
<div data-field="field3">{name}, you owe {amountOwing}.</div>
</div>
Bundle for Piglatin translation:
MyHeader=yHeaderMay
mypage.description=Lorem ipsum dolor sit amet, consectetur adipiscing elit.
mypage.input.placeholder=Value here, you must enter
mypage.input.title=This data entry field, use you must...
Innocent\ Bystander=Innocentay Ystanderbay
So, thoughts?
-Jonathan
[1]:
https://github.com/errai/errai/pull/24
[2]:
https://wiki.jenkins-ci.org/display/JENKINS/Plot+Plugin
_______________________________________________
errai-dev mailing list
errai-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/errai-dev