Practice
Setting Up Multilingual TYPO3 Sites Properly
Multilingual capability is one of the strongest arguments for TYPO3, because it sits in the core rather than in an add-on. The effort is not in switching it on, though, but in three decisions best made before the first translation.
Translations are linked, not copied
The most important difference from systems that retrofit multilingual support: in TYPO3 a translation is connected to its original. It is not a second, independent piece of content but a language version of the same one.
A great deal follows from that on its own. The system knows which pages are translated and which are not. A language switch can point at the matching version rather than at the home page. And the links for search engines come out of the same information.
Three decisions at the start
How languages are addressed. Directory or separate domain: the site configuration settles that and determines what every address looks like. There are details under routing.
What happens to missing translations. Hide them or show them in the source language. This setting affects navigation, indexing, and how complete a language version feels.
Who translates and in what flow. In-house, external or mixed; with or without an approval step. If an approval process is needed, workspaces are worth a look.
All three can be changed later, but every change drags rework behind it. An hour of clarification at the start is the best investment in the whole project.
hreflang: only what exists
Language links for search engines come out of the configuration, not out of manual work. The decisive rule is that an entry may only appear where the translation actually exists.
A pointer to a language version that is not there is worse than no entry at all. Search engines check this and discount the signals when they do not hold. That is exactly why the fallback decision above is more than a question of display.
What actually costs effort in maintenance
Not the technology but the discipline. A bilingual site is only bilingual once both versions are maintained, and experience says the second one slips first.
Two things help against that. First, an honest decision about which areas genuinely have to be bilingual; not every subpage needs an English version. Second, a backend that makes the state visible: people who can see which pages are untranslated are more likely to close the gaps.
Accessibility applies per language version
A point often overlooked: alternative texts, labels and error messages are created afresh in every language. An accessible German version says nothing about the English one.
Think of the two together and you save doing the work twice: accessibility belongs in the sitepackage and in the editorial training, and both affect every language at once.