IMHO, unless you plan to support more than half a dozen locales, it is less work to do one website (or frontend) for each locale than it is to build one website that adapts to multiple locales.
Good enough i18n is much easier. Just keep all strings in an associative array: {("greet", "en") : "Hello", ("greet", "ru") : "Здравствуйте!"} then each time a message is to be printed, have a function that looks up the correct translation: i18n_lookup(string_key, language).
https://github.com/DPKit/gdpr-portal/blob/master/src/transla...
We then have a custom Jinja filter that looks up the translation for a given word, such as
{{'summary'|translate}}
def t(key, lang):
return translations[lang].get(key, '[{} not found]'.format(key))
You can also keep date and number formats in the i18n dictionary to internationalize dates. Most internationalization libraries do not provide much more than that and try to be overly clever by e.g. offering automated pluralization etc. but in my experience they often subtly break things.
Works quite well for us both on the backend as well as frontend, here's an example of a website (also open source at https://github.com/DPKit/gdpr-portal) that uses this method:
DE: https://dsgvo.dpkit.com EN: https://gdpr.dpkit.com
(we decided to keep the different language versions on separate subdomains for better usability).
Don't be afraid to write your own solution for simple problems like that, no need to use 3rd party libraries for everything :)
[0] https://developers.google.com/international/
Disclaimer: I used to work on i18n and i10n for Google as a country specialist back in the days.