1đź‘Ť
All three of those are possibilities from a development standpoint. The “domain extension” model is likely to prove to be expensive and possibly impossible depending on your resources and the languages you wish to support – .fr for example is restricted to only residents or entities with a French presence.
The “first folder” model may not be that difficult to program for. When setting up your handlers, you could do something like this:
application = webapp.WSGIApplication(
[
('/(en|fr|de)/', IndexController),
]
Which would then explicitly pass the language identifier in as the first parameter to the handler.
Subdomains, as you pointed out, are going to be the cleanest from a url perspective. As noted in the PythonRuntime Environment docs you can map multiple subdomains to the same application – in fact hosted applications will all respond to [anything].[application name].appspot.com. The host used for access can be extracted from the request object.
Overall it seems like more of a personal preference than anything else.
3đź‘Ť
I just wanted to point out that this could also be done with a prefix in the url.
Like these:
www.site.com/en/rest_of_url
www.site.com/fr/rest_of_url
the app would be setup like this:
class LanguageHandler(webapp2.RequestHandler):
def dispatch(self):
request = self.request
args = request.route_args
if len(args) and args[0] in ['en','fr']:
self.language = args[0]
request.route_args = args[1:]
try:
# Dispatch the request.
webapp2.RequestHandler.dispatch(self)
finally:
# The web page response Header will now include the 2 letter language code...
self.response.headers['Content-Language'] = str(self.language)
class HomePage(LanguageHandler):
def get(self):
# self.language is now 'en' or 'fr'
# ...code goes here...
app = webapp2.WSGIApplication([
(r'/(en|fr)', HomePage),
], debug = True)
- [Django]-Initializing foreignkey in modelform
- [Django]-Django(v2.0.7) Admin: Callback post DB transaction commit
- [Django]-Django send_mail get result