[Council] i18n JEP

Jeremie jeremie at jabber.org
Mon Apr 15 16:38:29 CDT 2002

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.


On Wed, 3 Apr 2002, David Waite wrote:

> Sure!
> 1. What does xml:lang mean on a presence element? Can you specify 
> different status messages for different languages?
> 2. How can other systems query the current language of a user? (This 
> must be documented, as it is server to server and implementation 
> independant)
> 3. Can another user query the current language(s) of a user, so that 
> they can decide whether they are capable of talking to them?
> 4. Can a user specify they support more than one language? Parts of this 
> JEP look like they are programming locale for proper localization of 
> communication from the server, which is fine having one constant 
> language. However, other parts look like they are for conveying 
> information on messages _I_ send - but I might want to talk to a few of 
> my friends in French, but not my parents since they don't understand a 
> lick of it. I would probably end up switching from French to English 
> within the context of a conversation (and even within a single message) 
> because my French is bad. I also might want to specify in my vCard that 
> I know both French and English, but you cannot specify two languages 
> using xml:lang (as it is an attribute) .
> 5. Section 2.1 ; I don't think it is appropriate for the 'server' to 
> respond back with a language setting. Nothing in the Jabber architecture 
> requires the server to be a single unit like this, and there is nothing 
> that distinguishes one server from another once you are connected to the 
> Jabber network (internal.jabber.org could just as easily be another 
> server installation as it could be some manner of gateway). Different 
> endpoints will have different language capabilities, so this will need 
> to be reported to the user on a endpoint-by-endpoint basis. Getting the 
> language back in the stream:stream header only indicates some miniscule 
> facet of the overall Jabber network has recognized your preference.
> 6. It doesn't make sense to both require a compliant server to flag 
> messages, and for clients to flag messages so they can work with 
> non-compliant servers. I would propose that clients should just flag all 
> messages, since they are required to have that logic.
> So to summarize:
> - Clients should flag all requests with an appropriate xml:lang 
> attribute. I think it is safe to assume that no value indicates a 
> setting equivalent to the locale of the server for legacy.
> - Users may wish to have a way to indicate the languages they can 
> support for conversation; this probably should be an extension to vCard. 
> Components should not programmatically fetch this information, it is for 
> user experience only. Multiple languages can be specified, so xml:lang 
> is probably inappropriate.
> - xml:lang on stream:stream means nothing
> - presence may not mean anything with xml:lang added; if present, it 
> should be equivalent information to the vCard extension mentioned above 
> (as in, it should refer to the default language preference of the user.) 
> For presence to mean something, it might be neccessary to flag 'status' 
> with xml:lang, and allow for multiple statii.
> - xml:lang relations between endpoints is going to need to be defined 
> based on the type of endpoints, and should probably be defined within a 
> JEP for whatever describes that endpoint. For example, a conference room 
> may or may not indicate a language setting; this may or may not indicate 
> the language preference of present users.
> -David Waite
> Peter Saint-Andre wrote:
> >Any feedback on the 18n JEP?
> >
> >http://www.jabber.org/jeps/jep-0026.html
> >
> >Peter
> >
> >--
> >Peter Saint-Andre
> >email+jabber: stpeter at jabber.org
> >weblog: http://www.saint-andre.com/blog/
> >
> >_______________________________________________
> >Council mailing list
> >Council at jabber.org
> >http://mailman.jabber.org/listinfo/council
> >
> _______________________________________________
> Council mailing list
> Council at jabber.org
> http://mailman.jabber.org/listinfo/council

More information about the Council mailing list