The goal is recognition and correct reasoning:
- Site builders configure multilingual
- Developers write translatable code and avoid hardcoded strings
1. UI anchors (where multilingual is configured)
These paths help you connect the concept to the Drupal UI.
- Languages:
/admin/config/regional/language - Detection and selection (language negotiation):
/admin/config/regional/language/detection - Interface translation:
/admin/config/regional/translate - Content language and translation settings:
/admin/config/regional/content-language
Exam signal:
If the question asks how to enable or configure multilingual, the correct answer is core configuration via these pages.
2. Translating strings in PHP (backend developer pattern)
Backend code must use the translation system.
Example: Use $this->t() in services/controllers/plugins
return [
'#markup' => $this->t('Hello world'),
];
Example: t() in procedural code
$message = t('Submission saved.');
Why this matters:
- Allows interface translation
- Avoids hardcoded English
Exam trap:
Hardcoded strings are usually incorrect.
3. Translating strings in Twig (frontend developer pattern)
Twig templates should use the translation filter.
{{ 'Read more'|t }}
Why this matters:
- Keeps themes translatable
- Avoids duplicate templates per language
Exam trap:
Hardcoding language-specific text in Twig is usually incorrect.
4. Content translation vs configuration translation (developer awareness)
Content translation is for entity content.
Configuration translation is for labels and UI text.
Exam signal:
If the question mentions translating menu labels, block titles, field labels, or view labels, think configuration translation.
5. Language negotiation patterns
Common best practice is URL prefixes.
Example:
/en/.../es/...
Why this matters:
- Clear SEO
- Clear language context
Exam signal:
If the question asks how users select language, language negotiation is the answer.
6. Avoid hardcoding term IDs and language logic
Developer best practices:
- Do not hardcode term IDs
- Do not assume language by string comparisons
Why:
- Breaks when translations change
- Breaks in multilingual deployments
7. Accessing current language (advanced awareness)
Sometimes code must be aware of current language.
$langcode = \Drupal::languageManager()->getCurrentLanguage()->getId();
Why this matters:
- Used for language-aware output
- Should not be used to duplicate content
Exam signal:
If code is needed, it should respect language context, not bypass it.
8. Views and multilingual
Views can be configured to:
- Show content in current language
- Handle language fallback
Exam signal:
If listings must be multilingual, the correct approach is Views configuration, not custom queries.
9. Common exam traps (multilingual)
- Duplicating content types per language
- Building separate sites for simple multilingual needs
- Hardcoding strings in PHP/Twig
- Ignoring language negotiation
Correct answers favor Drupal core multilingual modules and configuration.
Final reinforcement
Correct Drupal thinking:
- Multilingual is configuration-first
- Developers write translatable strings
- Interface/content/config translation are separate systems
- Language negotiation decides which language is shown