Though ILWIS was in theory multilingual from the 2.0 version, it was hardly used. I believe there was a (partly?) Italian version and a partly Spanish version, but they never ended up in the release version and/or were maintained. In the 3.7 this for the first time changed. Thanks to the work of Robin Prest and the money from the Geonetcast project a french translation of the user interface could be made.
The work of Mr .Prest made me also realize that the existing translation system was cumbersome and difficult to maintain. Oh, it worked, the results are ok. But it is more work than needed and difficult to track changes. Furthermore I found is as a programmer also quite annoying. Basically I had to touch multiple files when adding a string in the code. So one of the goals for the 3.8 was a more comprehensive translation system.
From the GeontetCast project the clear whish was there to have a Spanish and Portugese translation. So it was reasonable to spend some time to make this easier
I had a few goals with the new translation system,
- The translator should have to touch as few files as possible.
- The programmer should have to touch as few files as possible
- Maintainance should be easy
- The translation files can be changed without needing the change anything in ILWIS.
Fortunately I had come across the Qt platform. For some time I am pondering how to move the Ilwis code base from Windows/MFC to something more modern and platform independent ( enough stuff there for another blog) and in this context I came along the Qt framework. Apart from other nice things they had a suitable translation system in place that I adopted with some modifications for Ilwis.
What basically happens it that every “translateable’ expression in the code is compared to a lookup table that is loaded at startup time of ILWIS. If there is a translation, it will choose the translation. If not it will use the original English phrase. Internally, Ilwis only uses English. The advantage of this system is that I can extend Ilwis without needing to update the translation files each time. Incomplete translation files will simply lead to more non-translated English in the UI. Not ideal, but much better than having nothing at all. Once in a while you update the actual translation files and then everything is cool again.
So how does translating ILWIS works? It is very simple.The language files exist inside a folder in the instalation folder of ILWIS : Resources\Strings. At the moment you will see there a number files with the extension .fr and .sp. French and Spanish translations ( I am not 100% sure if the spanish is already there in the beta-2, it is now). For each language there are three files (I take french as an example). Men.fr, Dsc.fr and string_table.fr. From a technical point ‘Men’ and “Dsc’ could probably be merged but I’ll leave it as they are not that big anyway.
- Men contain the texts of all the menus except for the operations menu. So when you translate ‘Men’ you will get a translation of all the menus. The men file consists of a number and a string. Each menu item is coupled to the number, and through the number it can find the string. This is a different organization than the ‘string_table’ file(see later) but there are technical reasons for that (never mind). When translating the file take care that the special signs (e.g. ‘&’) als end up in the translation. They have a meaning. The ‘Men’ file is not very large and can easily be translated
- Dsc ( short for description) is a direct companion of the ‘Men’ file. Basically it contains the description/short explanation of the menu commands that appear on the status-bar below ilwis windows. it is structure and numbering are identical to the Men file.
- The big translation table is the ‘String_Table’ file. it contains ‘the rest’. So all the forms, operation menu, windows etc.. The structure of this file is different. The file consist of a pair of strings separated by a ‘|’. For example “Invalid Map|Mapa Incorecto”. The software, internally, knows of the first english string and simply looks it up in the table constructed of this file to see if their is an (translated) alias. If so, great, it uses it. If not, it will use the internal english version. Note that when translating these texts it is very important to take over all the special symbols. Particual the ones marked with % ( e.g. %S, %i etc. These are, during execution, filled with internal values. So for example a string “Adding File %S” might become “Adding File MyMap” because that is something that was happening during execution.
This table is quite big, at the moment around 3700 entries. Not difficult to translate, simply a lot of work,
That is all there is need for translating ILWIS to a ‘local’ language. Ilwis translations have their limitations. When the internals of ILWIS were designed, many years ago, Unicode was in its infancy. It was not considered and still isnt part of Ilwis. So translations are limited to alphabets that uses the extended Ascii table. An annoying limitation these days but it is very difficult to change that (probably for a rewrite of Ilwis).
Ok, nice that we can translate things. But how do we activate a translation? Well, Ilwis contains a form that most people don’t seem to be aware of , the preferences form (under the file menu). In that form you have the ‘General’ page in the tree. That looks like this
In the form you can indicate which language files should be used (based on extension). In this example I have choosen Spanish (.sp). When I press Ok and restart ILWIS it will use the spanish translation. So a contour interpolation form suddenly looks like
A spanish form :).
Ilwis 3.8 will contain a french and a spanish translation. It is likely that there will also be a portugese translation but that remains to be seen.
One thing. The translation is about the user-inteface of Ilwis, not of the help files. That is far too much work to do for volunteers.
Hi Martin,
I!ll try someday to update some of the new functions.
If I may add some comments, one the the hardest parts in translation ILWIS was finding where the function came from and what context was used for it : as you may guess, some sentences have a different meaning depending on where you use it.
As a translator, I would love the following :
1. Classify all strings by context, with the english word left, a “;”, then a space for translation. You could add a unique number at the beginning of each line to make sure (as in a database), the string line would be referenced correctly in the code and the old sentences never used.
Exemple of an old translation file
#CLASS ENTITY
1;Polyline;Polyligne
2;Vector;Vecteur
3;Point;Point
4;Line;Ligne
#MENU FILE
4;Open;Ouvrir
5;Save;Enregistrer
…(etc)
3789;Quit;Quitter
Exemple of an future translation file :
#CLASS ENTITY
1;Polyline;Polyligne
2;Vector;Vecteur
3;Point;Point
4;Line;Ligne
3790;Voxel;Pixel 3D
3791;Whatever;
#MENU FILE
4;Open;Ouvrir
5;Save;Enregistrer
….
3789;Quit;Quitter
As you see, the new translation file just adds new numbers after the last one used. The translator just needs to translate number 3791 and one can see the number 3790 has already been translated.
You could also imagine changing the interface, no problem, you just need to place the numbers right :
#MENU FILE
4;Open;Ouvrir
3792;Open as…;Ouvrir comme…
3793;Save as…;Enregistrer sous…
In the code, the strings refer to unique numbers the refer to unique translation.
It only requires for the translator to check if each menu if fully translated, even if he has to retranslate the same word a few times, but that’s not really a problem, because as I saif, some identical words may change sense in different contexts.
Thanks for your work,
Robin.
Classifying string by context is quite hard and error prone. You are right of course in theory but the discipline needed to add the metadata consistently, most likely will fail. Anyway there is a huge amount existing strings scattered around the code that doesnt have this data, tracking them down is huge task.
I agree with you that it would be nice.