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>
Rather than exploding in the user's face (for example if we custom-configure
licenses in our MG instance, and there are still media with now "unknown"
licenses in the db), simply return a License object as a fallback, where all
attributes are set to the URL we were handed.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
"Objectify" our licenses to have .uri, .abbreviation, .name attributes
that we can pass into the templates and use there. namedtuples are a good
poor man's choice to make a License a class. (a named tuple really)
Document and optimize licenses_as_choices(), it is a one-liner really.
No need for verbose appends here...
Thanks to Elrond for noticing. We wrap error messages in <p> tags,
so there is no need to start the error message with <p>. DOH
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Rather than having a 404.html, a 403.html, a 500.html,...
we have a generic error.html template that we pass in an
error code, a title and a (html'ish) error message.
Implement the common render_404 and render_403 shortcuts. More exotic
cases can be achieved by the generic render_error function.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
We were not actually using the routes package anymore, but it was
still mentioned in the documention. Adapt the plugin documentation to
actually represent reality, although I don't like the API design.
(but this is for another day)
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Hardcode commas as tag delimiters per discussion in issue 390. Also
improved PEP-8'ness of the file while touching. Includes some improvements
suggested by gandaro.
Reviewed-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Removed the Routes routing functionality and replaced it with
werkzeug.routes. Most views are functional.
Known issues:
- Translation integration with the request object is not yet figured
out. This breaks 404 pages.
- Added HTTPError catching around the callback request, to not mark the
entry as failed, just log the exception.
- Fixed bug where I forgot to actually fetch the entry before passing it
to json_processing_callback.
- Changed __main__ migration #6 to create the ProcessingMetaData table
as it is currently, to prevent possible breakage if a siteadmin
is lagging behind with his db migrations and more than one migration
wants to fix stuff with the ProcessingMetaData table.
This reworks the plugin infrastructure so as to remove module-loading
side-effects which were making things a pain in the ass to test.
With the new system, there's no auto-registering meta class. Instead
plugins do whatever they want and then specify a hooks dict that maps
hook names to callables for the things they're tying into. The most
common one (and the only one we've implemented so far) is "setup".
This also simplifies the sampleplugin a little by moving the code
to __init__.py.
This fixes the template loader so that it can load plugin templates.
This adds code for registering template paths so that plugins can add
their own templates.
This adds the base code for the flatpagesfile plugin. It doesn't serve
pages, yet, but it's pretty close.
