New Drush command for developers for extracting translations of custom module, theme or profile

Created on 28 April 2024, over 1 year ago
Updated 16 September 2024, about 1 year ago

Problem/Motivation

As a developer I want to extract translations with a simple Drush command for one custom project (module/theme/profile) or all custom projects within a Drupal site setup.

Steps to reproduce

  1. Create a custom module with translatable strings within a multilingual setup.
  2. Extract translations for that module with one easy to use Drush command.
  3. Commit the module with the translations.

Proposed resolution

Port https://gist.github.com/TessBakker/34def66fa3679422dd437005e1d61b78 over to this module

Remaining tasks

  1. Create merge request
  2. Find a solution to display errors in a more readable way
  3. Create test
  4. Fix related issues within parent 🌱 [Plan] Create a new and better Drush Extract Translation Command for developers Active
  5. Merge mr

User interface changes

Feature request
Status

Active

Version

1.0

Component

Code

Created by

🇳🇱Netherlands tess bakker

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @tess bakker
  • First commit to issue fork.
  • Pipeline finished with Success
    about 1 year ago
    Total: 152s
    #284403
  • Status changed to Needs work about 1 year ago
  • Issue was unassigned.
  • Pipeline finished with Success
    about 1 year ago
    Total: 153s
    #285101
  • Pipeline finished with Success
    about 1 year ago
    Total: 173s
    #285118
  • 🇫🇷France johnatas

    Hi,

    Thanks for the work on this!

    Unfortunately, it wasn't fully "plug & play" on my side.
    For context, I'm using Drupal core version 11.2.2 and module version 1.1.0.

    I made a few small adjustments to get things working in my environment.
    Here are the changes I applied:

    • Added a check for $projectName before checking its status → In case it's NULL (e.g., when simply running drush pet), it would otherwise throw an error.
    • Replaced FileSystemInterface::EXISTS_REPLACE with FileExists::Replace → This has been deprecated since Drupal 10.3.0.
    • In my project (maybe due to my config?), the generated file for each module/theme is always named general.pot, regardless of the options passed → So I replaced:
      $translationStoredFile = $translationsDirectory . '/' . $projectKey . '-' . $languageCode . '.po'; with $translationStoredFile = 'general.pot';
    • Removed the create() method in favor of proper dependency injection.
    • Few optional improvements, such as adding type hint to constant and marking properties as readonly.

    Since I'm not sure whether these changes are compatible for everyone, I didn't commit them to the MR — but I'm attaching the patch I used.

Production build 0.71.5 2024