Dynamics 365 Dataverse Translations | Label Import and QA Guide

Did you know that Dynamics 365 label translations can import without appearing for the intended user? People searching for a Dynamics 365 translation export and import guide are often facing a specific Microsoft Dataverse localization problem: a customized table, column, form label or choice value is translated in a ZIP package, yet a model-driven app continues to show the base-language text. The missing step may be an unprovisioned language, an incorrect label row, an unpublished customization or a component outside the exported solution.

This guide teaches Power Apps model-driven app translation QA for Dynamics 365 and Dataverse custom labels. The single reader job is to get approved UI labels through an export–translate–import–publish cycle and verify them in the user’s selected language, while leaving logical table names, business data, security rules and automation untouched. It does not teach general document translation, Salesforce Translation Workbench or Power Pages website localization; those systems have different ownership and delivery rules.

The central mechanism is simple once its layers are visible. A solution contains customizations with localizable display strings. An export packages references to those strings; the target-language columns associate translated labels with component identities. Importing the package stores localized text, publishing makes relevant changes available, and a properly provisioned environment plus a user language preference selects what people actually see. Check each link rather than treating the successful upload message as the final outcome.

Quick answer: reproduce one translated label from end to end

Use an unmanaged solution containing the intended customized table or form. Confirm that the target language is enabled in the environment. Export translations through the solution’s translation action, preserve the structure of the resulting ZIP, add approved localized text to the correct language column in the exported translation data, and import it through the same solution workflow. Publish customizations in an approved maintenance window. Finally switch an authorized test user’s display language and inspect the exact label in the actual model-driven app, not just in a workbook.

If a label still appears in English, make a small diagnostic record: expected component, source label, target locale and language code, environment, solution, package revision, user preference, exact app screen and observed text. Ask whether the label was exported, imported, published and selected in that sequence. Microsoft documentation warns that some apparent translation failures are actually form-layer or base-language customization issues. The shortest fix follows the component’s identity, not a bulk replacement of English words.

Why display text is different from underlying CRM schema

Dataverse distinguishes what an interface says from what a system stores. A column can have an internal logical name used by code, integration mappings, views and automation, while presenting a friendly label to human users. That display label can vary by UI language without changing the field’s database identity. Translating ‘Estimated close date’ into French should not rename the column used by a Power Automate flow or update any opportunity dates. The localization layer makes the same data easier to understand; it should not mutate the data’s meaning or structure.

This separation is especially important in sales and customer service. A salesperson may read a translated form, but a reporting system still expects stable identifiers. Do not alter IDs, schema names, choice values or relationship definitions because their technical names look English. Translate the human-facing label assigned to each stable component. If a CRM administrator cannot tell which content is display text and which is a logical identifier, pause the edit and identify the right object in the app designer. A polished translation attached to the wrong component is more dangerous than an untranslated label.

The five gates between a translated file and a displayed label

Think of label delivery as five gates. First, the right language must be provisioned in the environment; the base language alone cannot demonstrate multilingual behavior. Second, the target component must be represented in the solution export. Third, the translated value must be placed in the correct row and language-code column without breaking package structure. Fourth, import and publication must complete correctly. Fifth, an actual user must select a compatible display language and open the screen that consumes the localized label.

A gate-based model helps diagnose partial failures. If all French labels are absent, check environment and user language settings before inspecting hundreds of XML rows. If one custom field is missing while other custom labels work, focus on export scope and component identity. If an old value persists after a successful import, inspect whether publication completed and which form or label layer is active. Each symptom narrows the search. Translation becomes quicker because the reviewer no longer treats every English word as a linguistic error.

Provision the language before translating the solution

Microsoft’s Power Platform guidance says that the target language pack must be added to the environment before users can use it and before imported solution labels can be displayed as expected. Provisioning is an environment administration task; it is not the same as choosing a language on a user’s profile. Depending on configuration it can take significant time, so do not schedule a release assuming a language appears instantly after clicking a checkbox. Confirm availability in the Power Platform admin center and allow the operation to finish.

For a concrete test, suppose an environment was created with English as its base language and the company now needs German. Provision German, then verify that a test user can select it. Do not confuse a German browser UI with the language selected for the Dataverse app. Distinguish the user’s language preference from region settings such as date, number and currency formatting. These may interact in the overall experience but do not grant new translation data to a component. The best evidence is a German interface that displays an approved custom label on the intended screen.

Scope the solution before exporting text

