Dealing with UiBinder i18n properties files is kind of a nightmare

[dankurka]

Originally reported on Google Code with ID 4355

[As discussed in the comments section of http://code.google.com/p/google-
web-toolkit/wiki/UiBinderI18n]

1. Getting i18n properties files to work at all requires too many magical 
attributes to be set on the <ui:UiBinder> element. The common use case should 
be much easier to find.

2. Users are required to know the name of the generated Messages interface. 
They either should not need to know it, or at least should be able to control it. 

Reported by rjrjr@google.com on 2009-12-14 22:43:10

[dankurka]

Also noticed that the properties file is *not* generated if my module has a specific

locale named, e.g.:

<set-property name="locale" value="en" />

If I remove this, then I get a generated file.  Unfortunately this means I have to

endure a very long compilation process just to get a properties file.

Reported by chris.lowe.uk on 2010-01-03 19:35:31

[dankurka]

for me this didn't work until I added the magic '-soyc' parameter to my compiler
options. By 'didn't work' I mean that no properties files has been generated. This
is
totally unintuitive and not documented anywhere (only mentioned once in the linked
discussion by chris.lowe.uk). I'm using the 2.0 release version. Is this a bug?

Reported by googelybear on 2010-01-11 14:33:26

[dankurka]

I'm also struggling with the same issue. I couldn't get it running after having
generated the properties files with the 'soyc' switch mentioned above. Where should
I
put the properties files afterwards? I'm sorry I'm a bit lost here as I couldn't find
any proper doc for this (also not in the official documentation at
http://code.google.com/intl/de-CH/webtoolkit/doc/latest/DevGuideUiBinderI18n.html).
Thanks a lot!

Reported by ledannibliss on 2010-01-11 15:35:42

[dankurka]

@ledannibliss - If your UiBinder file is called, say, 'LoginView.ui.xml' then call 
the properties file LoginViewLoginViewUiBinderImplGenMessages.properties (yes 
'LoginView' appears twice) and put it next to the view's java file in the source 
package, so altogether you'll have 3 files:

LoginView.ui.xml
LoginView.java
LoginViewLoginViewUiBinderImplGenMessages.properties

Reported by chris.lowe.uk on 2010-01-11 17:03:50

[dankurka]

great, thank you very much! That worked, that idea would have never occurred to me
that I have to rename those generated files.
BTW is it possible to have a single properties file that contains all the localizable
texts instead of having them spread out everywhere in the ui (sub-)packages? This
properties file could then ideally also be used to programmatically access it using
the com.google.gwt.i18n.client.Constants 'approach' (e.g. when not using uiBinder)
with the goal to have a 'unified' approach.

Reported by ledannibliss on 2010-01-11 17:44:07

[dankurka]

I'm using eclipse to build the project with the same .properties issue... How do I
add the '-soyc' parameter in eclipse?

Need I to use '-soyc dirname' or just '-soyc'?

Thanks and sorry for the dummy question :)

Reported by franzbischoff on 2010-01-11 19:19:15

[dankurka]

@ledannibliss - not sure on the unified approach, maybe that's one for another issue?

@franzbischoff - just "-soyc" (story of your compile), I also found that "-extra 
<directory name>" also worked and will be less cpu/memory intensive than -soyc.

Reported by chris.lowe.uk on 2010-01-11 19:25:27

[dankurka]

thanks :), but where in eclipse's menus I add this '-soyc'? I searched around and
found no place to set it...

Reported by franzbischoff on 2010-01-11 19:29:09

[dankurka]

When you select the red compile button from the toolbar, you'll get the GWT Compile

dialog.  At the bottom of this dialog there is an Advanced section.  Expand that and

add your parameters to the "Additional compiler arguments" section.

Reported by chris.lowe.uk on 2010-01-11 19:44:51

[dankurka]

Great!!! Thanks a lot :)

But interesting... now the compiler created lots of unwanted files in a new "extra"
folder... well, the world isn't fair :) at least I have the .properties file :)

