new install on ubuntu is [en-us, en].
I think it should just default to 'en', if you want uk english or us
english, then these are different languages, and should be forced.
-Thadeus
On Tue, Nov 24, 2009 at 2:25 PM, Yarko Tymciurak <
resultsinsoftw...@gmail.com> wrote:
> On Tue, Nov 24, 2009 at 2:10 PM, Thadeus Burgess <thade...@thadeusb.com>wrote:
>
>> Why can't it just be 'en'?
>>
>
> It probably could.... I just checked the request environment in a "new
> install" browser I've never used ("Konquerer on Ubuntu) and web2py is
> picking up
> http_accept_language=['en-US', 'en']
>
> So if a client had ['en-UK', 'en'], if no translation file for en-uk.py
> existed, it would "pick up" the en, and deliver in the site / apps
> internally encoded strings (which would be appropriate).
>
> If this is consistent, that the ordering from a client is first
> country-specific, then country-agnostic, then this would probably be
> reasonable. The only downside: if I complained (from UK for example)
> about "color" being misspelled (if I think it should be "colour"), then the
> app is not being explicit enough about what it says it's servering.
>
> Having said that, I am now convinced (pretty well) that 'en' should not be
> part of the gluon/languages initialization. I think it should be explicit,
> and only one language - the more specific declaration, not the broader one.
>
> So - I think that the original patch I sent (with only 'en-us') is correct,
> and what we should use.
>
> - Yarko
>
>
>> -Thadeus
>>
>>
>>
>>
>>
>> On Tue, Nov 24, 2009 at 1:01 PM, Yarko Tymciurak <
>> resultsinsoftw...@gmail.com> wrote:
>>
>>> a short version of this (context: U.N. type of meeting):
>>>
>>> you (in effect) changed the translator initialization code to say "The
>>> default language [string] I will present you is TWO lanugages", Massimo, it
>>> is _as if_ you said something like: "I'm speaking Itailan, or another way
>>> for you to think of it - I am speaking Russian"
>>>
>>> It cannot be! I cannot "hear" you that way - I have to know _which_
>>> language, if I am to have any hope of "hiring' the right translator!
>>>
>>> There is no "can of worms" in the _problem domain_; it is in your not
>>> being specific enough in what you told me you would be speaking!
>>>
>>> :-)
>>>
>>>
>>>
>>>
>>> On Tue, Nov 24, 2009 at 12:51 PM, Yarko Tymciurak <
>>> resultsinsoftw...@gmail.com> wrote:
>>>
>>>>
>>>> On Tue, Nov 24, 2009 at 12:37 PM, mdipierro <mdipie...@cs.depaul.edu>wrote:
>>>>
>>>>>
>>>>> I put en-uk not en-gr.
>>>>
>>>>
>>>> right, en-uk; from a software analysis perspective, only one language
>>>> should be in the initialization (addition of a non-country specific version
>>>> of said language should also be acceptable).
>>>>
>>>> You see, this is a big can of worms. How do you
>>>>> know that the default application is in en-us and not en-uk?
>>>>
>>>>
>>>> This is not can of worms at all: you do not "know" - you declare; the
>>>> patch as you made it, you in effect declared TWO languages (two contry
>>>> specific versions of the same base language, but for understanding this it
>>>> is clearer to ignore the "non-country-specific" part - and just think of it
>>>> as TWO languages.
>>>>
>>>> When you look at this as TWO languages, and your translation class code,
>>>> you will see that once any language is in accepted languages, it will not
>>>> be
>>>> picked up from the application's languages/*.py file.
>>>>
>>>> And that is the bug - you should not be initializing two languages,
>>>> because you prevent the (potential) translations of either of them from
>>>> being picked up, and served to the client.
>>>>
>>>> I can see that you considered this as "all english" - but if you think
>>>> of this as separate languages, and in terms of how you read-in the language
>>>> translation files, then the mistake is easy to see.
>>>>
>>>>
>>>>> This is
>>>>> way it was not specified before. This is why I am still not completely
>>>>> convinced it is a good idea not to let the users be explicit.
>>>>>
>>>>
>>>> You are not looking at this in the right way; you are wrong - look in
>>>> terms of your design, and it should be immediately clear.
>>>>
>>>> For example, think about setting "default language" as 'it' and 'es' ---
>>>> and try to walk thru the logic in gluon/languages.py - then it should be
>>>> very clear that only _one_ language should be initialized.
>>>>
>>>> After that point, you can extend this to see that adding a non-country
>>>> specific language to the initialization does not cause any bad behavior,
>>>> and
>>>> can be useful (help deliver the language appropriately more often).
>>>>
>>>> Just remove 'en-uk' from this patch, and it will be fine.
>>>>
>>>> - Yarko
>>>>
>>>>>
>>>>> On Nov 24, 12:14 pm, Yarko Tymciurak <resultsinsoftw...@gmail.com>
>>>>> wrote:
>>>>> > On Mon, Nov 23, 2009 at 2:25 PM, mdipierro <mdipie...@cs.depaul.edu>
>>>>> wrote:
>>>>> >
>>>>> > > Yarko's patch is tentatively in trunk since nobody seems to
>>>>> complain
>>>>> > > about this change in behavior.
>>>>> >
>>>>> > You made an error with the change you made in this patch: you added
>>>>> 3
>>>>> > languages, 'en', 'en-us', and 'en-gr';
>>>>> > This should only be either 'en-us' (the language of the distro), or
>>>>> at most
>>>>> > ['en-us', 'en'].
>>>>> >
>>>>> > As you've done it, you've introduced another bug.
>>>>> >
>>>>> > Putting en-gr will prevent 'en-gr' from being seen if it is a
>>>>> translation
>>>>> > file UNLESS application FORCES a base language (for example).
>>>>> > This means that 'behavior' and 'behaviour' will not be
>>>>> appropriately
>>>>> > picked up from a languages/en-gr.py file UNLESS EACH application
>>>>> forces
>>>>> > language to 'en-us' (or some other, non-[en-gr] language).
>>>>> >
>>>>> > For example, a 'en-us' app will NOT be able (with this app) to
>>>>> correctly
>>>>> > display to someone in England, who has their language set as 'en-gr'.
>>>>> >
>>>>> > Please fix this in trunk: to ['en-us']; ['en-us', 'en'] would
>>>>> also work
>>>>> > appropriately and be acceptable.
>>>>> >
>>>>> > - Yarko
>>>>> >
>>>>> > > Massimo
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
