MigrateExecutable and MigrateBatchExecutable should use TranslationInterface

Created on 9 July 2025, about 23 hours ago

Problem/Motivation

I have a form that instantiates a MigrateBatchExecutable. The $translation param expects the TranslationManager concrete class, but my form class is autowiring the TranslationInterface service. This makes phpstan unhappy, unless I assert that we have the concrete class.

Steps to reproduce

Proposed resolution

Replace \Drupal\Core\StringTranslation\TranslationManager with \Drupal\Core\StringTranslation\TranslationInterface

Remaining tasks

User interface changes

API changes

Data model changes

🐛 Bug report
Status

Active

Version

6.0

Component

Code

Created by

🇦🇺Australia mstrelan

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

Merge Requests

Comments & Activities

  • Issue created by @mstrelan
  • 🇮🇳India kulpratap2002

    Working on this.

  • Pipeline finished with Success
    about 17 hours ago
    Total: 214s
    #542760
  • heddn Nicaragua

    Hmm, but TranslationManager actually is a combination of both TranslationInterface and TranslatorInterface. How should this be handled?

  • 🇦🇺Australia mstrelan

    @heddn that's a great point. I note that TranslationInterface has only one implementation (outside of tests) and that is the TranslationManager. So by using TranslationInterface you'll always be getting TranslationManager, unless another module provides another implementation. The other thing to look at is what methods are actually called. I can see only ::translate and ::formatPlural, both of which come from TranslationInterface, so we could happily receive an object that implements only TranslationInterface and not TranslatorInterface.

    I haven't considered BC concerns though, I think it would be mostly fine because we're actually broadening the type in the base class. Even if subclasses are calling methods from TranslatorInterface, it will still work, but phpstan might complain.

Production build 0.71.5 2024