I had a spare hour this morning and noticed that zentrack has kind of what I wanted in a translation system. I decided to see if their code could be ported (they are GPL). Well it all seems to work fine.
I have attached a zip with what I have working.
I found that if I created a /include/class.translator.php which is most of the translator.class.php from Zentrack and edited it a bit then if I included that class file where the code enters into osticket e.g., in our client.inc.php I added,
require_once(INCLUDE_DIR.'class.translator.php');
and then I added this as well to the client.inc.php later....
$login_language = 'french';
/* Build up out translation strings - Sometime I must switch language to client desired language */
if( !$login_language ) {
$login_language = $cfg->getClientDefaultLanguage;
}
//Create the initialization array for the translator object. Note that the $ost is really this and its used
// only to grab the html_special_chars character set. I have hard coded as UTF-8. We need to add a $cfg->getCharacterSet
$translator_init = array(
'ost' => & $ost,
'domain' => 'translator',
'path' => INCLUDE_DIR."/translations",
'locale' => $login_language
);
tr($translator_init);
//save a bit on memory
unset($translator_init);
........then, for example, in say header.inc.php I am able to use,
echo tr('Log Out');
and that gets translated to something according to what is in the /include/translations/french.trans file (which gets "compiled" on-the-fly into a french.ctrans if that doesn't exist.
Obviously we wouldn't use default languages like this for clients but would add code to detect the language of the clients browser/OS or of their logged-in or display preferences e.g. set via cookie.
Also zentrack uses "english", "french" etc to name the files e.g. french.trans or english.trans which I don't like whereas I would use ISO codes e.g. en.trans en_GB.trans etc and provide a languages array (maybe in the config) that maps the language name to the code. That way we can easily have a language picker which would list the supported languages.
To ensure consistency between the code i.e. the use of tr(), ptrans(), trans() etc and the translation files there is a development script called tr-parser.php which you run from the command line once to create the translation file template. You then diff this with the current translations to merge in the new strings which the translators then work with. I hacked that a tiny bit to remove some zentrack specifics.
Included is a text file in /scripts on how to use these (assumes Windows PC),
Anyway I know that translation are planned for a future version but if a translation class (like attached) can be added into version 1.6 then this makes the transition to actually translating the code rather easy;
Step 1) Add translation class
Step 2) Add includes to this new class
Step 3) Add client and staff preferences to pick languages
Step 4) The big task of
a) converting all 'strings' into tr('strings') and trans('strings') etc
b) generating initial English translation template file
Step 5) getting translators to translate this initial template into local language
That's it really. Step 1 and 2 can be done easily. Step 3) is a little bit harder and then Step 4a) and b) is the big leap and then Step 5) follows on from that. As we know many people want to help translate.
Is it worthwhile furthering this and polishing the ported code or not ?.
[osticket_1.6TR.zip](https://forum.osticket.com/assets/files/migrated/a/e02d275c70ecb2725575bb55181b6d9.zip)
