PR# 12787 Allow different translations for the same string

It can happen that the same string in English is translated to different strings in another language.

Example:

The word 'Class' is used in the EiffelStudio GUI to denote a class, thus it is translated into the target language. But the word 'Class' also specifies the keyword in the preferences (capitalized since it is used in a title). This keyword should not be translated as it is specific to the Eiffel language. At the moment the keyword in the preferences will also be translated.


To solve this problem, GNU gettext allows to specify a 'context' for a string:

     #  translator-comments
     #. extracted-comments
     #: reference...
     #, flag...
     msgctxt context
     msgid untranslated-string
     msgstr translated-string

Now the message id has to be unique only inside a specific context. It is not mandatory to add a context, so this could be added without breaking backwards compatibility.

This could be used to add a context 'preferences' to all strings of the preferences menu and would allow different translations for the same word based on the location it occurs in the GUI.

The i18n library does not implement context at the moment, this would have to be added to the library first.


The GNU gettext manual explains context a bit more:

http://www.gnu.org/software/gettext/manual/gettext.html#Contexts

I am not sure separating one file into two is a good solution. 
Because:
- This doesn't perfectly solves the problem. i.e. We have "Group" in different places of GUI (apart from the preference messages). Imagine that we could have the  same string with different context in the same class.
- I don't see any application comes with two .mo files. 
- It also increases complexity of management/translation. 

The ultimate solution would be implementing this feature in i18n library and po generation tool.

Although "gettext" has added the message context "msgctxt" to it's specification lately, the current tools (poEdit, KBabel) don't support it at the moment. poEdit even strips them out. So until the tools support message context, we cannot use it for the po files.

Therefore I suggest that we have multiple po files (at least one for the interface, one for the preferences). We can already implement the library to support message context, but instead of looking at the "msgctxt" information, we take the file the message comes from as context.

We could have a directory layout as follos:

estudio/lang/po_files/estudio.pot
estudio/lang/po_files/preferences.pot
estudio/lang/po_files/estudio/en.po
estudio/lang/po_files/estudio/de.po
estudio/lang/po_files/estudio/...
estudio/lang/po_files/preferences/en.po
estudio/lang/po_files/preferences/de.po
estudio/lang/po_files/preferences/...

and the same with the "mo" files.

When we load the mo files, we could specify per directory as which "context" it shou
....
Output truncated, Click download to get the full message

Another possibility to allow different translations for the same string would be different "po" files. They could be loaded into different dictionaries and then used as "context".

One po file for the preferences, one for the debugger, one for the metrics, etc.

Another advantage of this would be that all messages inside one po file belong together and that we have smaller po files. Then also the translation effort could be split by giving the (smaller) po files to different translators without them translating the same thing twice.