Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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?
Comments
Comment #1
joelrosen CreditAttribution: joelrosen commentedYes 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!
Comment #2
fabsor CreditAttribution: fabsor commentedYou 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.
Comment #3
joelrosen CreditAttribution: joelrosen commentedAre 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?
Comment #4
plachPlease, move this back to feature request if it turns out we need some code written.
Comment #5
joelrosen CreditAttribution: joelrosen commentedI 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.
Comment #6
joelrosen CreditAttribution: joelrosen commentedOn 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...
Comment #7
joelrosen CreditAttribution: joelrosen commentedUnbelievably, 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.
Comment #8
plachNo patch here.
Comment #9
joelrosen CreditAttribution: joelrosen commentedSorry 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.
Comment #10
plachSorry 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.
Comment #11
plachAlso: it would be good to have @fabsor's feedback on the upcoming patch since he's the Views integration maintainer.
Comment #12
joelrosen CreditAttribution: joelrosen commentedHere's the patch. @fabsor, does this look like the right approach?
Comment #13
plachThanks 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.
Comment #14
fabsor CreditAttribution: fabsor commentedThis 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.
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.
This could be combined into one check instead of two separate if statements.
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.
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.
Make sure to add a new line at the end of the file.
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.
Let's end this comment with a period.
Missing a newline here as well.
Comment #15
joelrosen CreditAttribution: joelrosen commentedActually 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.
Comment #16
fabsor CreditAttribution: fabsor commentedThis looks all good to me now, great work!
Comment #17
plachFrom 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.
Comment #18
bforchhammer CreditAttribution: bforchhammer commentedAssigning to @plach based on #17.
Comment #19
mindaugasd CreditAttribution: mindaugasd commentedthank you, patch works great! I am able to do exactly that what I was describing in the first comment now :) handy feature.
Comment #20
rondev CreditAttribution: rondev commentedPatch #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.
Comment #21
rondev CreditAttribution: rondev commentedChange status
Comment #22
plachComment #23
guillaumev CreditAttribution: guillaumev commentedFor people like me who needs this patch on beta2, here is a patch that works with it...
Comment #24
interdruper CreditAttribution: interdruper commentedNo 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.
Comment #25
Anid4u2c CreditAttribution: Anid4u2c commentedHi,
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
Comment #26
capnut CreditAttribution: capnut commentedPatch #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.
Comment #27
Jose Reyero CreditAttribution: Jose Reyero commentedAfter 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.
Comment #29
plachThe details...
Comment not wrapping at column 80.
Surplus blank lines.
ET depends on Locale so this check is redundant.
Comment #31
paulihuhtiniemi CreditAttribution: paulihuhtiniemi commentedI updated the patch based on comments in #29.
Comment #32
paulihuhtiniemi CreditAttribution: paulihuhtiniemi commentedStill doesn't apply cleanly :(
[edit] This was a problem in one of our development environments, patch seems to work at least for me.
Comment #33
paulihuhtiniemi CreditAttribution: paulihuhtiniemi commentedComment #34
plachCan anyone confirm #32 is still working as intended? I am happy to commit it once it's RTBC.
Comment #35
Jose Reyero CreditAttribution: Jose Reyero commentedI 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).
Comment #36
plachOk, thanks. I will commit this later today.
Comment #38
plachCommitted and pushed, thanks!
(Sorry for blocking this for so long)