The exporter works with the components represented by the selected solution, and Microsoft warns that translation export for a table can include text from other forms associated with that table. A narrowly named solution does not guarantee a narrowly scoped workbook. Inventory the tables, columns, forms, views and relevant choice labels included in the export before sending it to a translator. Use an unmanaged solution in the editing environment, following the documented workflow. Avoid exporting directly from a production-only managed deployment as though it were your editable source.

For example, a ‘Customer Onboarding’ solution may contain one customized contact form. The export may nevertheless include many labels for the related table. If the translation vendor changes every unfamiliar string, it may inadvertently introduce broader component dependencies or conflict with another team’s terminology. Mark the owned rows and provide a clear scope statement. The desired operation is not ‘translate everything in the ZIP’; it is ‘safely localize these approved labels and leave all unrelated references intact’. That boundary saves cleanup during later solution upgrades.

Capture the base-language source revision

Before export, write down the intended base-language labels and where they appear. Take screenshots of the target form in a controlled environment and note the current solution version or customization revision. This is not busywork: source text can change during a development sprint, and a translation package exported on Monday may be imported after a field was renamed on Thursday. The translator could produce an impeccable target label for an outdated component.

Record the difference between source-content approval and translation approval. A form label ‘Expected revenue’ may be replaced by ‘Forecast amount’ because the product team changed the field’s use. That is a semantic source change, not just a punctuation update. The target should be reconsidered. If an editor changes a capitalization style without affecting meaning, reuse may be appropriate. Keep the exported artifact matched to the source revision; importing translations whose source cannot be identified turns language QA into guesswork.

Understand the exported ZIP as a controlled artifact

Microsoft’s documented flow produces a compressed package containing CrmTranslations.xml and [Content_Types].xml. Those files need to remain at the archive root for import. CrmTranslations.xml contains the localized label data and related structure; the other XML file is package metadata. Do not rename the files, nest them inside an extra directory or convert the package to a different document format because a spreadsheet program suggested it. Preserve an untouched export for comparison and disaster recovery.

Many teams open CrmTranslations.xml in Excel because the data is presented in sheets such as ‘Localized Labels’. That convenience creates a risk: a save dialog may change the file format, corrupt XML structure, remove a language-code column or reinterpret an identifier. After editing, validate that you still have a valid, importable XML package. Compare archive entries and key references against the untouched original. The export is not a free-form bilingual spreadsheet; it is a structured interchange artifact with a strict reader on the other end.

Match language codes instead of trusting column position

The exported data includes columns identified by language code. Microsoft examples use 1033 for English (United States), 1031 for German (Germany) and 1034 for a Spanish locale. The numeric code is not decorative: it connects each localized value with the language pack that will consume it. Verify the target code using the enabled environment languages, rather than assuming that the second empty column is always German or that every Spanish market uses one universal locale.

A row also belongs to a specific object and label. A translation entered one row too low can remain grammatically correct and still appear against a dangerous action. Imagine ‘Cancel opportunity’ accidentally receiving the phrase intended for ‘Close opportunity’. A spreadsheet can contain both phrases without warning. Preserve row identities, descriptions and context, and review translations with their precise component. When filters and sorting are used in Excel, do not lose the alignment between IDs and target strings. Stable identity is the foundation of safe reuse.

Translate complete UI actions, not isolated English words

CRM labels are short and ambiguous. ‘Close’ may mean closing a dialog, completing a sales opportunity or marking a customer case resolved. ‘Lead’ could be a noun describing a prospect, not a verb. ‘Order’ may mean a sales order rather than an instruction to rearrange items. A fast translator who sees only a two-word source will make plausible choices that may be wrong in context. Supply component type, screen, neighbouring labels, action result and any relevant domain glossary.

A reliable review pairs the label with the action the employee will take. If a button named ‘Deactivate’ changes whether a record is available, the target must not imply permanent deletion. If ‘Submit for approval’ initiates a controlled workflow, translating it as ‘Approve’ falsely assigns authority. Build a tiny context card for each ambiguous item: source, location, meaning, allowed behaviour and screenshot. This is cheaper than discovering the mistake during acceptance testing and safer than relying on translation memory to guess which sense of ‘close’ was intended.

Keep choice values, labels and data reporting separate

A Dataverse choice field can display localizable labels while maintaining its underlying option values. Users may select a translated status, but reports and integration logic should rely on stable values and approved mappings, not compare the visible German sentence with a fixed English string. When reviewing choice translations, inspect what each option means and whether its business distinction survives. ‘Qualified’, ‘Contacted’ and ‘Unqualified’ are not interchangeable simply because a bilingual reviewer finds natural synonyms.

