Comment 19 for bug 565294

What probably would have been better to do was to decide on a plural form expression that gracefully degrades. That's what Serbian team has done with KDE translations a long time ago: look at their formula in eg. http://websvn.kde.org/*checkout*/branches/stable/l10n-kde4/sr/messages/kdeadmin/kcron.po

GNOME translations for Serbian still use the 3 forms without special casing form for 1 (as a matter of fact, it seems Lithuanian and Serbian use identical plural form rules).

I.e. they use form 3 for the newly introduced "really singular" form. So, all existing tools and translations didn't have to be changed, and it worked correctly with Launchpad. At least it won't be totally messed up for Serbian in Launchpad: whenever number is 1, it will use the 1, 21, 31 rule which still works correctly (it's worse, but it works). In Lithuanian, plural forms will be all turned around.

Since Launchpad, just like KDE (at least before 4.0), has a single concept of plural forms definition per language (and not per-PO file, like eg. GNOME does), it also normalizes and maps plural forms where possible. With a different number of plural forms, that's however not possible.

What it does then is to just import all translations as-is (as-are?), but on export it exports a PO file with built-in plural forms (i.e. 3 for Lithuanian). What we need to investigate is to see if exporting the original header won't break anything for other languages, and if it doesn't, that's something we can try to do before the language packs are generated. If we don't get it in time (we've only got until Thursday), it's still something we can look into fixing for the next language pack update.