Add a "translatable" column to Manage Fields

I'll trade you a machine name column :-)

Regarding #1, see #1831890: Don't show "Machine name" in entity listings (as there's also some pushback on trying to remove machine names from admin overviews).

Adding steps as per point #1

Enable the Entity Translation module. To know more about how to us the entity translations, you can visit the help page [/admin/help/translation_entity]. You can reach help page by clicking on Help link next to the Entity Translation module on Extend page or by visting the help page.

To enable Entity translations for a content type Goto (Taking article content type as an example) -

1. Goto Structure->Content types (/admin/structure/types)
2. Click Edit against the name of the content type for which you want to enable tranlation (/admin/structure/types/manage/article)
3. At the end of the form open up Language settings. Under Translation, tick the checkbox Enable transation.
4. Click Save and translation should be enable for your content type. To confirm click on edit again and then on Manage fields tab (/admin/structure/types/manage/article/fields). You should see non-editable translation field available. See screenshot 1
5. Once you have enable the translation for the content type, you need to enable each field.
6. To enable for body field, click on edit next to body field (in manage fields tab).
7. Go to bottom of the form, expand global settings and tick checkbox under field translation. See screenshot 2. Click Save

You should now be all set with your content type.

Assigning to self. Tentatively will add something here in a day or two

I managed to implement this. Though there are still things to do, I would appreciate review comments

Thanks for the patch!

- I think it may be better to say "Translatable" and "Yes/No" as values. The "Translation" header sounds possibly misleading to me.

- The column should be before the Operations column.

- I'm not 100% sure this should be in translation_entity.module, because *theoretically* other modules could enable and implement field translation workflows, but in practice that is probably not going to happen, so it looks good where it is.

Concrete code feedback:

