Determining the number of projects to create for an application

To determine the number of projects to create when you translate your application, you must understand the concepts of character sets, code pages, and language families.

A character set is the grouping of alphabetic, numeric, and graphic characters that are related to one another as defined by a standards organization, operating system vendor, or hardware manufacturer. Character sets also include communication and printer control codes—nonprinting characters like backspace, tab, and keyboard characters. For example, the iso8859–1 code page is widespread in Western Europe, North America, and Latin America. Code pages often share characters.

Single-byte character sets contain characters that can be encoded into one-byte numeric code. OpenEdge supports the following categories of single-byte character sets:

Double-byte character sets contain characters that must be encoded into two-byte numeric code. OpenEdge supports double-byte character sets for the following languages:

Multi-byte character sets contain characters that are encoded into two or more bytes. OpenEdge supports the multi-byte Unicode encoding standard, UTF–8. Unicode supports all languages currently used in commerce worldwide in a single character set.

A code page is a table that maps a numeric code to each character in a set of related characters. The computer uses these numeric codes to interpret and process textual data.

For more information on code pages and character sets, see OpenEdge Development: Internationalizing Applications.

You have various options when deciding how many projects to create for an application. You can choose to have all language versions supported by a single project. This allows you to create r‑code with all languages. However, you can also work with multiple projects where each project supports a subset of all the languages being translated. Before deciding on the number of projects, take the following into consideration:

Decide whether you require a single multilingual version or individual versions of the application where each version supports one or a few languages.

The large size of a single multilingual version might require too much disk space or slow down the load process.

If you have a large single-language application (1500 or more files), it might work better if you split it into multiple small projects. The Translation Manager processes smaller projects more quickly and you can divide the work among several translators. Choose logical units when dividing projects, such as discrete modules in an application. You must ensure that individual translators synchronize their glossaries regularly. An up-to-date glossary is essential for leveraging translated material.

Decide if you will have the entire project translated simultaneously or if you will have the translations done in different phases of the application development cycle. If you are sending parts of the translation out at different times, it might be an advantage to have different projects coinciding with the different development phases.

Since most systems cannot display characters from all parts of the world simultaneously, it will be impossible to view translations into languages that are not in the current character-set language family. You can avoid this by using different projects for languages that share the same character set. For example, you can handle Western European languages in one project, Eastern European languages in another, and an Asian language, such as Japanese, in yet another.

If you are translating into more than one Asian language that requires double-byte character sets, each language (Simplified Chinese, Traditional Chinese, Korean, and Japanese) should have its own project.