_locale_rebuild_js doesn't store plural forms correctly

I suspect this is the same problem as #297507: validation error causes vertical tabs to disappear, where Vertical Tabs was using #after_build to add the JavaScript to the page. Since #after_build functions are not called when validation fails or when rebuilding a cached form, I suspect this was the problem. Vertical Tabs now used #theme, which consistently rendered.

Moving to fixed, as I believe this problem was fixed in #297507: validation error causes vertical tabs to disappear, please reopen if it still has the problem.

This bug is yet present in 6.x-1.0-beta3 version. Upload file corrupts tabs display and fields values ("author" to anomymous, etc... node gets unpublished).

+1, the bug is still present on last version (beta 3).

This is likely due to a bug in the JS translation parser.

// In function _locale_rebuild_js
if ($data->plural) {
  // When the translation is a plural form, first add it to another array and
  // wait for the singular (parent) translation.
  if (!isset($plurals[$data->plid])) {
    $plurals[$data->plid] = array($data->plural => $data->translation);
  }
  else {
    $plurals[$data->plid] += array($data->plural => $data->translation);
  }
}
elseif (isset($plurals[$data->lid])) {
  // There are plural translations for this translation, so get them from
  // the plurals array and add them to the final translations array.
  $translations[$data->source] = array($data->plural => $data->translation) + $plurals[$data->lid];
  unset($plurals[$data->lid]);
}
else {
  // There are no plural forms for this translation, so just add it to
  // the translations array.
  $translations[$data->source] = $data->translation;
}

As you can see, the source for plurals is thrown away, instead an array "singular" => "singular", "plural1", ... is formed.

This means we get the following example array in Drupal.locale.strings:

"1 attachment": [ "1 bijlage", "@count bijlagen" ]

Now:

For a singular, Drupal.formatplural will return Drupal.t(singular, args);

Drupal.t then fetches the array:

  if (Drupal.locale.strings && Drupal.locale.strings[str]) {
    str = Drupal.locale.strings[str];
  }

And tries to replace @count:

str = str.replace(key, args[key]);

As str is an array, this fails and all JS dies :(

For a plural, there won't be a string in Drupal.locale.strings (via return Drupal.t(plural, args);)

The bug is rare due to another bug: #532512: Plural string storage is broken, editing UI is missing; it only occurs for imported translations.

Promoted.

Hi there,

will this be solved for D6?

The solution I've used (not very elegant...) was to replace :
str = str.replace(key, args[key]);
by

      function is_array(input){
	return typeof(input)=='object'&&(input instanceof Array);
      }
      if (is_array(str)){
	var n = str.length;
	for (var i=0; i<n; i++){
	  str[i] = str[i].replace(key, args[key]);
	}
      }else{
	str = str.replace(key, args[key]);
      }

in misc/drupal.js

I think too that plural/singular distinction must be handled before a string can be manipulated.

Regards,
cfab

I'm not sure this is the right approach. Another approach would be to duplicate a part of t in Drupal.Plural so it doesn't call Drupal.t anymore.

Since we don't have upload module in core, there doesn't seem to be any reproducable breakage here. Patch looks lovely if it works.

#9: do306715-locale-js-parser-6.diff queued for re-testing.

I tested the patch above in #9 on Drupal 6.15 clean install with image_fupload js files and plural translations and works fine.

The patch is against 6 and cannot be tested. Also, I don't think this results in proper handling of multiple plural forms.

Heine at least our issue was solved after applying #9 for D6
We're using ckeditor, wysiwyg api, triggered by attachment upload (1 single).
We'll hear from users if it broke something different.

This issue makes user experience pretty unusable. Broken core JS should be critical. Singular / Plural js should be a stable a core feature.

Heine, what do you think is needed to consider to make this fixed in D7/D6?

#9: do306715-locale-js-parser-6.diff queued for re-testing.

The patch is against Drupal 6, so it cannot be tested atm.

Also, while the patch might "work" for certain languages, I'm not so sure it is the right approach for languages with another plural formula.

The best thing to do IMO would be to 1) store plural forms as now and 2) have Drupal.formatplural do the argument replacement itself, instead of calling Drupal.t (maybe refactor that out in a utility function).

subscribing...

This issue was originally reported as a vertical tabs issue. In #6 it was switched to Drupal core locale.module. So I need to ask if it still stands for latest 6.x dev of vertical tabs or not. I am not seeing any similar behavior as described in #0, but I hate this kind of surprises ;)

My guess is that it actually is a core bug but a workaround was hacked so it could fix the issue in vertical tabs (that was a side-effect of the actual core bug in the first place). Now, we simply need to wait to get this resolved in core and then the work-around code in vertical tabs can be removed. Am I right?

Yes, this is a core issue. It has not yet been fixed in Drupal 6, or 7.

I'm using Drupal 6.16 with Vertical Tabs 6.x-1.0-rc1, and this bug is still breaking Vertical Tabs, see #751940: Authoring information and publication options disappear and are saved as empty when editing nodes with vertical tabs enabled.

I'd appreciate to see this fixed in D6.

Best regards,
Peter

Sub.

While this is non-critical for 7 since it's not in core, it sure is critical for 6. :/

subscribing.

I tested #9 and it works flawlessly. Should be in 6 core.

#9: do306715-locale-js-parser-6.diff queued for re-testing.

"The patch is against Drupal 6, so it cannot be tested atm."

Also, see #19.

That's why I changed to 6.x-dev. Is there another reason we can't test patches against 6 of which I'm not aware?

I've never seen the testbot actually do anything with a patch against Drupal 6.x-dev. But we'll see.

Subscribing

Now a duplicate of #504506: Drupal.formatPlural incorrectly handle complex plural rules.

Patch attached to http://drupal.org/node/504506#comment-3045006 solved the issue for me...