On Sat, Nov 21, 2009 at 9:17 AM, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> 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.
>
You have your head down in the code, I think.
Sit at your browser, and be that user - The PyCon list reported it this way,
and I am puzzled you did not hear / read this. Let me see if I can help:
I (user) have a list of acceptable languages, that is I speak (lets say)
English, Polish, and can read Italian pretty wall.
I set this in my browser.
As I look thru the web, if a site has English, I prefer that (I am in the
US).
If it doesn't have English, but has Polish, I can follow that pretty well,
and will accept that as a second language choice.
If neither English or Polish is available on some site, I can read Italian
and will accept information in Italian. It's not great, but with a
dictionary, I can usually make sense of whatever information there is.
Now - I'm in the office next to my colleague.
He asks if I'm going to PyCon-2010.
"I don't know" I say. "How much is it this year?"
I look over his shoulder at the registration site, and think - "Yeah, I can
do that. Ok! I'm in! Let's go to PyCOn!"
I head over to my desk, and navigate to the site to register.
What's this?!?!!!!! Why did Frank get the registration forms & info in
English, and I'm getting it in Italian????
Ok - I did present at a Python conference in Europe this fall - all the
other sites I've been browsing the past months since that trip come up fine,
but let me check by browser settings.
Yep there it is, plain as day: [1]: english; [2]:polish; [3]: italian.
Why is this site showing me my third choice, but Frank gets it in English?
Not other sites?
I better report this.
.....
>
> 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.
>
Lets take this the next step, to the programmer of that app.
- languages: descrive how to translate the application presentation to
other languages (manual, P.47, P.103)
- T is a single global instance of the web2py class
gluon.languages.translator. All string constants (and only string
constants) should be marked by T.... (manual section 4.12, starting at
P.116). *The requested language is determined by the "Accepted-Language"
field in the HTTP header* but can be overwritten programmatically ...
T.force('it-it') for example
I think the bug is from P.116 of the web2py manual. The requested language
fails to be appropriately be determined from the HTTP header. That really
should be ALL this entire chain (since I gave you a patch) should have been
about.
If you shift from "the manual", and look from both the end user's and the
programmer''s perspective, it is clear this is a bug. The questions (at
this level) that will help make this clear are something like this:
[1] "What language do I need to present this content in?"
[2] "Does the material already appear in this form, or do I need to fetch a
translation from a languages file?"
I am not arguing anything - it is clear to me that the reasonable behavior
(as my story shows), and what the manual leads the programmer to expect -
both of these are not being achieved in the case where someone has multiple
language preferences set. Further, on tracing the initialization of this
global class, it is very clear where this bug is: given the current code
logic, it is exacly because the implied default language of gluon (and
welcome app) is not considered, and it needs to be.
That is the bug.
That is what needs to be fixed.
It in no way precludes setting a different default language for a site, nor
does it preclude translating _to_ english in those cases. It merely
explicitly declares, and counts (appropriately, as the logic of the code
then behaves properly) the default language during processing - it does so
without regard to what that default language is; that default language is
already implicitly and declaratively english.
Regards,
- Yarko
> Massimo
>
> On Nov 21, 1:50 am, Yarko Tymciurak <resultsinsoftw...@gmail.com>
> wrote:
> > On Sat, Nov 21, 2009 at 1:16 AM, mdipierro <mdipie...@cs.depaul.edu>
> 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 <resultsinsoftw...@gmail.com>
> > > wrote:
> > > > 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 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 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
-~----------~----~----~----~------~----~------~--~---
