Plural translations are broken for Lithuanian language

[Andrius Štikonas]

Binary package hint: language-pack-kde-lt

Due to the change upstream (number of plural forms were changed from 3 to 4) all KDE translations in launchpad are wrong for plural Lithuanian messages. Launchpad still uses 3 plural forms and does not work correctly with new translations.

[David Planella (dpm)]

We can change the plural information in Launchpad very easily. Notice, however, that this will affect _all_ Lithuanian translation projects, not only KDE.

Could you perhaps give us some more information on the change?

* Is this change recent?
* Has it only been done on KDE?
* Have all other upstream projects (GNOME, Debian, Mozilla, Translation Project, etc.) been migrated to the new plurals?

[Rimas Kudelis (rq)]

Yes, it is a recent KDE-only change. The difference from the rule with three plural forms is that number "1" is a separate case now. In three plural forms mode, 1 is the same case as 21, 31 etc. Note: neither is a mistake. KDE developers decided to change the plural form they use to get more freedome in that one case.

[Andrius Štikonas (stikonas)]

It was done in KDE S.C. since version 4.4.
KDE S.C. Lithuanian translation now use:

"Plural-Forms: nplurals=4; plural=(n==1 ? 0 : n%10==1 && n%100!=11 ? 1 : n%"
"10>=2 && (n%100<10 || n%100>=20) ? 2 : 3);\n"

instead of

"Plural-Forms: nplurals=3; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && (n%"
"100<10 || n%100>=20) ? 1 : 2);\n"

GNOME, Debian, Mozilla, Translation project, etc are still using 3 plural forms and I haven't heard about any plans to change this. So changing _all_ translations are undesirable.

[David Planella (dpm)]

Thanks to all for the prompt responses.

That is, however, something that should be solved within the Lithuanian translation community. Having different plural forms for the same language in different projects is just asking for (technical) trouble. I would recommend the different Lithuanian translation communities to get in touch and try to reach consensus on which is the best plural form to use and standardise in the one chosen.

This is something that cannot be changed in Launchpad. Languages as a translation interface are designed to be always the same, and not allow small variations for different projects.

> KDE developers decided to change the plural form they use to get more freedome in that one case.

Rimas, I assume you mean KDE _translators_, as they are the ones that should decide on such changes for their own language, not developers.

I'll leave the task as Incomplete for now, but that's rather a Won't Fix from a technical point of view, and again, I'd recommend the Lithuanian translation communities to discuss this.

If you need any help from the Ubuntu Translations Coordinators, please feel free to ask and we'll be happy to help.

[Rimas Kudelis (rq)]

* While I do agree with what you said regarding standardisation, we have a little problem: manpower. Lack of it is probably the biggest reason why I don't really see it happening in the short term: coming to a consensus is one thing, but actually realising it is totally different.

*) Yes, I mean the translators (though I see localization as part of the development process, so they're still developers in that sense).

Since it's not possible to provide different variations for the same language in Launchpad, then perhaps one of these would be possible:
a) strip the first form when importing Lithuanian KDE translation into launchpad (thus effectively degrading it to 3 plural forms)?
b) do not import Lithuanian KDE translations to Launchpad at all, and use upstream translations in Ubuntu instead?

[Andrius Štikonas (stikonas)]

>
> Since it's not possible to provide different variations for the same
> language in Launchpad, then perhaps one of these would be possible:
> a) strip the first form when importing Lithuanian KDE translation into
> launchpad (thus effectively degrading it to 3 plural forms)?
>

Stripping the second form would be more logical, however third and fourth
forms would have to be renumbered in this case, so it is probably not easily
achieved.

b) do not import Lithuanian KDE translations to Launchpad at all, and use
> upstream translations in Ubuntu instead?
>
> That would probably be the best solution, at least for now.

[Rimas Kudelis (rq)]

2010.04.17 17:08, Andrius Štikonas rašė:
> Stripping the second form would be more logical
>

How come? The first form targets cases where n==1, meanwhile the second
form targets n==21, n==31 etc., but still works fine with n==1.

[Andrius Štikonas (stikonas)]

>
>
> How come? The first form targets cases where n==1, meanwhile the second
> form targets n==21, n==31 etc., but still works fine with n==1.
>