Reported by franzbischoff on 2010-01-11 19:53:05

[dankurka]

You don't need the extras stuff all of the time - I just use it when I need to generate

properties files.

Reported by chris.lowe.uk on 2010-01-11 19:56:09

[dankurka]

if all we need are the properties files, which we have to rename, move and update 
ourselves anyway why do we need this rather complicated process? They're just regular

properties files...no magic at all...we can easily create them ourselves, what's the

advantage of having them generated? I mean the content in them has to be 
translated/replaced anyway...and the generator just creates new ones with the default

values not even taking into consideration already translated values....or am I no seeing

something here?

Reported by googelybear on 2010-01-11 22:22:22

[dankurka]

The point is when you want to take your untranslated strings and get the translated,

you have to have a way to do that.  This is not a full translation system, but a 
necessary piece (the alternative would be to write some code that looks for GWT-style

messages in the Java/UiBinder/etc source to produce your translatable files).

Reported by jat@google.com on 2010-01-11 22:51:58

[dankurka]

@googelybear Hi, you need to use the MD5 hash GWT creates. If you use any other
value, the string will not be localized. So you need to get the generated file to
know the what is the HASH GWT will use for that strings.

Reported by franzbischoff on 2010-01-11 23:01:20

[dankurka]

ok I see so this a one-time pass-through process and NOT an iterative process 
(which I assumed it would be). Isn't that problematic? It imposes the restriction that

the complete (!) code of a project must be finished before the translators can start

working. Example: Dev team finishes Milestone1, generate properties files. 
Translaters translate. Dev team adds new translatable content, generate properties

files (they will now have the default content). Translaters will have to perform 
cumbersome merging between the properties files that contain already translated 
material from M1 and the new properties. I hope I'm wrong here and be thankful if 
somebody could shed some light in the dark here. 

Reported by googelybear on 2010-01-12 09:53:02

[dankurka]

@googelybear Get this example:
<div><ui:msg description="Greeting">Hello, world.</ui:msg></div>

GWT generates a MD5 hash for the "Hello, world." string that is used in the "default"

locale (when system cannot find a proper locale). If you do not change the "Hello,

world." string, the MD5 still the same forever, and you can distribute the 
.properties files to translators normally.

If you create other versions of .properties files that just add another strings, its

ok, just give the updated files to the translators. But if you *change* an existing

string, you need to tell translators that the MD5 key for that string also changed.

Maybe we don't need the auto generated file, maybe is just matter of use a 
MD5(string) function to get the proper key... I didn't test the GWT algorithm yet.

Reported by franzbischoff on 2010-01-12 12:26:29

[dankurka]

Just tested at http://www.miraclesalad.com/webtools/md5.php
the MD5 generated there is the same as GWT generates. So we can build a manual 
.properties files. But, still we need to know the generated file name. Well this you

can see at normal building output. Just grab that .properties name, and create a file

with the same name plus the _en or _es, _de (whatever you need) at the same level as

your .java class.

Besides, you need to configure properly your .gwt.xml file to specify the locales you

want to build.

Reported by franzbischoff on 2010-01-12 12:55:46

[dankurka]

Note that, despite not being documented, you can actually use a key="" attribute on

<ui:msg> to provide the key yourself, instead of having it generated by the 
ui:generateKeys="" generator.
Just as ui:generateKeys="" is the equivalent of the @GenerateKeys annotation on a 
LocalizableResource (Constants or Messages), <ui:msg key=""> is the equivalent of the

@Key annotation.
There's also an undocumented ui:defaultLocale="" attribute (to be placed on the 
<ui:UiBinder> root element alongside ui:generateFormat="" and the like) to specify

the @DefaultLocale.

Reported by t.broyer on 2010-01-12 15:53:35

[dankurka]

There is a wide spectrum of solutions to how to handle translations, based on the 
effort you are willing to spend across a number of products, how many products you

have to translate, etc.  GWT isn't going to solve the problem for you, but instead

