Re: [flask] Is this a sensible way to handle site internationalization?
- Charlie Orford
- 2012-08-02 @ 00:20
Just to clarify: when I say registering blueprints multiple times, I
mean registering the *same* blueprint multiple times.
On 01/08/2012 18:37, Charlie Orford wrote:
> Hi all,
> As a way of learning Flask, I've decided to use it for a new site I'm
> building. One of the requirements for the project is the ability to
> render site content in multiple languages. In addition, I'd also like
> to provide language unique urls (to avoid having to always append a
> variable to the query string to indicate what language a resource
> should be rendered in).
> This is the approach I've come up with (point 4 is the part I'm not
> 100% sure about):
> 1). The same Flask app serves all language variants of the site (with
> translations handled by Babel and gettext).
> 2). Sub domains are used to determine which language to render in. So:
> www.domain.com would default to English, fr.domain.com would be
> French, de.domain.com would be German etc.
> 3). Blueprints are used for all the url routes and views of the app
> (exactly the same approach as:
> https://github.com/mitsuhiko/flask/tree/website/flask_website )
> 4). Inside the main __init__.py for the app, register each blueprint
> multiple times, once per sub domain. E.g.
> app.register_blueprint(support, subdomain='www', url_prefix='/support')
> app.register_blueprint(support, subdomain='fr' url_prefix='/support')
> app.register_blueprint(support, subdomain='de' url_prefix='/support')
> 5). For each incoming request, pass a WSGI environment variable from
> nginx through to Flask indicating what language Babel should use (the
> value of this variable is derived from the sub domain the user made
> their request to).
> I've tested the above and it works as planned. However, I'd like to
> know if registering blueprints multiple times has any major pitfalls
> or performance drawbacks I should be aware of? It would also be great
> to know if there's a better approach I haven't thought of.
> Many thanks,