Please add support for GetText PO translations instead of current "variable" solution
I'm translating ISPConfig to Spanish but it is becoming a frustrating task, i've contributed to various projects and i know the benefits of using gettext PO files what makes me more frustrated with the current ISPConfig language system.
Why move to GetText PO?
- GetText Portable Object (PO) files are the industry standard for multilingual websites in PHP.
- It's used by large projects like Wordpress, phpMyAdmin, Laravel...
- Have useful functions like Plural strings.
"One result was found", "%{count} results were found"
- gettext-based toolsets are widely known, battle-tested, with good documentation and practices on translation structure and pluralization.
- It's faster and have better performance
- The .MO file include hash tables.
- Gettext include a cache that improve speed.
- A benchmark: http://mel.melaxis.com/devblog/2006/04/10/benchmarking-php-localization-is-gettext-fast-enough/
- Makes it easy for translator to maintain the translations
- With the current system you have to manually check and modify 230 language files!! in multiple directories and recheck it one by one on every update.
- Gettext always provides a fallback locale without the need of "language merge" functions.
- Current system has duplicated strings that are hard to maintain.
- An example if you search for "type_txt" you'll find 31 variables in 31 separated files with the same translation.
find . -type f -name "en*" -exec grep -H '\''type_txt\''|"type_txt"' {} \;
- If the original (English) string is modified, but the name of the variable is left unmodified, it is almost impossible for a translator to realize it.
- Using gettext when you make changes to the sources, add strings, change some, delete some... there's a tool (msgmerge) to let your merge the new .POT with the existing .PO files. All matching strings will keep their translations... and the ones that have been slightly modified or the ones that resemble another one, will use an old translation which will be marked as "fuzzy". This way, the translators will only have minimal work in updating the translations for each new version
- You only need to run a tool (xgettext) to extract all the translatable strings from your sources and embed them in a single .POT file.
- poedit runs on Windows/Mac/Linux and other Unix OSes. You can see from the screenshot how untranslated strings appear in blue, "fuzzy" translations (the ones you're unsure of and the ones automatically genereated by msgmerge) appear in yellow, and translated strings appear in white. poedit will also let you add comments or read those the developer may have provided in the .POT file. And the best of all: poedit will show you all references of a given string in the source code. Even better, it will open the sources and highlight the occurrences for you. This way, you can really make sure what a string is used for when you're not sure about how to translate it!
- When you're developing, you don't need to search the variable for translation, or create it, just __('Show the new string')
- Current solution make both the programmer and the translator lives harder.
- The programmer does not see the actual message in the source code, losing important information.
- Current solution make both the programmer and the translator lives harder.
1 => array ( 'type' => 'UNIQUE',
'errmsg'=> 'username_unique'),
* Similarly, the translator sees the following on her files:
$wb['username_unique'] = 'Ya existe un usuario con ese nombre de usuario.';
This file does not contain the original message, contains information that does not matter to the translator and as such often requires comparing files in different languages. * With gettext, the programmers sees:
1 => array ( 'type' => 'UNIQUE',
'errmsg'=> __('There is already a user with this username.')),
* And the translator:
msgid "There is already a user with this username."
msgstr "Ya existe un usuario con ese nombre de usuario."
I think that GetText PO translations include lots of benefits and i understand that are a complicated transition but it will make the ISPConfig internationalization much more easy for developers and translators, it will reduce the number of source files and makes everybody happy :)
I can work on it but i would like to know the official position about this before.