Adding overrides to Constants/ConstantsWithLookup/Messages

[Jeff Larsen]

@John Tamplin

We're writing a highly internationalized app but one where we need to be able to sub out some industry specific terms based upon user requirements. For a very contrived example, lets say you have a menu, and company 1 in English wants to call the menu "Menu" and company 2 wants to call the menu "Chooser." (Note: calling our clients idiots and telling them they're stupid for wanting the word Chooser is not an option)

I've rebound Constants and ConstantsWithLookup to look in a locale cache first, before using the localized text. MessagesMethodCreator is a bit trickier. It looks like the message gets pretty mangled from its original "some text {0} more text" format. First, am I correct with that assessment, and 2 is there a relatively easy way of changin "Foo {0}" into "Bar {0}" at runtime?

[Jeff Larsen]

After looking at the output of Generated Messages files, it looks like I'm going to have to write my own parser to handle these types of situations creating some kind of cache parser.

Btw, this code generates 

@DefaultLocale("en")

public interface FooMessages extends Messages {

    

    public enum Gender{

        MALE, FEMALE, UNKNOWN;

    }

    @com.google.gwt.i18n.client.Messages.AlternateMessage({"one", "You have one tree."})

    @DefaultMessage("Some Message {0}")

    String message(@PluralCount int param);

    

    @com.google.gwt.i18n.client.Messages.AlternateMessage({"MALE", "Some other Message Male {0}", 

        "FEMALE", "Some other Message Female {0}"})

    @DefaultMessage("Some Other Message {0}")

    String otherMessage(int something, @Select Gender message);

    

    @DefaultMessage("{0} gave you their credits.")

    @AlternateMessage({

        "MALE", "{0} gave you his credits.",

        "FEMALE", "{0} gave you her credits."

    })

    String gaveCredits(String name, @Select Gender gender);

}

Generates

package com.hello.client;

public class FooMessages_en implements com.hello.client.FooMessages {

  

  public java.lang.String message(int arg0) {

    java.lang.String returnVal = null;

    int arg0_form = new com.google.gwt.i18n.client.impl.plurals.DefaultRule_en().select(arg0);

    switch (arg0_form) {

      case 1:  // one

        returnVal = new java.lang.StringBuffer().append("You have one tree.").toString();

        break;

    }

    if (returnVal != null) {

      return returnVal;

    }

    return new java.lang.StringBuffer().append("Some Message ").append(arg0).toString();

  }

  

  public java.lang.String gaveCredits(java.lang.String arg0,com.hello.client.FooMessages.Gender arg1) {

    return new java.lang.StringBuffer().append(arg0).append(" gave you their credits.").toString();

  }

  

  public java.lang.String otherMessage(int arg0,com.hello.client.FooMessages.Gender arg1) {

    return new java.lang.StringBuffer().append("Some Other Message ").append(arg0).toString();

  }

}

Note the lack of complete ignoring of the @Selector (gaveCredits is a complete copy/paste from http://code.google.com/webtoolkit/doc/latest/DevGuideI18nMessages.html)

[John A. Tamplin]

BTW, I don't regularly read this group (too much traffic, I do read GWTC though), so if you have a question for me specifically you should email me directly.

Regarding the @Select bug -- that was fixed in trunk a few weeks ago and will be in 2.4.

Basically, you want dynamic i18n and all of this functionality is performed at compile time.  You won't be able to substitute different messages at runtime, as there is no parsing of the format pattern at runtime at all.  Even if you port that code, hat would then bring in all possible message format code, since you don't know what will be needed until you parse the format patterns.  Also, you would have to replicate a ton of code to fully implement all of the functionality in client-side code.  This is basically why we don't support String.format -- the code itself is large and winds up pulling in lots of other code.

You can write your own dynamic i18n code (there may be external libraries for this already), but see the caveats above -- if you only support limited subsets, it might not be too  bad.  Another option would be to deploy different compiled versions for each of your clients.