Multi-language support in Dynamics 365

How to support multiple languages in Dynamics 365 — language packs, translation, customisation labels, and the patterns for global deployments.

Updated 2026-12-01

Global Dynamics 365 deployments serve users across countries and languages. Native multi-language support exists; configuring it well requires understanding language packs, customisation labels, and translation workflows. Done properly, each user sees Dynamics in their preferred language; done poorly, English bleeds through everywhere.

Microsoft language coverage.

  • 40+ languages supported across Dynamics 365 modules.
  • Module-specific — some languages may have lighter coverage per module.
  • Updated each wave — translations evolve.

For most major languages, comprehensive coverage.

Language packs. Per environment:

  • Base English (always).
  • Additional languages added.
  • Users select their language.
  • UI adapts.

Available languages vary per product (Dataverse, F&O, etc.).

Enabling languages.

  • Power Platform admin centre.
  • Per environment.
  • Multiple languages can coexist.
  • Provisioning takes minutes to hours.

User language preference.

  • Personal options — user selects from enabled.
  • Per-user setting — independent.
  • Default per environment — for new users.

Users in different roles can have different languages in same environment.

Customisation labels. Custom entities, fields, options:

  • Localised labels per language.
  • Translation export / import — XML-based.
  • Fall-back to default — if translation missing.

Without translated labels, custom fields show in default language only.

Translation workflow.

  1. Build customisation in default language (e.g., English).
  2. Export translations file.
  3. Translate (manual or via translation services).
  4. Import translations.
  5. Verify in each language.

The cycle repeats for each customisation update.

Translation tools.

  • Manual — translators edit XML.
  • Translation memory — Trados, others.
  • Machine translationAzure Translator API.
  • Hybrid — machine + human review.

For ongoing customisation, automated translation pipeline preferred.

Date, time, number formats.

  • Locale-driven — per user's region.
  • Decimal separators — comma vs period.
  • Date order — MM/DD vs DD/MM.
  • Currency formatting — symbols, position.

These are user-settings; respects user's preference.

Time zones.

  • Per-user time zone preference.
  • Records stored in UTC.
  • Displayed in user's local time.
  • Cross-timezone scheduling.

For global operations, time zone handling is critical.

Right-to-left languages.

  • Arabic, Hebrew, Persian — RTL.
  • UI layout flips automatically.
  • Mixed content (RTL + LTR) handled.

Less common but important for global reach.

Multi-language content data. Beyond UI:

  • Knowledge articles with language variants.
  • Product descriptions per language.
  • Customer communications in customer's language.
  • Document templates localised.

Data multi-language is harder than UI; partner extensions sometimes help.

Knowledge articles in multiple languages.

  • Master article in primary language.
  • Translations as language variants.
  • Search returns user's language version.

Covered in [[dynamics-365-customer-service-knowledge-management-deep-dive]].

Email templates.

  • Templates per language.
  • Selected based on recipient's language.
  • Variations for cultural appropriateness.

Mass emails should localise; single template across all languages comes across as foreign.

Customer communications.

  • Contact's preferred language stored.
  • Communications filtered by language.
  • Salesforce / agent speaks customer's language.

Customer satisfaction tied to language respect.

Document templates (Word, Excel).

  • Multiple templates per business process per language.
  • Auto-selection by context.
  • Quote, invoice, contract in customer's language.

For documents customer receives, language matters.

Marketing in multiple languages.

  • Customer Insights — Journeys supports per-language.
  • Conditional content by recipient language.
  • Segmentation by language.

Marketing localisation affects engagement rates significantly.

Power Apps localisation.

  • Multiple language labels per app.
  • Auto-translation for new languages.
  • User-language-driven rendering.

For canvas apps, similar pattern to model-driven.

Power Automate localisation.

  • Connector descriptions localised.
  • Action labels localised.
  • User-facing notifications can be language-aware.

Country-specific specifics.

  • Each language often paired with country / regulatory specifics.
  • Tax handling, currency, regulatory reporting per country.

Multi-language often part of multi-country deployment.

Translation governance.

  • Translation memory maintained.
  • Glossary of approved terms.
  • Review process for new translations.
  • Versioning.

Without governance, translation drift and inconsistency.

Common pitfalls.

  • English bleeds through. Untranslated customisations.
  • Bad machine translations. Customer-facing content poor quality.
  • Cultural insensitivity — direct translation misses nuance.
  • Right-to-left forgotten. Hebrew / Arabic users unhappy.
  • No update process. New customisations not translated.
  • Inconsistent terminology. Same concept translated differently.

Best practices.

  • Plan multi-language from start.
  • Use translation services for accuracy.
  • Maintain glossary.
  • Test in each language.
  • Update translations with each release.
  • User feedback on translation quality.

Operational rhythm.

  • Per customisation cycle — extract / translate / import.
  • Quarterly — translation quality review.
  • Annually — comprehensive audit.
  • On new feature — assess language scope.

Strategic positioning. Multi-language support is essential for global Dynamics 365 deployments. The platform supports it; the discipline of using it properly is the difference between truly global capability and "English with awkward translations."

For decision-makers:

  • Plan languages early.
  • Budget for translation work.
  • Establish governance.
  • Test in each language.
  • Listen to local user feedback.

The investment is meaningful; the alternative — forcing all users into English — limits adoption and offends users. Properly multi-lingual Dynamics deployments respect users and customers worldwide; that respect drives both adoption and customer experience.

Related guides