On Fri, Nov 20, 2009 at 11:31 PM, mdipierro <mdipie...@cs.depaul.edu> 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 - 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.
Currently, you are not handling this - and so this problem (as reported by
PyCon staff) will persist.
You video "solution" to add the languge by the application is... backwards:
the application fixing up a deficiency in gluon - not a good structure.
This patch handles by being 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.
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 incorrect - this would not affect backward / forward
anything, as all 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.
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
tranlation is assumed?
Either way there is a problem that needs solving. Doing nothin leaves a bug
that is not tolerable - at least not to the PyCon community, so this must be
dealt with seriosly; 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.
>
This is about code readabiliy --- 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 behavior is (which
is poor design - readability is important; "magic" code is.... well, just
does not promote either reliability nor maintainability --- all coming back
to that readability issue.
Every possible convenience is not at issue here - this is something that is
needed (or some solution, if not this). WHATEVER solution you choose, it
better not require a post to this list every time someone needs to figure
out what it is, or how to use it. That is just plain bad design. If its
not usable, except by those "in the know" - by gurus - then it's junk, or
doomed to become junk over not very long of a time frame.
At the first, essential need - 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?
>
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 (they won't, simply because it isn't). 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.
RE: 1) I do not agree this breaks backward compatibily in any significant
way; I do agree this "Breaks" a current bug. I think fixing the bug has
priority over backward compatibilty ("we are backward compatible - we keep
all our bugs" as an extreme position is silly, don't you agree?! ;-).
Your argument of "Oh, I don't care about people that set their language that
other way" .... will result in that population not using this tool. I don
not want that; do you? Besides, it doesn't matter how "most" people use it
- it's reasonable behavior that is not handles, so its a bug, and that's
all. It NEEDS TO BE FIXED.
Besides the way I have shown you, I can only think of the "all languages
have a languages/*.py file" approach, which then pushes special handling of
those files into the picture, and that might too have "backwards
compatibiliy" issues; which is lesser? Can you provide other
alternatives?
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).
Yarko
> Massimo
>
>
> On Nov 20, 8:43 pm, Yarko Tymciurak <resultsinsoftw...@gmail.com>
> 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 <mdipie...@cs.depaul.edu>
> 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 <resultsinsoftw...@gmail.com>
> > > 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 <szims...@gmail.com>
> wrote:
> >
> > > > > Tnx.
> >
> > > > > On Nov 18, 9:03 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> > > > > > I think you found a bug. I will watch the video again.
> >
> > > > > > On Nov 18, 2:00 pm, szimszon <szims...@gmail.com> 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 <mdipie...@cs.depaul.edu> 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 <szims...@gmail.com> 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 <mdipie...@cs.depaul.edu>
> wrote:
> >
> > > > > > > > > > Perhaps this can help.
> >
> > > > > > > > > >http://www.vimeo.com/7520812
> >
> > > > > > > > > > Massimo
> >
> > > > > > > > > > On Nov 17, 4:20 pm, jensmun <j...@acamedia.org> 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 web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