provides the tools to do it for you.

At the low end, you probably don't care about any hashes (the default of unqualified

method name is probably sufficient) and you just maintain property files.  I do this

myself, and check the generated properties files into source control, and after I 
make some change to a translatable string or add one, I just diff the old version 
with the new one and send it to a friend who translates it for me.  If you have 
multiple developers, it would be easy to automate this process in your build system.

If you have more products to localize, you probably have lots of different sources

you need to extract translatable text from such as HTML, server-side Java, etc, and

then you want to share translations across multiple products.  Here, using the hash

of the the message (which includes the meaning text if present, so you can 
differentiate "orange" the color from "orange" the fruit) helps solve the problem.

You will probably run the generated files through a translation memory, store them

into a database, and send untranslated messages off to a translator, whose 
translation winds up in the database, and periodically you extract translations from

the database to build the localized GWT app (and others).

In either case, GWT is just providing the way to get translatable text out of your

app and translations into the build process, but you are going to have to write some

glue yourself to integrate it with whatever system you are using.  That glue can be

very simple (in my case svn and a perl script), or it can be quite complicated.

Reported by jat@google.com on 2010-01-12 16:06:14

[dankurka]

This is how I would like it to be:

src/com/foo/client/MyWidget.java:
.....

src/com/foo/client/MyWidget.ui.xml:
<ui:UiBinder *IMPORTS* *GEN_FORMAT* *GEN_LOCALES(default)*>
  <div><ui:msg key="title" description="The title">Title message</ui:msg></div>
</ui:UiBinder>

Source folder I18N (containing the translation files):
i18n/

1. I compile my project.
2. Default language properties files is generated into /i18n/ (overwrites any
existing file/property), and hence creating:

i18n/com/foo/client/MyWidget.properties:
# Generated from com.foo.client.MyWidgetMyWidgetUiBinderImplGenMessages
# for locale default

# Description: The title
title=Title message

3. I send my properties file for translation
4. I put my translated file into:

i18n/com/foo/client/MyWidget_sv_SE.properties:
# Description: The title
title=Titelmeddelandet

5. I compile my application once again
6. I go to my application and sets the locale to "sv_SE"
7. My title says: "Titelmeddelandet"

Something like this would be very nice! If this is doable today, please help me by
answering these questions:

1. How do I generate (default language) properties files into my /i18n/ source folder
on compile (or even better; by simply rightclicking my MyWidget.ui.xml file in eclipse)?
2. How do I get the compiler to use the MyWidget_sv_SE.properties file from the
/i18n/ source folder when compiling permutation for locale "sv_SE"?

We have a very large application built on GWT 1.7 translated into 43 langauages where
each language has about 800 properties. Re-translating the application for each
language is NOT an option. :) UiBinder rocks!!! ...except for this "little" I18N
thingy...

Reported by thobias.karlsson on 2010-01-12 19:29:43

[dankurka]

From what i read this UiBinder translations seems odd. First the guys in my team who
where trying to figure out the properties generation went bananas before i got the
problem to solve myself.

This file generation problem is secondary to me (but personally i think it should be
made clear that you need to compile with a -extra parameter to get them instead of
looking for the -aux directory, since in most operating systems it will be hidden
deep down in some remote directory tree.) since it is not required to solve the i18n
problem. Here we are using a hand made property file for i18n and setting the key
value manually in the <ui:msg>.

So my problem is that not only my property files must have an incredibly complex name
but also i need one set of property files for each uibinder (right now we have one
main and 2 other for components and we are just starting the translation of the
project to GWT) thus having to manage several new files and making my translators
nuts (since they translate directly in the file words that repeat on each binder
needs to be double translated).

My proposition is that the UiBinder should respect the property ui:generateFilename
(or some other property since the double meaning for this tag could bring different
problems in the future) when looking for an i18n file, including packages (i.e.
"i18n/Messages"). That way we could point all uiBinders to the same files (including
my com.google.gwt.i18n.client.Messages implementation).

