Localization is the processes of translating a product to work in a new culture or language.

When it comes to MDriven we are in a good seat for handling all the texts that are available in a system.

Since we have the meta model of the system we can in theory know about all texts the system make use of.

Texts in a system comes in many forms:

1. Labels in UI
2. Actions, menus and menu groups
3. Constraints and validations
4. Static text in a string in an expression used somewhere inside the application

The standard solution to Localization is to instruct all developers to move all texts out to resources and create one resource bundle per supported culture – and involve translators ahead of delivery of the product to create the per culture unique resource bundle. Phew! A lot of work against a moving target… Sounds expensive and slow? Yes it is!

Having a MDriven systems you also change the product more frequently than with traditional development – and that makes it even more likely that your traditional translation process will slow you down too much to be acceptable.

In its simplest form we will need something like the model below. The Translatable is a text that may – or may not – have a Translation for a given Language.

If the Pattern from the above model is discovered by your MDriven system you may install the new IMDrivenUITranslation service – then the MDriven system will use the data found in the objects for the model and use them as translations.

The service is installed like this:

MDriven.Translation.MDrivenUITranslationImpl.Install(ecoServiceProvider);// Installs translation services

Newer versions of MDriven Turnkey does this already for you.

The IMDrivenUITranslation has a DefaultLanguage setting. The DefaultLanguage is set by MDriven Turnkey to the Language set in the user browser. Typically this is a value like “en-US” or “sv-SE”.

The new versions of MDriven also introduce a new operator on the string type – called Translate.

‘Translate this’.Translate(‘sv-SE’) is a valid expression that will try to look up a SysTranslatable object with Value equal to ‘Translate this’, it will then look for Translations that points out a Language with code equals ‘sv-SE’. If found the value of the matching SysTranslation object will be returned. If no matching translation is discovered the original value is kept.

It would be a complete pain to create all the SysTranslatables by hand and to help you avoid that you can perform this in an action: ‘Whatever’.Translate(‘SPOOLMISSED’) , sending “SPOOLMISSED” as a language has special meaning and create SysTranslatables for all complete misses that system has seen since start or since last call to SPOOLMISSED.

The actual dictionaries used to do the translations are created at system start up. That means that you will need to restart your system in order to see newly added translations to take effect. This may however not be a possibility for the translators on your team – most likely the translators are just ordinary users or administrators of your system – but they will want to see the effect of an added translation as soon as possible. To mitigate this we have added yet another special meaning lnaguage identifier: ‘Whatever’.Translate(‘RESETCACHE’). This will reset all cached pages in your application since they possibly contain translations – and the next request they will be re-done and thus reflect the new translations made.

Even if the SysTranslatables are created for you – the SysTranslations and SysTranslateLanguage are not. We suggest you use some ViewModels to manage the translations and possibly make use of the Excel-plugin to push large volumes of translations in and out of a system.