Support

The short answer is that we tried that, it was causing major grief and we ditched it.

We decided to not use GNU GetText (that's what the .po/.mo files are) because it's very difficult to create a correct translation.

For example, in English the string "process" may refer to process (noun) or process (verb). GNU GetText uses the string as the key. It allows differentiation by using a context and lets you provide a comment for disambiguation to translators. I've found that the way WordPress implements that makes it impossible to differentiate single word nouns and verbs on the same page. You need to adapt your language to satisfy the tool you are using for the translation. This is wrong. It must be the other way around. We write code for humans.

Moreover, the inclusion of the entire text to be translated breaks the cadence of code which makes it difficult to navigate and makes every change far more error prone. This led to a lot of bugs in the original Admin Tools for WordPress 1.0 release that was using GNU GetText. The Joomla translation method uses far shorter keys such as SOFTWARENAME_VIEWNAME_LBL_OPTION_HELP instead of a 60 word help tip.

Similar to that, the inclusion of the entire full text makes it problematic when you are reusing text in different places and you need to change it. Ironically, the shorter the text is the more difficult it becomes to find all of its uses. Things like "Confirm", "Publish" and "Unpublish" are impossible to locate in the code which leads to bugs every time you change a language string.

Also related to the above, since the original translation key disappears, every time you change a small typo in the English original all translations for that piece of text disappear and need to be re-translated. This is extremely annoying to translators, especially if it's a 50-60 word help tip.

Finally, regarding what is easier to do, the WordPress way or the Joomla way. Here's a comparison for Greek as an example.

Joomla way. Copy the translation INI file from en_GB.something.ini to el_GR.something.ini. Put in the appropriate directory. Edit the INI file with a plain text editor. Done.

WordPress way. Run spealized tooling to get the .pot file. Find the .pot file and download it. Use a text editor or special software to translate it into a .po file. Compile the .po file into .mo using specialized software and platform-specific instructions. Place the .mo file in your language directory. Done.

I'm sorry, but I find using specialised tools to create the .pot and compile the .po to .mo to be infinitely more difficult than NOT having to do these steps at all. If it weren't for these steps both methods would be identical from the perspective of managing a translation.

In any case, this point is moot. Two years ago I explained why we're not going to be including translations in our software.