RTL languages like Arabic, Hebrew etc were displayed from left
to right. I fixed this by adding a function to check
whether the language of the locale is rtl and change the
direction of the html in "base.html" accordingly.
[Fixes#220]
One should use lazy_* only if you have a good reason.
This one found by our unit tests!
For example add_message adds the message to the session,
the session needs to be serialized (with json) and well,
LazyProxy is not serializable.
To aid in debugging, gave our ReallyLazyProxy a __repr__.
py3 does not have dict.has_key any more. You have to use
"key in dict" instead. As that works in python2 as well,
let's use that.
Also some small bits of pep8.
E.g. in our test suite we don't send an "accepted languages" header, which
caused the language matching to fail. So we need to explicitely fallback to
en_US, in case request.accepted_languages is None. This fixes the tests and
all cases where user browsers don't send preferred languages.
This also fixes issue #562, the AVAILABLE_LOCALES are already case-normalized
and we don't need to fudge the preferred language through the lower_upper_locale
thing for each and every request.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
We were using "en" as fallback only when no preferred language matched.
This is obviously bad. Always insert en_US as available locale, so we
can match it with the accept_languages.
Don't set available_locales as mg_global, per discussion with paroneaya,
make it a global var in translate.py
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
In case of no matching translations, target_lang was "None" which
blew up things. Fall back to "en" in case we don't find a
corresponding translation.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Previously we would attempt to satisfy the user's first language
preference, immediately falling back to english if that was not
possible. Now, we will get the best match of the user's preferred
languages.
This requires storing the available locales on app startup, so we
have mg_globals.available_locales ready to compare them against the
list of preferred user languages.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
We only ever served english pages since the switch to werkzeug's requests.
Fix this by actually checking the accepted languages that our web browser
sends and using that or falling back to english.
This is not optimal, imaging our browser sends "klingon, de" as accepted
languages and we happen to not have a klingon translation ready (a deficiency
that should be corrected immediately anyway!!). We would then fall back
to english rather than sending the sensible and pleasant German language
which the user would understand. This will require more backend work though.
Removing the gettext.find() in mg_globals.py. It looked in the wrong directory
anyway (mediagoblin/translations) and as that does not exist, had always returned
None without anyone noticing.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
From WebOb release notes:
"Accept.best_matches() is gone; use list(request.accept) or
request.accept.best_match(..) instead (applies to all Accept-*
headers) or similar with request.accept_language."
... seems that's what borked it...
