Yarko please stop it until we get other opinions.
I have answered this question two times already.
You can say it again and again it will not change my opinion.
Yes. The PyCon registration code (not web2py) had a bug. It was
missing
T.current_languages=['en','en-us']
T.force(T.http_accept_language)
You fixed it and the PyCon registration code is working properly.
The question is, should the above two lines be default for every
web2py app?
Should web2py assume that english does not need translation if not
English translation is provided?
Should we provide a simplified API to replace the two lines above?
Perhaps so but I need to hear other opinions to be convinced.
I always fix bugs immediately if web2py does not conform to the specs.
In this case it does. The issue is whether the specs should be changed/
improved. Every time a similar issue has come up, I have asked for
more people to contribute to the discussion. It is not the first time.
Massimo
On Nov 21, 3:21 pm, Yarko Tymciurak <resultsinsoftw...@gmail.com>
wrote:
> 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:
>
> ...
>
> 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
-~----------~----~----~----~------~----~------~--~---
