i18n fallback not considered during compile but works in dev mode

[dankurka]

Originally reported on Google Code with ID 5769

Found in GWT Release (e.g. 1.5.3, 1.6 RC): 2.1.0

Encountered on OS / Browser (e.g. WinXP, IE6-7, FF3): All

Detailed description (please be as specific as possible):
in my module definition I define the locales like so:

  <extend-property name="locale" values="en"/>
  <extend-property name="locale" values="de"/>
  <set-property-fallback name="locale" value="en"/>

and implicitely disclose the 'default' locale by setting a fallback to 'en'. In my
Messages interface I dont annotate with @DefaultMessage nor I provide the Messages.properties
for the default locale, since there is none as I defined the fallback to 'en'.

While running in dev mode everything works as expected and GWT does not lookup for
the default locale properties.

But when I run the compiler I get following error:

------------------------------
      Computing all possible rebind results for 'kn.client.MyMessages'
         Rebinding kn.client.MyMessages
            Invoking generator com.google.gwt.i18n.rebind.LocalizableGenerator
               Processing interface kn.client.MyMessages
                  Generating method body for motd()
                     [ERROR] No resource found for key 'motd'
com.google.gwt.i18n.rebind.AbstractResource$MissingResourceException: No resource found
for key 'motd'
------------------------------

seems like the generator tries to lookup for default locale properties and ignores
the fallback parameter

Workaround if you have one:

create a dummy MyMessages.properties file or define dummy @DefaultMessage annotation
in the interface

Reported by eplischke on 2010-12-16 10:05:27

[dankurka]

ok here a workaround:

  <extend-property name="locale" values="en,de"/>
  <set-property-fallback name="locale" value="en"/>

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

Reported by eplischke on 2010-12-16 10:53:48

[dankurka]

I haven't set up a repro case, but based on your example and workaround, I think the
problem is you are still compiling the "default" locale, and it is failing to find
any messages.

The normal way you would do this is to put the source messages in annotations in the
Messages interface, and declare its language (via @DefaultLocale("en") for example),
then set the fallback to be "en".  Is there a reason you are avoiding putting the source
messages there?

Regardless, GWT should handle this situation better.

Reported by jat@google.com on 2011-01-05 01:52:07

• Status changed: Accepted
• Labels added: Category-I18N, Type-Defect

[dankurka]

I think I can confirm the above as we use GWT in a very similar way. Using those options
GWT will compile the "default" locale as well even though it is not used as far as
I can tell.

In our application there is a requirement to have all the messages for the application
in a single, easy to maintain place. This includes mostly UiBinder based messages but
also some messages taken directly from a Messages interface - for example some plural
forms which UiBinder doesn't support and also more business logic driven messages.

We already have to use the workaround of placing all our files at com.google.gwt.i18n.client.LocalizableResource_*.properties
to get this to work properly. Having the English - or any real default language - in
annotations in the interface just adds to the problem. I'm sure it's very useful in
particular situations, just not in ours.

The above workaround seems to work well and makes sure the unnecessary "default" locale
compile disappears so we also get the added bonus that compiles are quicker.

Reported by cknowles on 2011-01-13 15:03:45

[dankurka]

@jat

as for me, I would not bother about the issue with comipilation for a default locale,
but during that process the compiler forces me to provide keys for default messages
(either via annotations or via default properties file), regardless of setting the
@DefaultLocale("en") on the interface, right? I am integrating GWT into environment
where java localization is in place AND the properties catalogue is provided by third
parties so it would be best to embed them directly into compilation process w/o the
need of manually coding the messages into annotations. Also I failed with the i18n
creator (on windows), which should be able to create / sync interfaces with the properties
file, at least gwt 2.0.4, did not try it yet with 2.1

Reported by eplischke on 2011-01-13 15:54:49

[dankurka]

The workaround was necessary for me as well.

http://groups.google.com/group/google-web-toolkit/browse_thread/thread/cf0661dc2584ddcf

If you're curious, we have about 10,000 resources from an already localized application
that we convert to a format that GWT can use. It involves a script to split constants
and messages into two separate files. It also fixes some escaping issues that we were
running into (newlines and backslashes). Then we use com.google.gwt.i18n.tools.I18NSync
with the -createMessages flag when appropriate. We no not use UiBinder. We have our
own interface generator that we built before UiBinder existed.

Reported by pulazzo on 2011-03-01 17:40:21

[dankurka]

Is this still present with GWT 2.5.1?

Reported by dankurka@google.com on 2013-06-02 16:00:33

• Status changed: AssumedStale

[dankurka]

It appears this is still an issue in 2.5.1.

However I tried the reply #1 above, and it did indeed reduce the permutations from
15 to 10 (for my 5 browser types and 2 languages):

  <extend-property name="locale" values="en,es"/>
  <set-property-fallback name="locale" value="en"/>

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

It puzzles me why we need a redundant-looking line after the 'fallback' line, but it
does the trick.

Reported by reuben.sivan on 2013-06-12 22:25:51

[dankurka]

John, will you be able to address this in your I18N overhaul patch?
Maybe simply changing the error message when compiling for locale=default and there's
a fallback value?

BTW, the doc should also be updated to hint about using <set-property> to remove the
default locale entirely: http://www.gwtproject.org/doc/latest/DevGuideI18nLocale.html#LocaleDefault

Reported by t.broyer on 2013-06-13 10:13:41

• Status changed: Accepted

[dankurka]

@t.broyer - no, the shared i18n APIs change won't do anything about this.

Personally, I would like to see the "default" locale go away, and be just a reference
to some real locale that you are compiling for (and you could choose just "en" for
that if you want English with most-obvious date/time formats etc for when you have
no idea what country the visitor is coming from).  We talked about doing that about
5 years ago, but it was vetoed as too large a change.

The second phase of work I want to do, which is completely changing how i18n code is
generated (so that you can generate server-side implementations of Messages/etc as
well), could address this.  However, that isn't going to be anytime soon.

Reported by jat@jaet.org on 2013-06-13 17:22:44