Problem/Motivation

We should avoid calling t() directly in classes that allow dependency injection.
This issue covers the core/modules/update/*

Proposed resolution

Convert t() to $this->t() whenever possible.

Remaining tasks

  1. Fix code.
  2. Review.
  3. RTBC.
  4. Commit.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

N/A -- totally internal.

Comments

Hardik_Patel_12 created an issue. See original summary.

hardik_patel_12’s picture

StatusFileSize
new4.58 KB

Kindly review a new patch.

hardik_patel_12’s picture

Assigned: hardik_patel_12 » Unassigned
Status: Needs work » Needs review
Rangaswini’s picture

Assigned: Unassigned » Rangaswini
Rangaswini’s picture

Assigned: Rangaswini » Unassigned
Issue summary: View changes
Status: Needs review » Reviewed & tested by the community
StatusFileSize
new432.72 KB
new332.3 KB

Thank you @Hardik_Patel_12
Above patch LGTM
I have tested the patch, doesn't break any text message as shown in screenshots.

dww’s picture

Issue summary: View changes
Status: Reviewed & tested by the community » Needs work

This can't be RTBC if the bot can't even apply the patch. ;)

longwave’s picture

Status: Needs work » Reviewed & tested by the community

Previous test was against PHP 7.2 but minimum dependency on 7.3 went in since, so retesting on 7.3; RTBC if it passes this time.

dww’s picture

@longwave re: #7: Ahh, right, makes sense.

Reviewed #2. Changes seem fine.

After applying the patch, the "only" uses of a raw t() (not $this->t()) are either in the tests/* subdir, or in the following files:

./update.api.php
./update.authorize.inc
./update.compare.inc
./update.install
./update.manager.inc
./update.module
./update.report.inc

DI isn't available in any of those, so I think this patch gets us as far as possible (for now). See also #3100110: Convert update_calculate_project_update_status() into a class for t() conversion while moving some of that procedural code into classes.

Therefore, +1 to RTBC, assuming the bot is happy (which it should be).

Also, added an actual issue summary here and simplifying the title for a better commit message.

Thanks!
-Derek

dww’s picture

Title: t() calls should be avoided in classes, use dependency injection and $this->t() instead in Update module » Use $this->t() instead of t() in Update module classes

Not sure what happened to the title change I tried to do in #8. Trying again. ;)

alexpott’s picture

alexpott’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs followup

Let's fix test module code too whilst we at it...
\Drupal\update_test\TestFileTransferWithSettingsForm::getSettingsForm - this will need to use the string translation trait because it is not a real form :) - hmmm actually that asks a deeper question about whether or not \Drupal\Core\FileTransfer\FileTransfer should use the trait. I guess it should be that should be a separate issue.

Can someone create the follow-up and add to the parent issue - and then we can proceed here.

jungle’s picture

Status: Needs work » Needs review
StatusFileSize
new5.67 KB
new1.08 KB
/**
 * Provides an object to test the settings form functionality.
 *
 * This class extends \Drupal\Core\FileTransfer\Local to make module install
 * testing via \Drupal\Core\FileTransfer\Form\FileTransferAuthorizeForm and
 * authorize.php possible.
 *
 * @see \Drupal\update\Tests\FileTransferAuthorizeFormTest
 */
class TestFileTransferWithSettingsForm extends Local {

\Drupal\update\Tests\FileTransferAuthorizeFormTest should be \Drupal\Tests\update\Functional\FileTransferAuthorizeFormTest

It's out of the scope of this issue, so I did not touch it.

jungle’s picture

xjm’s picture

Status: Needs review » Closed (duplicate)

Thanks for working on this.

In general, issues should not be scoped by file or module; instead, they should be scoped by making the exact specific change across as much of core as possible. Reference: https://www.drupal.org/core/scope#files

In particular, t() calls should be replaced based on whether the translation service is already available in the class, and more specifically, based on which base class it extends. (So, for example, one issue for form builders, one for controllers, one for list builders, and then splitting that up further only if the resulting patch is too large to be manageable.) We also need to decide the approach before we proceed with child issues. See #3113904: [META] Replace t() calls inside of classes for more discussion. So, closing as a duplicate of the parent issue in #3113904: [META] Replace t() calls inside of classes .

Thanks!