Dexterity: Designed for Translation

From the Translating Dexterity Applications Series. 

When Great Plains Software decided to update their text based Great Plains Accounting (GPA) software for the graphical user interface (GUI) world of Windows and Macintosh, they found that a suitable development environment did not exist and so decided to develop their own. Hence we have Dexterity.

What was Needed

One of the design principles for Dexterity was that it needed to be translatable.  Translation includes changing the complete application into another language as well as just changing terminology for localization.

Examples of terminology changes from US English to International English include:

• Customer - Debtor
• Vendor - Creditor
• Zip Code - Post Code
• Check - Cheque
• Fiscal - Financial
• Inquiry - Enquiry
• Color - Colour

It was important that the ability to translate did not require any code changes or recompilation.  This would separate the development process from the translation process and decrease the possibility that application faults would be introduced during translation.  It also allows a language expert with no development skills to translate the application without needing the assistance of a developer.

How it was achieved

To be able to translate the application without changing the source code, Dexterity uses Message resources which can be accessed from scripts and displayed to the user interface as desired.  By removing all user visible strings from the actual source and placing them into Messages, there is no requirement to change source code when translating.

To be able to translate the application windows and reports, Dexterity uses String resources.  By storing every field prompt caption, button label, drop down list item, etc. as strings, there is no requirement to directly edit the window or report layouts when translating.

By using Message and String resources, Dexterity has separated all the text that is visible to the user from the source code and the window and report layouts.  Now we can extract all the messages and strings.  Translate them and import them back into the Dexterity dictionary. This creates a translated dictionary.

The End Result

The core dictionary (Dynamics.dic) is shipped as US English (which is how it is developed) and can be patched by a language chunk file (such as UKERR.CNK or AUERR.CNK) to update the messages and strings.

A third party product which re-uses any of the strings or messages from the Dynamics.dic will now have those resource translated and only needs any additional strings or messages changed.  For translated third party products it is usually easiest to deploy a translated chunk file rather than use patching.

Now that the theory is covered, the following posts in this series explain in more details how this process works.  Please be sure to catch them as they are published.

David