Test each representative choice by selecting it in a non-production record or safe test environment and observing the stored and reported outcome. Then switch language and confirm the display changes while the semantic value remains the same. If a downstream dashboard appears to relabel categories incorrectly, determine whether the problem is the label layer or an application transformation. Localization should improve usability without altering workflow gates, approval states, revenue calculations or the set of permissible selections.

Know which strings the solution translation tool does not own

Not every visible phrase in a Dynamics 365 experience enters through the same exporter. Microsoft specifically notes exceptions such as some sitemap labels that use alternative customization properties. Canvas applications, embedded custom controls, web resources, plug-ins, email templates and Power Pages content may require different localization workflows. Do not mark a solution translation import as failed merely because it did not change text outside its documented scope.

Inventory the remaining English text by owner. A fixed label in a custom React control could be an engineering localization defect. A vendor-managed widget may have its own resources. A site navigation title may need a different designer property. The absence of a string from CrmTranslations.xml can be evidence that it belongs elsewhere, rather than proof of a missing export. Assign a separate work item with a clear surface and supported method. This article stays focused on the exported Dataverse/model-driven app label pathway so that its success criteria remain testable.

Preserve base-language customizations in the right editor

One of the more surprising Microsoft-documented behaviors is that translation import is not designed to manage all base-language labels. If a translator edits the base-language column inside CrmTranslations.xml, those changes may not take effect. Likewise, unchanged base-language labels may not be included in exports because the export reflects customized elements and their layers. A missing row is not always a software error. Ask whether the component was customized and how its display name was changed.

When the original English label itself needs correction, make the source customization in the supported app or form designer, then export for other provisioned languages. This preserves the intended layering and makes the change visible to people who manage the app. Do not try to force a new English base label through the German import step or insert fabricated rows with guessed IDs. The localization pipeline should follow the component lifecycle rather than impersonate it.

Avoid corrupting XML when editing through a spreadsheet

Opening an XML file in a familiar grid can make a rigid format feel permissive. Yet spreadsheet software may reinterpret long numeric identifiers, trim leading zeros, normalize text, change quoting, or write an incompatible representation when saving. Work on a copy. Maintain the source columns and metadata, ensure identifiers remain exact strings, and test the resulting XML with a parser or controlled import before production use. The goal is to change approved target labels only, not to reshape the workbook.

Avoid bulk find-and-replace without context. Replacing every occurrence of ‘Account’ with ‘Company’ might hit a different table, plural form or record type. Microsoft guidance specifically warns against indiscriminate replacements in exported display strings. Use targeted rows and review their object identities. Preserve placeholders and punctuation where they have execution meaning, but allow normal grammatical reordering around them. If the file cannot be parsed, restore the last known-good package rather than hand-editing mysterious XML fragments until the importer accepts them.

Respect the imported-text length constraint

Microsoft documents a 500-character limit for translated text items in this import mechanism; an oversized entry can cause the import to fail. This constraint should be checked before packaging, rather than only after a rejected production upload. Count target characters in the way the relevant system expects, identify outliers, and ask the content owner to approve a concise but complete label where needed. The limit is a technical gate, not permission to discard legal qualifiers or safety instructions.

If a message truly needs more explanation than a label can hold, consider whether the interface should separate its action label from supporting help text through a supported component. Do not invent a shortened translation that reverses meaning. For example, ‘Close without saving any changes’ must not become an ambiguous ‘Close’ if the distinction matters and users could lose work. A system limitation is an issue for design and workflow ownership; the translator should report it with alternatives and exact affected locations.

Repackage the translated files correctly

After the approved edits, reconstruct a ZIP whose root contains the expected CrmTranslations.xml and [Content_Types].xml. Check the archive before import by listing its paths; if they begin with an unnecessary folder name, the package is structurally different from the required input. Keep file encoding and XML syntax intact. Generate a checksum or revision identifier for the package so the result can be associated with the translation approval and tested solution.

An effective handoff note includes environment, solution name, target language codes, source revision, exported file reference, translated rows, character-length validation and any intentional untranslated entries. Make the note short enough to use but specific enough for another administrator to reproduce. People move between teams and vendors; a packaged translation without provenance becomes a liability during incident response. Do not put confidential CRM records into the handoff. Exported labels should be treated as configuration resources, not a database dump.

Import in the correct environment and publish deliberately

