5:33 p.m.
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
3:20 p.m.
Thanks for the write-up, Jonathan.
I've put this on my to-do list and will get on it as soon as I can.
Will report back once I have something worth you guys tearing apart. :)
-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
3:23 p.m.
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
10:38 a.m.
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/errai-dev
>
_______________________________________________
errai-dev mailing list
errai-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/errai-dev
11:54 a.m.
Responses also inline, snipping for readability. :)
On 03/13/2013 11:38 AM, Jonathan Fuerth wrote:
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.
I think there are solutions to this problem, though that doesn't mean I
disagree with you. :) That said, if I use GWT resources I'm worried
that *all* translations will get pulled down (even if all at once).
That's potentially a lot of data that won't be used. I'm not sure if
this is true or if this is a problem even if true.
> 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.
okey dokey
> 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.
Yes, I agree - exactly my point. At runtime the template is parsed by
the browser, which is pretty darn good at that sort of thing (and is
also rather lax about syntax errors). At compile time we won't have the
browser available, so parsing will be different. Just something I'm a
little worried about, that's all.
Here's another question: what do we do about Elements that contain both
text nodes and child elements? For example:
<div>This is something I <b>really</b> like!</div>
What i18n keys does this create in the bundle? Possibilities are:
== Possibility #1 - each text node is an entry in the bundle ==
This_is_something_I_=This is something I
really=really
_like_= like!
== Possibility #2 - only leaf nodes get translated ==
really=really
If we go with #2 then users could override with:
<div data-i18n="my-key-name">This is something I <b>really</b>
like!</div>
With a bundle that looks like:
my-key-name=This is something I <b>really</b> like!
I think I favor the latter (only leaf elements with *only* text nodes
get auto-translated). That probably handles the 80% case. Then
data-i18n can be used to override that behavior. As I visit the DOM I
will stop as soon as I encounter a data-i18n attribute.
-Eric
4301
days inactive
4313
days old
4 comments
2 participants
participants (2)
-
Eric Wittmann -
Jonathan Fuerth