Appearance
To run a multilingual Omeka S site, build on its native ability to tag every metadata value with a language code, then add the Internationalisation module to translate the interface and let visitors switch language. The discipline that makes or breaks it is tagging every value with its language from the start — an untagged value shows up no matter which language a visitor chose, and a half-tagged collection looks broken. Here is the practical order of operations.
Step 1: Decide one site or many
Before touching settings, choose your architecture. One multilingual site with language-tagged values is right when the same items appear in several languages — you describe each item once and attach translated values. Separate sites per language only make sense when the audiences, editorial teams or structures genuinely diverge.
| Approach | Best when | Cost |
|---|---|---|
| One site, language-tagged values | Content overlaps heavily | Discipline tagging every value |
| One site per language | Teams/audiences differ | Duplicated items, double maintenance |
For most archives and collections, the single-site model wins.
Step 2: Set language tags on every value
This is the foundation. Beside each property value in the editor is a small language field. Set it (en, fr, cy, etc.) for every value you enter. A title in two languages is the same property entered twice, each with its own tag:
text
dcterms:title → "The Old Bridge" [en]
dcterms:title → "Le Vieux Pont" [fr]The cardinal rule: never leave a value untagged. Untagged values display in every language context, so the visitor browsing in French still sees stray English strings. Make tagging part of your cataloguing checklist on day one.
Step 3: Add the Internationalisation module
Core Omeka S handles value-level language but not interface switching. Install the Internationalisation module to get a language switcher, locale-aware display (values matching the chosen locale surface first), and a place to manage available languages.
bash
# modules live under modules/ ; download, unzip, then enable in admin
cd modules
unzip Internationalization-x.y.z.zip
# Admin → Modules → Internationalization → InstallAfter enabling, configure the site's available locales in the module settings so the switcher only offers languages you actually maintain.
Step 4: Translate the interface and theme
Two layers of text are not your metadata: Omeka's own UI strings, and the strings your theme hardcodes (button labels, footer text, section headings). Omeka ships translations for many languages; for theme-specific strings, provide them through the theme's language/ translation files or, where the theme exposes them, through theme.ini settings per locale. Audit your active theme for hardcoded English before going live.
How does language affect URLs and SEO?
Omeka S language switching is primarily value-level rather than producing a clean separate URL per language, so plan your approach deliberately. Add an hreflang strategy in your page templates so search engines understand which pages are language equivalents, and document a consistent URL convention. Do not assume automatic per-language URLs — decide and record what you do.
html
<link rel="alternate" hreflang="en" href="https://yoursite.org/s/en/item/42">
<link rel="alternate" hreflang="fr" href="https://yoursite.org/s/fr/item/42">What are the common pitfalls?
- Untagged values — the number-one failure; they leak across languages.
- Translating only metadata — the chrome (menus, buttons) stays English and breaks the illusion.
- Authority drift — use shared controlled vocabularies so "Manuscripts" links to the same concept regardless of display language.
- Maintaining two sites you didn't need — doubles the workload for content that should have been one item with two value sets.
Step 5: Test as each visitor
Switch the site to each language and walk a real journey: homepage, a browse page, an item, a static page. Anything still in the wrong language is an untagged value or a hardcoded theme string. Fixing those before launch is far cheaper than after.
Key Takeaways
- Omeka S tags values with language codes natively — that is your foundation.
- Tag every value from the start; untagged values leak into every language.
- Store a field in two languages by entering the same property twice with different tags.
- Add the Internationalisation module for UI switching and locale-aware display.
- Translate the theme's hardcoded strings, not just the metadata.
- Prefer one multilingual site over many when content overlaps.
- Plan
hreflangand URLs deliberately; don't assume automatic per-language URLs.
Frequently Asked Questions
Does Omeka S support multilingual metadata out of the box?
Partly. Omeka S lets you tag each property value with a language code, which is the foundation. To translate the interface and switch display language per visitor you add modules such as Internationalisation and the locale-aware theme settings.
How do I store the same field in two languages?
Add the property twice on the item, once per language, and set the language tag (e.g. en, fr) on each value using the small language field beside it. The same property can hold multiple language-tagged values.
Which modules do I need for a multilingual site?
The core ones are Internationalisation (for UI strings and language switching) and Value Suggest/Custom Vocab for shared authorities. Translate theme strings via the theme's translations and use a language-aware navigation.
Should I run one site per language or one multilingual site?
Prefer one site with language-tagged values when content overlaps heavily — it avoids duplicating items. Use separate sites only when the editorial teams, structure, or audiences genuinely differ between languages.
How does language affect URLs and SEO?
Add an hreflang strategy so search engines map equivalent pages. Omeka's language switching is largely value-level, so document your URL approach and keep it consistent rather than relying on automatic per-language URLs.
What's the most common multilingual mistake?
Forgetting to set language tags on values. Untagged values display regardless of the visitor's language, so a half-tagged collection shows a confusing mix. Tag values consistently from the start.