I need to create a solution so that my client could translate thousands of products and product display titles in one place.

I decided to create a table view with two columns, one with an english title, and other in other language. Also use editable fields module for fast ajax editing.

The problem is that I can only show field in the current language. How to show entity title field in other language also? Is this possible? Wouldn't it be extreemly useful?


Yes I have the exact same requirement. Also need a bulk translation editor interface. Seems like this ought to be pretty easy to expose to Views, no? I will look into it but any pointers would be appreciated!

Status:Active» Needs review

You should be able to this with entity translation alpha 2 which contains views integration. Do something like this:

Create a new view and add a relationship to the entity translation table (Under relationships). You should now be able to get information about all available translations in the entity translation table.

As for displaying the title in the right language, make sure you use the Title module, and output that field. Views should show the correct language automaticly.

Are you sure? I tried doing this already with ET alpha 2, and it doesn't seem to give me the right info. I add Taxonomy term: Entity translation: translations in the relationships box. Then in my fields box I get these options:

Entity translation: changed
Entity translation: created
"" Entity id
Entity type
Needs update
Translate link
Translation status

None of these appear to actually contain field and language specific translation content. Am I missing something?

Category:feature» support

Please, move this back to feature request if it turns out we need some code written.

I have no idea how to use the Views API, but would it be possible to create a Views row plugin that allows the user to select the language in which to display a field? Then if you wanted to show the value of a field in multiple languages in a view, you could add the field twice, and configure each one for a different language. Definitely need some code written, but perhaps someone who is more familiar with the secrets of Views could help or provide direction.

On closer inspection, it looks like a Views row plugin is not the solution, since it only allows to set configuration for all rows, not for specific rows. Now I'm thinking that to do this probably requires a custom Views field handler for each field type, or a custom field formatter for each field type. Otherwise, I don't see any other places where you can hook in to modify the behavior of all fields, either in the Views side, or in the Fields side...

Version:7.x-1.x-dev» 7.x-1.0-alpha2
Category:support» feature
new17.93 KB

Unbelievably, I seem to have figured it out.

Attached is a module that provides a new field handler that allows you to choose the language in which to display a field. It's just based off the default views_handler_field_field, with very minor changes. To use it, install the module and look for fields ending with ":translated" in the Views "add fields" interface. You can then select the language to use in the field settings.

So far I've just tested it with regular text fields, which thankfully is all I need at the moment, so I'm not sure how many types of fields this will work with. Can somebody take a look and see where this code should live? I'm thinking it should go in entity_translation.

Status:Needs review» Active

No patch here.

Sorry I'm new here. Would you like the code in the module I provided to be patched into Entity Translation, and if so, where should it go? I was hoping to get some review and feedback on my code. I'm not sure I did things the right way and perhaps somebody with more Views know-how could take a look. You are also welcome to take the code and patch it in yourself if you think it looks good. Thanks.

Version:7.x-1.0-alpha2» 7.x-1.x-dev

Sorry for somehow dismissing your efforts, I'll try to be a bit more constructive :)

If you wish to have your code included in the Entity Translation project you need to post a patch here containing the code implementing the feature. This makes my work easier as I can use the proper tool to review the proposed changes. Please understand that this is the standard workflow to contribute to Drupal core and contrib modules.

The patch will need to be rolled against the latest code in the repository so I'm changing the target version.

Also: it would be good to have @fabsor's feedback on the upcoming patch since he's the Views integration maintainer.

Title:Ability to show different languages in views at the same time for fast translationExpose translated field content to Views so that multiple language translations can be shown simultaneously
Status:Active» Needs review
new4.49 KB
PASSED: [[SimpleTest]]: [MySQL] 681 pass(es).
[ View ]

Here's the patch. @fabsor, does this look like the right approach?

Thanks a lot for the patch, I gave a (really) quick look and it seems it has coding standard issues. Before committing it we will have to fix them, however we can wait @fabsor's review before doing that, hence not moving to 'Needs work' yet.

Status:Needs review» Needs work

This seems like a good approach to the problem. It's simple enough and it solves the issue. A more intrusive way of doing it would be overriding the default behavior of the current implementation in views, but I don't think that's a good idea since it could lead to weird issues when moving over to entity translation.

Here's a quick review:

In general: There are a lot of trailing whitespace. You can usualĺy configure your editor to strip that out. Go over the code and remove any trailing whitespace in it.