For the future we could use a functionality that read these already translated files
and merge them when generating the property files during compile. That way if i
already translated the property B24A02C484F383E I wont have to re-translate it or use
a secondary system to manage the translation.

I used to translate the google site to Portuguese back when the "Google in your
language" program were open so i kinda see the purpose of the generated files but to
the majority of developers out here it is kinda pointless.

I think the documentation should also be reviewed since it doesn't say anything about
where should i put the translation files, what name should they have or anything like
"ok, i generated the files, what now?").

Reported by alvaroludolf on 2010-01-18 21:33:35

[dankurka]

One point that may not be clear -- i18n property file lookup walks up the locale 
inheritance tree as well as the class inheritance tree.  Since all the 
constants/messages (including those generated by UiBinder) inherit from 
LocalizableResource, you can have a single set of property files for all your 
translations -- just name them 
com/google/gwt/i18n/client/LocalizableResource_<locale>.properties for each locale.

Obviously, if you do this your keys have to all be unique -- the easiest way to do

that is to use a key generator that computes a hash like MD5, but other ways work 
too.

I agree UiBinder needs some way to specify the generated names, and that we need to

make clear -extra is needed for any generators that produce non-deploy artifacts that

you need to reference in external systems (such as the i18n with @Generate).

Regarding where to put the files, is the javadoc on Constants (which is also 
referenced from the Messages javadoc) not sufficient?

Reported by jat@google.com on 2010-01-18 21:53:26

[dankurka]

I totally agree with alvaroludolf - this is exactly what I would need as well!  

Jat: Thanks for pointing this out! - at least for me this was not clear at all. I will
try to 
use this workaround in the meantime in order to maintain a single set of properties
files 
and prevent duplicate translations. Is there

Reported by googelybear on 2010-01-18 23:13:39

[dankurka]

The approach indicated by jat seems to work. When using uibinder AND constants
interfaces together I end up having a Constants interface defined in
org.example.client.resources.MyTexts. but the properties files are located in
com/google/gwt/i18n/client/LocalizableResource_<locale>.properties (which is also
accessible from the uibinder templates). This seems a bit awkward at least to me, how
do you handle this? Another drawback is that I can no longer use the
com.google.gwt.i18n.tools.I18NSync tool to generate the Constants interface class.

Reported by dennis.rietmann on 2010-01-19 10:45:41

[dankurka]

The name of the generated .properties file is decided by the MessagesWriter class in
gwt-dev.jar lib. 

Am I able to override this class when compiling? (It does not work with classical
<replace-with ...><when-type-is ...> in module.gwt.xml, I've tried.)

If this is doable, how do I get GWT to read from these new locations when compiling
the ui.xml files?

Location of MessagesWriter:
com.google.gwt.uibinder.rebind.messages.MessagesWriter

Reported by thobias.karlsson on 2010-01-19 13:58:09

[dankurka]

Trying to find out how to i18n widget's attributes. All the examples I've seen so far
only deal with body text.

Let's say I have:

<g:Button text='Click me' title='Click me'/>

How can the text and title attributes be i18nized in this case?

Reported by urgisb on 2010-01-20 01:40:11

[dankurka]

@urgisb

Have you reviewed the UiBinder doco? Have a look to 
http://code.google.com/webtoolkit/doc/latest/DevGuideUiBinderI18n.html#HTML_attributes
_that_need_translation

Reported by luismahou on 2010-01-20 01:44:34

[dankurka]

This issue is flagged as an enhancement, but de minimus a docs bug: given current
published code and docs the uninitiated developer is unable to use UiBinder i18n
without perusing this bug thread and hacking such well-intended and perhaps
once-correct but now partially-correct advice as appears in <a
href="http://code.google.com/p/google-web-toolkit/issues/detail?id=4355#c4">Comment
4</a>. 

Reported by steve.mook on 2010-01-25 05:28:24

[dankurka]

Could somebody post here what's the correct alternative to comment 4 (re the naming
of the properties files)?

