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. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/rVDWzsfG4lMJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
