I18N - Internationalization

The task of localization is foremost one of the client software which connects to the Cinnamon server. The current client is a desktop program which implements the complete GUI itself and does not receive HTML pages from the server to be rendered by the browser. This is the main difference between the Cinnamon CMS and other WebCMS systems. As we have to distribute a client anyway, it is easy to include the localization files with translations for all required languages. This reduces client-server traffic, as the server does not need to provide the redundant translations each time the client connects.

A more interesting aspect than the question where the default language packs are stored is: how are customized system objects localized?

The problem with customized system objects

If you are a computer user with a modern operating system set to a non English locale, you will probably have seen that your OS translates the name of certain folders into your native language. For example, the "Documents" folder may appear as the "Dokumente" folder to a German user. This is an example of advanced localization, which maps file system names of special paths to another language. (And it is a source of trouble for those using older software, which is confused by a folder called "Dokumente").

Now imagine that you are going to add a new ObjectType to your Cinnamon repository, for example "Business Contract Template". You fire up your browser, use the AdminTool to add this shiny new ObjectType - and lo' and behold: From now on, you can use this new type to categorize document objects in Cinnamon as being templates for business contracts. This is all very well, until your French or German users stumble upon this object type and ask "What's that? It would be really nice to have a translation for this kind of object..." And that is where the I18N-capabilities of Cinnamon come into play. The Cinnamon server allows you to add translations of customized system objects for all languages supported by the client software.

Creating a translation for custom system objects

First step: define languages

There are three default language codes already defined:

1. 'und' - ISO code for undetermined language
   
2. 'mul' - ISO code for multiple languages
3. 'zxx' - ISO code for no lingustic content

Note that you can name a language different from its ISO-639-2 code - this is a feature, as some users have their own (legacy) naming schemes for languages.

Adding a new language is simple, just navigate to the language list and select "Add a language"

Second step: add a message id

MessageIds are the names you give to new system objects as you create them. For example, let's assume that you have created a new object type named "contract.template". To create translations in the languages of your users, add a new messageId to the system. Navigate to "Message-Ids and translations" and select "Create new message id".

Third step: add translations

In the message id list overview, click on the message id you want to translate and select "edit"

You can edit the message id itself (here: contract.template) or the translations.

Note: you should add a valid translation for all languages that you allow for your users. 

Source of Inscription image: http://en.wikipedia.org/wiki/File:One_Ring_inscription.svg / Author: Alarr / License: GPL