Yarko, I have been thinking about this. If I understand you proposed: 1) make it a default such that en-us is not translated 2) create a new API that "app_defaul_language" that would do, in one go both set "current_languages" and "force".
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. 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. 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? 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> > > > > > > > > > > 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 -~----------~----~----~----~------~----~------~--~---