Reported by fkereki on 2010-02-15 02:52:27

[dankurka]

According to experimentation, it seems that for

/testi18n/src/com/kereki/testi18n/client/Example.ui.xml

the resource bundle for, say, british english, should be at the same directory, but
named ExampleMyUiBinderImplGenMessages_en_GB.properties.

Reported by fkereki on 2010-02-15 03:09:44

[dankurka]

I used the trick by @dennis.rietmann and put all my translations for a given locale
in 
a single file: com/google/gwt/i18n/client/LocalizableResource_<locale>.properties ,
it 
works perfectly! My property file combines MD5 hashes generated by UIBinder with my
own 
(simple text) keys for static string constants. The only thing I would need is some

script that would look in the 'extra' directory for all the UIBinder generated property

files, and merge them within their respective 
LocalizableResourcegoes_<locale>.properties file... Possibly warning on unused 
translations. If anybody writes that scrip before me, please post it here!

Reported by philippe.beaudoin on 2010-02-25 16:31:30

[dankurka]

How is it going with this issue? Has anybody come up with an "acceptable" solution?
Can't imaging why this issue is not more prioritized, how are companies going to
create large scale applications using UIBinder if it is a nightmare to
internationalize it?

Reported by thobias.karlsson on 2010-02-26 07:17:48

[dankurka]

I worked around it - at least partially. I created a Label subclass that has access
to a 
ConstantsWithLookup via DI (I'm using Guice) and then I can set the message key in
my 
ui.xml file.

The only problem is that it only works for static messages i.e. cannot use {0} in 
messages. For those I still use code i.e. not declarative.

Its good enough till this infra gets sorted out. 

Reported by steve.buikhuizen on 2010-02-26 07:34:22

[dankurka]

I have written a Python script that does what I have proposed above: merge all the 
UIBinder generated properties into one central translation file per locale. It also

annotates required or obsolete translations. This makes the process of using UIBinder

+ Constant + Message almost painless.

I haven't tested the script thoroughly, but if you're interested you can get it from:
  http://code.google.com/p/puzzlebazar
Look for mergelocales.py. The script is fairly well documented, but you might want
to 
check the related wiki page:
  http://code.google.com/p/puzzlebazar/wiki/UiBinderInternationalisation
Comments welcome.

Reported by philippe.beaudoin on 2010-02-26 09:24:46

[dankurka]

How come there is no Google developer commenting this thread? Are they dodging it? ;-)

I'm more than willing to help out with solution proposals to this.

Reported by thobias.karlsson on 2010-02-27 08:03:48

[dankurka]

@Thobias Karlsson - look for comments by rjrjr@google.com, he's your G man on this 
issue.

Reported by chris.lowe.uk on 2010-02-27 08:48:24

[dankurka]

... and jat@google.com

Reported by chris.lowe.uk on 2010-02-27 08:49:48

[dankurka]

My proposition is that we all try to find a solution that would work for everyone.

Some of us wants one single file containing all translations, and some of us want to
be able 
to specify filenames for each UiBinder (to be able to translate only blocks/specific

UiBinders of the application). 

Personally I would prefer an attribute like "ui:msgFilename" which is used for both

generating files and for source on compile.

Example 1:
One properties file for multiple UiBinders.
ui:msgFilename="com.google.foo.Bar.properties"
(specified in both com.google.foo.BarOne.ui.xml and com.google.foo.BarTwo.ui.xml)

Generated into: 
/gen/com.google.foo.Bar.properties 
(or /gen/com/google/foo/Bar.properties)

When compiling, it should read translations from source package, e.g: 
/i18n/com.google.foo.Bar.properties
(or /i18n/com/google/foo/Bar.properties)
where /i18n/ is a source folder.

Example 2:
ui:msgFilename="default" or ui:msgFilename is not set
/gen/com.google.foo.I18N.properties
(which includes all translations for the module/application that has not specified

ui:msgFilename attribute)