+++ b/views/entity_translation.views.incundefined
@@ -224,4 +224,35 @@ function entity_translation_views_data_alter(&$data) {
+  // Expose all translatable fields, using a special default field handler that allows users to select
+  // the language to display the field in:

Make sure comments wrap on 80 chars. I don't think this handler is "special" or "default", just field handler will do as a description.
I also think you should end the comment with a period rather than a colon.

+++ b/views/entity_translation.views.incundefined
@@ -224,4 +224,35 @@ function entity_translation_views_data_alter(&$data) {
+    if ($field['translatable']) {
+      if ($field['storage']['type'] != 'field_sql_storage') {
+        continue;

This could be combined into one check instead of two separate if statements.

+++ b/views/entity_translation.views.incundefined
@@ -224,4 +224,35 @@ function entity_translation_views_data_alter(&$data) {
+      $defaults = field_views_field_default_views_data($field);

We get the defaults for all fields from here, which is good, but we might want to change the group to "Field translations" or something like that, so we don't add a lot of extra fields under Content. There can be a lot of fields in there already, and we probably don't want to add more of them. This particular fields should only be used when you really want to select a particular translation of a field so I think it makes sense to move them away from the normal category to not confuse other users.

+++ b/views/entity_translation.views.incundefined
@@ -224,4 +224,35 @@ function entity_translation_views_data_alter(&$data) {
+          $field_title = $table_data[$field['field_name']]['title'];
+          ¶
+          // Set defaults and just change the handler, title, and help

Move this comment to the top of this code block, it's partly about setting the title, which is done above it. End the comment with a period.

+++ b/views/entity_translation.views.incundefined
@@ -224,4 +224,35 @@ function entity_translation_views_data_alter(&$data) {

Make sure to add a new line at the end of the file.

+++ b/views/entity_translation_handler_field_field.incundefined
@@ -0,0 +1,66 @@
+class entity_translation_views_handler_field_field extends views_handler_field_field {

This class is misnamed. It should have the same name as the file, entity_translation_handler_field_field. This makes the fields show up as "Broken handlers" when you add them in views.

+++ b/views/entity_translation_handler_field_field.incundefined
@@ -0,0 +1,66 @@
+   * Overrides parent::field_language, retrieving the language from the handler options

Let's end this comment with a period.

+++ b/views/entity_translation_handler_field_field.incundefined
@@ -0,0 +1,66 @@

Missing a newline here as well.

Status:Needs work» Needs review
new4.39 KB
PASSED: [[SimpleTest]]: [MySQL] 681 pass(es).
[ View ]

Actually I thought the ideal approach would be to override the default behavior of existing Views field handlers, since, ideally, users shouldn't have to select a special field to display in a specified language, they should just be able to choose the language for existing fields, or default to the View's global setting. The only reason I did it this way is because I couldn't find anywhere to hook into Views without entirely taking over the process with my own custom handler. And I still don't know how many types of fields this patch works for.

Anyway, here is the fixed patch, I think I got everything you brought up. I just set the group to 'Entity translation' since I figure that's consistent with what you already have.

Status:Needs review» Reviewed & tested by the community

This looks all good to me now, great work!

From a first look I am not completely satisfied with a couple of details, I'll have a closer look later and see if I can fix them on commit or whether this will need a last reroll.

Assigned:Unassigned» plach

Assigning to @plach based on #17.

thank you, patch works great! I am able to do exactly that what I was describing in the first comment now :) handy feature.

Status:Needs work» Reviewed & tested by the community

Patch #1605406-15: Expose translated field content to Views so that multiple language translations can be shown simultaneously doesn't work for me for fields of file.
I get each fields with same language whatever language I choose with the language selector or "field language" views option.
I don't know if it related but I use Chaos tools 7.x-1.1 due to title block translation issues.

Status:Reviewed & tested by the community» Needs work

Change status

Assigned:plach» Unassigned
Status:Reviewed & tested by the community» Needs work

For people like me who needs this patch on beta2, here is a patch that works with it...

No luck for me with this patch. The new fields with the extension :translated are exposed correctly, they appear in the list of available fields under the Entity translation filter as expected. But when I try to add to the view any of them, it shows me an ajax parse error from the new defined entity_translation_handler_field_field.
I have no time just now to debug it, I will try it in the next days, but it seems that the patch is not ready yet to be committed.

I am using the latest Views 7.x-3.x-dev and Entity Translation 7.x-1.x-beta3.

This feature would be hugely useful for administrators/translator of multi-language sites, since it would allow us developers to build really powerful views for their work.


I installed the Entity Translation module to be used with the Translation Management module and I keep getting the following error:

"Notice: Undefined index: base table in entity_translation_views_data_alter() (line 207 of /my/server/.../sites/all/modules/entity_translation/views/entity_translation.views.inc)."

I realize that the most recent patch in this post will help me, but my hosting is through godaddy and as this site is in development I am using their shared hosting account and they don't have the "patch" command enabled at the SSH command line interface.

If anyone is familiar with the issue and has successfully patched their version of the module, would it be possible to get a zipped copy of the updated module?

I will also be contacting the module developer.

Many Thanks,

- Nick

Issue summary:View changes

Patch #23 works for me
Views 7.x-3.7
Entity translation 7.x-1.x-dev (2014-Jan-22)

After adding a patch I am able to output field 'Entity translation: Body' with manually setting up a language for each output.

Thanks, the feature is greatly appreciated.