Calm down please. Speaking louder does not help make your point any better.
If a user requests "en, fr, sp, pl" and the app only has a translation file for "pl" and the app does not tell web2py that "en" does not need a translation file, choosing "pl" is the correct behavior. I think there is no reason why it should assume that english does not requires translation. You think this should behave differently. The only way to settle this is to hear what other people expect and go with the majority. Massimo On Nov 21, 1:50 am, Yarko Tymciurak <[email protected]> wrote: > 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 > > ... > > 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 -~----------~----~----~----~------~----~------~--~---
