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

[Adam Young]

On 09/20/2010 10:07 AM, Rob Crittenden wrote:
> 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

I'm aware, I just wasn't certain if this info was available to the plugins

>
> 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?

JS has acces to the header info, and could also let the user save their 
preference in a cookie.  I'd like to have both options, and so think we 
should only evaluate the parameter if it is present, and use the header 
info as the default.

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

If we get to the point that we are differentiating between en_US and 
en_AS, we will have won this battle.  I'll update the Docs once we start 
doing locale specific files!

>
> rob