wesley tanaka

poEdit and Drupal's Locale Export

‹ Itchiness | Database index for Drupal's Who's New Block ›
()

Just downloaded poEdit onto the computer of someone who is going to help me with some translations. However, when I tried to export a .po language file from Drupal (5.1) and open it in poEdit, I got an error message that said:

Couldn't load file xxx.po, it is probably corrupted.

The details added:

Broken catalog file: singular form msgstr used together with msgid_plural

Looking through the file, I found that it contained blocks of lines like:

msgid "1 comment"
msgid_plural "@count comments"

with no translation following. It turns out that I'm not the only one that's run into this, and it appears that there are two problems. The first problem is that the metadata for the language is somehow broken (not handled by drupal's upgrade procedure? After more perusing of code it looks more like a very finicky importer sets the plurals field to 0 if _locale_import_parse_plural_forms is in an even slightly bad mood), and the second problem is that Drupal produces this broken output if the database metadata is thus broken.

In my case, the problem seems to be that the plurals column in the database is set to 0 for the language. Seems to me like it's definitionally not possible for a language to have 0 plural forms and that if the export encounters such a situation that it should fail with an error message, or assume either 1 or 2. format_plural seems to do just fine in the face of this broken metadata -- why can't the exporter? The data's already all right there in $parent[$plural].

It looks like a workaround for the problem is to import a .po file with a Plural-Forms header that makes _locale_import_parse_plural_forms happy. You may be all set if there's a Drupal translation available. You can even pick the "Existing strings are kept, only new strings are added" option.  Don't worry if it says there are "1 newly created translated strings" (an irony of grammar given the subject) -- it seems to do that no matter what -- perhaps because it's detecting that the metadata changed.

If no such file already exists, you can probably just run an UPDATE on the {locales_meta} table. The translated strings should be output out as long as you set the plurals column, but if you want a Plural-Forms header to be output, you'll need to set formula to something too.

I just realized that the importer may have broke my metadata when I imported a .po file from some non-drupal open source project.

Suggested Links

Syndicate content