Labels are not translated with i18n_field for Drupal core.

Field labels are in fact not really implemented yet by i18n_field due to #1157426: Field system uses t() incorrectly and inconsistently, which once committed would get us free reign to control translation for all field properties. At least core would not intervene where it should not. I'm not sure how does your patch solve that? Where is the code to save them for translation?

Yes, the string list function will only run if you refresh your field strings, not when you add a new field, so it cannot be considered "implemented" yet in that sense.

As it is fixed in core and will be in next release, we should take care of this too, never mind field labels get double translation until next Drupal 7.x is out.

Btw, we've got now translation tabs for fields too and some string api improvements as a result of #1154364: Add consistent translation tabs for objects

This patch will need update I guess.

Yep, field labels are untranslatable again (with D7.2 and latest i18n dev).

Waiting for update :)

This patch makes field lables translatable in Drupal 7.2. Maybe we should drop support for older version (< 7.2).

Optional: Drop Support for older drupal version.

Committed the patch in #7

About the patch in #8 I am not sure we want to break sites that have not yet upgraded to latest core version. The only issue they'll get is field labels not being translated properly but they can still enjoy the rest of the features.

I have installed latest dev from git - field label translations on the edit page are back, but not on the rendered page.

I looked in manage fields -> field -> translate: 'instance' is translated, and 'field' is not. I tried to enter a translation, but after I clicked 'save' - nothing happened.

I checked 'Translate interface' - I have two translations for each label.

I have refreshed and updated strings and cleared Cache of course.

Same problem here, D7 upgraded to 7.2.
Label for field Tags in Article content-type was translated to other languages in D7, now it is not.
Using latest dev of i18n I can add translation for the field instance, but it is not translated in the output. (Try switching to Čeština on http://d7.mapsys.cz, there should be Śtítky instead of Tags)
Patch in #6 does not apply to current dev version, so I guess it is already there.

Needs more tests.

Tests for field labels commited in 8e652f9. This feature is working properly. All tests passed.

But not in real life :D

Hmm thats right. Its only working for forms. Try this patch ...

I am not sure about this last patch. Its this the right hook to do the translation?

patch in #14 works for me. thanks!

Patch from #14 works for me as well, but only after clearing the cache, so don't forget to do that.

Code looks OK to me.

I still can't translate 'field' on a field translation tab.

Terms are untranslated in exposed filters, but it's probably a views issue

Patch doesn't work for me. Should I get latest dev version instead of Beta6?

yep

Patch looks good and seems to work.

Committed. Thanks.

Subscribing to this issue and #1169798: Field labels are not translated anymore after upgrading to D7.2.

We are getting tons of "me too" reports about #1169798: Field labels are not translated anymore after upgrading to D7.2 in the Drupal core queue.

Any chance of a new release of i18n module with this change, so these folks have a way to fix this on their sites?

@webchick,

Sure, we'll have one this weekend.

Hi!
First of all, I should really thank all of you for hard work over this issue! But there are some minor problems still.

First of them is with "Boolean" field label. You can translate it, and translation will be used when your entity is shown to user. But if you'll check 'Use field label instead of the "On value" as label' option at field properties, you'll see untranslated field label when you create or edit your entity.

Next problem is with fields, where you can add unlimited number of values. When you add or edit entity with such a field attached, you have at least two field labels, they are absolutely the same. One of them is for all bunch of field examples, and the other(s) for each example of that field. Bunch label is not translated, and others are.

The Date field label is not translated at Add or Edit screens (though translated label is shown on entity page this field attached to). Probably the problem is with Date module itself, though.

I'm having problems with the patch, using the dev from JUne 09:

Fatal error: Cannot redeclare i18n_field_field_attach_view_alter() (previously declared in
/sites/all/modules/contrib/i18n/i18n_field/i18n_field.module:261) in
sites/all/modules/contrib/i18n/i18n_field/i18n_field.module on line 300

Adam, did you applied patch to dev version from June 09? If yes, you should reinstall module, because this patch is already there. If not, it is better to check current dev version (June 10), and if the problem is still here, to post the way to reproduce it.

@renat

I reinstalled the site using the June 10 dev version now, and the problem persists. To reproduce:

1. Create a content type with a select list field with two allowed values: boy and girl.
2. Create a node of the content type. Choose either boy or girl as value
3. View the node
4. Install a new language
5. Translate (using the built in UI) 'boy' and 'girl' to the new language
6. View the node. The allowed value will be displayed in english instead of the translated language
7. Edit the node. The allowed value will be displayed in the translated language.

@AdamGerthel

We were talking here about 'Field labels', which are not field options. Anyway, for options to display translated you need to select 'Default translated' on the 'Manage display' page for that field's format.

@Jose Reyero

Thank you! I'm not sure how I could have missed that one. I've had trouble with translating both labels, taxonomy terms and allowed values so I must've gotten them mixed up.

Hello,

The 7.x-1.0-beta7 module now provides this neat "Translate Field instance" thumbnail...

(path : admin/structure/types/manage/profile/fields/field_name/translate)

However, entering a translation and seeing the confirmation message ("translation saved") makes no difference. The strings won't save to the database and will still appear as "untranslated" when the edit page is reloaded.

I don't know if this should be signalled as a separate bug though... To me this is just a continuation of the initial problem : my field labels appear in English where they shoud appear in French.

You can use 'translate interface' instead of 'translate field' tab, until it's not fixed

Not sure if this should be a separate issue but all my labels and error messages are correctly translated, except for form_errors that use $instance['label']. E.g. the core number module sets an error like this in number_field_widget_validate.

$message = t('Only numbers and the decimal separator (@separator) allowed in %field.', array('%field' => $instance['label'], '@separator' => $field['settings']['decimal_separator']));

%field doesn't get translated in my case (required and other error messages are correctly translated).

When going to the translate tab on the field, the instance seems correctly translated, the field sub tab doesn't show translations (and doesn't allow to save a translation either, also not sure if that is related).

