User experience
===============
For users it means we can provide localized web-sites to enrich their
overall experiences.
Although for the Blender Cloud this doesn't make much sense (since the
content is in English), Flamenco and Attract can really benefit from
this.
New configuration settings
==========================
There are two new parameters in config.py:
* DEFAULT_LOCALE='en_US'
* SUPPORT_ENGLISH=True
They are both properly documented in the `config.py` file.
Technicall details
==================
We are using the 'Accept-Languages' header to match the
available translations with the user supported languages.
If an extension has a `translations` folder, it's used for translations.
However the main application (e.g., Blender Cloud) is the one that
determines the supported languages based on its `languages` folder.
How to mark strings for translation
===================================
See the documentation in README.md.
But as an example, 404.pug and pillar/__init__.py::handle_sdk_resource_invalid
have marked up strings that will be extracted once you install pillar,
or run any of the translations commangs.
Remember to **gulp** after you update the template files.
How to setup translations
=========================
You will need to create translation for the main project, and for each
extension that you want to see translated. I added a new entry-point to
the installation of Pillar.
So all you need is to use the `translations`
script to initialize, update and compile your translations.
Pending tasks
=============
Aside from marking more strings for extraction and start the translation
effort it would be interesting to replace the pretty_date routine with
momentjs.
Acknowledgement
===============
Many thanks for Sybren Stüvel for the suggestions and throughout code
review. Thanks also to Francesco Siddi for the original documentation
and suggesting me to tackle this. And Kudos for Pablo Vazquez for the
motivational support and for the upcoming "strings mark up" task force!
The core of the implementation is based on Miguel Grinberg i18n chapter
of his great 'The Mega Flask Tutorial'.
Reviewers: sybren
Differential Revision: https://developer.blender.org/D2826
Eve expects 'flask>=0.10.1,<=0.12' so we can't use flask==0.12.2 in
pillar for now.
This needs to be fixed upstream (eve), but for now `python setup.py
install`.
The implementation is still rather simple, using hard-coded configuration
values. This will change in subsequent commits.
The worker can be started with "manage.py operations worker". Celery
Worker CLI options can be passed after a double dash, like this:
./manage.py operations worker -- -C -E
Switched from Sybren's RSA library to the new stdlib module 'secrets' to
generate secret tokens. This also means that the rsa library was demoted
to secondary requirement.
Some packages had to be removed; they are deployment-specific anyway,
and may not even be needed any more.
I've also added some secondary requirements that weren't specified yet.
The next steps will be to split into runtime and development requirements.
- Comments are stored in HTML as well as Markdown, so that conversion
only happens when saving (rather than when viewing).
- Added 'markdown' Jinja filter for easy development. This is quite
a heavy filter, so it shouldn't be used (much) in production.
- Added CLI command to update schemas on existing node types.
A POST will create a short link (if it doesn't exist already), whereas
a GET will return the short link for the node.
The endpoint will return a dict like:
{'short_code': 'XXXXXX',
'short_link': 'https://blender.cloud/r/XXXXX',
'theatre_link': 'https://blender.cloud/r/XXXXX?t'}
This also updates Cerberus to 0.9.2 and simplejson to 3.8.2.
I've also changed the way we get to the application object, by replacing
from application import app
with
from flask import current_app
SCST tokens are now stored in the 'tokens' table.
This unifies old token handling and new subclient-specific tokens.
Also ensures the BlenderID expiry of the token is taken into account.
Removes use of httpretty, in favour of responses.
Authorised users can now create projects. The before and after insert
projects hooks take care of stripping unwanted urls and attaching
default node_type and permissions, as well as initialising a storage
bucket per project. We are temporarily switching to the development
version of the gcloud library, since it allows the creation of EU-based
buckets.
It is now possible to specify an encoding backend (at the moment only
zencoder) to take care of video variations encoding. Files transfer
happens directly on CGS (although any storage backend can be
supported). New requirements is the Zencoder Python library.
We introduce a new node_type, storage, which can support different file
storage backends and makes them available for browsing via dedicated
entry points in the application. We intend to keep pillar storage
agnostic and support both internal/local storages as well as
remote/hosted solutions.