Use the supported Import Translations action on the intended unmanaged solution and verify completion. Then publish customizations as directed by Microsoft’s guidance. Publication is not a harmless background detail; it can affect users’ work, so schedule it according to the organization’s change policy. A successful import does not by itself prove that every updated label is visible to the user’s app session. Wait for the appropriate completion signals and test the running interface under an enabled language.

Avoid a broad production publication as an ad hoc experiment. Reproduce the import in a development or test environment where possible, then use the organization’s normal release management to transfer the approved solution to production. Keep rollback and support ownership clear. If labels seem stale, capture which environment and application are actually open before repeating imports. Many apparent localization mysteries arise because a tester is looking at a different environment, app version or form than the one represented in the exported package.

Choose the right person and language for acceptance testing

Dataverse users may choose their preferred display language from among those enabled in the environment. The person who authored a solution in English might continue seeing English even after German labels were imported. Use an appropriately authorized test identity, explicitly select German, and load the intended model-driven app. Record the account role, language preference and exact form where the label should appear. Do not assume changing the operating system or browser language is sufficient evidence.

Roles matter because they determine which records, forms and actions a user can see. A successful administrator test may not prove that a sales representative encounters the same form, especially when apps have role-dependent navigation or multiple form variants. Choose the test role to match the reader of the label while protecting production data. The translation should never be evaluated by asking a real customer or employee to manipulate an important case or opportunity merely to generate screenshots.

Compare what appeared with the correct component identity

A translated word on screen is not proof that the intended source row was used. Inspect the exact form, column or command the user is interacting with. A table display name can appear in a view, a navigation entry and a related-record selector, each of which may have different localizable elements. Some text may originate in platform defaults while other text comes from a customized field. Record the origin and expected value for the occurrence being checked.

For each critical label, a useful test record includes the underlying component reference, UI location, base-language wording, target-language wording, target language code and screenshot. When the same English phrase appears in several places, do not blindly require identical target wording. Grammar and action context may call for differences. The identity-and-context record makes those differences intentional, so reviewers can approve them rather than misclassify them as inconsistencies.

A worked example: German labels on a sales opportunity form

A company customizes an opportunity form used by sales representatives. It adds a date field labeled ‘Forecast decision date’, changes a choice label to ‘Awaiting customer approval’, and includes a command labeled ‘Request review’. The German localization team receives the solution export, translates the three phrases and returns a ZIP. An administrator imports it and declares the work finished. A German-speaking salesperson reports that the date label remains English and the option label is wrong, while another user sees the German command.

Begin with the environment gate. Confirm German is provisioned and the affected user’s preference is German; the localized command already suggests at least part of the language selection is working. Examine the form identity next. There may be multiple opportunity forms for different roles, or the team may have exported a solution that contained a different form customization. Match the date label’s component identity to the exported row rather than searching by English text alone. If that component did not enter the export, correct the solution scope or source customization and create a new controlled export.

For the option, inspect the target-language column and the underlying choice value. Suppose ‘Awaiting customer approval’ was translated as ‘Approved by customer’. That reverses the workflow state even though the string is fluent. Change the target label through the approved row, ensure the stable choice value remains unchanged, and validate the test record’s stored state. Also inspect whether the command label belongs to the same solution exporter or another command customization surface; do not use its success to infer that the entire opportunity form was localized.

Reimport the corrected package in the controlled environment, publish the relevant customizations, sign in as the appropriate test user and open the intended opportunity form. Verify the date field, the displayed choice options and the command’s actual behavior. Review the source revision and make sure the German words still match the current English meaning. The resulting defect report can now say precisely: ‘Missing export row for form B’, ‘incorrect translation for choice value X’, and ‘command translated correctly’. Three targeted observations replace a vague demand to reinstall the language pack.

Failure mode: the file imports, but labels remain English

Follow evidence in order. Check whether the user can select the target language and whether the environment provisioned it before importing the relevant solution. Check that the package contained rows for the intended component and correct language code. Review whether publication occurred. Confirm the test user opened the right environment, app and form, and check solution layers or customization provenance if a form label remains unexpected. Microsoft documents particular interactions between form label layers and displayname elements that can affect inspection.

Do not respond by modifying the base-language column or rebuilding the entire solution immediately. Such steps can introduce new unmanaged customizations and hide the original issue. If only one label fails, compare it to a known-good label from the same package. What differs in identity, scope, form or source customization? A good diagnostic isolates one variable at a time and leaves a trail the release engineer can use. This is faster than repeated import cycles with no structured hypothesis.

