Code Styling Project

Since few month often problems occured with the translation files (*.po) my plugin war creating. PoEdit was able to load them but failed to save the language file after translation and shows up a lot of error messages. Futhermore my plugin was able to create non standard language files (*.mo) this way.

I found the issue finally and wrote again a bugfix at my plugin. With version 1.99.1 this was solved and meets the way PoEdit expect it.

First of all I present a short list of web pages which were discussing this topic more or less expensive and also did come up with temporary solution how to patch the *.po files my plugin did create:

• Dennis Morhardt (www.dennismorhardt.de)
• WordPress Deutschland Forum
• Freelance Jobs

For a better understanding why and where this problem occured, I will give you a short briefly description about this phenomenon. And we need at least some code examples to visualize it. I took one from WordPress 3.0.1 version and did create my own artificial one too.

existing real life example

As mentioned above this is the real life example out of the WordPress 3.0.1 core PHP code.

1
2
3
4
5
6
7
8
9
10
11
12

//file: wp-admin/includes/dashboard.php:264
// Categories
 $num = number_format_i18n( $num_cats );
 $text = _n( 'Category', 'Categories', $num_cats );
 
//file: wp-includes/taxonomy.php:55
'labels' => array(
     'name' => __( 'Categories' ),
     'singular_name' => __( 'Category' ),
     'update_item' => __( 'Update Category' ),
),
 

The term “Category” has been used as pluralization and also as singular term. Normally those occurances are different for translation because they are always bound to the context where the have been used. My plugins consequently threat them as 2 different entries. But this forces PoEdit to utilize 2 times the same msgid in this case. But it is not permitted to have duplicate entries at localization files. So PoEdit was not able to generated the language file (*.mo) and stopped the generation process with a lot of warnings.

artificial self created example

For testing purpose I did create an artificial example. I will use it to explain that the pure bugfix by it’s own is not the full story. Programer should also know at every time, what they are doing and should also spend some time understanding how localization works, if they code it into their software.

1
2
3
4
5
6
7

<div>Testing container: 
 <?php _e('All'); ?> 
vs.
 <?php echo _n('All', 'All', $count); ?> 
vs. 
 <?php echo _n('All', 'Total', $count); ?>
</div>

Again the same problem: singular and plural term are sharing the same main key “All” at sources. But additionally there is also a second plural term with equal main key but tries to explain somethings completely different at the whole thing.

But what will happen, if PoEdit will reads the terms out ouf the source files by it’s own ?
It’s easy to show and will look like this result at your *.po file:

1
2
3
4
5
6
7

#: index.php:11
#: index.php:13
#: index.php:15
msgid "All"
msgid_plural "Total"
msgstr[0] ""
msgstr[1] ""

Surprise, suprise, isn’t it? At the end only one can survive this battle. As you can see the plural terms All -> All are gone completely and the information, that there was also a singular term is not longer visible and known. If you now translate this file you will wonder later on, why some places at the UI won’t show you the expected results or funny texts.

One essential thing has been left out completely during localization: All texts anywhere visible at the UI are always related to the surrounding place they oocur or the other text arround it. That’s why those things can be handled with context specific localization functions provided by the gettext interface or you modify the terms to avoid any of this collisions. But this is a much bigger story and would blow up this article.

Plugin Bugfix and advantages for programers/translators

It was essential for me to get informed about those potential problems. That’s why my plugin has been extended to remark those cases at the coding comment entries of *.po files. Doing so not only my plugins will show them but also PoEdit will show this comments as well. Having such a case in doubt, somebody can inspect it and make the right decisions for solving this issues.

At my plugin it will look like this one taken from my example above:

conclusion

My new version 1.99.1 is about to be published soon. It will now create again the well formed *.po files compatible to what PoEdit expects and supports. They also can be exported into correct language files by both of them.
As you can see out of the examples I have shown, localization is no “kindergarden” work. You will need at least basic knowledge about languages and their utilization/behavior. Only with this knowledge you will be able to develop clear forwarded translatable modules.

As developer of Themes or Plugins it will be a good idea to deal with backgrounds of translation work too, if you have the wish to publish really good and programatic translatable software.