[Freeipa-devel] [PATCH] admiyo-freeipa-0034-2-Metadata-I18N.patch

[Rob Crittenden]

Adam Young wrote:
> On 09/17/2010 02:24 PM, Adam Young wrote:
>> Metadata I18N
>>
>> Created a clone of the json_metadata plugin called plugin_metadata
>> It is identical in all reagards to the json_metadata plugin, except it
>> performs the gettext transalation based on the 'language' parameter
>>
>> Once this is accepted, the next step is to change over to using this
>> plugin,
>>
>>
>> _______________________________________________
>> Freeipa-devel mailing list
>> Freeipa-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-devel
> I was doing an improper check for the presence of a key in the
> dictionary of env vars
>
>
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel

It would be nice to be able to use the Accept-Language header provided 
by the browser.

The wsgi environ variable holds the headers as a dictionary and it'll 
look something like:

'HTTP_ACCEPT_LANGUAGE': 'en-us,en;q=0.5'

So this means my browser accepts en-us and en (and prefer en-us over 
en). See full definition at 
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.4

We should be able to stick the accepts-language value into the request 
context and evaluate it later. See in ipaserver/rpcserver.py the call to 
create_context().

How is the javascript call going to know what language to request?

And a small nit. The help for the argument says 2-character language 
code. This ignores the language subtags (e.g. en-US).

rob