[standards-jig] Re: [Council] i18n JEP

Max Horn max at quendi.de
Sun May 12 20:42:57 UTC 2002

Sorry for the extremly late response to this, but a) I didn't see 
Jer's mail in the first place (stpeter told me about it recently 
<g>), and b) I was swamped with other stuff.

Jer's mail was on the council list, but I think a discussion of this 
might be more fit for standards-jig - not sure on which list to 
continue this best, though, if you think it rather should continune 
on the council list, please tell me.

At 16:38 Uhr -0500 15.04.2002, Jeremie wrote:
>IMHO it's important to try and take this one in baby-steps, start doing a
>little i18n so as to get others with more experience involved to tackle
>the harder problems.


>In doing that, what about tackling just one aspect in this JEP, the
>expression of the language used within that element?  The JEP could be
>limited to having a client send an xml:lang attrib on any
>iq/message/presence it wanted to express a language preference for.  That
>information could be used by any iq-responder (service) to select an
>appropriate reply, or by a client receiving a message/presence to indicate
>the language used (or offer the use of a translation service :).
>This would simplify the JEP significantly and solve DW's immediate
>comments (leaving the rest, like querying and negotiation, for future work
>based on these steps).  It is simply a recommendation to all clients and
>services to express their language, and at this point it would really help
>get the ball rolling towards building better i18n support.

Indeed. This way, the I18N-JEP would indeed be rather short, but 
that's not bad. We would lay the foundation for future I18N 

In the future, we probably want some negotiation protocols for 
prefered languages, which allow two entities to agree on a 
communication language. E.g. I speak German and English, my prefered 
language is german. Some service might be available in English and 
French (with "available" I mean here that the texts in it, e.g. for 
forms, are available in both languages). Thus, the logical decision 
for the service should be to offer the english version to me. This 
requires some way this information can be exchanged. Either the 
service has to query us for the "supported" languages, or (probably 
the better approach), the client will sent on each query a list of 
favorite languages, in order, and the service would (if it supports 
that feature) pick the first language from that list it supports.

On the user side, this would equal to a preference for prefered 
languages, just like most web browsers offfer it already.

I imagine this could be done with a simple <x> protocol, attaching 
the list of prefered languages to already existing <iq> messages; 
e.g. one could send an iq:register request to a service, including a 
list of the users prefered languages; existing services would just 
ignore this list, and new ones could take advantage of it. OTOH, if 
an old client makes contact to a new service (that is, it sends now 
list of prefered languages), the service would just assume some 
default language.

I think of something like this:

<iq type="get" id="1001" to="aim.denmark">
   <query xmlns="jabber:iq:register"/>
   <x xmlns="jabber:x:lang">
     <item xml:lang="de-DE"/>
     <item xml:lang="de-DE"/>

If nobody objects, I will update the JEP in the couple of days 
according to Jer's suggestion.


Max Horn
Software Developer

email: <mailto:max at quendi.de>
phone: (+49) 6151-494890

More information about the Standards mailing list