librelist archives

« back to archive

Is this a sensible way to handle site internationalization?

Is this a sensible way to handle site internationalization?

From:
Charlie Orford
Date:
2012-08-01 @ 16:37
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')
etc..

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,
Charlie


Re: [flask] Is this a sensible way to handle site internationalization?

From:
Charlie Orford
Date:
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')
> etc..
>
> 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,
> Charlie
>
>
>