The locale module doesn't currently provide a way to set nodes' languages in bulk, using the "Update options" form at admin/content/node. Users who want to changes nodes' languages have to do it one node at a time, which is infeasible for large sites.

The attached screenshot illustrates the desired functionality, and the attached patch provides it.

Note: It's my understanding that API changes are no longer being accepted for Drupal 6.x. I tried to provide this functionality as a contributed module, but was told that the module was too simple. The functionality really does belong in core, IMO. However, if updates to 6.x core simply aren't going to be entertained at this point, I'd appreciate it if someone would tag this issue "won't fix", so that I can go back to the CVS administrators and try again.

Thanks,
Andrew.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Andrew Schulman’s picture

Status: Active » Needs review
mokko’s picture

For me on a Drupal 6.14 the patch works. It would be nice to have this in a module, instead of patch.

Andrew Schulman’s picture

Good. Yes, it's been explained to me that D6 core is frozen, so I'm going to be providing this feature in a module soon. I'm also going to submit it as a patch for Views Bulk Operations.

Andrew Schulman’s picture

Version: 6.14 » 8.x-dev

VBO can already do this, so I won't be submitting a patch for that.

The Language assignment module now provides this functionality for Drupal 6, and as soon as I can get to it, for Drupal 7 as well.

For Drupal 8, this option should be added to the core Locale module. Retagging for 8.x-dev.

Gábor Hojtsy’s picture

Status: Needs review » Needs work

The last submitted patch, language_bulk_update.patch, failed testing.

Andrew Schulman’s picture

I'll update this for 8.x and resubmit.

Andrew Schulman’s picture

The "Set language" operations come in four kinds:

  • Operations for nodes
  • Actions for nodes
  • Operations for users
  • Actions for users

Can someone please recommend how I should propose these? As One Big Patch, or one patch for nodes and one for users, or 4 separate patches, etc.? Are some of the above more likely to be of interest than the rest in core?

Thanks,
Andrew.

plach’s picture

Title: bulk "Set language" operations and actions » bulk "Set language" option at admin/content/node

Would the user "Set language" operation change the user language preference? If so I ain't sure this is consistent with the node equivalent operation: they would present exactly the same but they would have different meanings.

However, personally I never had the need to change language preferences en masse, while I had the need to change multiple node languages many times (I have a small custom module for this in my installations :). How would we solve the need to specify the language? In my custom module I have an additional select to choose it, but I ain't sure this is actually what we want in core.

Perhaps we should hear a UX folk on these.

Anyway, maybe we can split this issue in operations and actions patches. Not sure if there is some kind of good practice guidance on this.

Andrew Schulman’s picture

Issue tags: +Usability

Would the user "Set language" operation change the user language preference? If so I ain't sure this is consistent with the node equivalent operation: they would present exactly the same but they would have different meanings.

Yes, that's what the Language Assignment module currently does for users. It's true that the meanings are different, but there's no conflict since they're always presented in different places. But you're right that it might be better to label the user operation "Set language preference".

However, personally I never had the need to change language preferences en masse, while I had the need to change multiple node languages many times (I have a small custom module for this in my installations :).

OK. This suggests that it might be better to split the patch into a node piece and a user piece, since the nodes might be of greater interest. I think the code breaks down a little more naturally that way.

How would we solve the need to specify the language? In my custom module I have an addtiona select to choose it, but I ain't sure this is actually what we wanto in core.

Language Assignment provides a separate "Set language to" operation for each installed language. But it alters the bulk update forms so that they're presented a little more nicely as suboptions of a single "Set language" operation. See the screenshot.

Andrew Schulman’s picture

Title: bulk "Set language" option at admin/content/node » bulk "Set language" operations and actions
Gábor Hojtsy’s picture

I think we should focus on nodes for now. There are some interesting problems there to solve. For example, if you set a node to German and it already is a member of a translation set that has a German node, then that needs to be solved. Also, if you set it to German and it has translated fields in German, how does that work? It will have two different German versions then? These are some very interesting things to consider here.

Gábor Hojtsy’s picture

mo6’s picture

Title: bulk "Set language" option at admin/content/node » bulk "Set language" operations and actions

In the mean while: there's a module for D6/D7: http://drupal.org/project/languageassign

Andrew Schulman’s picture

Yes, that's the module I wrote to provide the "Set language" operations and actions. My hope is to get those integrated into D8, so that there won't be any more need for Language Assignment.

Currently in D7, Language Assignment does the following to change the language of a node:

    // Update node language:
    $node->language = $newlang;
    // Update body language:
    $node->body[$newlang] = $node->body[$oldlang];
    $node->body[$oldlang] = array();

I borrowed this from locale_field_node_form_submit() in locale.module, which has:

      // Handle a possible language change: new language values are inserted,
      // previous ones are deleted.
      if ($field['translatable'] && $previous_language != $node->language) {
        $form_state['values'][$field_name][$node->language] = $node->{$field_name}[$previous_language];
        $form_state['values'][$field_name][$previous_language] = array();
      }

The above code seems to work, but see #1086454: DATA-LOSS: Changing the Language of a node via language assignment deletes the content on the edit page.

I need to think through Gábor's questions in #12.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

sun’s picture

Title: bulk "Set language" operations and actions » Bulk "Set language" operations and actions
Issue summary: View changes

Just ran into this problem after importing lots of content in the wrong language. Coming from a WordPress background, it is weird that it is not possible in Drupal to bulk edit built-in content fields and properties by default.

The simple answer to @Gábor Hojtsy's question in #12 is that the user should get an error message after the bulk operation (without aborting it): The language could not be assigned, because the content has that language assigned already. Everything else would mean a potential data loss. The user will happily deal with it.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

jukka792’s picture

Ran to same problem, no way to change content language as bulk. Imported 400 000 nodes with wrong language :).

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.