Translations and captions in AL: the XLIFF workflow, even if you only ship English

Business Central users pick a language in My Settings, and every caption on every page follows it. An extension that ships only its source captions shows English to a Polish warehouse worker in a tenant where everything else is Polish. More to the point, separating what the code calls a thing from what the user sees is good design even in one language: you can reword a field for users without a schema change.

Captions

Every object, field, action, enum value and page control has Caption. Set it on everything (UICop insists). The caption is the source-language text; the name is for code. Report labels (labels { }) and text constants (Label variables) are also translatable, which is why all user-facing text is a Label (naming post).

The XLIFF workflow

1. In app.json, "features": ["TranslationFile"] (and "TranslationsWithNamespaces" on runtime 18+). Build. The compiler writes Translations/<AppName>.g.xlf: every translatable string with its ID and source text.
2. For each target language, a copy named <AppName>.<culture>.xlf (.de-DE.xlf, .fr-FR.xlf) with the target elements filled in. The generated file is regenerated on every build; the language files are yours and are merged by tooling.
3. Tools: the XLIFF Sync VS Code extension (community) keeps the language files in step with the generated one and flags new and changed strings; AL Language Tools and NAB AL Tools add translation helpers; for volume, Microsoft's Dynamics 365 Translation Service (DTS) machine-translates XLIFF for Business Central with a reviewed glossary, and professional translators work in any XLIFF tool.
4. Ship the language files in the app; the platform picks the one matching the user's language and falls back to the source.

Locked labels and comments

Locked = true on a label excludes it from the XLIFF: technical strings, telemetry, URLs, format strings. Comment = '%1 = Customer No.' tells the translator what the placeholder is; without it they will guess, and the Polish version will have the words in the wrong order. MaxLength on a label warns the translator the text must fit a field.

Even for UK-only

• You get a complete inventory of every user-facing string, which finds the ones with typos and the ones that say "Invalid" and nothing else.
• A customer who opens a Dutch subsidiary next year is a translation job, not a rewrite.
• AppSource requires it; a per-tenant extension that might become a product is ready.
• The pipeline can fail the build on untranslated strings for the languages you support, which is a cheap quality gate.

Translating data, not code

Item descriptions, payment terms descriptions and the like are data, not captions. The base application's Translation table and Codeunit Translation (Translation.Set(Rec, FieldNo, LanguageId, Text) / Get) store per-language values for any field you register, with the standard "Translations" page pattern. Item translations for documents are the older Item Translation table used by sales documents in the customer's language. Use the first for your own tables; respect the second when you print.

Formats

Dates, numbers and currency formats follow the user's region, not the language; use Format with no format string for display and Format(x, 0, 9) for machine-readable, and never build a number into text with string concatenation that assumes a decimal point.

Related posts