On Sat, Nov 21, 2009 at 1:16 AM, mdipierro <[email protected]> wrote:
> > Yarko, the issue you raise has merit but this is not a bug. It is ABSOLUTELY a BUG !!!! Trace thru the code, when the browser settings are a in your video: During translator.__init__, 'en' is not in current_langes, and it's not in the files (languages/*.py), SO even though the default is (IMPLICITLY) english, the dang code selects the NEXT down the list of http_accept_languages --- until the first in that list exists in languages/*.py !!!!! HOW CAN YOU SAY THIS IS NOT A BUG?!!! ITS A BIG FAT JUICY BUG!!!! THEY DON'T GET CLEARER THAN THIS!!! :-o ACH! > You are > proposing that web2py declares by default that the default language is > 'en-us', I am not convinced there should be such default but I agree > current messages default to English. > The default in gluon code IS English - by NOT setting current_languages in translator.__init__(), you MISS PICKING UP ENGLISH from the top of http_accept_languages --- which is WHY all those people on the PyCon list complained!!!! FURTHERMOER: Your video overrides the BUG by having the APPLICATION set English!!!! NOW - the only reason (in your video) 'it' is correctly selected when you move it up the list, is because --- without that FORCE in applicaitons/models/db.py --- languages.py::translator.__ init__() would INCORRECTLY pick 'it' (because of the BUG). ACH! BIGGEST MOST OBVIOUS BUG - EASIEST TO SPOT - I HAVE SEEN IN A LONG TIME!!!!! > > Another option would be provide an explicit translation file en-us.py. > I always assumed that people who really use internationalization would > create such a file. It just takes a click of a button. > Fine - so for the simple case: registration, for example - now you will lookup each string in the application when Wesley (or any of the others who complained) want to register, and --- what???? replace each string before you present it --- with itself?!?!!!!!! Ha!!! or maybe make a SPECIAL CASE of "If the translation file is empty I assume it's the default language - HAHAHA!!!! LOOK ----> Direct is better: the problem / the bug (to begin with) is because this default is implicit. Want a cleaner solution? THen we need to look at the structure of translations, and what it processes, and what the correct structure would be - but right now there is a bug.... and there are (within the current shape of things) only some very limited - and, by the way, some VERY OBVIOUS (if you step through the code as it's going) and VERY STRAIGHTFORWARD, SIMPLE ways to fix this: be explicit (one way or another: either correctly populate current_languages, or provide some "default" translation file to translate the default language to ... itself .... ugh - even saying that feels ugly! ;-) > > The problem PyCon users have reported is due to the fact that PyCon > registration app does not declare that the default language is 'en-us' > but it should. That was a bug in the PyCon app. > No - this is a bug in the initialization code of translator.__init__() --- it simply does the WRONG thing, does not do the reasonable thing by default - BUG in gluon. I am just not buying any other argument after tracing this. > > I am going to sleep on this. I think we need to hear more voices. I am > not saying no. > > I think you just need to pull out your Wing that they so graciously gave you, set a breakpoint at gluon/languages.py:: translator.force() at "for language in languages:" and use the settings from your video --- and you'll see what the initalization looks like - that it needs to be fixed here. Just look at it --- it will take you all of 10 minutes to step thru it. *sigh* --- too much work to convince you of what is clearly, blatently a logic bug in gluon. Don't "hack/patch" it in app (that's ok for overriding default language, not for fixing the bug). Sleep well. Tell me after you've stepped through that code. Ciao, -- Yarko > Massimo > > P.S. I have no issues with Django. I did not mean to make a > denigratory comment. hehehe..... no worries ;-) > I just emphasize that keeping a minimalist API > set is a distinctive feature of web2py that I would like to keep. > Minimal is not the same as obfuscated - for minimal to be useful, meaningful, it must be clear, to the point, well bounded, and do no more than necessary. This stuff in every app is not necessary (the stuff you show in your video; you're just working around this bug, since it should not be necessary at all for proper, reasonable behavior IF translator.__init__() was setup correctly..... > > > > > > On Nov 21, 12:36 am, Yarko Tymciurak <[email protected]> > wrote: > > On Fri, Nov 20, 2009 at 11:31 PM, mdipierro <[email protected]> > wrote: > > > > > Yarko, > > > > > I have been thinking about this. If I understand you proposed: > > > 1) make it a default such that en-us is not translated > > > > I don't think this is accurate. As it is, there is no > languages/en-us.py > > file, nor en.py so by default this is currently not translated. To > > translate from Polish to English (for example) you would create en.py > > translation files; this will also be so. The difference is you will need > to > > declare polish as the default app language. Of course, this still has > > problems, because you do not have appropriate structure to handle > different > > "default" string encoding within the code - one for gluon core, and a > > different one for application. EIther way, this system needs more major > > refactoring. > > > > The bug in the current gluon system - that is, there is a hole in the > > system: > > > > You accept browser language preferences, but you only set language to one > > that exists in languages. > > > > The problem this creates is the bug reported by so many on the PyCon > list. > > The failure of the code is that it FAILS to recognize the SOURCE language > of > > the strings in the application, which implicitly defaults to en-us. > > > > My patch declares this explicitly, so that your code in class > translations > > will work properly in these cases. Your code in the video has code in > the > > application (!) make a call to correct this deficiency in the gluon code. > > This is NOT a good solution. This is a boundary-of-responsibilities > > violation, and unnecessary coupling. Correct default behaviour should be > > accomplished by the gluon code, not by the app (what will you do for just > > admin, no app? Have admin fix it? what about some graphical design > tool? > > that will need to make the correction too? --- the "FIX" will soon > > propagate everywhere, creating a fragile, error prone situation - > precisely > > why this should absolutely NOT be done this way). > > > > Currently, gluon languages.py::class translator() has a bug - that should > be > > fixed within languages.py > > > > This patch patch is explicit about the assumed default language of the > > application (and framework) code. There is the remaining issue that if > one > > language is default for string encoding of messages in gluon, and another > > for applications there is not sufficient structure in gluon to handle > this. > > But that is a separate problem, and one that could be addressed later. > > > > There is at least one other way I can think of to handle it, and i think > > that will create more special cases and not be a good solution (have a > > languages/*.py file for all languages, even the default) - and I did not > > even do more than briefly think of it. Maybe you can come up with other > > potential designs for a solution - I could not immediately think of one, > and > > this one is straight forward, simple, and will be reliable. > > > > > 2) create a new API that "app_defaul_language" that would do, in one > > > go both set "current_languages" and "force". > > > > That is correct - encapsulate in something that communicates (I think) > what > > you were doing in your video. > > > > > > > > > 1) cannot accepted because it would break backward compatibility. We > > > have more users overseas than in US. I have seen people code in polish > > > or German and translate to English. Patch 1 would prevent their apps > > > from being translated. > > > > I am sure that is largely incorrect - things work as they do now - > except > > that the BUG of mis-selecting a language in the case of multiple language > > preferences in the request is currently mishandled. > > > > There is NOTHING that precludes translating to English. The backwards > > compatibility issue is that these applications (as you mention - code in > > Polish, provide languages/en.py translation files) * would need to > declare > > polish as their default*. > > > > But even this case specific case, this is not necessary (ergo no backward > > compatibility issue): consider, browser language is polish; if there is > no > > polish languages/pl.py file, then it will not be selected (from the multi > > language case, that shows this bug), and fhe FIRST language file from the > > list of languages selected by the browser that exists will be the > selected > > file!!!!! For example, if the only translations are for en.py, then > > english will (incorrectly) be set as the application default language - > > fixing this bug TRUMPS any "backward compatibility" issue, as for that to > > matter, the backward code had to WORK. As it is, with this bug, it only > > worked in some cases - bug undiscovered is still a bug. You woul have > them > > make a change to plug a security hole without concern for "BC",and this > is > > the same: fix the bug you haven't discovered yet. > > > > The other design alternative (if your current gluon code is to work > without > > the current bug) is to ALWAYS have translation files languages/en.py (and > > anything else that might be set). In that case, you would need to think > > about what to do in those files - e.g. if en is the coding of the app, > what > > would the en.py file contain? one-to-one lookups replacing each string > with > > itself? special handling in the case of an empty en.py file, where no > > translation is assumed? This is messy enough that I thought about it for > > just a brief time, and discarded consideration of such an approach. > > > > Either way there is a problem that needs solving. Doing nothing leaves a > > bug that is not tolerable - at least not to the PyCon community, so this > > must be dealt with seriously; doing "nothing", to me, does not seem to > be a > > viable option. > > > > > > > > > 2) The majority of users who use internationalization on this list do > > > not use the http_accept_language to set the language but created a > > > language state in session and explicit language buttons. That is the > > > reason to have two API instead of one. Having one additional function > > > would save one line of code in some cases. Is this worth it? I tend to > > > be oppose to API proliferation unless there is a compelling reason > > > like it enable us to do something we cannot already do or it increases > > > generality. If we create a new API for every possible convenience > > > function we would become like Django. > > > > Ha! I am surprised you are taking this kind of reaction publicly... > Really! > > - forget your issues with Django, and consider what is really being said > > here: > > > > This is about code readability --- if I read the code, and I see "set > > languages" and force(), and I have to ask "what the heck is that doing?" > and > > I have to look thru lists, or manuals or code to figure it out, then two > > things are at play: > > > > - it promotes misuse and bugs (unclear code); > > - it is an improper abstraction (e.g. name) for what the behaviour. > > Readability is important; "magic" / obfuscation does not promote either > > reliability nor maintainability --- all coming back to that readability > > issue. > > > > Every possible convenience is not at issue here; this is fundamental. > > Consider if you were arguing for having a "fileOpen()" be called > > "channelPrep(); permissionsCheck(); someotherstuffNotImmediatelyCLear()" > - > > clearly you would not, so STOP IT! - this is something that is needed (or > > some solution, if not this). WHATEVER solution you choose, it better be > > clear! > > > > It should not require a post to this list every time someone needs to > figure > > out what it is, or how to use it. > > It had better be descriptive, and say what it does appropriately - or it > > doesn't deserve to be around at all. (YMMV). > > > > > > > > > Anyway. I am not say no to 2). I would like to hear some pros and cons > > > from other users. I may also have misunderstood your point about 1). > > > Do you agree that it would break backward compatibility? > > > > No, I do not (see what I say above). > > > > RE: 2): If you can describe in one or two sentences what the point of > YOUR > > two lines from the video is, when to use it, what the intended effect is, > > when it is not appropriate to use - AND people think it is clear from > those > > two lines of yours, then fine (I don't believe they will, simply because > I > > don't believe it is nearly clear enough). If not, then some way of > writing > > it that captures the essence of your short (1-2 sentence) description is > how > > this should be named. Forget about proliferation, and think "appropriate > > name". > > > > RE: 1) I do not agree; I think fixing the bug has priority. > > > > I have already fixed this for PyCon as I've posted here - and for that > app > > it will stay that way, until I see a better way (or there is an > equivalently > > effective way proposed, but then I'm in no rush to change). > > > > Kind regards, > > > > Yarko > > > > > Massimo > > > > > On Nov 20, 8:43 pm, Yarko Tymciurak <[email protected]> > > > wrote: > > > > I have replied to Massimo in detail privately, as he also sent me a > more > > > > detailed private note about this. > > > > > > The way shown in the video is a rough way to set the default language > for > > > an > > > > application (what will not need to be accessed from a translation > file, > > > but > > > > rather is what is native in the strings in the code). > > > > > > For reasons I have at length explained to Massimo, I stand behind my > > > patch > > > > as a correct, needed fix. > > > > > > Massimo's video shows how an app can override the default site > assumption > > > > about what the language is used in the app's code.... but it is too > > > obtuse. > > > > > > The attached, updated patch has a function to wrap those lines which > > > Massimo > > > > shows in his video into something that says what it does, reads like > > > this: > > > > > > T.app_default_languages('it', 'it-it') > > > > > > With this patch, there is no need for any app to define anything for > the > > > > default ('en-us') encoding; default behavior is proper (perhaps, > > > Massimo, > > > > you will want to make it dual 'en', 'en-us'?). > > > > > > Regards, > > > > Yarko > > > > > > On Fri, Nov 20, 2009 at 5:29 PM, mdipierro <[email protected]> > > > wrote: > > > > > > > Hi Yarko, > > > > > Settings english by default would encourage users to edit source. > > > > > This issue was > > > > ... > > > > read more ยป > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
