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