[Council] i18n JEP
mass at akuma.org
Wed Apr 3 15:59:52 CST 2002
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
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.
Peter Saint-Andre wrote:
>Any feedback on the 18n JEP?
>email+jabber: stpeter at jabber.org
>Council mailing list
>Council at jabber.org
More information about the Council