Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Problem/Motivation
Entity Translation does not play well with the i18n_taxonomy
module of the Internationalization suite. There are lots of conflicts both at UI and API level, because both modules try to handle the translation process, with hugely different approaches.
Proposed resolution
- Define a 5th option in the vocabulary translation settings, explicitly enabling ET for that particular bundle. This way ET will not touch terms that are meant to be translated via i18n.
- Even when i18n_taxonomy is not enabled allow to enable ET per vocabulary similarly to what we do for content types.
Remaining tasks
None
User interface changes
API changes
None
Data model changes
None
Comment | File | Size | Author |
---|---|---|---|
#30 | et-i18n_taxonomy-1661348-30.patch | 11.64 KB | plach |
| |||
#30 | et-i18n_taxonomy-1661348-30.interdiff.txt | 4.51 KB | plach |
#11 | Tags___Drupal_7_x.png | 149.8 KB | plach |
Comments
Comment #1
plachWe need a far better integration with i18n_taxonomy, which right now is really confusing and not really working well. Attached there is a first stab at ensuring that at least the i18n_taxonomy and ET translation for taxonomy can work together.
We need an option in the vocabulary settings specifying that ET translation is enabled for that particular vocabulary.
Comment #2
plachComment #3
plachCommitted and pushed #1. Back to active.
Comment #4
bforchhammer CreditAttribution: bforchhammer commentedComment #5
plachI think we should simply define a 5th option in the vocabulary translation settings, explictly enabling ET for that particular bundle (we need to add a bundle callback for taxonomy).
Comment #6
mvdve CreditAttribution: mvdve commentedI agree. It would be amazing to have the same functionality as the node entity translations.
This would make the functionality generic and much easy-er to understand.
So an fifth option in the translation settings of the taxonomy vocabulary should be the best option.
This makes the import (with feeds) of multilingual taxonomy terms possible. You have to make a lot of custom functionality to make this happen now.
If I can help in any way, let me know.
Comment #9
plachThis seems to be working correctly.
Comment #10
plachWe should probably add an update function.
Comment #11
plachHere is a screenshot:
Comment #13
plachSlightly better patch.
Comment #14
plachComment #15
blacksnipeI've tried both patches in #9 and #13. Here's my feedback:
When I leave the checkbox (not like the screenshot?) unchecked, it doesn't do a thing - works as expected.
But if I check it for a taxonomy, it gets my records in the entity_translation-table deleted whenever I try to save an edit!
Comment #16
plachAre you sure you are not experiencing #2396103: [DATA LOSS] Translations deleted?
Comment #17
gonssalSo, I got to that point where you have a perfectly working translated taxonomy tree in a vocabulary, and then you have to edit the vocabulary, so all your default language terms are reset to 'und' language. It's so much enjoyable and fun. This breaks the entity translation, if I'm not mistaken, due to this in the entity_translation table:
Also the 'language' column in the 'taxonomy_term_data' is set to 'und'.
This effectively breaks all the translations because their source language is no longer present. Apart from that, the Translate tab doesn't appear on the terms edit page (I guess it's because the term language is also set to 'und'), so you can't delete the translations. Even if you try to delete them by using "taxonomy/term/[tid]/translate/delete/[langcode]", it won't work. So basically everything breaks. The only what to get it "fixed" is executing
UPDATE `taxonomy_term_data` SET `language` = 'en'
, where 'en' will be your site's default language. Even if you uncheck the "Hide language selector" and the "Exclude Language neutral from the available languages" options in the ET settings for the taxonomy term, it won't let you change the 'und' language because it gets one of the "orphan" translations instead of the 'und' entry.I applied the patch on beta3 and got the following error:
I checked anyways and the new "Field translation. Term fields will be translated through the Entity translation module." option appeared, was selectable and it sucessfully saved the new setting. Sadly, nothing changed and my taxonomies were still "stuck".
I then updated to -dev, ran update.php and reapplied the patch. The new "Field translation..." option is not there now.
If I'm not mistaken, I think all of this mess would be resolved by fixing the #2366585: Saving a vocabulary resets all terms to LANGUAGE_NONE issue, and not the other way arround as you commented in there. I might be wrong though.
Comment #18
plachWell, the idea is that this patch (that should be applied to the latest -dev) would prevent you from configuring your site in a way that triggers #2366585: Saving a vocabulary resets all terms to LANGUAGE_NONE. It can do nothing to recover data, sorry.
Comment #19
gonssalSo what happens when a user switches from Drupal's content translation to entity translation? I mean, there's even a migration submodule in ET that provides an "upgrade path".
Also, as I noted, even after applying the patch to the -dev version, the "Field translation. Term fields will be translated through the Entity translation module." option isn't appearing for me.
Don't get me wrong, I'm fine with looking at code, applying patches and running SQL queries, but I'm sure there's people getting crazy trying to understand what's happening with their taxonomy right now.
Comment #20
Nchase CreditAttribution: Nchase commentedapplied the patch from #16 gave me two problems:
1. all Tag titles / descriptions were empty (using title module)
2. Views doesn't recognize the language selection (relationship + entity translation filter)
Comment #21
Nchase CreditAttribution: Nchase commentedviews does recognize the language selection but when I configure a taxonomy view to display the taxonomy term names of a vocab I get the terms in the original language but the links to the translated language.
I don't know if this is a entity translation or a views problem.
Comment #22
colanI tried turning i18n_taxonomy on, off, uninstalling it. No matter what I do, I always hit the following:
Maybe it needs to be re-rolled?
Comment #23
colanYup, this method was already defined in #2203801: Impossible to update taxonomy term after enabling i18n_taxonomy which was committed a month after #13 was written.
Comment #24
plachComment #25
badrange CreditAttribution: badrange at Wunder commentedAttached is an updated patch that is created from 7.x-1.x that takes colan's comment into account. I hope it makes sense. What I did was remove the getLanguage() function call from the patch, and add the new I18N_MODE_ENTITY_TRANSLATION to the translation mode check that should trigger entity translation for the term entities.
Note: without the new
if ($mode == I18N_MODE_NONE || $mode == I18N_MODE_ENTITY_TRANSLATION ) {
the data in the terms name_field and description_fields was deleted.
Comment #26
badrange CreditAttribution: badrange at Wunder commentedAttaching interdiff and a new version of the patch, seems like I messed up when creating it.
Comment #27
badrange CreditAttribution: badrange at Wunder commentedComment #28
badrange CreditAttribution: badrange at Wunder commentedOh how could I upload a patch with .txt ending AND no newline at the end of the file. Such unprofessional.
Comment #29
candelas CreditAttribution: candelas as a volunteer commentedHello
Since this issue is a blocker for Entity Translation 1.0 https://www.drupal.org/node/1624830 and now plach is working on this, please, test. Also, Entity Translation is asking for a coo-maintainer. I wish I had the knowledge to apply since it is a great opportunity to learn from a senior developer...
I have test in a new demo Commerce Kickstart 7.x-2.37 installation. When I installed, I selected that it will be translatable. Steps I made:
I have tried also in a customized Commerce Kickstart and it works. I have this modules enabled (they are related for translation): hreflang, languageicons, i18n_block, i18n_contact, i18n_field, i18n, i18n_menu, i18n_path, rules_i18n, i18n_string, i18n_redirect, i18n_translation, i18n_user, i18n_variable and i18nviews. So no incompatibilities with them.
Have a good weekend!
EDIT: I forgot to say that in the customized CK, I had to re-make the taxonomy translatable in its edit form. Also in the customized one, I tested the different options that are in the Entity Translation form, as "Exclude Language neutral from the available languages", and they work without problems.
Comment #30
plachI tested #28 plus some small additions you can see in the interdiff and it seems to be working well and allowing to configure different vocabularies with different translation modes (ET, i18n, none).
The patch also provides an upgrade path, since now translation needs to be explicitly enabled for each vocabulary requiring entity translation. Be sure to backup your site before testing this.
I'd like to commit this on -dev ASAP, unless there are major flaws with it, so we can start widening the testing user base.
Comment #32
plachOk, committed and pushed.
Thank you all for your help! If you find problems please file new issues and reference them from here.
Comment #33
plachComment #35
Triumphent CreditAttribution: Triumphent commentedLast patch works well for me. Thanks. :)
Comment #36
adam1 CreditAttribution: adam1 commentedDespite I installed the newest dev version of the module (where the patch is included already - isn't it?), on some terms I got no translate tab and got the message "access denied" when I tried to edit or delete them. In the vocabulary settings the 'fieldtranslation' setting is enabled.
What's the trick?
Comment #37
webmasternew CreditAttribution: webmasternew commented7.x-1.x-dev
Notice: Undefined index: href in menu_local_tasks() (line 2070 of /var/www/reg_ru/data/www/taxi.lazy.su/includes/menu.inc).
Comment #38
scott shipman CreditAttribution: scott shipman commentedWill this get rolled to a beta6 version soon? Do you have an ETA?
Comment #39
stefanos.petrakis@gmail.com#2849464: Add an API to set active language is gonna trigger a beta release pretty soon, ETA => a few days.