The Power Platform is international and used worldwide. It therefore makes sense that it should work seamlessly with different languages. This is often seen as a minor detail, but the choice of language in a Power Platform environment has much more impact than just the UI.
Language settings are important to keep your apps clear and user-friendly for end users, and to make things manageable and understandable for developers. In this blog, I’ll explain how languages and translations work in Power Platform environments, and what you should keep in mind.
Environment language: the foundation of the environment
When creating a new environment in Power Platform, you choose a base language (environment language). This is much more important than it might initially seem. This chosen language forms the foundation and naturally influences the entire environment. It’s a setting that can only be chosen once during environment creation and cannot be changed afterwards.
For admins and developers, this means that management and configuration happen in that language, and for end users it determines how the UI of apps looks. For example, a button may show “Nieuw record” in Dutch or “New record” in English in a model-driven app. Formats are also set, such as date notation or the use of commas and dots in currency. Additionally, it impacts Out-of-the-box entities (like Contact, Account, Lead), as they automatically receive their (translated) names based on the chosen language.
For developers, the biggest pitfall is the difference in syntax and naming.
- In Canvas Apps, this determines the function syntax. For example:
- English: If(IsBlank(TextInput1.Text), “Empty”, “Filled”)
- Dutch: Als(IsEmpty(Tekstinvoer1.Text); “Leeg”; “Ingevuld”)
- As you can see, not only the function names differ, but also the separators (, → ;).
- In Power Automate, connector names and expressions also differ depending on the chosen language.
This can be quite confusing (for developers), so the best practice is to choose English as the base language, unless there’s a strong reason to use another. Developers especially benefit from English, as it ensures compatibility with documentation, community support, resources, and tutorials.
Language vs. User Language
As a user, it’s not always convenient to be tied to the environment language. Fortunately, you’re not completely stuck with it. You can make an environment multilingual by installing additional languages in the advanced settings.
- Environment Language: chosen once when creating the environment. It cannot be changed later.
- User Language: can be adjusted per user. This determines, for example, how the UI of apps looks for that user.
- It can be set manually in personal settings.
- As an admin, you can also update it in bulk using tools or scripts (such as PowerShell scripts or community tools like XrmToolBox with the “User Settings Utility”).
This way, every user in a multilingual environment can set their own preferred language. Labels and UI are therefore determined by user settings, not only by the environment language.
After installing multiple languages, you’ll often notice that custom entities and fields don’t have translations but always appear with their initial naming. This happens because there is no automatic translation, but you can provide these yourself.
Translations for custom entities, choices & labels
Where standard entities are often neatly translated automatically (through Microsoft-supported language packs), this is not the case for custom entities, choices, fields, forms, and even views. For these, Power Platform simply takes the initial name you provide and copies it to all available languages in the environment. Fortunately, you can adjust this manually by exporting the translations, completing/correcting them, and reimporting them.
If you don’t provide translations, this can lead to a poor user experience for international clients. Best practices in multilingual environments are therefore: always provide translations for all your additions for all installed languages.
The workflow for exporting and importing translations is as follows:
- Go to the settings of the solution containing the custom entities/fields to be translated.
- Choose the option “Export Translations”.
- You’ll get a ZIP file containing the following:
- [Content_Types].xml: a descriptive file that mainly contains metadata. You can ignore this.
- CrmTranslations.xml: the important file containing the actual labels and translations.
- Open CrmTranslations.xml in Excel:
- Open the tab “Localized Labels”. This contains all terms.
- At the top of the columns, you’ll find language codes (e.g., 1033 for English, 1043 for Dutch). Below, you can find the necessary labels and adjust/translate them easily.
- Tip: the XML sometimes also contains labels of views or form components that are not visible to end users. You don’t always need to change these, but you can translate them for consistency.
- Save the file.
- Repackage both files into a ZIP and import it back into your solution by choosing “Import Translations” in the solution settings. Then, you often need to publish the solution so the changes become visible to all users.
- This process can sometimes be a bit cumbersome, so there are also tools you can use to simplify it; such as XrmToolBox with the “Easy Translator.”
Conclusion
It should now be clear that language choice has a big impact. Language in Power Platform is much more than just a UI setting. It affects your environment, syntax, formats, entity translations, and overall user experience in apps.
My advice: make conscious choices, document your decisions/additions, and use tooling to maintain consistency and clarity.
With a mindful approach, you ensure that your Power Apps are not only functionally strong but also linguistically correct and user-friendly for every possible user.