Example 3:
ui:msgFilename="this"
Generated file should get the same name/package as the UiBinder file, e.g. for Bar.ui.xml:
/gen/com.google.foo.Bar.properties

The major problem as I see it is that the output from the file generation cannot directly
be 
used as source.

Reported by thobias.karlsson on 2010-02-27 13:19:57

[dankurka]

The first problem is that a generator cannot write arbitrary files -- it can only 
produce artifacts under the aux directory.  The second problem is that artifacts are

immutable once produced, so you can't have the generator append to an existing file
-
- if you want the outputs to be combined, there would have to be a linker or external

step in the build process that does that.  These limitations combine to reduce the

ability to accomplish everything people want to do in the i18n generator (UiBinder

just produces Java source for the i18n generator, so it can't do anything that the

i18n generator doesn't provide hooks for).

I don't understand what you mean by "The major problem as I see it is that the output

from the file generation cannot directly be used as source."

Reported by jat@google.com on 2010-02-27 14:07:04

[dankurka]

Sorry, I knew that I should have been more specific about that. :-) 

What I meant with "The major problem as I see it is that the output 
from the file generation cannot directly be used as source." is:

Let's say that I have a UiBinder file, com.google.foo.Bar.ui.xml
I compile my application with -extra, and it generates a properties file, e.g:

"com.google.foo.BarBarGenUiBinderImpl.properties" or something similar (I don't have
GWT 
installed on this computer)

Now, I translate it into swedish, e.g 
"com.google.foo.BarBarGenUiBinderImpl_sv_SE.properties"

This file will have to be renamed and split into package and file to get the compiler
to read 
from it when compiling, e.g:
File: BarBarGenUiBinderImpl_sv_SE.properties
Path: com/google/foo/BarBarGenUiBinderImpl_sv_SE.properties

What I meant was that it is a very large job to rename all these files and to put them
into 
the specific package. Please correct me if I'm wrong about this, because it took some
time 
just to figure out WHERE the properties file should be placed and what they should
be renamed 
into to get the compiler to use it as source file.

Reported by thobias.karlsson on 2010-02-27 14:47:47

[dankurka]

Works fine in Hosted Mode, Tomcat doesn't wanna know...

I was following the an internal wiki page that a colleague created a while ago.
It all went smooth in hosted mode ( http://localhost...&locale=it )

Tried the application running off Tomcat, it only picks up default locale, even if
I 
use Firefox locale switcher ( for example ). Other methods to set browser's locales

failed too.
Anybody had the same problem?

Thanks

Reported by dan.arbo on 2010-03-04 17:33:08

[dankurka]

@dan.arbo:

Unless you are doing something on the server like LocaleMatcher from incubator, 
changing the browser's locale has no impact.  The default GWT method is to get the

locale from the URL ie, (?locale=it) or from a meta tag in the host page (presumably

put there by your server).

Reported by jat@google.com on 2010-03-04 19:15:21

[dankurka]

@dan.arbo:

Currently there is no built-in support for the browser's locale. You have to do the
connection between browser locale and gwt locale yourself. E.g. I use this method to
get the browser locale and then set it accordingly in my app:

public static native String getBrowserLocale() /*-{
        if ( navigator ) {
                if ( navigator.language ) {
                    return navigator.language;
                }
                else if ( navigator.browserLanguage ) {
                    return navigator.browserLanguage;
                }
                else if ( navigator.systemLanguage ) {
                    return navigator.systemLanguage;
                }
                else if ( navigator.userLanguage ) {
                    return navigator.userLanguage;
                }
            }
    }-*/;

This has however the drawback that the app has to be loaded again (ugly)...has
soembody come up with a workaround for this problem yet?

I don't know why the gwt devs have decided to not support this, it is a functionality
that almost all internationalized apps use, as users are expectng to be greeted in
the language they set in the browser without the need to manually switch the language
first...or am I missing something here?

Reported by googelybear on 2010-03-07 11:24:14

[dankurka]

@googleybear

See issue http://code.google.com/p/google-web-toolkit/issues/detail?id=4228

The right place to put that code, so you don't have to reload your app, is in the 
locale property provider.

The downside is AFAIK, there is no way to get at what the browser sends to the server

in an Accept-Language header, so if you have a user you prefers German over French

and doesn't speak any other languages, you will only be able to get German.  If the

app was compiled in French and English, it will fall back to "default" which is 
probably English, so the user wants a language supported by the app but does not get

it.

Also, you don't want the full table of locale inheritance and aliases (for example,

suporting es_419 for Latin-American Spanish and knowing that es_AR maps to that 
rather than just es) to be downloaded to the browser, so I continue to think the best

