Database Localization
The software globalization process must include database design adjustments in order to enable multilingual capabilities. Managing database globalization requirements in the early phases of enterprise software development is the best approach to achieve strong multilingual software with less time and effort.
In comparison, re-designing databases to enable multilingual capabilities toward the end of the development process is a complicated process and involves additional steps, such as re-testing and QA. It also involves risks such as corrupting the software main technical structure and then re-adjusting and re-compiling.
Database Localization Methods
There are several methods to localize a database and they each have positive and negative aspects. The best approach will always depend on the type of application used and how the data is structured and manipulated.
One method commonly used for developing a multilingual database is to create two tables:
- The first table contains only the non-language specific fields, such as Primary Key and Boolean values.
- The second table contains one row per language, which contains the equivalent translation, the language ISO Code
and the Foreign Key to reference the Primary Key from the first table.
This method provides the necessary flexibility for adding additional languages at any time without the need to extend the table or add more columns. But, as mentioned, there is no a perfect approach, this method, when implemented, will need additional solutions to handle the search function and to display data from the database, depending on the selected language.
Database Localization Checklist Items
There are a few items that are present on most localized databases and I will use Microsoft SQL Server as an example:
- Set the appropriate Database Collation.
- Use the appropriate field types, such as nvarchar, nchar, ntext instead of varchar, char and text,to be able to store the Unicode data.
- Make sure there are no incompatibility issues with Unicode and CodePage.
- As most of the new Operating Systems and Development Platforms use Unicode internally, it is highly recommended to use the Unicode types (such as nvarchar) to avoid doing encoding conversion each time you need to read or write the database.
- Make sure that the character max length for certain fields can handle content in several languages, as some translations from English are larger in number of words and characters. Ex: translation into German.
- Database developers must use the number date parts instead of name strings as days and months depending on the target language selected when developing Date and Time comparison procedures.
- Avoid using strings in stored procedures for search, update or insert as any strings that are non-constant can differ from language to language.
Summary
In conclusion, I discussed the best time in the project development life cycle to consider database globalization implementation. I also reviewed an example method for how to design databases to handle multiple languages. Finally, we defined a set of checklist items that are essential for any database that will be used to store more than one language. As mentioned, there are many different methods to use for software globalization, but it is vital that whichever method a developer uses is implemented early in the process.
Further Website Translation and Website Localization Resources
Globalization Partners International (GPI) has created a more extensive overview of website globalization for several global markets in a series of Website Globalization and E-Business Series white papers, which you may download for free. You may also benefit from reviewing the following blogs on different aspects of website translation and website localization:
