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 already solved in 1.72.3. The proper way to handle is > > > explained in this vimeo video: > > > > >http://www.vimeo.com/7520812 > > > > > Massimo > > > > > On Nov 20, 4:16 pm, Yarko Tymciurak <[email protected]> > > > wrote: > > > > There was a bug in language selection with web2py: > > > > > > To reproduce: > > > > > > - in Firefox (can do in other browsers), open Edit =>Preferces => > > > > Languages and choose multiple languages; > > > > > > What happens: > > > > > > The implicitly default language ('en-us') is never selected when > there > > > are > > > > multiple language choices in your browser; instead, the FIRST > LANGUAGE > > > from > > > > your browser preferences list which has a translation file in your > > > > application/myapp/languages directory is used. > > > > > > Expected Behavior: > > > > > > First language in your browser preferences list of languages for > which > > > there > > > > is a "translation" will be selected (INCLUDING the default language > of > > > the > > > > site / app - that is, the default language the strings are written > in). > > > > > > The attached patch fixes this (makes DEFAULT_LANGUAGE explicit). > > > > > > FUTURE WORK: > > > > > > You can now change the default language of your site, by changing the > > > > DEFAULT_LANGUAGE setting in gluon/languages.py. > > > > A Better setup will be to have your app (say, in models/db.py or > > > > models/0.py) be able to set the DEFAULT_LANGUAGE for its request. > > > > > > ANALYSIS: > > > > What is currently preventing this: the environment for request (and > > > > therefore the translator, and default language...) is setup BEFORE > the > > > > application directory is read for the request. > > > > > > One possible solution: > > > > Store the default translator instance per language, have a site > default, > > > and > > > > allow "switching", or lazy instantiation on first encounter of a > "new" > > > > default language (something like this in models/db.py: > > > > > > T.default_language='it-it' > > > > > > This will have to work with multiple languages set in your browser. > > > > Comments / discussion of this part welcomed. > > > > > > In the meantime, here is a patch to correct the current bug. > > > > > > Regards, > > > > - Yarko > > > > > > On Thu, Nov 19, 2009 at 1:19 AM, szimszon <[email protected]> > wrote: > > > > > > > Tnx. > > > > > > > On Nov 18, 9:03 pm, mdipierro <[email protected]> wrote: > > > > > > I think you found a bug. I will watch the video again. > > > > > > > > On Nov 18, 2:00 pm, szimszon <[email protected]> wrote: > > > > > > > > > I expect a different behavior or I don't understand how > translation > > > > > > > works :-o > > > > > > > > > What is different if there is T.force and T.current... and no. > > > > > > > > > If there is no T.force... just Italian language preferred by > the > > > > > > > browser, your example text is translated to Italian and the > flash > > > > > > > messages in the top right corner (so Italian translation is > present > > > > > > > for the flash message). 4:27min > > > > > > > If there is T.force... only your example message is translated > to > > > > > > > Italian the flash not. 6:20min > > > > > > > Is it to be expected? > > > > > > > > > On Nov 18, 8:43 pm, mdipierro <[email protected]> wrote: > > > > > > > > > > I do not understand the comment. Did you expect a different > > > behavior > > > > > > > > than shown in the video or you cannot reproduce the behavior > > > shown in > > > > > > > > the video? > > > > > > > > > > On Nov 18, 7:07 am, szimszon <[email protected]> wrote: > > > > > > > > > > > Hm. I look at the video and, > > > > > > > > > > > First time you add language "it" to the brower preferences > and > > > > > moved > > > > > > > > > up then the flash is translated to Italian in the web page. > > > > > > > > > But after the T.force thing and Italian was the browser > > > preferred > > > > > one > > > > > > > > > the flash was in English... > > > > > > > > > > > On Nov 18, 1:29 am, mdipierro <[email protected]> > wrote: > > > > > > > > > > > > Perhaps this can help. > > > > > > > > > > > >http://www.vimeo.com/7520812 > > > > > > > > > > > > Massimo > > > > > > > > > > > > On Nov 17, 4:20 pm, jensmun <[email protected]> wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > Thanks for this everybody. Looks really cool. > > > > > > > > > > > > > I've been playing with this tonight for the first time > and > > > > > everything > > > > > > > > > > > was fine until I got to internationalization. It > doesn't > > > seem > > > > > to > > > > > > > > > > > respond at all or randomly to me changing language on > > > FF3.5.5 > > > > > and OSX > > > > > > > > > > > 10.5. > > > > > > > > > > > > > Nothing changes - and I've checkedhttp:// > > > > >www.cs.tut.fi/cgi-bin/run/~jkorpela/lang.cgi<http://www.cs.tut.fi/cgi-bin/run/%7Ejkorpela/lang.cgi> > <http://www.cs.tut.fi/cgi-bin/run/%7Ejkorpela/lang.cgi> > > > <http://www.cs.tut.fi/cgi-bin/run/%7Ejkorpela/lang.cgi> > > > > > > > > > > > to make sure I'm on eg. spanish or italian. > > > > > > > > > > > > > Is this something that is wrong on my side? > > > > > > > > > > > > > Thanks, Jens > > > > > > languages.patch > > > > 1KViewDownload > > > > > > > > languages2.patch > > 2KViewDownload > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