place to do this is on the server, where you have access to the Accept-language 
header on request for the selection script and the full locale inheritance 
information.  Finally, for runtime locales support you really have to do the locale

selection on the server, since you are selecting two locales -- the one used to 
select the deferred binding locale, and the one used to select number/data/time 
formatting rules and the default currency.

One other point -- in your code above, the browsers use '-' to separate locale 
components, while GWT uses '_', so you will need to map it before using the result.

Please continue any discussion of this aspect on issue 4228.

Reported by jat@google.com on 2010-03-07 14:49:17

[dankurka]

Hi, thanks for your replies.

At the moment the application is calling a javascript function from within gwt.xml.
Which works without any problems in hosted mode, but deployed on Tomcat the same 
application behaves differently. Will give more details in issue 4228 as suggested.

Reported by dan.arbo on 2010-03-08 09:13:39

[dankurka]

Hi, thanks for your replies.

At the moment the application is calling a javascript function from within gwt.xml.
Which works without any problems in hosted mode, but deployed on Tomcat the same 
application behaves differently. Will give more details in issue 4228 as suggested.

Reported by dan.arbo on 2010-03-08 09:14:04

[dankurka]

I've been struggling with the generation of the properties files. Adding -soyc or -
extra makes no difference, the properties files are simply not created. Can somebody

PLEASE upload a skeleton uibinder i18n eclipse project for all of us to check out.

Reported by frogweb.at on 2010-04-27 10:32:38

[dankurka]

to craig@frogweb.at 

I use solution from Comment 4  by chris.lowe.uk,

Really, you need only these 3 files... I didn't generate the properties file. I
utilized "key" attribute in my ui.xml and the simple properties files..

For example, you have UserScreen.ui.xml... so you should create
UserScreenMyUiBinderImplGenMessages_en.properties file (file name is important!) with
simple structure (mainTitle = Данные пользователя)
After that you can write:
<ui:msg key="mainTitle" description="Maint title">User data</ui:msg>

Everything should work  

Reported by akorotenko11 on 2010-05-02 20:02:11

[dankurka]

Here is a step by step of how to get it working. 

I'm using Eclipse and I created a sample GWT project and created a UiBinder file 
called "HTMLPanelExample.ui.xml".

Open the module XML file and add the "extend-property" with the list of locales that

you need to support, example:

<?xml version="1.0" encoding="UTF-8"?>
<module rename-to='gwtsandbox'>
  <!-- Inherit the core Web Toolkit stuff.                        -->
  <inherits name='com.google.gwt.user.User'/>

  <!-- Inherit the default GWT style sheet.  You can change       -->
  <!-- the theme of your GWT application by uncommenting          -->
  <!-- any one of the following lines.                            -->
  <inherits name='com.google.gwt.user.theme.standard.Standard'/>
  <!-- <inherits name='com.google.gwt.user.theme.chrome.Chrome'/> -->
  <!-- <inherits name='com.google.gwt.user.theme.dark.Dark'/>     -->

  <!-- Other module inherits                                      -->

  <!-- Specify the app entry point class.                         -->
  <entry-point class='com.dummy.client.GwtSandbox'/>

  <!-- Specify the paths for translatable code                    -->
  <source path='client'/>

  <extend-property name='locale' values='en_US'/>
  <extend-property name='locale' values='es_MX'/>
