Hello community ;
Some words about localization
Planned for beta 4 and already in trunk, Machine object files (GNU gettext) are now used in replacement of the database tables for translation storage.
This greatly improves overall performances because the database is no longer involved. Before, we had a database table for each language, where each column contained a translated string. This means that for every of translation string, we had to do a SQL query. The calculation is quick simple here. For each page, we had about 50 SQL queries to be performed only for the translation.
I. How to help us to translate i-MSCP
To make the translation easier, we are using the translation service provided by Transifex that provides a set of Web-based tools to translate the softwares.
If you want contribute to the translation, you only have to be registered on Transifex to begin to make the translation.
Transifex provides documentation that explains to new users how to translate. For this reason, no further explanation is made here. The only important thing that you must take into consideration is that i-MSCP uses only UTF-8 as encoding for translation files. That means that if you want translate with your editor (such as Poedit) and do not use the Web-based interface provided by Transifex, you must use this encoding.
This last statement is also valid when you want install the locale on your server. For example, if you want install the locale es_ES for i-MSCP and also install it on your server, you must select the UTF-8 version of it. With Debian, that can easily achieved through 'dpkg-reconfigure locales' as the root user.
II. i-MSCP Frontend (GUI) - internal localization management
i-MSCP manages the locales in different ways, depending whether the locales are installed or not on the system.
Example for one locale:
1. The locale is installed on the server
In this case, the iMSCP frontend is able to use native PHP gettext functions. The performances are greatly improved because the Machine object files (MO files) are read once per process.
However, a workaround is in place here to be able to update any translation file through the GUI without having to reload the Web server since the files are cached in memory. When native PHP gettext functions are used, i-MSCP creates a specific production file with an unique gettext domain name based on the modification filetime of the upstream file and load it instead. When the upstream Machine file is updated by admin, the GUI detects the change and then, creates another production file which is used in replacement of the previous.
You must note that natives PHP gettext functions are used only if the locale being used is also installed on the server.
2. The locale is not installed on the server
Unfortunately, native PHP gettext functions can not be used if the locale being used is not installed on the server. In this case, a specific library (PHP-gettext) that provide similar set of functions to simulate localization is used. This is slower since the parser is implemented in PHP and not in C, and also because the files (translation tables) are not cached in memory. In this situation, the admin is warned by email.
i-MSCP Team