Field translation
This field is shared among the entity translations. Enable translation

#6 entity_translation-field_translation_process_drush-1800530-6.patch3.64 KBpvhee
PASSED: [[SimpleTest]]: [MySQL] 721 pass(es). View
#1 1800530-1-ET-drush-commands.patch3.94 KBdrzraf
PASSED: [[SimpleTest]]: [MySQL] 681 pass(es). View
Members fund testing for the Drupal project. Drupal Association Learn more


drzraf’s picture

3.94 KB
PASSED: [[SimpleTest]]: [MySQL] 681 pass(es). View

this is a stub for this and #1800158: Entity Translation Upgrade, drush extension..
This does not work, for a reason or another.
Tricking forms could be painful. Let's hope someone could jump into this.

plach’s picture

Component: Node translation upgrade » Base system
Status: Active » Needs review
drzraf’s picture

This is really a stub, it uses the form API upon which ET admin is built.
So these drush commands correctly register batches, but I don't know the right way to trigger them, either automatically or manually from drush. Neither I know how to grab the output continuously in order to give a feedback about the running process.

drzraf’s picture

Status: Needs review » Needs work

the patch needs love from someone who knows how to trigger batches from drush.

Owen Barton’s picture

Triggering batches from Drush is pretty straightforward - just set your batch as usual (via the form, or directly based on command args), then call drush_backend_batch_process(); which will process it in batches, using a separate process for each (even on the CLI, memory can be an issue with long running processes).

For details see: and

pvhee’s picture

Issue summary: View changes
3.64 KB
PASSED: [[SimpleTest]]: [MySQL] 721 pass(es). View

I wrote a patch from scratch to address the same issue: use drush to enable field translation for a given field.

My use case is the following: we enable field translation for a given field, and we make the changes in the exported field settings. When we deploy these changes, the field translation changes are changed but the data is not processed. We'd use the given drush command to process these field changes.

The patch does the following:

  • Refactor the entity_translation_translatable_form_submit function by removing the form logic from the batch setup. The batch setup now lives in the new function entity_translation_translatable_batch_setup. It also cleans up some unlogical use of the "translatable" parameter which is used reversed in the form submit function
  • Create a new drush command "entity-translation-process-field-translation" that takes as parameter the machine name of the field for which to process field translations.

Usage of the drush command:
drush entity-translation-process-field-translation field_name
with "field_name" replaced with your field machine name.

pvhee’s picture

Status: Needs work » Needs review

Setting to needs review.

eelkeblok’s picture

Status: Needs review » Needs work

While doing my own custom drush work I ran into a memory usage issue. The reason seems to be that drush will run all batch operations in a single run, and the enity_load static cache will blow up the memory usage of the process. This is no issue for the existing usage of the function as the regular Batch API will do many http requests. Mostly since I only found this issue just now, but also because it might be useful for others doing their own custom drush work, I've created a separate issue for this. However, I would say that for this issue to make it into the module, that one is quite essential as well. #2709211: Make entity_translation_translatable_batch() more drush friendly.

FWIW, I think the patches in this issues do not take into account the scenario where the field will already be configured to be translatable (e.g. through Features), but still need to have their content migrated. I'd say this patch would become a lot more useful if it allows for that scenario as well (this is the scenario I've been working on).