[standards-jig] Service discovery and localization

Matthias Wimmer m at tthias.net
Mon Dec 8 20:19:56 UTC 2003


Hi Matthew!

Matthew A. Miller schrieb am 2003-12-08 11:56:26:
> I believe it has been implied in the past that the "xml:lang" of the 
> outlying <iq/> determines what localization the results should be 
> returned as (with a missing "xml:lang" meaning the results are in the 
> responder's default locale).  How about simply explicitly relying on 
> this behavior?  Additionally, as a more complete compromise, use the 
> "xml:lang" on each <item/> that is *not* in the returned locale (since, 
> in the Real World, not every string is necessarily translated).  I don't 
> expect every implementation to know what locale a string was localized 
> as, so implementations shouldn't depend on this.

I agree with you, that your solution is the best available, because I
don't want to break existing clients either.

But a limitation that is present with your approach is the following:

Server has English as the default language and also the texts in the
French locale.

The users prefered language is German, but he speaks French as well -
but no English.

The client will then send the request with xml:lang="de" and the server
will fall back to English as it does not support the de locale and
English is the default one. If the client would have gotten all results,
he might have choosen the French version, as it could know that the user
speaks French as well.

What you suggested is the gettext() approach, the problem I describe is
not addressed by gettext() either, but could be handled by the model HTTP
uses in the Accept-Language header.


Tot kijk
    Matthias

-- 
Fon: +49-(0)70 0770 07770       http://matthias.wimmer.name/
HAM: DB1MW                      xmpp:mawis at charente.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20031208/ab174eda/attachment.sig>


More information about the Standards mailing list