Failure mode: an import rejects the translated ZIP

An import can fail even when the translations are linguistically excellent. Start with the exact error message. Inspect archive root paths and verify the presence of both required files. Validate that CrmTranslations.xml remained XML after spreadsheet editing, check for accidental renaming or extra directory nesting, and scan for entries violating documented length limits. If the edited package differs structurally from the untouched export, restore the original structure and apply only the authorized target changes.

Do not use production as the file-format validator. A test import in a suitable environment can catch structural mistakes before the release window. Keep raw error text, package revision and solution context with the report. Where an importer rejects a particular row, identify its component and target text rather than making indiscriminate changes to all rows. A rigorous workflow can distinguish a corrupt container, unsupported value and wrong deployment target, which are three different problems with three different fixes.

Failure mode: translating a form creates an unexpected dependency

Microsoft cautions that exporting translations for a table may cover more forms than the one that originally motivated the work. If an editor modifies labels from unrelated forms, those changes can become additional dependencies or produce competing expectations across teams. The translation file may appear complete, but the eventual managed solution package may now include a broader surface than approved. This is an application lifecycle issue, not a grammar problem.

Prevent it with row ownership. Mark each row inside scope and review the exact set of edited component references before import. After import, compare the intended modifications with the solution’s reported changes, following the organization’s configuration-management process. Do not accept ‘we only edited the German column’ as sufficient proof of safe scope. A language edit still changes localized metadata on a component. Treat it with the same care given to other changes that can affect a shared enterprise application.

Build a practical validation worksheet

A lightweight worksheet can contain these columns: solution and environment, object reference, screen, English source, target language code, approved target, original source revision, import package revision, import result, publication state, user language, observed screen result, and resolution. Assign a small number of high-risk labels to a human reviewer: decision outcomes, approvals, money, dates, status transitions and destructive actions. Less critical navigation labels can be sampled after basic structural checks pass.

The worksheet is not a substitute for app testing. A ‘pass’ row must be attached to a visible outcome on the correct screen. Where a command changes a record, validate safely against a test record and inspect the resulting status; avoid clicking potentially destructive buttons in live customer data. When performance or access controls hide a component from the tester, record ‘not observed’ instead of ‘passed’. This vocabulary reduces false confidence and makes review ownership clear.

Design a reusable release process rather than a one-off upload

A stable cycle begins with the approved source customization, a versioned export, translator context, structured validation, test import, publication, user-language verification and release sign-off. Retain the last accepted translations as a reference, but carry forward only entries whose component and meaning still match the current solution. Review additions, removals and renamed components in the next release; do not rely entirely on identical English strings or spreadsheet positions.

Consider an app that adds ten fields every month. An efficient process does not force translators to reread every unchanged label. It detects which component identities were added or whose approved source text changed, asks for targeted review, and then regression-tests the highest-risk screens. Record which labels came from standard platform resources versus custom solution content. This architecture also prevents a vendor from trying to translate terms Microsoft already localizes through language packs. The fewer false tasks you send, the faster the actual changes can be verified.

Transfer exercise: find the owner of three similar phrases

Open a non-production model-driven app with a customized table, a view and a form. Identify three visible occurrences of the word ‘Account’ or another common domain term. For each, determine whether it is a table display name, column label, navigation element, platform default or custom control. Predict whether the exported solution translation package will own that particular occurrence. Then select one safe custom label and trace its path through export row, language column, import, publication and test-user display.

Finally, propose a scenario in which two occurrences should receive different translations because the first describes a legal entity and the second describes a customer account. Write one context note that helps a translator distinguish them. This exercise transfers the method beyond a single ZIP file. You are learning to follow label identity, ownership and runtime selection, which remain useful when the application gains more forms or integrates with other Microsoft systems.

An operational sign-off that protects business meaning

The release owner should receive evidence for both language correctness and system stability. Confirm that translated labels appear on the intended screens; choice values and record statuses remain unchanged; no unauthorized fields, forms or commands were modified; critical terms have domain approval; and the correct environment and solution revision were used. Keep the evidence proportionate to the change. Three revised field labels do not need a hundred-page test pack, but they do need more than a screenshot of Excel.

Where a label remains intentionally in the base language, document why. It might be a product name, an unsupported component or a temporary limitation with an owner and expiry trigger. Do not label every English term a failure, and do not hide a genuine missing target behind ‘probably standard content’. The result should be explainable to both a bilingual business reviewer and the CRM administrator who will support the app. That shared understanding is how translation stops feeling like a risky last-minute upload.