</module>

Then open "HTMLPanelExample.ui.xml" and follow the instructions on the UiBinder i18n

guide, this is an example of how it should look like:

<ui:UiBinder xmlns:ui='urn:ui:com.google.gwt.uibinder'
             ui:generateFormat='com.google.gwt.i18n.rebind.format.PropertiesFormat'
             ui:generateKeys="com.google.gwt.i18n.rebind.keygen.MD5KeyGenerator"
             ui:generateLocales="default"
             xmlns:g='urn:import:com.google.gwt.user.client.ui'>

  <g:HTMLPanel> 
    <ui:msg description="My hello world optional description">Hello world!</ui:msg>

  </g:HTMLPanel>
</ui:UiBinder>

Compile the project using the "-soyc" (story of your compile) flag, in Eclipse, click

on the "red" compile button, in the dialog that pops up, click on the "advanced" and

add the "-soyc" under "Additional compiler arguments", then compile.

If everything is going OK so far, you should see something like this in the console:

Compiling module com.dummy.GwtSandbox
   Scanning for additional dependencies: 
generated://BF196BE6B36139F72326A790BC092A68/com/dummy/client/HTMLPanelExample_Binder
Impl.java
      Computing all possible rebind results for 
'com.dummy.client.HTMLPanelExampleBinderImplGenMessages'
         Rebinding com.dummy.client.HTMLPanelExampleBinderImplGenMessages
            Invoking com.google.gwt.dev.javac.StandardGeneratorContext@12193ae
               Generating 
com.dummy.client.HTMLPanelExampleBinderImplGenMessages.properties from 
HTMLPanelExampleBinderImplGenMessages_ for locale default
   Compiling 18 permutations
      Compiling permutation 0...

Once it finished compiling, go to the folder where you have your GWT project, you 
should have an "extras" folder, inside you should have a folder named after your GWT

project and inside it you should find a properties file, in my case I had a file 
called "com.dummy.client.HTMLPanelExampleBinderImplGenMessages.properties".

Rename that file to just "HTMLPanelExampleBinderImplGenMessages.properties" and place

it in the same folder where "HTMLPanelExample.ui.xml" is located.

Create a copy of that properties file for each supported locale, example, I want to

support both English and Spanish so I ended up with 3 files:
HTMLPanelExampleBinderImplGenMessages.properties
HTMLPanelExampleBinderImplGenMessages_en_US.properties
HTMLPanelExampleBinderImplGenMessages_es_MX.properties

Obviously open the "es_MX" and translate it, here's what it looks like:

# Generated from com.dummy.client.HTMLPanelExampleBinderImplGenMessages
# for locale default

# Description: My hello world optional description
86FB269D190D2C85F6E0468CECA42A20=Hola mundo\!

Then you need to compile one more time.

Now debug your project so GWT launches the web server, append the locale parameter
to 
the url and you should have your message i18n'ed!

Example:
http://127.0.0.1:8888/GwtSandbox.html?gwt.codesvr=127.0.0.1:9997

Will show the "Hello world!"

http://127.0.0.1:8888/GwtSandbox.html?gwt.codesvr=127.0.0.1:9997&locale=es_MX

will show the "Hola mundo!"

I hope this helps...

Reported by carlos.aguayo on 2010-05-06 21:01:15

[dankurka]

Thanks for this post, Carlos. Very helpful. 

If others out there are interested in a single-.properties-file solution to i18n in
ui:binder, i would highly recommend philippe beaudoin's mergelocale.py script:

http://code.google.com/p/google-web-toolkit/issues/detail?id=4355#c40

It takes all your disparate *.properties files as generated by -soyc compilation and
merges them together into one LocalizableResources.properties file. 

I was able to get it running in our project almost instantly and it works perfectly.

Reported by euzuro on 2010-05-06 22:41:57