Number field prefix/suffix get t()'ed through format_plural()

t() is not meant to be called on user-entered data, that is the realm of http://drupal.org/project/i18n.
Translation of field properties is handled by the i18n_field module.

It's rather a bug in number.module that number_field_formatter_view() runs the prefixes and suffixes through format_plural(). We need to use our own non-t() logic in there.

I guess something like the attached patch. This does not support languages with more than one plural form, but :
- I don't think the current code (straight from the CCK era) does either - at least not officially. The help text for the 'prefix' and 'suffix settings reads : "Define a string that should be suffixed to the value. Separate singular and plural values with a pipe ('pound|pounds')".
- At this time in the night, I can't seem to make any sense of the logic behind multi-plural languages inside format_plural() anyway.

In other words, opinions from i18n / locale people welcome :-)

+++ b/modules/field/modules/number/number.module
@@ -284,8 +284,11 @@ function number_field_formatter_view($entity_type, $entity, $field, $instance, $
+          // We cannot use format_plural() to determine the right strings, ¶
+          // because those should not go through t().
+          $index = ($item['value'] == 1) ? 0 : 1;
+          $prefix = (count($prefixes) > 1) ? $prefixes[$index] : $prefixes[0];
+          $suffix = (count($suffixes) > 1) ? $suffixes[$index] : $suffixes[0];
           $output = $prefix . $output . $suffix;

mmm, I don't want to sound bitchy, but the added inline comment documents a fact or bug that shouldn't have existed in the first place (common knowledge)... -- whereas I have an extremely hard time to figure out what that effin' $index logic is actually doing, but there's no comment for that... ;)

10 days to next Drupal core point release.

This remix, of directly accessing and using locale information in the global language object to handle and output plural forms of user input, requires architectural discussion.

1. locale_get_plural() only exists if Locale module is installed. Whereas number fields also exist on sites without Locale module.
2. locale_get_plural() takes the plural formulas from the configured list of languages.
3. locale_get_plural() does not work for English.
4. This is the first time I see code attempting to use locale meta information from configured languages to process configured plural form strings (user input). The idea definitely makes sense, but Drupal core is not prepared at all for this.

Yes, I theoretically agree that given that we assume the site setting is in the default site language, we should use the plural rules for the default site language. Looks like the easiest way out would be to fix locale_get_plural() to work with English as well.

Postponing on #1221276: locale_get_plural() only works for a single language within a request and does not work for English -- there's a working patch over there, just needs tests to get RTBC.

Adding UI language translation tag.

#1221276: locale_get_plural() only works for a single language within a request and does not work for English is nearing completion, please review there! Thanks!

Tagging for the content handling leg of D8MI (too).

@all: #1221276: locale_get_plural() only works for a single language within a request and does not work for English just landed in Drupal 8, so we can continue fixing this one! Yay!

Needs reroll

Rerolled the patch #9.

21: 1220964-21.patch queued for re-testing.

This was resolved for 8.x as part of #1785748: Field formatters as plugins although it propably still needs a backport to 7.x.

This still a concern in D8? Unassigned issue too.

I tested this on 9.4.x, standard install, and was not able to reproduce this error. On the edit form, the prefix and suffix are now translated.

Therefore, closing as cannot reproduce. If you are experiencing this problem on a supported version of Drupal reopen the issue, by setting the status to 'Active', and provide complete steps to reproduce the issue (starting from "Install Drupal core").

Thanks!