[Council] i18n JEP

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.
Agreed.
>>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
improvements.
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"/>
</x>
</iq>
If nobody objects, I will update the JEP in the couple of days
according to Jer's suggestion.
Cheers,
Max
--
-----------------------------------------------
Max Horn
Software Developer
email: <mailto:max at quendi.de>
phone: (+49) 6151-494890