[errai-dev] ErraiUI and i18n

Jonathan Fuerth jfuerth at redhat.com
Wed Mar 13 11:38:18 EDT 2013


On 2013-03-12, at 4:23 PM, Eric Wittmann wrote:

> 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.

I'd also prefer one bundle per GWT module.

> 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?

Yes, Errai UI templates are included via GWT resources. I think this makes sense for translations, too. The problem with requesting them dynamically is that it we'd need another roundtrip to the server after page load before any UI can be displayed. Not a great thing to plan for, IMO.

> 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.

I hadn't thought of that, but good point. I'm not sure it would be harmful, really... if anything it could lead to some interesting techniques. :)

> 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.

That sounds like it could be inconvenient. Let's try it in some "real" apps whichever way you think is best, and then revisit.

> 3) Not sure how easy it will be to generate the translation report @ 
> compile time - though I agree it's a great feature.

It should be pretty easy as long as we can parse the language files at compile time.

-Jonathan

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




More information about the errai-dev mailing list