On Tue, Nov 24, 2009 at 4:40 PM, Thadeus Burgess <thade...@thadeusb.com>wrote:
> Yarko, I can always imagine you talking with tone fluctuations and > everything since you are so expressive on your emails! :) > > Thadeus - Thank you! I take that as a great compliment! WIshing you and yours (and everyone on list) a Happy Holiday season. To borrow a little bit from each of Star Wars & Star Trek, "Use web2py and prosper!" ;-) - Yarko > > -Thadeus > > > > > > On Tue, Nov 24, 2009 at 4:11 PM, Thadeus Burgess <thade...@thadeusb.com>wrote: > >> since 'en' is generic that is good.... and since when did color vs colour >> become that big of an issue ? >> >> If parts of web2py have color, and other parts have colour, then using >> 'en' is what we need to use, since it is generic. >> >> -Thadeus >> >> >> >> >> >> On Tue, Nov 24, 2009 at 3:45 PM, Yarko Tymciurak < >> resultsinsoftw...@gmail.com> wrote: >> >>> 'en' is less specific. >>> >>> color or colour might be in it (depending on who wrote the string); it >>> is ambiguous. >>> Removing ambiguity, so that - if some application appropriately needs to >>> be picky about spellings, idioms, grammatical subteties, I think is >>> important. >>> >>> 'en' is "generic"; >>> >>> However, it is also what comes (from web2py?) to the client in the >>> Content-Language setting (in essence, we are here, within web2py, declaring >>> for the application writier what the default content-language is, so that it >>> can be matched with a client "accept-language" --- that is, acceptable >>> language to serve for the request). >>> >>> I do not have a powerful position on this - but am more convinced this >>> patch should declare only one language (the concept of it declaring in >>> effect a web2py "content-language" at the program level seems to fit, make >>> sense, and work for me). >>> >>> There is a lot to read on this, >>> >>> http://www.w3.org/International/questions/qa-http-and-lang >>> >>> and I would only say that I think if we think in terms of this being >>> about declaring the web2py level equivalent of "content-language", then it >>> should be singular. >>> >>> - Yarko >>> >>> >>> On Tue, Nov 24, 2009 at 2:40 PM, Thadeus Burgess >>> <thade...@thadeusb.com>wrote: >>> >>>> Maybe it's just me, but I can read the same sentence in en-us, en-uk, >>>> and en-gr, and I understand exactly what they mean just the same. Can't it >>>> just default all to en, and then any new messages that are written get >>>> added >>>> with this in mind? >>>> >>>> -Thadeus >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Nov 24, 2009 at 2:31 PM, mdipierro <mdipie...@cs.depaul.edu>wrote: >>>> >>>>> >>>>> I agree with you. Besides most of the current messages have been >>>>> written by Fran and Jonathan who are both in Europe. How are we to >>>>> decide what is en-us and what is en-uk? >>>>> >>>>> On Nov 24, 2:28 pm, Thadeus Burgess <thade...@thadeusb.com> wrote: >>>>> > 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 -~----------~----~----~----~------~----~------~--~---