Track managed-solution layers across environments

Development and production environments can expose different effective customizations because solutions are layered and their deployment histories differ. The imported labels may be valid in the development environment while a different managed solution version, unmanaged customization or component layer governs what production users see. Before comparing screenshots, record the solution versions and relevant deployment history in both environments. Ask which layer owns the visible form and which customization was last published. An English label that survives a German import may be an older layer or an unexpected form selection, not an instruction for the translator to invent another synonym.

Plan translation work within the organization’s application lifecycle management process. Export from the intended editing source, validate the resulting labels there, then deploy the approved solution package and test the target environment’s enabled languages. Treat emergency edits made directly in production as controlled exceptions, because they can diverge from the source of truth and disappear on the next upgrade. If a production label is unexpectedly different, capture its component identity and solution-layer evidence. This prevents a common failure in enterprise localization: correcting the wording in one environment while the next routine deployment quietly brings the old wording back.

Verify accessibility and long-label usability

A label can pass translation review and still be unusable in the model-driven app. Long German or French field names may wrap unexpectedly, overlap controls or become truncated in compact forms, grids and mobile layouts. Review the actual app at realistic viewport sizes and with a test user’s relevant accessibility settings. Confirm that the label still names the correct field, that help text does not contradict it, and that keyboard navigation and screen-reader announcements remain meaningful. Do not depend solely on a desktop administrator screenshot at a generous width.

Treat usability findings as shared responsibilities. A translated label may be accurate but need more space, a different form layout or approved shorter terminology. If the field is ‘Date customer approved final contract’, removing ‘approved’ to fit a narrow header changes the decision being recorded. Raise the issue with the form designer and business owner. Verify that any revised short label remains distinct from nearby fields such as ‘Date submitted for approval’. A global translation can be reused quickly only when the component’s size, context and consequences are checked where employees actually work.

Retain terminology decisions with component context

Organizations often maintain dozens of related status and approval phrases. A glossary helps, but a single English word does not always have one valid translation. Record term decisions alongside the kind of CRM component, action and business meaning. ‘Opportunity’ as a sales record should be consistent within the relevant application; ‘case’ as a customer-service ticket may need a distinct established term. A translated action should not be borrowed from a navigation label merely because the English surface is identical.

When a reviewer changes a proposed target, note why. Was the original technically incorrect, commercially misleading or simply inconsistent with approved product language? Connect the decision to the component ID and source revision so future exports can reuse it responsibly. Review translation memory matches against that context before bulk application. The best reuse accelerates repeated correct decisions; indiscriminate reuse spreads the same misleading label across multiple forms. Domain-specific examples are especially valuable for new contributors who have not yet learned how the organization names its records and workflows.

Summary: publish the right label to the right user

For Dynamics 365 and Dataverse, successful label localization is a chain of component identity, language provisioning, controlled export, target-language editing, structurally valid import, publication and user-context verification. Preserve logical names and option identities, check solution scope, and treat label rows as configuration rather than loose prose. A precise error report identifies the failed gate so that the right administrator can repair it without disturbing sales data or workflows.

Frequently asked questions

Why did my German translation import but still show English?

Check that German was provisioned before the relevant solution import, that the affected user’s display language is German, that the component was included in the exported package, and that customizations were published. Also confirm you are testing the intended environment and form.

Which files must be inside the import ZIP?

Microsoft specifies CrmTranslations.xml and [Content_Types].xml at the ZIP root. Do not add an extra containing folder or save the XML as an unrelated spreadsheet format.

Can translation import rename Dataverse logical columns?

No. The mechanism is intended for localizable display text. Keep logical schema names and stable choice values separate from human-visible labels; changing them is a different customization operation.

Why is a customized label absent from the export?

Export scope and source customization matter. Microsoft notes that some unchanged base labels are not exported and that form label layers can behave differently. Verify the right solution and supported label element before adding guessed XML rows.

Does importing translated text make it visible instantly?

No. Microsoft instructs administrators to republish customizations after import. Users must also be working in the appropriate enabled language. Publication should follow the organization’s operational change process.

Can I use translation export to localize Power Pages content and custom controls?

Not as a universal method. A Dataverse label export covers specific solution customizations; websites, embedded controls and other resources may use separate localization mechanisms. Identify the content owner before editing.

How People Translate Quickly | Dynamics 365 Dataverse Label Translation QA: Export, Import and Verify CRM Language Packs