[Council] i18n JEP

David Waite mass at akuma.org
Wed Apr 3 15:59:52 CST 2002


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
>






More information about the Council mailing list