aboutsummaryrefslogtreecommitdiffstats
path: root/mediagoblin/tools/translate.py
Commit message (Collapse)AuthorAgeFilesLines
* No lazy_* needed here; Add ReallyLazyProxy.__repr__.Elrond2013-04-251-0/+7
| | | | | | | | | | | | 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__.
* Adding ReallyLazyProxy, a proxy that does what we expect :)Christopher Allan Webber2013-04-241-4/+13
|
* Create set_thread_locale and use it.Elrond2013-04-241-0/+5
| | | | | | Setting up a new template env should not directly touch the translation tools, but go through a function in translations.py.
* Adds the timesince ability which fixes #394Jessica T2013-04-111-0/+20
|
* Better Py3 compat: d.has_key(k) -> k in dElrond2013-01-301-1/+1
| | | | | | | | 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.
* Add example to the lazy gettext version to make clear when it's appropriateSebastian Spaeth2012-12-141-1/+4
| | | | I needed an example to really get when lazy_gettext would be good...
* Fallback to "en_US" if browser does not send preferred languagesSebastian Spaeth2012-12-041-16/+13
| | | | | | | | | | | | | 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>
* en_US is always availableSebastian Spaeth2012-12-021-7/+8
| | | | | | | | | | | 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>
* Fixing bug where not all conditions returned a language in ↵Christopher Allan Webber2012-12-011-1/+2
| | | | | | get_locale_from_request() Just had to change the indentation level of the last commit.
* Fall back to "en" if we don't find matching translationsSebastian Spaeth2012-12-021-1/+1
| | | | | | | | 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>
* Honor user's browser language (#558)Sebastian Spaeth2012-12-021-9/+19
| | | | | | | | | | | | | 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>
* Fix i18n in our browserSebastian Spaeth2012-12-011-12/+13
| | | | | | | | | | | | | | | | | | 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>
* Fixed 404 page under werkzeug.routingJoar Wandborg2012-10-141-6/+1
| | | | | - Removed ?lang=<langcode> feature due to incompatibility with werkzeug routes in the current state of the architecture.
* Replaced all request.POST with request.form, ...Joar Wandborg2012-09-291-1/+1
| | | | | - Fixed error handling in OAuth plugin - Changed request.POST file fields to request.files
* Switch from webob.Request to werkzeug.wrappers.RequestJoar Wandborg2012-09-291-13/+4
|
* replaced os.path.split()[0] with os.path.dirname() and corrected a couple of ↵Aleksej2012-08-131-2/+2
| | | | comments
* make mg_globals.translations thread-safeJakob Kramer2012-07-181-5/+4
| | | | | I added mg_globals.thread_scope (an instance of threading.local) and made `translations' an attribute of it.
* It's 2012 all up in hereChristopher Allan Webber2012-02-021-1/+1
|
* Support for older webobs and newer webobs both in accept language mess :)Christopher Allan Webber2011-10-151-2/+11
|
* Fixes issue662, MediaGoblin was broken by recent WebOb release.Christopher Allan Webber2011-10-151-7/+3
| | | | | | | | | | 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...
* Moved common, translation, template, and url code out of util.py and into ↵Aaron Williamson2011-10-011-0/+167
tools/[file].py