Well, the problem persists on i18n-7.x-1.0 (stable) with i18n_field properly activated, under Drupal 7.8

I'm getting pretty desperate.

The "Field settings" label interface at the following URL is useless, and doesn't "save" the translations :

admin/structure/types/manage/content-type-name/fields/field_name/translate/fr

However, I must remind that all labels were properly translated and working under Drupal 7.1, and are still marked as such in the "classical" admin/config/regional/translate interface.

+++

I don't have this problem in a newer installation, where i18n was activated after Drupal got past the 7.2 version (although the label translation interface under "field settings" remains as useless...)

De-installing and re-installing i18n_field doesn't help.

@paradiso,

You need to translate the 'Field instance' label, not 'Field settings'.

Field labels under Field Instance are already translated, and have been translated for a long time.

They stopped working after the D 7.2 upgrade.

What can I do besides updating Drupal core and i18n modules? I'm about to fiddle directly into the database on this one, but I guess this won't help much in terms of improving Drupal.

This problem is NOT fixed... unless the core issue at node/1169798 is a better place to report it.

+1

**Disregard, problem was unrelated to i18n

#39 What is the problem origin then?

Okay, I made a screen capture to reproduce this problem.

In this capture, I've used fresh Drupal 7.8 standard installation profile with i18n and i18n_field modules enabled (7.x-1.1). I have installed Drupal with english and added finnish from locale settings.

http://screencast.com/t/fYsiO0n5Gr

I found out with webflo, that you shouldn't change the default language. Instead configure your language detection (path prefix for example) and see the node edit form and node view to get this work.

After all, I feel stupid :D

I upgraded my test website from Drupal 702 to drupal 708 ,and I18m from 7.x-1.0-beta6 to 7.x-1.1 and now my labels are translated!
You did it! Thanks a lot. Really, thanks for all that work

Tested with the latest version and it doesn't work

Settings :
- Default language : English (nerver changed)
- Second language : French
- Languages for content : Enabled languages only.
- text language detection : URL(path prefix)

Attempting to modify label translations gives me a weird error message :

Cannot delete string, not found field:field_role:profile:description for text group field: [empty string]
Cannot delete string, not found field:field_role:profile:default_value for text group field: [empty string]
Cannot delete string, not found field:field_role:#field:label for text group field: [empty string]

I am not trying to delete anything here ! I'm just trying to update some of the translations that do not appear where they should - that is, the French interface of my website.

The path where this error happens is :
admin/structure/types/manage/content-type-name/fields/field-name/translate

I've the same issue as paradiso.

Finally, it have tested on a clean install and it works now, but everybody cannot rebuilt its website from zero...

Upgrading to 7.x-1.1 worked for me. Thanks!

EDITL: Woops, spoke to soon...Only the fields labels that I translated prior to upgrading to 1.1 have been changed. I'm now getting the same message as above.

