A multilingual taxonomy connects the same subject-matter entity via a stable, language-neutral ID with its own labels, synonyms, descriptions, hierarchies, and URLs for each language. For websites in South Tyrol, this means that German and Italian are not maintained as separate content worlds, but rather as linguistic variations of the same structure.
After over 20 years in branding and web development, I rarely see the decisive bottleneck in the translation itself. Inconsistencies usually arise earlier: a term is not clearly defined, responsibilities are unclear, or German and Italian are structured independently. This results in duplicate categories, contradictory services, and pages that cannot be reliably assigned across languages.
Multilingual taxonomy: Separating identity and language
The most important principle is: The identity of a term must not depend on its visible name. Therefore, a service, category, or characteristic receives a stable ID that does not change during translation or editorial renaming.
For example: A South Tyrolean accommodation provider offers "Guided Hikes." In Italian, the preferred term is "Escursioni guidate." Both terms refer to the same entity and therefore receive the same language-neutral ID, such as tx-0042 . The visible terms differ, but the business identity remains the same.
- Stable ID: tx-0042
- Preferred designation DE: Guided walks
- Preferred designation IT: Guided excursions
- Slug DE: guided hikes
- Slug IT: escursioni-guidate
- Parent ID: tx-0010 for active holidays or active holidays
This separation is the basis of a semantically structured website . Users see relevant terms in their language. The system simultaneously recognizes that both language versions describe the same service.
Which fields does a multilingual taxonomy need?
A taxonomy for German and Italian needs binding fields that separate meaning, translation, and responsibility. The following structure is practical for SMEs:
Identity and linguistic representation
- Language-neutral ID: An immutable technical key such as tx-0042. The ID should not be derived from a German or Italian term.
- Entity type: For example, performance, product group, travel destination, industry, material, target group or theme.
- Preferred term per language: The legally binding term displayed on the website.
- Regional synonyms: Alternative terms that people search for or that are used in everyday life.
- Description per language: A brief definition that specifies what the term includes and what it does not.
Relationships and responsibility
- Parent ID: The stable reference point is the parent-child relationship.
- Localized slugs: Understandable URL components for German and Italian.
- Status: Draft, under review, approved, blocked, or obsolete.
- Responsible person: The person who is allowed to decide on meaning and use.
- Date of modification and version: Basis for a comprehensible change log.
Such a multilingual content structure can also be used for filters, internal links, search functions, product data, and other output channels. If you want to establish a central data source first, our 30-day starter plan for a Single Source of Truth will help you with the organizational preparation.
Why the ID should be language-neutral
An ID like "guided-hikes" seems practical at first. However, if the German term is later changed to "guided hiking tours" or Italian becomes the primary editorial language, the ID no longer matches the established term. A neutral ID like tx-0042 remains unaffected.
The stable ID links all language versions. Labels, synonyms, descriptions, and slugs may change without losing links to articles, products, or services.
Multilingual taxonomy for regional terms
Multilingualism is not a word-for-word task. Terms that cannot be translated literally require a solution that is appropriate both technically and regionally. Especially in South Tyrol, there are terms that are culturally specific or used differently in each language.
"Törggelen" is a good example. Instead of creating an artificial Italian equivalent, "Törggelen" can also be used in Italian as the preferred term and explained with an understandable Italian description. The concept remains the same, while the explanation is adapted to the respective target group.
Regional synonyms should not be created as new categories. They belong to the existing entity as alternative terms. This ensures that the multilingual taxonomy remains unambiguous, even when different formulations are taken into account.
- One meaning, various names: Synonyms are assigned the same ID.
- Similar terms, different meanings: Separate entities are created.
- Regional self-concept: The term is retained and explained in the other language.
- Unclear correspondence: The responsible expert decides on the scope and delimitation before publication.
Professional planning for German-Italian website translations therefore begins with meaning and usage context. Only then does the linguistic formulation follow.
Properly structuring translated hierarchies
A translated hierarchy does not consist of two independently created category trees. In a multilingual taxonomy, the parent-child relationship is defined via stable IDs; the visible levels are given appropriate labels for German and Italian.
One possible model for a tourism business looks like this:
- tx-0001: Services
- tx-0010: Active holiday / Vacanze attive, superior tx-0001
- tx-0042: Guided hikes / Escursioni guidate, parent tx-0010
This leaves it clear: "Guided hikes" and "Escursioni guidate" belong to the same subcategory. The navigation may be sorted or editorially weighted differently in the two languages. However, the fundamental semantic relationship must not be altered unnoticed.
If the Italian market requires a different subject classification, this deviation must be consciously modeled and justified. Taxonomy and navigation fulfill different functions: Taxonomy describes meaning and relationships, while navigation controls access to content.
Localized slugs in a multilingual taxonomy
Localized slugs should be understandable in every language. A German slug should not be copied into the Italian URL for purely technical reasons. The connection between the language versions is established via the stable ID, not through identical URL components.
- German: /de/aktivurlaub/gefüehrte-wanderungen/
- Italian: /it/vacanze-attive/escursioni-guidate/
If a preferred name changes, the slug does not need to be automatically updated. An existing, understandable URL can remain unchanged. If a change is sensible or necessary, the process includes a permanent redirect, updated internal links, and an entry in the changelog.
You should review the allocation of language versions, keywords per market, and other SEO questions separately from the taxonomy. Our article on SEO planning for a multilingual website covers this next step.
Practical example of a German-Italian taxonomy
In my work with SMEs, I often see a similar starting point: The German website was built first. Later, Italian was added, and a second person redefined the categories according to their own understanding.
Previously: two language structures without a fixed assignment
- German uses "active vacation" as its main category.
- Italian uses "Esperienze" as a supposed equivalent.
- "Guided hikes" is listed as a service in German.
- “Escursioni” also appears in Italian as a general theme.
- Posts and offers are linked to different categories.
- The relationship between the terms is not documented.
The problem isn't just the translation. "Active vacation" and "experience" can have different meanings. Equating them without definition results in a technically imprecise classification.
Afterwards: a shared identity with localized manifestations
- Each business entity receives a stable ID.
- The scope of meaning is defined in a short definition.
- DE and IT each receive a preferred designation.
- Regional synonyms are added, but not created as new categories.
- The parent-child relationship is defined once via IDs.
- Localized slugs remain associated with the same entity.
- Any differing terms will be reviewed and documented during the approval process.
After the cleanup, a new post, offer, or service is assigned to the correct entity once and can then be displayed consistently in both language versions. This reduces the need for duplicate maintenance of the multilingual content structure.
Release process for a multilingual taxonomy
A multilingual taxonomy remains reliable only if decisions are documented. This requires clearly defined roles and a binding approval process.
1. Define the technical significance
The subject matter expert defines what the entity encompasses, what content it includes, and how it differs from similar terms. This decision is made before the translation.
2. Locate the labels
A person with strong linguistic skills formulates the preferred term, description, and regional synonyms for German or Italian, ensuring that the same meaning is expressed clearly for each language area.
3. Check hierarchy and slugs
The website administrators control the parent ID, the translated hierarchy, localized slugs, and existing links. Overlaps with existing categories are resolved before publication.
4. Conduct a cross-linguistic cross-check
A second person checks whether DE and IT actually describe the same entity. Particularly important are similar terms with different scopes and terms that cannot be translated literally.
5. Release and publish with versions
Once approved, the data record is published. The status, responsible person, date, and relevant changes are documented in the change log. This ensures that it remains traceable why a label or assignment was changed.
Terminology governance defines who creates, modifies, reviews, and approves terms. This eliminates the need to make fundamental decisions for every new page.
Checklist before publication
Identity and language check
- Does the term have a unique, language-neutral ID?
- Do DE and IT actually describe the same meaning?
- Is the preferred term defined for each language?
- Are regional synonyms assigned to the correct entity?
- Were duplicate or very similar categories excluded?
- Is the parent-child relationship professionally sound?
Check URLs and sharing
- Are the slugs understandable in both languages?
- Do existing links still lead to the correct content?
- Was a redirect set up when the URL was changed?
- Are the responsible person, release status, and change date documented?
- Has the display in navigation, filters, and internal links been checked?
Technical implementation of the multilingual taxonomy
A translation tool can transfer text, but it cannot resolve unclear meanings. Therefore, the domain model should be established first. Then you choose a system that supports stable IDs, separate language fields, localized URLs, and documented approvals.
In btlabs Core , we implement this principle with a central, multilingual content base: content and company data are centrally maintained and structured for various languages and output channels. However, this tool does not replace the professional definition and approval of terms.
When restructuring your German-Italian website, start with ten to twenty core services, categories, or topics. Define their identity, relationships, and responsibilities. Once this core model is working, you can expand the multilingual taxonomy in a controlled manner.
Questions about the multilingual taxonomy
Do German and Italian terms need the same ID?
Yes, if both terms describe the same business entity. The shared stable ID keeps content, filters, and relationships together, while the label, description, and slug are maintained independently for each language.
Is it permissible for the hierarchy to differ between Germany and IT?
The professional parent-child relationship should generally remain the same. Language-specific navigation may use different sorting or weighting methods; however, genuine semantic deviations must be consciously modeled and documented.
When does a synonym become its own category?
A synonym remains the same entity if only the name varies. As soon as the meaning, scope, or classification differs, you should create a separate entity with its own ID.
Do slugs need to be adjusted every time a name is renamed?
No. A well-known and established slug can remain even if the visible label changes. If a URL change is necessary, you'll need a redirect, updated internal links, and a documented entry.
Who should approve a German-Italian taxonomy?
The subject matter expert confirms the meaning, linguistically competent individuals review the German and Italian versions, and the website administrator checks the hierarchy and URLs. This division of labor prevents meaning, translation, and technical consequences from being determined by a single person without review.
How do I deal with terms that cannot be directly translated?
If necessary, retain the regionally established term and add an understandable description in the other language. Both language versions remain associated with the same entity; the decision is documented in the terminology system.
How do I get started with an existing website?
First, export all categories, services, and keywords from both languages. Highlight duplicates, unclear assignments, and missing translations, and prioritize cleaning up the most business-related terms.
A consistent multilingual taxonomy for German and Italian is not simply a translation project. It defines which services, topics, and categories your business offers, how the entities relate to each other, and who is responsible for changes. This clarity makes a multilingual website maintainable in the long term.
