i18n_field should translate prefix/suffix of number fields

the issue #1221276: locale_get_plural() only works for a single language within a request and does not work for English has been fixed but affixes are still not working

sorry

any one know status of this? it does look like #1221276: locale_get_plural() only works for a single language within a request and does not work for English has been fixed but i still see no method of translating field suffixes/prefixes.

Any progress here?

As i18n_field not translates all components of field suppose it is a bug that should be fixed ASAP.

I found how to translate field suffix/prefix on entity add/edit form. But I have no idea how to translate them during field_attach_view(), because hook_field_attach_view_alter() got value that already was formated using suffix/prefix.

I attached a patch that could help someone to continue working on this issue.

Change issue status.

Thanks for the patch. It works great for the node edit form.

I would also love to know how to get the translation working for "field_attach_view."

I confirm that prefix and suffix was in the local module.
But in my commerce installation (field attached to product) suffix not translated.

The patch needs to be rerolled since #1904368: [7.x-1.8 regression] Field translation fails in numerous situations landed and it makes some of the changes in the patch unneeded.

Furthermore, I see that the referenced Drupal core patch hasn't landed yet, isn't that a blocker for this issue?

here is the patch rerolled.
so the prefix/suffix should be translatable, but the translations still not used for the field view.

@bojanz: which Drupal core patch did you mean?

Probably because you're changing $element instead of $alter_element.

using $element it's ok, as it works for the field form alter - we have tranlated prefix/suffix.
within $alter_element won't work.

Re-rolled patch without extra whitespaces.

changed the last patch: use $alter_element ($alter_element['#' . $element_property] <=> $element['value']['#' . $element_property]).
patch attached.

#16: i18n_field-i18n_field-should-translate-prefix-suffix-of-number-fields-1221208-16.patch queued for re-testing.

Thought this patch would be applied in the dev release but it was not, now the patch made i18_field create prefix/suffix translation strings. they work fine in the new content / edit content forms. but still the display widget displays the original prefix/suffix string not the translated one.

> still the display widget displays the original prefix/suffix string not the translated one.

So it seems there's still some work to do here.

We need to add some tests before we add any other field feature: #2061999: Add tests for field translations to avoid regressions (i18n_field.test)
(And this one needs tests too).

here is a new patch that overrides the number fields output with prefix/suffix using the translated values of these settings.

I patched a fresh dev release install of i18n and test results are:

There still a problem with the display widget, everything's still fine on add/edit forms.

On the default english node view an error msg appears and no prefix/suffix displayed:
Notice: Undefined index: suffix in i18n_field_field_attach_view_alter() (line 377 of /home4/azraph/public_html/sallefny/sites/all/modules/i18n/i18n_field/i18n_field.module).

On the translated node everything's fine including the prefix/suffix translation display.

@Azraph : indeed. Thank you Sir.
tip : when a patch fails (is not working), please change the issue status to "needs work".

here is a new patch that should solve these errors.

Works perfectly, thank you @vasike

Needs tests, see #20

new patch with number fields Test.

This may work though the patch is still lacking a few things for using the API properly:

1. Metadata for these properties, it should be in i18n_field.i18n.inc i18n_field_i18n_object_info()
(See menu link properties about how to do it for nested properties, i18n_menu_i18n_object_info())
** Btw, do these prefix and suffix values show up properly in the field translation tab? (it should be fixed by the right metadata).
2. After that you'll find all the translating code can (and should) be simplified because we won't need that many specific lines for these two properties, they will be just translated when invoking i18n_string_object_translate()

i can't get how these "nested properties" are supposed to work.
i mean i can't see 2. happening.

however here is patch that uses i18n_field_i18n_object_info() for these properties.

#28 did not worked for me (the suffix was not translated on the node edit page). #23 worked but I got "undefined value" errors (such as for $settings['scale']) in some cases (maybe because I was using EVA module).
Using this

          if (isset($context['display']['settings'])) {
            $settings = $context['display']['settings'];
          }
          elseif (isset($instance['display'][$element['#view_mode']])) {
            $settings = $instance['display'][$element['#view_mode']]['settings'];
          }
          else {
            $settings = $instance['display']['default']['settings'];
          }