Cannot delete string, not found field:field_test:user:description for text group field: [empty string]
Cannot delete string, not found field:field_test:user:default_value for text group field: [empty string]
Cannot delete string, not found field:field_test:#field:label for text group field: [empty string]
Translations saved.

Same problems with latest -dev

Cannot delete string, not found field:field_test:user:description for text group field: [empty string]
Cannot delete string, not found field:field_test:user:default_value for text group field: [empty string]
Cannot delete string, not found field:field_test:#field:label for text group field: [empty string]

It's caused by this code here in file i18n_string/i18n_string.pages.inc:

    // If we don't have a source we create it
    if (!$source && empty($disabled)) {
      $item->update(array('messages' => TRUE));
      $source = $item->get_source(); // This also seems like a bug since it's called above as well.
    }

The 'messages' => TRUE causes the error.

'mesages' => TRUE causes string_update() to display the error.

Also while looking at the code I noticed that it doesn't appear that the second call to $item->get_source(); may be a bug. It seems out of place.

+1

some issue #48

+1
Problem still persists

downgrade to 1.3 realise, problems still persist.

+1

For those of you who need a workaround and retrieve their lost label translations, Display Suite works fine!

http://drupal.org/project/ds

1. You need to create a "group" for each field (for instance: group_field1, group_field2)
2. The group labels should match those of the corresponding fields.
3. Format your groups as an open div (not collapsed !)
4. Place each field within its corresponding group, and hide the broken label.

The group label shoud appear as a nifty h2, h3 or whatever, right above the field. Its translation works fine.

Cleaned that warning messages.

Otherwise AFAIK this works fine, but for fields created with previous versions of the module. For such case, you can go to the field instance edit page and click save or go to Regional & Language - Strings - Refresh Field strings.

Marking as fixed but feel free to reopen if the issue persists with latest (-dev) version, that will be 7.x-1.4 soon.

Hi,

I am not able to make this work for me.

Only enabled (and default) language is Norwegian.

Here is what I have done so far:
- Installed latest dev
- Enabled the i18n_field module and dependencies (variable, i18n, i18n_string)
- Changed source language to English in "Multilingual settings"
- Found the label in Translate user inteface and translated it to Norwegian

The string, in the context commerce_order_total:commerce_order:label, now has a Norwegian translation.

At this point I expected this to work, but it did not.

I then tried:
- Edited the bundle that holds the field instance. It shows up with the english label, but with the correct translation under Translation. Tried editing and saving Translation any way. I could only change "Field label" under "Field Instance", all the other fields - including Label under the "Field settings" tab, is disabled.

-> Saving has no change.

The field is locked, could this be an issue? Is that why I can not change the label under "Field settings"?

Atle

under multilingual settings -> Translatable text formats have you checked your right formats?

@ciraxis: Thanks for your suggestion. I selected all text formats to test, but it does not make any difference.

@atlea,

As I understand your issues are with Commerce labels.

This is mostly about fields provided by Drupal core. For other modules please open a different issue either for i18n or for Commerce.

Hi,

I still having the same problem with file field. I'm running drupal 7.19, I translated the file field label and description but the translation is not displayed while other field are translated correctly.

I did a print of the $context['field'] in the i18n_field.module in the i18n_field_field_widget_form_alter function, and the image field(s) didn't appear.

I'm also having issues with the "Image field" & "file field" label and description translations all other fields work fine

I'm having an issue with a checkbox field label nob being translated on node add/edit form, but it works fine on the node display.

I have the same issue with a couple commerce field labels and a bunch of taxonomy terms. In all cases, the node view is translated, but the node form is not, so it appears the issue is broader. I even am seeing differences between my production and dev instances where the configuration hasn't changed, but some new content was added (taxonomy terms).

Edit: I'd like to help wherever possible, so let me know if I can provide more information or insert some debugging statements anywhere.

I had the same problem, now it works. See: http://drupal.org/node/1944408

I'm having this problem but with group field labels? Any ideas

As for @stevieb, translations for Drupal’s “Image fields” do not work for me either. The attached patch solves the problem for me, although I’m not sure whether this is the best way to fix the issue.

Sorry for the noise, attaching the (hopefully) correctly formatted patch now …

I suppose this patch will not fix all issues. See #1964234: Not all fields are translated.

Related #1961750: Unable to translate field label and description containing html tags/entities.

Let's close this ancient issue again.

The problems that the previous patch is attempting to fix are being fixed in #1904368: [7.x-1.8 regression] Field translation fails in numerous situations (the patch there seems to be the most complete).

EDIT
Sorry