[Jabber-IETF] internationalization/localization

Iain Shigeoka iain.shigeoka at messaginglogic.com
Tue Oct 15 17:30:15 CDT 2002

On 10/15/02 2:52 PM, "Marshall Rose"
<mrose+internet.ietf.jabber at dbc.mtview.ca.us> wrote:

>> The problem is when we have s2s situations, including using a GroupChat
>> service on a remote server.  (Example: I access jdev at conference.jabber.org
>> from my jabber.com account).
>> It is likely that the remote service would want to know my locale, so that
>> the configuration information for rooms could be localized for me.  How
>> should it determine that?
>> Yes, you could argue that this should be the responsibility of the groupchat
>> protocol (which is not currently in scope for the IETF work), but I think
>> there is a generic problem here.
>> Let me try to boil a suggestion down to an algorithm that a server could
>> use:
>> 1) The client SHOULD include xml:lang on stream:stream.
>> 2) If server sees xml:lang on the stream:stream, it SHOULD remember that
>> value.
>> 3) If the server does not receive an xml:lang from the client, it SHOULD
>> have a configurable default locale that it remembers instead.
>> 4) For all packets, if the client does not send an xml:lang attribute on the
>> root tag of the packet, the server SHOULD apply its remembered value.
>> 5) If the client does send an xml:lang attribute on a packet, the server
>> MUST NOT modify or delete it.
> well, this sounds like a reasonable way to proceed.

It seems a bit noisy though. Redundant xml:lang info is going to be every
where and we could see significant performance benefits to ignoring the
suggestion. We don't want to encourage non-compliance. :)

How about extending the idea of a default xml:lang from just in the stream
to once per jid/node:

1) Remain unchanged
2-3) remain unchanged
4a) Clients SHOULD send xml:lang in the first packet sent to any particular
jid since that jid became "available". Receivers can ask for default
xml:lang info by just changing presence to unavailable, then back to
available (in case the receiver go offline or forgets the default xml:lang
for a sender).
4b) For all packets, if the client does not send an xml:lang attribute on
the root tag of the packet AND if the packet is the first sent to a
particular jid since it became "available", the server SHOULD apply its
remembered value.
5) remain unchanged
6) Every recipient SHOULD remember the last xml:lang value for packets
coming from a particular jid. If any subsequent packets don't contain a new,
default xml:lang attribute, this remember value applies

It's more bookkeeping for the server and compliant clients but should cut
down significantly on the xml:lang noise. Too complex?


More information about the xmppwg mailing list