Yarko, the issue you raise has merit but this is not a bug. 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.
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. 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. I am going to sleep on this. I think we need to hear more voices. I am not saying no. Massimo P.S. I have no issues with Django. I did not mean to make a denigratory comment. I just emphasize that keeping a minimalist API set is a distinctive feature of web2py that I would like to keep. 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 -~----------~----~----~----~------~----~------~--~---
