Why can't it just be 'en'? -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 -~----------~----~----~----~------~----~------~--~---
