Add multi-language support

[AkifB37]

The customization feature looks very interesting; it allows users to make adjustments very easily.
However, it does not support multilingual websites.
Do you have any plans in this regard?

[michael]

First off, v2 is at an early development stage (aka ready in a couple of months). But I'm glad you asked the question, as I haven't thought multi-lang through yet for v2.

The key challenge is how to effectively store translated content. I think there's two directions, each with their own pros and cons:

1. Individual page per language (think home_page_en, home_page_de, etc.)

• con: content might run out of sync
• pro: flexibility to structure content differently for different languages

2. Individual block per language (think hero_235_en, hero_235_de, etc.)

• pro: structure is defined in one place (the page), translated content is stored per individual block. so when you add a new block in english, the german version will already have that new block but falls back to english, until translated
• con: there might still be properties on the block which shouldn't be duplicated. e.g. image_grid.layout
• con: per block actually means per block-hierarchy, e.g. a list block contains list_items, so we would still run into

Hmm, actually I'm not happy with both directions. A better approach might be to only translate annotated_text properties, and otherwise keep a single source of truth (the page with all its data including the texts for the main language)

It would basically work like this: When you switch the language from en (main language) to de (translated language) as an admin, it will fetch the document again with the german translations (at least for those that exist yet, falling back to the main language for those missing). Now once you hit save, we'd actually remove all existing translations of the selected language for the page, replacing them with the new just updated ones.

Best of it: This would also allow multi-lang to be completely opt-in. If there's no translations configured and stored, users would just see the main language. And the translations table would be empty.

Unless I'm overlooking something, I can add that new feature without breaking any existing sites, that don't have the translation feature yet. All you'd have to do to enable translation is specify a new env var:

So to answer your question:

Do you have any plans in this regard?

Now I do :) Still can't promise when it will land, but happy i have an answer now.

PUBLIC_LANG='en,de,es'

The first item being the main language. I can also gradually add translation for the UI elements, though I will start with hardcoding them in english for now, as it's too early to think about translations when then the UI labels are not clear yet. Probabably won't be many anyways.

Questions:

• Should we use localized language labels (en-US, de-AT) or just generic ones (en, de)? Since we don't have region dependent things like pricing etc. I'd tend towards generic ones, though there might be situations where you want to distinguish between american english (organization) vs british english (organisation). But not sure this is enough of a reason to introduce localized codes. Will also lead to more redudandancy in the database.