There are some strings where either of these choices would be bad. That's
why I support option (b) if it is feasible.

E.g.
Delete this file. (Trinti šį failą)
Delete the following files. (Trinti šiuos failus)
Stripping the 1st form would make the case n==1 clumsy. Stripping the second
case would make cases n==23, 31, etc clumsy. So stripping either of them is
at the best choosing the lesser evil.

Such strings were the main reason why KDE S.C. Lithuanian translators did
such intrusive change. There are a lot of such strings in KDE S.C. and other
projects and it is not possible to fix them without ugly hacks in the source
by adding 2 strings and if-else statements.

[Donatas Glodenis (dgvirtual)]

I would vote for Rimas' suggestion b) – not to import Lithuanian KDE translations to Launchpad at all.

It is also consistent with the Kubuntu developers' position on the temporary suspension of the usage of Launchpad:

The project Timelord articulates this position:

„For the reasons mentioned above, the Project Timelord team has deemed that in
Kubuntu's current state, using the Launchpad Translations system is counter-productive
to achieving the goal of a localized, human KDE experience. During the Kubuntu 9.10
development cycle, a concentrated, cooperative effort between Kubuntu and Launchpad
developers occurred to try to improve KDE translations in Kubuntu. Great improvements
were made to this point, and while we appreciate the time and effort the Ubuntu
Translations team has taken to improve the current situation for Kubuntu, we must face
the facts that given current developer and translator resources that Kubuntu is unable to
use this translation architecture in a productive manner.“ (see http://www.kubuntu.org/news/timelord for details).

Also we should perhaps raise the question about changing the number of plural forms with other developers and translators in Lithuania to perpahs switch to 4 forms... Would it be possible to achieve, what do you think?

[Jonathan Thomas (echidnaman)]

In theory, I suppose using upstream translations could be done by demoting kde-l10n-lt to Universe, reuploading, and then somehow blacklist the KDE translations from language-pack-kde-lt-base.

The only thing is that since language-selector does not, as of yet, install the kde-l10n-* packages when language-pack-* packages are installed, installing Lithuanian language support via the GUI would not give the user translations by default. They'd have to know to install kde-l10n-lt manually. :(

Sucks, I know. If my GSoC project gets approved, I do plan on getting language-selector-qt to install kde-l10n-* packages when it installs language-pack-* files.

[Arne Goetje (arnegoetje)]

Jonathan Thomas wrote:
> In theory, I suppose using upstream translations could be done by
> demoting kde-l10n-lt to Universe, reuploading, and then somehow
> blacklist the KDE translations from language-pack-kde-lt-base.
>
> The only thing is that since language-selector does not, as of yet,
> install the kde-l10n-* packages when language-pack-* packages are
> installed, installing Lithuanian language support via the GUI would not
> give the user translations by default. They'd have to know to install
> kde-l10n-lt manually. :(
>
> Sucks, I know. If my GSoC project gets approved, I do plan on getting
> language-selector-qt to install kde-l10n-* packages when it installs
> language-pack-* files.

language-selector does support this functionality already, including
qt-language-selector, since it calls the same function like its gnome
counterpart. If kdelibs5-data is installed, it should pull kde-l10n-*
packages, next to the language-pack-kde-* packages. If it doesn't work
for whatever reason, then it's a bug.

[Jonathan Thomas (echidnaman)]

Ah, it does seem to work now. Neat. :)

[Jonathan Thomas (echidnaman)]

I should add, though, that .desktop translation templates shouldn't be blocked, if the decision is to not use Launchpad translations. Since the desktop translations get stripped from the packages (where upstream distributes them), the langpacks are the only source of translations.

[Donatas Glodenis (dgvirtual)]

I see that getting rid of launchpad integration is problematic.
However, as I have mentioned, it is more than just us who may want to
bypass Launchpad. I will communicate with the Kubuntu team about the
issue that is being disclosed here.

2010/4/18 Jonathan Thomas <email address hidden>:
> I should add, though, that .desktop translation templates shouldn't be
> blocked, if the decision is to not use Launchpad translations. Since the
> desktop translations get stripped from the packages (where upstream
> distributes them), the langpacks are the only source of translations.

Does it often happen that .desktop files contain plural forms? I should check...

--
Donatas Glodenis

[Andrius Štikonas (stikonas)]

> Does it often happen that .desktop files contain plural forms? I should
> check...

.desktop files never have plural forms. So this is not a blocker, just an
additional thing to consider.

[Gintautas Miliauskas (gintas)]

FWIW, I as the GNOME Lithuanian translation coordinator would also like to bypass Launchpad translations for GNOME packages that are translatable under l10n.gnome.org.

[David Planella (dpm)]

Hi all,

Thanks to everyone for the input, I'll try to address all points. Please
let me know if I forget anything.

El ds 17 de 04 de 2010 a les 13:44 +0000, en/na Rimas Kudelis va
escriure:
> * While I do agree with what you said regarding standardisation, we have
> a little problem: manpower. Lack of it is probably the biggest reason
> why I don't really see it happening in the short term: coming to a
> consensus is one thing, but actually realising it is totally different.
>

But if there is this lack of manpower, would it not have been better to
wait with the plural migration and try to reach consensus first, rather
than a project using a different plural form than all the others?

El dg 18 de 04 de 2010 a les 07:30 +0000, en/na Donatas Glodenis va
escriure:
> I would vote for Rimas' suggestion b) – not to import Lithuanian KDE
> translations to Launchpad at all.
>

That's technically not that easy, and especially not now, less than two
weeks before release.

For more information on why we import upstream translations, I'd
recommend having a look at this document:

    https://wiki.ubuntu.com/Translations/Upstream

> It is also consistent with the Kubuntu developers' position on the
> temporary suspension of the usage of Launchpad:
> time
> The project Timelord articulates this position:
>
> „For the reasons mentioned above, the Project Timelord team has deemed that in
> Kubuntu's current state, using the Launchpad Translations system is counter-productive
> to achieving the goal of a localized, human KDE experience. During the Kubuntu 9.10
> development cycle, a concentrated, cooperative effort between Kubuntu and Launchpad
> developers occurred to try to improve KDE translations in Kubuntu. Great improvements
> were made to this point, and while we appreciate the time and effort the Ubuntu
> Translations team has taken to improve the current situation for Kubuntu, we must face
> the facts that given current developer and translator resources that Kubuntu is unable to
> use this translation architecture in a productive manner.“ (see http://www.kubuntu.org/news/timelord for details).
>

If you are interested in the Timelord project, I'd also recommend you to
read
http://jontheechidna.wordpress.com/2010/02/24/project-timelord-midterm-review/ to learn more about the progress, where the current state of things on Lucid is to remain with Launchpad in order not to introduce regressions on an LTS.

> Also we should perhaps raise the question about changing the number of
> plural forms with other developers and translators in Lithuania to
> perpahs switch to 4 forms... Would it be possible to achieve, what do
> you think?
>

I think this should be discussed within the Lithuanian community and
whichever communication channels the different upstream translation
projects use, rather than on this bug. This will give you the
possibility to get input from everyone involved and to discuss in a more
appropriate medium than on a bug tracker (mailing list, IRC, forum,
etc.).

El dl 19 de 04 de 2010 a les 14:53 +0000, en/na Gintautas Miliauskas va
escriure:
> FWIW, I as the GNOME Lithuanian translation coordinator would also like
> to bypass Launch...

[Rimas Kudelis (rq)]

Hi,

2010.04.19 19:06, David Planella rašė:
> El ds 17 de 04 de 2010 a les 13:44 +0000, en/na Rimas Kudelis va
> escriure:
>
>> * While I do agree with what you said regarding standardisation, we have
>> a little problem: manpower. Lack of it is probably the biggest reason
>> why I don't really see it happening in the short term: coming to a
>> consensus is one thing, but actually realising it is totally different.
>>
> But if there is this lack of manpower, would it not have been better to
> wait with the plural migration and try to reach consensus first, rather
> than a project using a different plural form than all the others?
>

It wasn't a problem until Launchpad. As you of course know, every .po
file has its own plural header, so there is no conflict, especially
among different projects.

> El dg 18 de 04 de 2010 a les 07:30 +0000, en/na Donatas Glodenis va
> escriure:
>
>> Also we should perhaps raise the question about changing the number of
>> plural forms with other developers and translators in Lithuania to
>> perpahs switch to 4 forms... Would it be possible to achieve, what do
>> you think?
>>
> I think this should be discussed within the Lithuanian community and
> whichever communication channels the different upstream translation
> projects use, rather than on this bug. This will give you the
> possibility to get input from everyone involved and to discuss in a more
> appropriate medium than on a bug tracker (mailing list, IRC, forum,
> etc.).
>

I guess Donatas' question was directed at me. In any case, we will
probably have a discussion on our mailing list, but like I said, I'm
rather skeptic about the outcome because of the lack of manpower AND
this problem being KDE-specific (Donatas explained me why KDE went for
four plural forms, and I don't think the problem being solved is common
in other projects).

> El dl 19 de 04 de 2010 a les 14:53 +0000, en/na Gintautas Miliauskas va
> escriure:
>
>> FWIW, I as the GNOME Lithuanian translation coordinator would also like
>> to bypass Launchpad translations for GNOME packages that are
>> translatable under l10n.gnome.org.
>>
>>
> That is a separate discussion, which I'd be happy to discuss further on
> the Ubuntu Translators list or offline. In any case, that is currently
> not technically possible, and I'd personally would prefer to keep a
> unified approach in handling translations than having exceptions.
>
> If there is any kind of conflict or miscommunication between the
> Lithuanian GNOME and Ubuntu translation teams, please let me know and
> I'll try to help in what I can.
>

I guess the main problem is that mostly it's the same people that
produce translations both in upstream and in Launchpad. Keeping them in
sync manually only consumes more time and doesn't really add much value
to the result. Perhaps Launchpad could be extended to allow blacklisting
certain packages from being translatable in it, and Ubuntu would just
use upstream translations in those cases, at least as long as they're
complete.

> As a summary, though, in my opinion the solution to this problem should
> rather be social than technical, and it would be good that the
> L...

[Данило Шеган (danilo)]

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.

[Данило Шеган (danilo)]

To confirm it's not going to break any other translations, we should probably find all PO files that have a nplurals=something where something differs from our number of plural forms for the language.

[Данило Шеган (danilo)]

Note that us working around this problem for Lithuanian is not a real solution: you should still agree on a common plural form expression for all (at least major) projects.

[Данило Шеган (danilo)]

Unfortunately, we will not be able to get this fix rolled out before 2200UTC.

[Andrius Štikonas (stikonas)]

Данило, now it is of course too late but should KDE Lithuanian team move the really singular form to the msgstr[3] for KDE S.C. 4.5? It should be possible to write a script that does this.

[Rimas Kudelis (rq)]

2010.04.23 00:35, Andrius Štikonas rašė:
> Данило, now it is of course too late but should KDE Lithuanian team move
> the really singular form to the msgstr[3] for KDE S.C. 4.5? It should
> be possible to write a script that does this.
>

Shouldn't we discuss the possibility to move to 4 plurals in all
projects first? I think if we agreed on that, it would probably make
more sense to list them in correct order (1, 2, 10, 21).

Rimas

[Donatas Glodenis (dgvirtual)]

2010/4/23 Rimas Kudelis <email address hidden>:
> 2010.04.23 00:35, Andrius Štikonas rašė:
>> Данило, now it is of course too late but should KDE Lithuanian team move
>> the really singular form to the msgstr[3]  for KDE S.C. 4.5? It should
>> be possible to write a script that does this.
>>
>
> Shouldn't we discuss the possibility to move to 4 plurals in all
> projects first? I think if we agreed on that, it would probably make
> more sense to list them in correct order (1, 2, 10, 21).
>
> Rimas

I would agree – it is of course an OT matter for this particular bug
report, but it has to be done first.

Would Andrius raise the issue in <email address hidden>? I will second the suggestion.

And Rimas, could you count how many strings would be affected in, for
example, Firefox, or Gnome? these numbers would be nice to have at the
beginning of the discussion.

It was not a very big transition for KDE, one person did it, actually,
and KDE must be as big as Gnome, Firefox and OpenOffice.org taken
together :)

--
Donatas Glodenis

[Данило Шеган (danilo)]

Andrius, Rimas: I think you should first consider agreeing on a single set of plural forms for all languages: if that's doable, it's relatively easy to change plural forms in Launchpad (except that we'd have to re-import all the translations with new sets of plural forms, but that's needed anyway or your messages will be incomplete).

[Данило Шеган (danilo)]

Donatas, you are probably underestimating the size of GNOME: there's a lot of modules in extras, though it doesn't use plural forms in extra modules as much as it does in main modules.

As for OpenOffice.org and Firefox, I am pretty sure you don't have to worry about them because they use an advanced translation format and infrastructure which doesn't support concept of plural forms.

[Gintautas Miliauskas (gintas)]

A preliminary analysis of all modules on l10n.gnome.org shows 619 strings with plurals. We might be able to upgrade them to the new plurals gradually over time, but I think it's a bit too much work for a single strong push.

[Donatas Glodenis (dgvirtual)]

2010/4/27 Gintautas Miliauskas <email address hidden>:
> A preliminary analysis of all modules on l10n.gnome.org shows 619
> strings with plurals. We might be able to upgrade them to the new
> plurals gradually over time, but I think it's a bit too much work for a
> single strong push.

I wonder if there is a possibility to filter out all the strings with
plural forms into separate files, then quickly distribute the files to
multiple translators, then merge back the translations – it could be a
very quick operation. I would contribute.

We did that with KDE when we needed to switch from using „byla“ to
„failas“. But that was filtering based on keyword, which is possible
thanks to translate-toolkit. Does anybody know if such filtering is
possible based on the presence of plural forms?

--
Donatas Glodenis

[Ursula Junque (ursinha)]

Fixed in stable r10784 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/10784>

[Данило Шеган (danilo)]

We've released a fix in Launchpad translations. Next language pack export should have correct plural forms for Lithuanian, but unless it's a full one, it might not fix all the existing files.

[Andrius Štikonas (stikonas)]

PPA build of language-pack-kde-lt now doesn't contain any Lithuanian translations at all. Is this expected?

https://launchpad.net/~ubuntu-langpack/+archive/ppa/+build/1719045

[Arne Goetje (arnegoetje)]

On 05/09/2010 02:40 AM, Andrius Štikonas wrote:
> PPA build of language-pack-kde-lt now doesn't contain any Lithuanian
> translations at all. Is this expected?
>
> https://launchpad.net/~ubuntu-langpack/+archive/ppa/+build/1719045
>

They are in language-pack-kde-lt-base, since the last one was a full export.

[David Planella (dpm)]

This bug was fixed quite a long time ago in Launchpad, but we haven't heard anything from the Lithuanian community since then.

There is a language pack in lucid-proposed that fixes the issue That language pack was not uploaded to lucid-updates because there was no feedback from the Lithuanian team on the call for testing [1].

However, I'd very much like to release it, as it contains such an important fix.

Could perhaps someone from the Norwegian team could test it following the simple procedure outlined in [1] and give some feedback?

If the feedback is positive, we could proceed to upload the package to lucid-updates and all Norwegian users could benefit from the fix.

Thanks!

[1] https://wiki.ubuntu.com/Translations/LanguagePackUpdatesQA

[Andrius Štikonas (stikonas)]

I've just returned from the holiday so I haven't tested this update before.
But quick testing now doesn't reveal any problems so I think that it is safe
to release. And thank you very much for fixing this!

[Andrius Štikonas (stikonas)]

I've looked at this issue on Maverick. Plural form header is correct (4 plural forms) in *.mo files but for some reason the actual number of plural forms is still cut down to 3. This should be happening on Lucid too unless KDE S.C. 4.5 is installed from PPA which is why I have not noticed it at first.

[Henning Eggers (henninge)]

Andrius, can you please explain what you mean by "the actual number of plural forms is still cut down to 3"?

[Andrius Štikonas (stikonas)]

If I run msgunfmt on .mo file I see this in the po file header:
"Plural-Forms: nplurals=4; plural=(n==1 ? 0 : n%10==1 && n%100!=11 ? 1 : n"
"%10>=2 && (n%100<10 || n%100>=20) ? 2 : 3);\n"

but later in the file I can only see msgstr[0], msgstr[1] and msgstr[2] forms. msgstr[3] form is missing everywhere.

[David Planella (dpm)]

Andrius,

From what I understand, the .mo files exported from Launchpad (i.e. those in the language packs) are ok, but the applications don't seem to be loading all plural forms correctly.

If that is the case, the bug in LP was indeed fixed, but there is some other package affected that's stopping applications to load all plural forms.

Could you give us an example of a particular string and application where you've observed this?

Thanks!

[David Planella (dpm)]

Oh, and I forgot to mention that the language pack update for Lucid was already released in lucid-updates

[Andrius Štikonas (stikonas)]

David,

No, only the header of .mo files is good, the files itself are broken.

Upstream (from kdebase) processui.po file contains:

"Plural-Forms: nplurals=4; plural=(n==1 ? 0 : n%10==1 && n%100!=11 ? 1 : n"
"%10>=2 && (n%100<10 || n%100>=20) ? 2 : 3);\n"

#: ksysguardprocesslist.cpp:165
msgid "End Process..."
msgid_plural "End Processes..."
msgstr[0] "Nutraukti procesą..."
msgstr[1] "Nutraukti procesus..."
msgstr[2] "Nutraukti procesus..."
msgstr[3] "Nutraukti procesus..."

On the other hand, processui.mo file exported from Launchpad has:

"Plural-Forms: nplurals=4; plural=(n==1 ? 0 : n%10==1 && n%100!=11 ? 1 : n"
"%10>=2 && (n%100<10 || n%100>=20) ? 2 : 3);\n"

#: ksysguardprocesslist.cpp:165
msgid "End Process..."
msgid_plural "End Processes..."
msgstr[0] "Nutraukti procesą..."
msgstr[1] "Nutraukti procesus..."
msgstr[2] "Nutraukti procesus..."

The last plural form is missing even though the plural header is correct. And this happens for all plural messages, I've just taken this as an example.

E.g. dolphin.mo has:

msgctxt "@info"
msgid "%1 item selected"
msgid_plural "%1 items selected"
msgstr[0] "Pažymėtas %1 objektas"
msgstr[1] "Pažymėtas %1 objektas"
msgstr[2] "Pažymėti %1 objektai"

The last form is also missing. I hope that the problem is clear enough now.

[Henning Eggers (henninge)]

David,
I am not sure about languagepack creation here. Does Launchpad export po files or mo files? Does the mo creation happen on Launchpad or is that part of langpack-o-matic's job?

Henning

[David Planella (dpm)]

El dv 20 de 08 de 2010 a les 15:41 +0000, en/na Henning Eggers va
escriure:
> David,
> I am not sure about languagepack creation here. Does Launchpad export po files or mo files? Does the mo creation happen on Launchpad or is that part of langpack-o-matic's job?
>

Launchpad exports PO files, you can see them here:

 https://translations.launchpad.net/ubuntu/maverick/+language-packs

Langpack-o-matic then takes care of building the mo files that are
shipped in language packs.

[Mohamed Amine Ilidrissi (ilidrissi.amine)]

What's the status on this bug? Should it still be marked as Incomplete?

[Данило Шеган (danilo)]

I believe we should open a new bug for the remaining problem: we cut the number of exported plural forms to the number we have for the language, instead of using the number from the header.

[David Planella (dpm)]

I've opened the follow up: bug 636936

[Yaron (sh-yaron)]

In Hebrew we suffer from a smiliar problem.

Only some of the apps needs a different plural forms and we need to be specific.

[David Planella (dpm)]

El dt 14 de 09 de 2010 a les 10:57 +0000, en/na Yaron va escriure:
> In Hebrew we suffer from a smiliar problem.
>
> Only some of the apps needs a different plural forms and we need to be
> specific.
>

Hi Yaron,

If I remember correctly that is a planned change for Hebrew, which
hasn't been put into place yet.

As the Hebrew translations are ok in that regard, I'd suggest commenting
on the follow-up bug instead, to make sure your planned changes can be
supported when that bug is fixed.

Thanks!