Coming up with Schoorbs 1.1 we introduce a new translation system which is object-oriented, more portable and needs less code. One major thing I wanted to have, is to be independent from the operating system’s locales, so that we do not need anymore those large language code conversation arrays and as wished by users the translations of dates will now ne done by Schoorbs itself and not by the OS, so you do not depend anymore that the locale the users needs is installed on your system, e.g. on an fresh linux installation with only English as the one and only available language in Schoorbs 1.0 the dates where only available in English on the web interface, even if there was a translation file available for the user’s language, now dates are translated into the user’s language if they were already translated in Schoorbs and not if the locale is installed on the system. This fact has many positive sides, the Schoorbs user/administrator does not depend anymore on his webmaster/provider that he installed all the needed locales and the webmaster/provider needs not to install a big amount of locales to satisfy all users of a certain Schoorbs installation which keeps the system clean and nobody has to care of the differences of operating system if one wants to install a different locale.
After the theoratical part we now move on the practical usage of this new system. The “endusers” of this new translation system do not really see a change. In Schoorbs 1.0 a string was translated by calling “get_vocab(’string’)“ now this done with “Lang::_(’string’)“. The only outwardly remarkable change is that ’string’ is returned directly as a translation if no suitable translation was found, before nothing was returned which led to empty buttons in some cases. Under the hood the system completely changed. I will explain the new architecture by doing an example call on “Lang::_(’Time’)“: At first Lang::_() fetches the best available language for the user via Lang::getUserLanguage(). Lang::getUserLanguage analyzes the HTTP_ACCEPT_LANGUAGE strings and search based on the priority for the best fitting language for which a translation exists. If it found a suitable language it gets an instance of it via Lang::getLanguage() and returns it to Lang::_(), if no suitable language was found English is used. If a new language instance is created, the translations are read from a XML-file from schoorbs-includes/lang/schoorbs-<langcode>.po-xml, the format of these files is simple and should be self-explaining. I used this format insted of using directly po-files because it didn’t wanted to include a complete po-parser in Schoorbs and on various sites people disadvise from using PHP’s gettext-functions. Still po-files are used as translation storage since its a common format and I included a rake task that automatically converts the po-files to XML ones. Using po-files as storage during the development enabled me to use launchpad.net as a GUI to translate Schoorbs.
Because it’s a complete new class and could be used in other projects too I duallicensed this translation system under the terms of the GPL 2.1 and a MIT/X11-style license.
Links: