diff --git a/docs.json b/docs.json
index e84fa7d..981c639 100644
--- a/docs.json
+++ b/docs.json
@@ -58,6 +58,7 @@
"docs/learning-how-tos/examples-and-guides/translation-beginners-guide",
"docs/learning-how-tos/examples-and-guides/how-to-use-context-parameter",
"docs/learning-how-tos/examples-and-guides/translating-between-variants",
+ "docs/learning-how-tos/examples-and-guides/customizations-for-variants",
"docs/learning-how-tos/examples-and-guides/placeholder-tags",
"docs/best-practices/language-detection"
],
diff --git a/docs/learning-how-tos/examples-and-guides/customizations-for-variants.mdx b/docs/learning-how-tos/examples-and-guides/customizations-for-variants.mdx
new file mode 100644
index 0000000..713d3fe
--- /dev/null
+++ b/docs/learning-how-tos/examples-and-guides/customizations-for-variants.mdx
@@ -0,0 +1,126 @@
+---
+title: "How to Apply Customizations to Variants"
+description: "Learn how to apply glossaries and style rules when translating into language variants like FR-CA or EN-GB."
+public: true
+---
+
+DeepL supports regional language variants such as `PT-BR` vs `PT-PT`, or `FR-CA` vs `FR-FR`. When applying customizations like glossaries and style rules, there is an important distinction: both must be **created** using the root language code, but can be **applied** to any variant in your `/translate` call.
+
+**This guide shows you:**
+- Why customizations must be created with root codes (e.g. `PT`, `FR`) and not variant codes
+- How to pass a root-code glossary or style rule when translating into a variant target
+- A practical example of using variant-specific glossaries to enforce locale-appropriate terminology
+
+
+Some CAT tools may block passing a root-code glossary or style rule when the target is a variant. This is a client-side limitation, not an API restriction — the DeepL API fully supports this pattern.
+
+
+## Glossaries
+
+### Creation: root codes only
+
+DeepL distinguishes between root language codes (e.g. `pt`) and regional variant codes (e.g. `pt-BR`). Glossaries must be created with the root code — attempting to create one with a variant code will fail. See [supported glossary languages](/docs/getting-started/supported-languages) for the full list.
+
+| **Use this** | **Not this** |
+|:---|:---|
+| `zh` | `zh-Hant`, `zh-Hans` |
+| `pt` | `pt-BR`, `pt-PT` |
+| `fr` | `fr-CA`, `fr-CH` |
+| `de` | `de-CH` |
+| `it` | `it-CH` |
+| `es` | `es-ES`, `es-419` |
+
+### Application: variants are supported
+
+Once a glossary is created with a root code, pass its ID in the `/translate` call with a variant `target_lang` — the glossary applies automatically. See the [`glossary_id` parameter](/api-reference/translate/request-translation) in the translate reference.
+
+The following example creates a `ZH` glossary and applies it when translating into `ZH-HANT`:
+
+```python
+import deepl
+
+translator = deepl.Translator("YOUR_AUTH_KEY")
+
+# Step 1: Create glossary using root code
+glossary = translator.create_glossary(
+ "My Chinese Glossary",
+ source_lang="EN",
+ target_lang="ZH", # root code — not ZH-HANS or ZH-HANT
+ entries={"product": "产品", "customer": "客户"}
+)
+
+# Step 2: Pass the glossary ID when translating into a variant
+result = translator.translate_text(
+ "We value every customer.",
+ source_lang="EN",
+ target_lang="ZH-HANT", # variant target — glossary still applies
+ glossary=glossary.glossary_id
+)
+
+print(result.text)
+# 我們重視每一位客戶。
+```
+
+Glossaries are also useful for enforcing locale-specific terminology that DeepL wouldn't produce by default. Without a glossary, DeepL returns `"fatura"` for "invoice" in both `PT-BR` and `PT-PT`. In Brazil, the legally correct term is `"nota fiscal"` — a separate glossary per variant enforces the distinction:
+
+```python
+# PT-BR glossary: enforce the Brazilian legal term
+glossary_br = translator.create_glossary(
+ "PT-BR Invoice Glossary",
+ source_lang="EN",
+ target_lang="PT", # root code
+ entries={"invoice": "nota fiscal"}
+)
+
+# PT-PT glossary: keep the standard European term
+glossary_pt = translator.create_glossary(
+ "PT-PT Invoice Glossary",
+ source_lang="EN",
+ target_lang="PT", # root code
+ entries={"invoice": "fatura"}
+)
+
+result_br = translator.translate_text(
+ "Your invoice is ready to view.",
+ source_lang="EN",
+ target_lang="PT-BR",
+ glossary=glossary_br.glossary_id
+)
+
+result_pt = translator.translate_text(
+ "Your invoice is ready to view.",
+ source_lang="EN",
+ target_lang="PT-PT",
+ glossary=glossary_pt.glossary_id
+)
+
+print(result_br.text) # Sua nota fiscal está pronta para ser visualizada.
+print(result_pt.text) # A sua fatura está pronta a ser visualizada.
+```
+
+---
+
+## Style rules
+
+### Creation: root codes only
+
+Style rules follow the same constraint — they cannot be created for variant codes. Attempting to create a style rule for `fr-CA`, `es-419`, or `de-CH` returns a "language not supported" error. Use the root code only. See the [style rules reference](/api-reference/style-rules) for supported languages.
+
+### Application: variants are supported
+
+Once created under a root code, pass the style rule's `style_id` in a `/translate` call targeting any variant of that language. See the [`style_id` parameter](/api-reference/translate/request-translation) in the translate reference.
+
+The following example applies a style rule created for `FR` when translating into `FR-CA`:
+
+```python
+result = translator.translate_text(
+ "Please review the attached document.",
+ source_lang="EN",
+ target_lang="FR-CA", # variant target — root FR style rule applies
+ extra_params={"style_id": "your-style-rule-id"}
+)
+```
+
+
+Variant codes are not selectable in the style rule creation UI — only root codes appear. You'll need to map the correct root style rule ID to each variant target on your end.
+