The title is pretty much self explanatory. I have a Dutch Drupal 7 site with a content type containing translated fields. After upgrading to 7.2 these Dutch fields switched back to English for some reason.

This can't be working as designed or can it? Anybody out there for support?

CommentFileSizeAuthor
#17 view.png44.46 KBbartl
#17 edit.png18.42 KBbartl
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

plach’s picture

This is not so obvious as you are supposing it to be, it's a behavior never observed before so something weird must be going on. Would you please provide some more information on your setup? Languages installed, languages enabled, language negotiation settings, language-related contrib modules installed, and anything else you think might give a clue of what is happening.

nieuwkar’s picture

Status: Active » Postponed (maintainer needs more info)

Sure, I'll try to be as precise as possible. I have two languages enabled which are Dutch and English. Dutch is the default language. The negotiation settings are set to use the default language (Dutch) and the only language related modules I´ve installed are the locale (core) module, the localization client module and the localization update module.

I had given the fields English labels which I'd translated into Dutch. The only odd thing I see is that the content translation module is not necessary to translate content.

plach’s picture

Status: Postponed (maintainer needs more info) » Closed (works as designed)

Ok, now I understand your issue: you were talking about field labels. The t() calls that allowed strings to be (incorrectly) translated have been removed. See #1157426: Field system uses t() incorrectly and inconsistently.

nieuwkar’s picture

Mmm ok thank you for your quick response.

So how do you suggest to translate these labels? use a field template? This also implicates that core themes have to be updated doesn't it?

plach’s picture

As stated in the other issue the solution is the 18n_field submodule shipped with the i18n package.

nieuwkar’s picture

Right, sorry for that.

mediameriquat’s picture

Status: Closed (works as designed) » Active

Hello,

This issue shouldn't be fixed yet. I have the same problem, which seems to have popped up right after the Drupal 7.2 upgrade. My site is "live" and is hosted on an Aegir account so it is not really possible to patch i18n or revert back to Drupal 7.0.

For instance, I have a field called "Role" in a content type called "Profile". The string is :

field:field_role:profile:label

The English original label "Role or Position" used to be correctly translated to "Rôle ou fonction" in French. Now the English label appears both in the French node AND the node edit form, although the translation is still OK in the database.

Language negotiation is set to url (en/node-title, fr/node-title)

I should add that views-related strings (such as block titles, etc.) are OK. The problem, as far as I know, happens on the default Drupal node display.

plach’s picture

Component: language system » locale.module
Category: bug » support

@paradiso:

This issue shouldn't be fixed yet. I have the same problem, which seems to have popped up right after the Drupal 7.2 upgrade. My site is "live" and is hosted on an Aegir account so it is not really possible to patch i18n or revert back to Drupal 7.0.

This is unfortunate but, as stated above, this cannot be fixed in core, it was an error to let field labels be translated through t(). As a temporary measure until this is fully addressed by i18n_field you can pass your field labels through t() in the theming layer.

plach’s picture

Title: I've upgraded to Drupal 7.2 and now my translated strings are being ignored. » Field labels are not translated anymore after upgrading to D7.2
plach’s picture

Status: Active » Fixed

I guess this is fixed.

Mamouri’s picture

I have the same problem. After upgrading to Drupal 7.2 fields titles are not translated anymore. Can you please tell me is this a bug which will solve in say 7.3 or it's a permanent things.

I did not found i18n_field submodule in i18n moudle

plach’s picture

This is a permanent thing. The i18n_field is a submodule of the 7.x version of i18n:

http://drupalcode.org/project/i18n.git/tree/90b6d77ae1f62e05dd00cf8fcfc9...

j0nathan’s picture

webchick’s picture

I've added this to the 7.2 release notes since this seems to be a common support request.

A new release of i18n module would really help people who come across this. In retrospect, I should've waited until that was done before committing this patch. :(

plach’s picture

@webchick:

We've done this exactly because i18n_field could not go on without t() calls being removed.

Boobaa’s picture

bartl’s picture

FileSize
18.42 KB
44.46 KB

I've had the same problem, last week, and after upgrading from 7.2 beta 6 to beta 7, it looks like it's mostly fixed. But not completely.

In particular: the word "Title" still appears in English, as do the labels for date fields (associated with the Date module) which are rendered translated in view mode, but not in edit mode.

In the attachments, see 2 cropped screenshots of the same record. Note that "Date of first use" and "Date of registration" appear in English in edit mode, and in view mode, in Dutch as "Datum van ingebruikname" and "Datum van inschrijving" respectively.

BTW I just noticed that the date format is wrong, too: it uses the format for English instead of the format for Dutch as it should. I'm pretty sure this worked as intended last week. I don't know if this is just an unexplainable glitch (as often happens in Drupal, unfortunately), or if it is related to the upgrade to beta7.

