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