Labels untranslated

I'm not 100% sure on how translations work, but it's wrapped in t() exactly the same as Field Collection.
Perhaps it is related to http://localize.drupal.org/translate/projects/field_collection_table returning a 404?

I'm not sure what to do about this.

Oh, I completely misunderstood. I will try to work on this tomorrow.

Try this, I think I got all of the instances.

Corresponding issue in field_collection: #1246778: Make Add/Edit/Delete links translatable

The patch above has cleanly applied for me and works well.

I'm wondering how we can more completely document the input vs. output of tables that need to be translated throughout the Drupal project.

It turns out this is completely wrong, and only works because those strings happen to be translated already by core. :(
See #1246778-9: Make Add/Edit/Delete links translatable, I'm going to wait for a fix there.

I don't get what the problem is

Why can't a t() be added around the field label in field_collection_table_field_formatter_view()?

like this:

    case 'field_collection_table_view':
      $header = array();
      $field_names = array();
      foreach (field_info_instances('field_collection_item', $field['field_name']) as $field_collection_item) {
        $weight = $field_collection_item['display']['default']['weight'];
        $field_names[$weight] = $field_collection_item['field_name'];
        $header[$weight] = array(
          'data' => t($field_collection_item['label']),
          'class' => $field_names[$weight],
        );
      }

Works fine for me...

From the documentation for t(): http://api.drupal.org/api/drupal/includes--bootstrap.inc/function/t/7

You should never use t() to translate variables, such as calling

<?php t($text); ?>

It should always be the exact string that needs to be translated.

This works, I'm sure it can be done better but as it turns out $content[$field_name]['#title'] has the translated user string as is. So no incorrect usage of t() is needed.

Following the rules of issue priorities of drupal.org I would recommend to use "normal" here since untranslated labels doesn't break anything.

Patch in #10 was giving undefined index errors in PHP 5.3, fix with:
$header[$weight]['data'] = isset($content[$field_name]['#title']) ? $content[$field_name]['#title'] : "" ;

Patch 10 & 12 don't work.

I know that #8 is not the right way but the only solution at the moment?

@adiatis: fyi patches 10 & 12 did work for me

@mathieuhelie - I rewrote your fix a bit, because your patch overwrites the original caption when no translation is defined.

#14 works for me too.

This patch works when you hide empty columns, but when you show them, empty column headers won't get translated.
I wrote a workarround for this (works after applying patch):

//patch code
if (isset($content[$field_name]['#title'])) {
  $header[$weight]['data'] = $content[$field_name]['#title'];  
}
//my code
else{
  global $language;
  $i18n_string = i18n_string_translate(
    array(
      'field', 
      $field_name, 
      $field_collection->field_name,
      'label' ), 
    $header[$weight]['data'], 
    array('langcode' => $language->language));
  $header[$weight]['data'] = $i18n_string;
}

However, I think it wouldn't be right to create a patch for this, because this code is using i18n_string api to get string translation of field label, but this module shouldn't depend on any i18n modules, nor even any translation module. Regardless of this, I put this code so anyone can use this code as a workarround, and some developer can find a better way to fix this issue properly.

#14 worked for me too

+++ b/field_collection_table.moduleundefined
@@ -70,6 +70,9 @@ function field_collection_table_field_formatter_view($entity_type, $entity, $fie
+            $header[$weight]['data'] = $content[$field_name]['#title'];  ¶

contains extra space

i think #17 means this needs works..i use hide empty as well

In addition, this patch does not translate any header (even with my code in #17 :( ) when columns are all empty.

Hi all,

I found this bug also in my projects and I want to commit my patch.

I'm using Internationalization 7.x-1.10, Field Collection 7.x-1.0-beta5+8-dev and Field Collection Table 7.x-1.0-beta1+2-dev.

My project has the following setup:
I have 2 languages enabled. 1 Content Type named "Article". In "Article" fields I have 1 field collection field named "my_field". "my_field" has 1 autocomplete field named "my_field2" that is translated in both language using Internationalization field translation module. The issue appears when I'm selecting table as widget type for "my_field" and is represented by the fact that "my_field2" isn't translated on node add and node edit.

My patch resolves this and because it's my first patch please bear with me and tell me if it works for you also.

Thanks.

#14 worked for me as well

#21 is correct, the field labels on the widget are still not translated.
His patch would only work on a reference field, however.

For a regular textfield, you'd have to target:

      $title = $field[$language][0]['value']['#title'];

So this is not a good fix (yet).

There is i18n module for translating fields - i18n_field. So we should use it in our case.
I attach the patch in PhpStorm format, can somebody adapt it?

Here is the patch in proper format.

Thanks for the patch. It works for me (after clearing the cache).

I've re-rolled the patch against the latest dev. It would be nice to get this committed. Could we get a few more reviews? Thanks.

#30 commited in the latest dev version.

Shouldn't this be committed to the recommended version too? After all it makes the module complete. 95% of the websites we make are in more languages, so does almost every large project.