[standards-jig] Re: [JDEV] Internationalization

David Waite mass at akuma.org
Sun Nov 4 23:52:57 UTC 2001

Max Horn wrote:

> At 16:04 Uhr -0700 04.11.2001, David Waite wrote:
>> Perhaps we should instead focus on using XML instead of english text 
>> to convey instructions and errors? That was, after all, one of the 
>> main points behind XML :-)
> I don't see how you can encode every possible need for automatic test 
> messages in XML, including fill words etc. I am thinking here e.g. of 
> iq:gateway. How would you fully encode every possible meaning there?
> Of course, XML "forms" are another important thing that is needed (and 
> people talk about it for well over a year now, but nothing is 
> happening :/). But it can't be a full substitute for locale support in 
> my eyes.
> Max

Are you speaking of the Forms JIG, or the XForms working draft 
(http://www.w3.org/TR/xforms/) ? XForms is something a bit different - 
it defines (or perhaps will define) a description language defining what 
input is required for a form, and allow for different rendering 
implementations to render the data accordingly.

jabber:iq:search, jabber:iq:register, and (not-quite-yet) 
jabber:iq:gateway  and the proposal done by the Forms JIG all describe a 
full user interface to present to the user; the client does nothing with 
these except render them and send off responses. In standardization, 
these should *require* language to be specified, since the client can do 
nothing to correct the problem. This is a tradeoff - something much more 
complicated would be required to describe all the possible meanings of 
the registration fields in order for the client to perform localization.

For things like the groupchat protocol though, messages such as "User 
foo has entered" are a closed set - they can be defined fully in the 
protocol specification, and represented exclusively by XML. This is what 
I did for my conferencing proposal;
- if support for a particular feature is required for entering a room, 
all responses, errors and events are defined in XML
- if support for a particular feature is optional, yet it still 
generates side-effects, the client will receive both an XML description 
of the event and english text describing the event. This means a user 
only sees english text if it does not support a feature of the remote 
server. An example of this would be 'kicking' someone from the room - 
you get a message saying they have been removed from the room in XML 
format, and get it in plaintext format as well, so that users who are 
using clients which do not understand removal notifications still get a 
message which explains that the fellow didn't quite leave on their own 
- locale information is not sent to users within the room, just because 
I haven't figured out a use for it yet.

-David Waite

More information about the Standards mailing list