How to write 3rd party components such way that applications using them can easily be localized

This document describes the basic steps that you should follow when writing 3rd party components. It is very important to follow this instructions. If you do not you will make localization of the end application much harder than it should be. Remember your components is just a part of a larger application that might use several other 3rd party components. If they all implement localization on their own way the result is a big mess.

Use VCL's localization method

Do not write your own localization support. Use VCL's build in localization method. It is based on two resource formats: forms and resource strings. Whenever you create a form you are using form resource. You do not have to do any further steps. Every form is ready to be localized. When designing forms remember to keep the layout as much international as possible. Most components use some message strings or other text data. Whenever you have a hard coded string that might be needed to be localized replace it with resource string.

Do not use old style of RC files. Delphi's resourcestring is much easier to read and maintain. Also when using resourcestring you give a resource string an name (e.g. SInvalidValue) instead of an id (e.g. 1034). This name give translator much more information than a numeric id. A localization tool can also group resource strings per unit so it is much easier to translate them than if would be with none grouped numeric ids.

What language should I use as a default language?

Answer is easy, English. Make this the default original language. If you want to provide translations of your resource strings isolate all your resource string into one unit that only contains resource strings (e.g. Consts.pas in VCL). After that copy the resource string unit into language depend sub directory (e.g. de\MyConsts.pas) and translate the strings. If your components have build in forms use English in the forms too. If you want to provide translations do same as resource strings and copy form files (.dfm) in text format into a language depend sub directory and translate them. An alternative solution is not to put the real values in the DFM but update the Caption properties on run time (in OnCreate or OnShow events) using resource strings. Both way are acceptable but former gives better context information for translators.

Some vendors tend to make multilingual RC file using string table and base index. Do not use them. It is a bad and inflexible solution. They bring the same value several times in many languages. This will confuse translator and often makes translation very difficult because suddenly instead of one original language there are the same string in several languages. Remember that in most cases the translator can only translate one single language pair (e.g. from English to Japanese). If there are string in other languages it will make things harder and more expensive.

Join our 3rd party program

Finally you should join Sisulizer's 3rd party program. This will ensure that localization professionals at Sisulizer will check your component thoroughly. If there are anything that needs to be fixed you will be informed with instructions how to fix it.