Language Translation in MPS Concept

I just took my first steps with MPS. Since I am not a developer, my development skills are unfortunately very limited and my questions may be "for dummies".

Which concepts can be used for the internationalization (translation) of texts in MPS? I do not only want to customize the output using TextGen, but also selected strings directly within the concept (e.g. Titel_German, Titel_French, Titel_English, ...)

Thank you for some hints on how this is typically implemented in MPS.




If you're looking to translate the text in the IDE, so that your language users get an English/French/German-speaking editor, mbeddr platform has some support for that in the form of com.mbeddr.mpsutil.multilingual.editor language and related languages. In this case a language developer will be providing the translations for language users.

If your goal is instead for language users to provide the translations that then would be used to generate output from the model, then you need to accomodate for those translations in your language. For example, rather than having a simple title property you would need one property per language (title_en, title_fr, title_de) if the set of languages is fixed. If it's not fixed you may need to create a special concept for Translation, containing a list of TranslationEntry concepts, each of which would have the language code and the translated text. I don't know of any published patterns about this but I could write a more detailed explanation.

Which case do you want to know more about?


I just want to add some ideas:

- For editors: you can separate editor to different editor components for each language and show them on some condition (it's easy to implement)

- For dropdown lists: we can use custom transformation menus to change the text (it will not be easy so you need to create an own tricky implementation)

- For concepts itself: you can implement your own tricky solution. For example:


thank you for being willing to give me some hints for a suitable procedure. I'm definitely looking for a solution so that "language users" can capture translation for generating artifacts themselves.

I would like to create a good basis which can be extended step by step in the long run. I have already tried some steps like "title_en, title_fr, ...". Currently I am capturing numerous elements like "DialogTitle" "Widget Label" "PageLabel" ... ect. For all of them I would like to have exactly 4 languages in a minimal version + one developer language enabled. In the first approach I have created strings for each concept (Dialog, Widget, Label) for the respective translation. But I have the impression that the translation of strings could/should be solved more generally. Hence the question if/how I could use a common "language concept" for all Labes/string etc. to be translated. The Language User should be able to capture the resource strings for the translation of the application to be generated.

In the long run I would like to extend this concept e.g. in the following way:
- For each label/attribute there is a SHORT/STANDAR/DESCRIPTION text
- If a translation field is not defined, there are fallback strategies, e.g. if SHORT is not defined, the first three characters of STANDARD are used
- Optionally, ICONS or GLYPHS can also be used for a term
- Status that defines, for example, whether the translation for a string is already reviewed, checked, approved or incorrect
- date, visa who translated/checked string
- …

The longer-term requirements are not important at the moment, but should indicate that the translation concept could be more extensive later and it would therefore be important to use or inherit a common concept for all strings to be translated.

I am looking forward to further hints and thank you already now for your support


What you need is partially covered by the com.mbeddr.mpsutil.multilingual.* family of languages, so you could look there for inspiration ().

In general, I think you want something like a generic TranslatableString concept which would contain the string to be translated, and possibly some key. Another concept would define a list of Languages to translate strings into. A separate TranslationUnit concept could contain Translations of a TranslatableString into a certain Language.

To check for missing translations you could use checking rules and, when that becomes slow, switch to assessments (, look for Assessments).


Please sign in to leave a comment.