Re: i18n Translations to String

[Jeremy Quinn]

Hi Vadim

Many thanks for you reply :)

On 17 Nov 2006, at 13:54, Vadim Gritsenko wrote:

Jeremy Quinn wrote:

Now I need to work out how to do the above from FlowScript, when my i18n messages may have parameters, eg :

:)

<message key="upload.progress.sent">Sent: {0}% ({1} of {2} bytes). Filename: {3}.</message>

I have not worked out yet how I18nTransformer does this ....

  Map parameters = new HashMap();
  parameters.put("1", "1234567");
  ...
  ParamSaxBuffer message = (ParamSaxBuffer) bundle.getObject(key);
  message.toSAX(handler, parameters);

All the work is done in ParamSaxBuffer. So instead of using XMLResourceBundle.getString(key), you should be using getObject(key): ParamSaxBuffer currently does not have toString(Map parameters) method in case if you want to get only text of the message, but between SaxBuffer.toString() and ParamSaxBuffer.toSAX(handler, parameters), I'm sure it won't take you long to implement toString (Map parameters). :)

Your confidence in my abilities makes me blush ;)

Actually, I have always found SAX programming to be a big of a mystery .... lets see how it goes :)

Ideally, one should be able to get a String which contains any tags that were in the i18n Message, as widgets may want to use these, by injecting them as InnerHTML.

You'd have to use some of those ContentHandler implementations which would serialize SAX events into String (using TrAX, or there is org.outerj.daisy.xmlutil.XmlSerializer from daisy-util.jar).

Makes sense ....

JSON Serialization, we need better solutions ....

But jexl does not like 'instanceof'.

I am currently using JXT for serializing the JSON Response (as this allows the use of XMLizable I18nMessage), but it is a pretty foul way of doing it. I am not sure that JXT is able to determine the class of Objects in a nice way, I tried this : <jx:when test"${item instanceof Packages.java.lang.Number}"> . . . </jx:when>

It's not Java ;)

or JavaScript ;)

This means that my serialization currently has to turn everything into a String. (yuk)

Try testing for a presence of a method? In JavaScript, you'd do

  if (item.toSAX) {
    // XMLizable
  }

XMLizable is not actually an issue, as JXT already handles this transparently, and I can safely output it between quotes, setting it up as a JSON String. More problematic from the PoV of using JXT are Numbers, Booleans etc. where to make a JavaScript primitive, you'd leave the quotes off, and stuff like Collections and Maps, where you need recursion. Hopefully, if we can get some kind of I18nMessage.toString() working, then we do not need JXT for the Serialization. But I see your point, if I am forced to use this approach, I need to identify signature methods that can be used to identify generic Objects.

What kind of Objects should we expect to be serializing to JSON ?

JavaScript: Objects, functions and primitives: should be easy once FlowScript is updated to have .toSource().

There is a vote going on about Rhino, which I think will effect this.

Java: Maps, Collections, Strings, Numbers, Booleans, Dates, primitives: use generic FlowScript (could be adapted from Dojo's code?)?

  Java: POJOs : use Jettison ?

No idea :)

Jettison was Sylvain's suggestion from an off-list discussion.

This sounds like the /serious/ way of doing this ..... mapping files etc. etc. What I'd like to find is a simple clean way of doing simple generic stuff. Make it easy to do things like passing JS Objects between the client and server, from FlowScript.

Java: I18n Message Strings : a must-have ..... Dojo's i18n mechanism is not in place yet, without this it will be very difficult to i18n dojo widgets. We may not even want to have 2 i18n mechanisms with 2 types of resource file format.

Sounds reasonable.

There is very little scope for i18n in Dojo Widgets







I am pretty sure this does not cover all usecases ....

1. You can have optional attributes on the tag (that can have their values i18n) that are used by the Widget on instantiation. This could become cumbersome. 2. You could conceivably have a Widget load it's instantiation Template via an i18n Pipeline, but I would argue against this approach, as ideally you'd want the template cooked-in to the Widget for production systems. 3. You can i18n the content that the Widget requests from the server after it instantiates, like I am doing with JSON data, also like the BrowserUpdate feature of CForms does.

ATM, we only have 2 widgets that use JSON, but IMHO this number will grow. We also need a clear route for people developing their own widgets, so can we all have a think about this ?

Yes, guys, please think about ... widgets! :)

:)

regards Jeremy

smime.p7s
Description: S/MIME cryptographic signature