instead of this:

          if (isset($instance['display'][$element['#view_mode']])) {
            $settings = $instance['display'][$element['#view_mode']]['settings'];
          }
          else {
            $settings = $instance['display']['default']['settings'];
          }

in the "// Translate number fields prefix/suffix if exist." part of the patch made it work, though I did not take the time to really understand what I did...

#26 gives the option to translate the prefix/suffix text through the translation interface.

It works perfect. Thank you.

based on #26 added t function as follows on i18n_field.module and I'm able to see translations

$prefix = (count($prefixes) > 1) ? format_plural($item['value'], t($prefixes[0]), t($prefixes[1])) : t($prefixes[0]);
$suffix = (count($suffixes) > 1) ? format_plural($item['value'], t($suffixes[0]), t($suffixes[1])) : t($suffixes[0]);

I used the path #26 and it works fine, but when translating nodes with empty value of integer cck field that has translated prefix, I receive the following error message:

Warning :number_format() expects parameter 1 to be double, string given in i18n_field_field_attach_view_alter() in sites/all/modules/i18n/i18n_field/i18n_field.module

I have never had that error before applying the patch.

I applied the patch #26.

When I create a view and I show a Decimal field with prefix/sufix, drupal gets me this error for each value on this field.

Notice: Undefined index: scale en i18n_field_field_attach_view_alter() (línea 376 de /var/home/timit/htdocs/nav-administradors/sites/all/modules/i18n/i18n_field/i18n_field.module).
Notice: Undefined index: decimal_separator en i18n_field_field_attach_view_alter() (línea 376 de /var/home/timit/htdocs/nav-administradors/sites/all/modules/i18n/i18n_field/i18n_field.module).
Notice: Undefined index: thousand_separator en i18n_field_field_attach_view_alter() (línea 376 de /var/home/timit/htdocs/nav-administradors/sites/all/modules/i18n/i18n_field/i18n_field.module).

The notice appears in all languages but english.

i18n without #26 patch does not show these notices.
I decided to use the dev version on i18n without prefix/sufix translation functionality. It's not what I need but it's better than has the notice.

If anyone can reproduce this issue and knows how to solve it, please, post it here. Thanks.

there is a new patch that includes the code suggested at #30.
@GaëlG : thank you Sir

i hope this will solve the "undefined value" errors (such as for $settings['scale']) issues.
and i hope will pass the tests.

do not try the patch from #26 anymore, check the #27 and #28 comments.

any help with the tests implementation for this field translation (testNumberFieldTranslation)

I am a non-coder and don't know how to apply a patch properly. Nevertheless, I might be able after some Google research. The last Status of the patch is "failed testing". Does that mean that I shouldn't use the patch?

In general I was kind of surprised that it is currently not possible to translate Suffix and prefix. You can translate so much using entitiy translation and i18n but these little peaces are not translateable. One should think that almost every multilingual website faces this bug.

In patch #37, there is an issue with this part:

  // Normalize translated instance.
  foreach ($instance_current['settings'] as $setting) {
    if (!empty($instance_current[$setting])) {
      $instance_current['settings'][$setting] = $instance_current[$setting];
      unset($instance_current[$setting]);
    }
  }

When using it, I received this error:

Warning: Illegal offset type in isset or empty in i18n_field_field_widget_form_alter() (line 230 of ./sites/all/modules/contrib/i18n/i18n_field/i18n_field.module).

Thing is that the $setting variable is used to store $instance_current['settings'][-something-] 's value foreach loop, which in some cases can be "FALSE" for example (This is when this when I get the warning)...

Was it meant to be like this?

  // Normalize translated instance.
  foreach ($instance_current['settings'] as $setting => $value) {
    if (!empty($instance_current[$setting])) {
      $instance_current['settings'][$setting] = $instance_current[$setting];
      unset($instance_current[$setting]);
    }
  }

(marking as need review to trigger testbot)

This patch is #42 + the fix in #30 for views. #37 mentions that it added #30 but I don't see the code in the patch.

FWIW, I tried applying the latest patch in this thread on a very simple use case where I need to translate the suffix of an integer field, and it works fine as far as I can tell.