+++ b/core/modules/translation_entity/translation_entity.moduleundefined
@@ -573,6 +573,23 @@ function translation_entity_field_extra_fields() {
 /**
  * Implements hook_form_FORM_ID_alter().
  */
+function translation_entity_form_field_ui_field_overview_form_alter(array &$form, array &$form_state, $form_id) {

Maybe add an extra line of comment of what is going on, something like:

Adds translation column to field overview forms.

+++ b/core/modules/translation_entity/translation_entity.moduleundefined
@@ -573,6 +573,23 @@ function translation_entity_field_extra_fields() {
+      'label' => array(

Not indented enough (add 2 spaces).

+++ b/core/modules/translation_entity/translation_entity.moduleundefined
@@ -573,6 +573,23 @@ function translation_entity_field_extra_fields() {
+            '#markup' => $field_data['translatable'] ? t('Enabled') : t('Disabled'),
+          ));

Indented too much (subctract 4 spaces).

Updated patch with review comments. - Updated comment below

Updated patch with review comments.

1. Changed title of the column from translation to Translatable
2. Changed data of the column to show "yes" if translation is enabled for the module. For fields not enabled, we don't show anything
3. Move the Translatable column to before operations column.

Adding interdiff between patch #6 and #10

I would sugget to hide the column if the translation is not enabled on the edit content type form. If none of the fields are enabled, i think it would be good to show the translation column to show that it is enabled on the content type page, but not for fields. Does that make sense?

Can you guide me through on writing these tests.

I agree with #16, if the entity type has translation enabled but not any of the fields it would still make sense to show this information, so the user knows to enable something :) Not sure if the best representation of that state is the empty Translatable column.

(Also restoring tag).

Updated all review comments from #12

Yes @YesCT.

Performed some minor adjustment. Setting to needs work since this still needs tests.

+++ b/core/modules/translation_entity/translation_entity.module
@@ -602,6 +602,36 @@ function translation_entity_form_field_ui_field_overview_form_alter(array &$form
+  $form['fields']['#header'][] = 'Translatable';

Missing t() call.

+++ b/core/modules/translation_entity/translation_entity.module
@@ -602,6 +602,36 @@ function translation_entity_form_field_ui_field_overview_form_alter(array &$form
+      $field_data = field_info_field($value);

Usually the variable holding the value returned by field_info_field() is called $field.

+++ b/core/modules/translation_entity/translation_entity.module
@@ -602,6 +602,36 @@ function translation_entity_form_field_ui_field_overview_form_alter(array &$form
+      $form['fields'][$value]['Translatable'] = array(

The capitalized T here is misleading: it's not immediately clear we are dealing with a key.

I would suggest tooltips, since we are short on real-estate and may be other modules might also want to extend and add their own fields? Let me know and I will patch it.

Thanks @YesCT. Going through the links and hopefully will update a patch soon.

@YesCT: The edit link already leads to a page where you can enable translatability (and edit all other properties displayed in the table). I'd not make the translation one special, all others are edited there, so the edit link should suffice. So those that do not have translation enabled could either say No or be empty. It might be easier to spot the Yes-es, if there are no No-s :) I don't know.

+++ b/core/modules/translation_entity/translation_entity.moduleundefined
@@ -572,6 +572,35 @@ function translation_entity_field_extra_fields() {
+    if ($value != '_add_new_field') {

You'll need to find another way to make sure you're looking at a Field API row, because there's also the '_add_existing_field' row (or whatever key, don't know it by heart right now) and extra fields that can be on this screen as well. Contrib can add here too (like field_group). I suggest looking at the #row_type which should be on $form['fields'][$field_name']['#row_type']. The value for a field instance will be 'field', all other rows get another value there.

Additionally, you'll have to check the colspan's too if you're only adding the translation row in there - unless you always add no matter what, but even then you'll have to make sure the table doesn't break.

+++ b/core/modules/translation_entity/translation_entity.moduleundefined
@@ -572,6 +572,35 @@ function translation_entity_field_extra_fields() {
+  foreach (element_children($form['fields']) as $field => $value) {

Use $field_name instead of $value to be consistent with core.

Updated patch to include the following -

1. Added code to check if the translation is enabled on entity bundle. If not we do not add the Translatable column from the Manage fields page
2. Added code to check if a field supports translation. If not we show "n/a"
3. Added invisible tags around text

Need some help in checking if a particular field supports translation. Currently I am trying to use the function field_is_translatable(), but this only check the same thing that we set on the edit field tab. So I guess this is incorrect. What we want to achieve here is to put in a check to see if a fields supports translations, if yes and translations are not enabled, we show "blank column", if enabled we show "Yes" and not supported we show "n/a".

Another workaround could be that we use the $form['#extras'] as non translatable based on the assumption that "properties" are not translatable. and all fields are. Any pointers?

Screenshot of Changes done...

Fixed code review errors.

And another stab at the coding standards....Phew, having a bad day today!!!

Currently working on fixing comment http://drupal.org/node/1833104#comment-6756420

Also fixing

1. Manage Comments tab
2. Manage fields tab on vocab

Fixed

1. Review comment from comment http://drupal.org/node/1833104#comment-6756420
2. Manage comments tab. To test you will need to enable translation first
3. Manage fields tab on vocab. To test you will need to enable translation first

Changing to needs review to trigger tests.

Adding tags again

nagwani : nice! Only one left over piece of code that can go away:

+++ b/core/modules/translation_entity/translation_entity.moduleundefined
@@ -572,6 +572,66 @@ function translation_entity_field_extra_fields() {
+  $non_translatable_fields = $form['#extra'];

This can go away.

Updated patch including tests for content type, comment, vocabulary, user. Fixed comment # http://drupal.org/node/1833104#comment-6770520

Currently the tests that are pending are the ones to check for the field not being displayed if translation is disabled on entity level.

Screenshots for all pages attached.

Updated patch. Fixed a bug where in it was showing Translatable Yes even when it was not.

Added tests for n/a, Yes, not enabled.

Added tests for n/a, Yes, not enabled.

Fail tests. These are suppose to fail

Change status to trigger tests.

Fail patch.

Fixed review comments from comment #49. Added check for n/a fields.

Setting to needs review to trigger tests

Great work on this so far! I have a few suggestions for organizing the tests, which I discussed with @nagwani and @YesCT in IRC.

1. +++ b/core/modules/comment/lib/Drupal/comment/Tests/CommentTranslationUITest.phpundefined
   @@ -24,7 +24,7 @@ class CommentTranslationUITest extends EntityTranslationUITest {
   -  public static $modules = array('language', 'translation_entity', 'node', 'comment');
   +  public static $modules = array('language', 'translation_entity', 'node', 'comment', 'field', 'field_ui');
   

   Rather than adding additional modules that will be installed in all these tests, I'd suggest adding the methods to a new class, perhaps (e.g.) CommentTranslationFieldUITest. However, I need to check what's in EntityTranslationUITest. Any test methods on that class will also be run for the child class, so it's either misnamed, or intended to repeat certain tests for all the classes that extend it.

2. +++ b/core/modules/comment/lib/Drupal/comment/Tests/CommentTranslationUITest.phpundefined
   @@ -112,4 +112,68 @@ function testTranslateLinkCommentAdminPage() {
   +  function testEnabledTranslatableColumnManageFieldsTab() {
   ...
   +  function testEnabledFieldTranslatableColumnManageFieldsTab() {
   ...
   +  function testDisabledFieldTranslatableColumnManageFieldsTab() {
   ...
   +  function testNonTranslatableFieldTranslatableColumnManageFieldsTab() {
   

   Each test method installs a new copy of Drupal, so it would be a good idea to merge these where possible rather than having a separate method for every GET request. (It's a matter of balancing manageable tests with performance, of course.)

3. +++ b/core/modules/comment/lib/Drupal/comment/Tests/CommentTranslationUITest.phpundefined
   @@ -112,4 +112,68 @@ function testTranslateLinkCommentAdminPage() {
   +    $this->admin_user = $this->drupalCreateUser(array('administer content types', 'access administration pages', 'access content overview', 'administer nodes', 'bypass node access'));
   +    $this->drupalLogin($this->admin_user);
   

   Since this is repeated in every method, I'd suggest moving the creation of this user to a setUp() method.

4. +++ b/core/modules/node/lib/Drupal/node/Tests/NodeTranslationUITest.phpundefined
   index ba9c152..f796dde 100644
   --- a/core/modules/taxonomy/lib/Drupal/taxonomy/Tests/TermTranslationUITest.php
   
   +++ b/core/modules/taxonomy/lib/Drupal/taxonomy/Tests/TermTranslationUITest.phpundefined
   @@ -139,4 +139,68 @@ function testTranslateLinkVocabularyAdminPage() {
   +   * Tests Yes in Translatable column on manage fields tab for a translatable field.
   +   * Also test the invisible words included for screen readers
   

   The one-line summary should generally have a blank line between it and any subsequent paragraphs. (However, in this case, we probably want to move some of this text to inline comments.

5. Finally, it looks like some of the test methods are repeated for each entity type, with just the entity paths changed? Maybe we could refactor these into helper methods in (e.g.) an EntityFieldTranslationUITestBase or such.

I looked in EntityTranslationTest and it has several of its own test methods, none of which use any entity-related protected test class member properties that I could see. Unless there is a specific reason to run these test methods five or six times, other test classes should not be extending this class. (This was not introduced with this patch, but is potentially a bug we should keep in mind when adding new tests.) Edit: I'll double-check this when I'm less asleep and file a related issue if appropriate.

@xjm: this issue deals with tests extending *EntityTranslationUITest* not *EntityTranslationTest*. The UI test only has one test common method (testTranslationUI()) and is heavily dependent on the entity type being tested. I think this might be a misunderstanding :)

...slightly better issue title. Thanx for working on this guys.

Will post updated test patch soon. Have been out for some time now.

This feels like a pretty bad idea. I mean, the form is already super crowded - its not a "linked" setting and we don't do this for other settings in fields They are all trown under instance/widget settings - why is multilingual different? I don't see this working on anything but really wide screens.

99% of the sites I've built are multilingual. Most of these in two languages and quite a few in three. One of the repeated tasks I go through each time in order to ensure a content type is fully translatable is to check each and every field's multilingual settings. This leads to an endless back 'n' forth that is really tedious and nerve-breaking. As I add and rearrange fields to content types I need to go back and check their translatability. So, I either need to memorize the fields that are already translatable or to take notes as I do things. A total waste of time now that I know that this addition discussed here has a chance of being implemented.

I hope this answers the "why is multilingual different?" question. As for the "I don't see this working on anything but really wide screens." comment, let me kindly point you to Responsive table classes for modules and themes. So, thanx to #1276908: Administrative tables are too wide for smaller screens we can wrap the "TRANSLATABLE" column to a RESPONSIVE_PRIORITY_MEDIUM or a RESPONSIVE_PRIORITY_LOW class that will take care of hiding it when the table is displayed in smaller screens. No reason to not implement this then I guess.

Klonos: the patch at #1810386: Create workflow to setup multilingual for entity types, bundles and fields has a much better overview, even across all entity types.

So overall looks like the work here will not have a good chance to get in, however users will get an even better (and actionable) overview in #1810386: Create workflow to setup multilingual for entity types, bundles and fields where they get a UI that they can even use to make changes. So this looks like a duplicate of that one.

@nagwani: I hope you are not discouraged, you did a great job getting this patch through several reviews and improvements. It just turns out there is going to be a better solution. If you want to take on a simpler one for a break, #1869328: Restore simplicity of language list still has a task to resolve weights of items not shown once the list is saved.

Updated issue summary remaining tasks that were done, linked to issue comment number