Protect plural forms

Import here admin/build/translate a translation (*.po) for e.g. drupal, not for project. than drupal set the plural formula for your language in the db. because the l10n_server needs the plural formula from the db.

Looks like you've fixed this issue by now. Also, there is an existing Persian server advertised on the project page: http://l10n.farzanbeh.com Maybe work with them to get their translations imported to your server, so you can keep the work on. You seem to be farther ahead. Retitling so that the issue reflects the problem.

Hmmm... I don't like to import files as I'm only hosting a few projects that are not available elsewhere. Isn't there no way to pre-configure them? Shouldn't we know the plural form if we have a language!?

If I do understand this correctly a "malicious" user can import a wrong plural form into my server and all data is/is going to be destroyed... This is also true for core today if I remember correctly from past where I have had a few German files without a plural form. I think the users haven't been aware about this and nobody sees an issue in PoEdit - if there is no plural form in the edited .po file - but the server may become cluttered isn't it?

Well, this error message calls for importing a translation for Drupal on the core local UI. That fills in the plural form. The l10n_server does not touch, update or modify the plural forms in any way, it just picks it up from Drupal. That is how it is protected in this module. So if you give a malicious user access to your core Drupal locale import, then they can do worse things, therefore I don't consider this a security issue.

Sure, we could "know" the plural forms of languages, and if you use the drupalorg connector it even installs these when enabled. We can make some coolness to preinitialize these even in other cases. I was initially afraid that the plural forms collected might not all be right, so I was reluctant to push that down on the different team's throats.

When I saw this plural form issue the first time it was caused by a module I've downloaded and tested the first time. It have had a de.po included that was automatically imported into my installation and the translator have missed to add the plural form... So you make me checking every po file of every language of my site if the plural form is correct. :-( malicious or lazy or clueless... however we name it - it could potentially clutter my l10n_server... never thought about security.

I'm only not sure what will happen if I have no plural forms and I'm importing a PO file via l10n_server import... not tested. I haven't tested what will happen or may get cluttered, but it sounds like a problem if the import makes use of the plural form and only if the correct one exists it saves the strings correctly in the database. Haven't you not used a null bye to delimit the plural strings... does this depends in any way on the plural form settings in language table? Maybe bullshit not sure...

Related: #209325: Admin interface for plural settings was just solved - support for plural formula editing was added.

While as said above, this was not an issue with people given access to the l10n_server UI, not only with people given access to the core locale UI, it still might be an issue with imported strings. So I've worked out a solution for the import form itself, which protects the plural forms. Also updated the help text when there is no plural formula, so that it points to the new editing screen as well.

The batch import way of breaking plural forms is not yet fixed, so marking this needs work. Committing this one however to get this one fixed.

Retitling for what this issue became. Also, committed this update which also covers the system and theme forms. Yay.

It would be good to fix this up in core in Drupal 7, so the keep option would keep the plural forms as well, making it a much safer choice. Issue added at #566390: Apply locale import protection to the plural forms. Please support, so we get that in soon and do not run out of time for Drupal 7 :)