I've modified the patch because I created my own custom field formatter and this one already does the i18n translation + adds extra spans etc. The patch should only replace the markup if it's one of the formatters provided by drupal core.

The formatter shouldn't replace anything ever. i18n should create a new formatter, like it does with all other formatters, e.g. list_text: Default translated.

This patch creates 2 new formatters: i18n_number_integer and i18n_number_decimal. Default will still work, exactly as it used to. And Unformatted is still unformatted, which was broken with previous method. This is less intrusive and more inline with i18n. It's more code though, and won't work automagically.

It uses all of number.module's formatter logic, so updates etc won't interfere.

Interdiff attached too:

• extend i18n_field_field_formatter_info()
• add i18n_field_field_formatter_settings_form()
• add i18n_field_field_formatter_settings_summary()
• extend i18n_field_field_formatter_view()
• remove chunk of i18n_field_field_attach_view_alter()

And it also work for number_float fields, which previous patch didn't..?

I don't know why tests fail, screw that, it works perfectly.

Patch #48 worked for me. In my case it is just a simple integrer with suffix for prices.
Don't know too why it failed testing. In any case, thanks for the patch!

I would actually argue that prefix and suffix should alway be shown in the translation form.

For example, english and french currency data in Canada use the following format:

English
$1.50

French
1,50 $

So the translation is the fact that the prefix is now a suffix.

I agree with @minorOffense

Triggering test?

Ok, not triggering test...

Re-upload #48

Well, that's quite strange..... PHP 5.3 has 3 fails. PHP 5.6 has 2 fails =)

Tested the patch, works like a charm, NR for testbot

#56 working for me. If you're using Views, remember to choose the Default Translated formatter.

Patch #56 works great. I'm running it in production since several days. What has to be done before RTBC now?
Are the tests wrong or is the patch wrong?

RTBme ;)

Two remaining items left on this patch todo.

1. fix the testbot errors.
   
   
   Here are the testbot results, two errors to fix:

   createStringTranslation
   
   ✗	exception: [Notice] Line 344 of sites/all/modules/i18n/i18n.test:
   Undefined offset: 1
   
   ✗	testNumberFieldTranslation
   
   fail: [Other] Line 176 of sites/all/modules/i18n/i18n_field/i18n_field.test:
   Field description is not translated
   
   fail: [Other] Line 183 of sites/all/modules/i18n/i18n_field/i18n_field.test:
   Field description is translated

   
   Looks like the same cause.

2. add suffix or prefix option as described by @minoroffence in comment#52

Patch #56 works like charmed for me :-)

Does #56 work with i18n 7.x-1.17?

Yes, it does work

Hello everyone, tell me please, where can I translate the prefix and suffix? Unfortunately I did not find any settings. Drupal 7.54 and i18n 1.17. Thank you!

Patch #56 apply with few warnings

patching file i18n_field/i18n_field.i18n.inc
patching file i18n_field/i18n_field.inc
patching file i18n_field/i18n_field.module
Hunk #3 succeeded at 281 (offset 4 lines).
Hunk #4 succeeded at 370 (offset 4 lines).
patching file i18n_field/i18n_field.test

A new patch with just a quick re-roll against the latest dev.

patch #70 works fine with the 7.x-1.24 (as well as with the older 7.x-1.22). Thank you.

To answer #68: you need to select the formatter as Default (translated), then display the page containing this field in another language, and then translate it the usual way (eg with admin/config/regional/translate/translate)

However, #70 doesn't work for me with plurals on the node edit form - maybe I am missing something:
My suffix is ' meter| meters' which is translated (in french) to ' mètre| mètres'

In the i18n_field_field_widget_form_alter, in the // Translate field properties function, I have:
$property_value = ' meter| meters'
$translated_property_value= ' mètre| mètres'

but my $element['value']['#' . $element_property] = ' meters'. It has already been set to the plural form therefore it never validates the $element['value']['#' . $element_property] == $property_value and doesn't get translated.

I don't know how this should be handled, I changed it to

if (!empty($element['value']['#' . $element_property]) && $translated_property_value != $property_value) {
        $alter_element['#' . $element_property] = t($alter_element['#' . $element_property]);
      }

which works for me - but don't know if it's the ideal solution