update Deleting the date format for English, under "Localize date formats" (q=admin/config/regional/date-time/locale/en/edit), so it reverts to the system default, which is "dd/mm/yyyy", makes it appear as it should in Dutch. So it really does use the format for English. In Dutch.

Gábor Hojtsy’s picture

Bartl: please follow up in the i18n module issue queue. Read up what people have experienced in #1157512: Labels are not translated with i18n_field for Drupal core. and if related post there. If unrelated but connected to field property translation, please open an i18n module issue.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

yched’s picture

Another field property that gets run through t() : #1220964: Number field prefix/suffix get t()'ed through format_plural().
Feedback from i10n / i18n folks welcome :-)

[edit : oops, I means that for #1157426: Field system uses t() incorrectly and inconsistently. Well, works here too...]

bartl’s picture

Well, after updates to newer versions of Drupal and of several modules, the problem fixed itself, without me doing anything else. I don't know which upgrade fixed it, but it's nice that it did.

mediameriquat’s picture

Version: 7.2 » 7.8
Status: Closed (fixed) » Active

The problem persists on Drupal 7.8, i18n-7.x-1.0 (stable) with i18n_field properly activated, and field labels properly translated in the database.

Just can't get the translated field labels to show in the French node edit form and the nodes themselves.

There must be a way to fix sites that were set up before that very annoying 7.2 core upgrade. Things work fine with a fresh Drupal install, so I guess something's screwed in my DB.

Gábor Hojtsy’s picture

@paradiso: Do you see those translations when you go to the "Translation" tab on the field's configuration screen?

mediameriquat’s picture

@gabor : yes, I do.

Gábor Hojtsy’s picture

Status: Active » Closed (fixed)

@paradiso: ok, that service is provided by the i18n module, not Drupal core. If that is not working, this is an i18n module bug. You already seem to be on #1157512: Labels are not translated with i18n_field for Drupal core. which looks to be the i18n bug counterpart to this. Moving back to closed (fixed) as per the above.

jwilson3’s picture

I've been thinking about this and cannot wrap my head around why field labels are even stored in the translation database, if the translations cannot be used to display the translated labels. Is it because my fields and content types are exported as features? I'm not honestly sure.

Anyway, I don't want or need to download i18n, install i18n_fields and all its dependencies *just* to get translated field labels.

This seems to me to be like the one single element that keeps you from cleanly running a simple non-english site without needing the i18n module, where content types in code are defined in English, and translated in the database.

So below, I've created two functions that add translatability back to Drupal: one for the front end via a hook_preprocess_field() to translate the field label (if present), and one for the backend, to translate the field labels and descriptions on the node edit form.

Use at your own risk, as this is currently considered the WRONG way to translate "user-entered" strings (even if those strings are in code, from fields created by features).

// Put this inside the "myproject_i18n" feature (myproject_i18n.module)
/**
 * Implements hook_preprocess_field().
 */
function myproject_i18n_preprocess_field(&$vars) {
  // Sadly, translations for field labels was removed from Drupal 7.1, even
  // though the string translations are stored in the database, Drupal core
  // does not render them translated. Thus, we are forced to either install
  // i18n_fields module, or the less performance intensive solution: pass the
  // labels through the t() function in a preprocess function.
  //
  // See http://drupal.org/node/1169798, http://drupal.org/node/1157426,
  // and http://drupal.org/node/1157512 for more information.
  if (!empty($vars['label'])) {
    $vars['label'] = t($vars['label']);
  }
}


/**
 * Implements hook_form_alter().
 */
function myproject_i18n_form_alter(&$form, &$form_state, $form_id) {

  // Sadly, translations for field meta data on node edit forms was removed
  // from Drupal 7.1, even though the string translations are stored in the
  // database, Drupal core does not render them translated. Thus, we are forced
  // to either install i18n_fields module, or the less performance intensive
  // solution: pass the meta data (labels and description) through the t()
  // function in a form alter function.
  if (isset($form['type']) && $form['type']['#value'] . '_node_form' == $form_id) {

    // Use the $form_state Array to find the field names.
    foreach (element_children($form_state['field']) as $field) {

      // In Drupal 7 the "#language" value is set on each form field.
      if (!empty($form[$field]['#language'])) {

        // Obtain the field's language.
        $lang = $form[$field]['#language'];

        // Translate the field's label on the $form_state.
        if (!empty($form_state['field'][$field][$lang]['instance']['label'])) {
          $form_state['field'][$field][$lang]['instance']['label'] = t($form_state['field'][$field][$lang]['instance']['label']);
        }

        // Translate the field's description on the $form_state.
        if (!empty($form_state['field'][$field][$lang]['instance']['description'])) {
          $form_state['field'][$field][$lang]['instance']['description'] = t($form_state['field'][$field][$lang]['instance']['description']);
        }

        // Translate the field title.
        if (!empty($form[$field][$lang]['#title'])) {
          $form[$field][$lang]['#title'] = t($form[$field][$lang]['#title']);
        }

        // Translate the field description.
        if (!empty($form[$field][$lang]['#description'])) {
          $form[$field][$lang]['#description'] = t($form[$field][$lang]['#description']);
        }

        // Translate the meta data on any instances on the field.
        foreach(element_children($form[$field][$lang]) as $instance) {

          // Translate the field's instance descripion.
          if (!empty($form[$field][$lang][$instance]['#description'])) {
            $form[$field][$lang][$instance]['#description'] = t($form[$field][$lang][$instance]['#description']);
          }

          // Translate the field's instance value descripion.
          if (!empty($form[$field][$lang][$instance]['value']['#description'])) {
            $form[$field][$lang][$instance]['value']['#description'] = t($form[$field][$lang][$instance]['value']['#description']);
          }

          // Translate the field's instance title.
          if (!empty($form[$field][$lang][$instance]['#title'])) {
            $form[$field][$lang][$instance]['#title'] = t($form[$field][$lang][$instance]['#title']);
          }

          // Translate the field's instance value title.
          if (!empty($form[$field][$lang][$instance]['value']['#title'])) {
            $form[$field][$lang][$instance]['value']['#title'] = t($form[$field][$lang][$instance]['value']['#title']);
          }

        }
      }
    }
    //kpr($form_state);
    //kpr($form);
  }
}
mohammadjolani’s picture

Thanks for all and specially fo jwilson3
I altered the code above to accept all types of fields
see my code below.


// Translate the meta data on any instances on the field.
foreach (element_children($form[$field][$lang]) as $instance) {
  /*
   * This foreach add by Mohammad Jolani
   * This will handel another fields types like email 
   */
  foreach (element_children($form[$field][$lang][$instance]) as $subInstance) {
	$form[$field][$lang][$instance][$subInstance]['#title'] = t($form[$field][$lang][$instance][$subInstance]['#title']);
  }
zuernBernhard’s picture

Issue summary: View changes

So that is still not in the Module Code on Drupal.org ? I'm on the latest DEV-Release for Drupal 7. But I also had to write my own form_alter to get translatet field labels :(

function np_post_feature_form_views_form_moderate_posts_page_alter(&$form, &$form_state, $form_id) {
    if (isset($form['tokens'])) {
        unset($form['tokens']);
    }

    $instance = field_info_instance('node', 'field_1st_stage_approval', 'post');
    $form['bundle_post']['show_value']['field_1st_stage_approval']['#title'] = i18n_field_translate_property(
        $instance,
        'label'
    );

    $instance = field_info_instance('node', 'field_2nd_stage_approval', 'post');
    $form['bundle_post']['show_value']['field_2nd_stage_approval']['#title'] = i18n_field_translate_property(
        $instance,
        'label'
    );
}
RAWDESK’s picture

2018 and it's still an issues on 7.58
I have added 4 custom fields to admin/config/people/accounts/fields
with an English label on a Dutch default language site.
In my via Features exported DS settings ( myfeature.features.field_instance.inc ), I am locating this :

'ds_extras_field_template' => 'theme_field',
    'entity_type' => 'user',
    'field_name' => 'field_name',
    'label' => 'Last name',
    'required' => 1,
    'settings' => array(
      'linkit' => array(
        'enable' => 0,
        'insert_plugin' => '',
      ),
      'text_processing' => 0,
      'user_register_form' => 1,

where label 'Last name' is not wrapped by t() function.
Setting this wrapping translation and reverting the feature did not solve the issue on our case.

Instead, I also had to implement a hook_form_alter() as shown below :

 $form['field_name']['und'][0]['value']['#title'] = t($form['field_name']['und']['#title']);
  $form['field_firstname']['und'][0]['value']['#title'] = t($form['field_firstname']['und']['#title']);
  $form['field_gender']['und']['#title'] = t($form['field_gender']['und']['#title']);
  $form['field_gender']['und']['M']['#title'] = t($form['field_gender']['und']['#options']['M']);
  $form['field_gender']['und']['F']['#title'] = t($form['field_gender']['und']['#options']['F']);
  $form['field_birth_day']['und'][0]['value']['date']['#title'] = t($form['field_birth_day']['und']['#title']);

Each field type (text, date, select) has his own way of rendering a label or #title in this hook implementation making it time consuming to find the right translation override.
That said, I hope Drupal 8 will bring more relieve in overall translation transparancy.