i18n strings support

The patch works for me, but we have got some other strings to translate (prefixes, suffixes, checkbox label). Let's fix it as well.

Added support for prefix and suffix following the same strategy.

Updated the issue to reflect the extended goal.

Ups posted the same twice.

Wrong array key

I just realized that there are more user defined strings to translate:

• Widget: checkbox label
• Widget: placeholder for textfield and textarea
• Formatter: prefix and suffix
• Formatter: table columns labels

At this point updating string sources in hook_field_update_instance() looks as more generic solution.

I have added i18n support for all double field settings. It works for me but needs more testing before release. Thanks for the help!

Doesn't work for me, but I'm not even sure it's the right approach. This was mentioned in #1.

Field properties, such as prefixes and suffixes in this case, are user-entered data. The string translation interface, though, is for strings within code. As far as I know, field properties should be translated via the Field Translation module (i18n_field). There is some API info, but it's lacking a good example implementation, and I couldn't find one anywhere else.

So properties should be translatable via:

• Administration » Structure » Content types » (content type) » Manage fields » (field) » Translate » (some language) translate.

...not:

• Administration » Configuration » Regional and language » Translate interface » Translate (admin/config/regional/translate/translate)

So right now I see Label, Description, and Default Value, but no Prefix, Suffix, etc. which are specific to this module.

In spite of that, for the purposes of testing the above commits, my prefix does show up in the interface translation section, but when I add a translation to it, it doesn't show up. The prefix is always that of the original language. What's strange, possibly due to my configuration, is that the prefix text is crossed out for the target language (as though it's already been translated). Then , when I really do add a translation, it gets uncrossed. So it looks like it still needs to be translated. Not sure why this is backwards.

As far as I know, field properties should be translated via the Field Translation module (i18n_field). There is some API info.

That API is very pure. Check out the documentation of hook_i18n_field_info(). As the issue subject suggests, we are using i18n_string module not i18n_field module. So the field properties should be searched on admin/config/regional/translate/translate page.

@Chi: Not sure what you mean by "pure"?

@colan it is not useful for our case

I use double field with select option + textfield widgets and the two patch #1 and #9 does note work for me.

Some help?

maxlife58 what are you trying to translate? Have you tried dev version of the module?

Hi Chi, i'm tring to translate the double field label.
I tried the new dev version today but does not work.

It's possible to solve??

Field labels for any kind of fields can be translated with i18n module.

Hi Chi, thanks for your fast reply, I translate the field label by two way:

1) using the translate tab on edit field page
2) using the string tranlsation interface

but in any case the translated labels are not displayed!

Obviously all the other labels who do not use double field are translated properly!

I just noticed something that can be improved.

We use
i18n_string_update('double_field:' . $instance['id'] . ':' . $i18n_key, $value);

But using numeric id is a bad as they might change as the site gets rebuild by features and other circumstances.
Let's use bundle + field_name like the i18n_module does.

Attached a patch with my suggested change.

Related with the discussion I think is good that we use i18n_string instead of the i18n_field module. for this translations.

ups, forgot the "-" separator between the bundle and the field_name

@rodrigoaguilera, it appears to me that conjunction of bundle and field name does not guarantee uniqueness of the field. We should take into account entity type as well. See field_name_bundle key in field_schema.

Yes, I know is not unique. I don't know why i18n_field does it that way. I guess not to make the string super long.

So let's make it [entity type]-[bundle]-[field_name]. the info is already in the instance. Do you agree?

Yes, lets make it unique.

Here is the patch.

I consolidated the generation of the prefix based on the instance in one function and added hook_create_instance because I'm developing install profiles with features and the strings are not created if you don't implement that hook.

Let's get that new hook to do only what we want it to do.

I had to add one more check to avoid warnings:

with features when you create an instance of the field you have all the info available like widgets and displays.
If you create the instance using the interface it doesn't have all the information double_field expects for generating translations.

Commited. Thanks.