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?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

joelrosen’s picture

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!

fabsor’s picture

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.

joelrosen’s picture

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
Label
Language
Needs update
Source
Translate link
Translation status

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

plach’s picture

Category: feature » support

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

joelrosen’s picture

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.

joelrosen’s picture

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...

joelrosen’s picture

Version: 7.x-1.x-dev » 7.x-1.0-alpha2
Category: support » feature
FileSize
17.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.

plach’s picture

Status: Needs review » Active

No patch here.

joelrosen’s picture

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.

plach’s picture

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.

plach’s picture

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

joelrosen’s picture

Title: Ability to show different languages in views at the same time for fast translation » Expose translated field content to Views so that multiple language translations can be shown simultaneously
Status: Active » Needs review
FileSize
4.49 KB

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

plach’s picture

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.

fabsor’s picture

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.

joelrosen’s picture

Status: Needs work » Needs review
FileSize
4.39 KB

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.

fabsor’s picture

Status: Needs review » Reviewed & tested by the community

This looks all good to me now, great work!

plach’s picture

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.

bforchhammer’s picture

Assigned: Unassigned » plach

Assigning to @plach based on #17.

mindaugasd’s picture

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

rondev’s picture

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.
Edit:
I don't know if it related but I use Chaos tools 7.x-1.1 due to title block translation issues.

rondev’s picture

Status: Reviewed & tested by the community » Needs work

Change status

plach’s picture

Assigned: plach » Unassigned
Status: Reviewed & tested by the community » Needs work
guillaumev’s picture

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

interdruper’s picture

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.

Anid4u2c’s picture

Hi,

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

capnut’s picture

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.

Jose Reyero’s picture

Status: Needs work » Needs review

After testing with a clean install and a number of field types, included text, number, files and images, I've found the patch in #15 just works.

Also I like the patch implementation as it just adds a new field type that won't break any of the existing views. Thus it won't harm anyone not using the feature.

So I'm wondering:

- @plach (#17) which are that "couple of details"... ?

- @interdruper (#24), still getting that error with latest versions of Drupal/views/et? If so, could you please be more specific about the error you are getting?

- @rondev (#20), cannot reproduce your issue... are you using latest versions of modules and talking about Drupal core field types?

- The issue in #25 seems unrelated to this patch.

It would be nice if we could move this one forward.

plach’s picture

Status: Needs review » Needs work

The details...

  1. +++ b/views/entity_translation.views.inc
    @@ -224,4 +224,32 @@ function entity_translation_views_data_alter(&$data) {
    +  // field handler, that allows users to select the language to display the field in.
    
    +++ b/views/entity_translation_handler_field_field.inc
    @@ -0,0 +1,66 @@
    + * This file contains a field handler for entity translation that shows field content translated into a specified
    ...
    +      // Give the Field Language API a chance to fallback to a different language
    +      // (or LANGUAGE_NONE), in case the field has no data for the selected language.
    +      // field_view_field() does this as well, but since the returned language code
    +      // is used before calling it, the fallback needs to happen explicitly.
    

    Comment not wrapping at column 80.

  2. +++ b/views/entity_translation.views.inc
    @@ -224,4 +224,32 @@ function entity_translation_views_data_alter(&$data) {
    +
    +          $data[$table_name][$field['field_name'] . '_et'] = $table_data[$field['field_name']];
    +
    +        }
    +
    +      }
    +    }
    
    +++ b/views/entity_translation_handler_field_field.inc
    @@ -0,0 +1,66 @@
    +class entity_translation_handler_field_field extends views_handler_field_field {
    +
    +
    +  function option_definition() {
    

    Surplus blank lines.

  3. +++ b/views/entity_translation_handler_field_field.inc
    @@ -0,0 +1,66 @@
    +    if (module_exists('locale')) {
    

    ET depends on Locale so this check is redundant.

paulihuhtiniemi’s picture

paulihuhtiniemi’s picture

Still doesn't apply cleanly :(

[edit] This was a problem in one of our development environments, patch seems to work at least for me.

paulihuhtiniemi’s picture

Status: Needs work » Needs review
plach’s picture

Can anyone confirm #32 is still working as intended? I am happy to commit it once it's RTBC.

Jose Reyero’s picture

I can confirm the patch applies cleanly -trust the testbot- and it works as intended.

This is a simple re-roll fixing also issues 1. (comment indentation) and 2. (blank lines) in @plach #29
(I didn't touch any line of code though).

plach’s picture

Status: Needs review » Reviewed & tested by the community

Ok, thanks. I will commit this later today.

  • plach committed b0905df on 7.x-1.x authored by joelrosen
    Issue #1605406 by joelrosen, Jose Reyero, paulihuhtiniemi, guillaumev |...
plach’s picture

Status: Reviewed & tested by the community » Fixed

Committed and pushed, thanks!

(Sorry for blocking this for so long)

Status: Fixed » Closed (fixed)

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