Problem/Motivation

It is a bad habit to have code like:
$this->t($some_var)
because potx cannot find those strings.

There are places like generic YML files, where it is required to have such a mechanism

Proposed resolution

  • Let's use a special inline comment to make sure potx don't forget about some of them.
  • Discuss the comment
  • Bikeshed the comment
  • Write a patch and identify all instances
  • Commit it

Remaining tasks

User interface changes

API changes

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

YesCT’s picture

Issue summary: View changes

typo in summary.
---
Might be related to, or need a related issue in, https://www.drupal.org/project/issues/search/potx?issue_tags=Drupal%208%...

YesCT’s picture

in
$this->t($some_var)
I wonder where the value of $some_var usually comes from.
If it is from a config file, or an annotation, we might be gathering them anyway.

Maybe we should look at some specific examples.

xjm’s picture

pwolanin’s picture

Title: Explicit document all instance of calling t($variable) » Explicitly document all instances of calling t($variable)
herom’s picture

my suggestion:

    // Needs potx support. source: plugin annotations.
    $this->t($plugin['definition'])

or if "potx" isn't a well-known module:

    // Needs translation extraction support. source: plugin annotations.
    $this->t($plugin['definition'])
dawehner’s picture

FileSize
723 bytes

We should also mention that calling t() with variables is a bad thing, so maybe something like this?

er.pushpinderrana’s picture

Status: Active » Needs review
jhodgdon’s picture

Status: Needs review » Needs work

The comment in #6 seems very verbose, and yet it doesn't give enough information to tell people who don't have any idea what's really happening.

So my suggestion would be:

a) Write up a brief documentation page (or section on a page) about this. There's probably something already that says "don't do this" in a module developer guide, so we could just add an "except" there.

b) In the "standard comment", link to this. Something like:

// Variable use in t() is normally not OK, but is OK here. See https://www.drupal.org/whatever.
herom’s picture

what about this?

Variables in t() calls cannot be automatically extracted by POTX (see https://www.drupal.org/developing/api/localization).
But in this case the strings are defined in YML files, so POTX can scan them.
dawehner’s picture

We don't have to mention POTX here, given that POTX is part of our community. POTX might confuse more people.

herom’s picture

removed the potx mention.

Variables in t() calls cannot be automatically extracted for translation (see https://www.drupal.org/developing/api/localization).
But in this case the strings are already extracted from YML files.
jhodgdon’s picture

Probably we should link to https://www.drupal.org/node/2133321 (which probably could use an alias), instead of https://www.drupal.org/developing/api/localization for Drupal 8, and add notes there about this topic?

er.pushpinderrana’s picture

Status: Needs work » Needs review
FileSize
929 bytes
778 bytes

Updated this patch on the basis of points mentioned in #11 and #12. Please review.

herom’s picture

I have also added a note in https://www.drupal.org/node/2133321 about (not) using variables in t() calls. maybe review that too?

note: You should not use variables inside t() calls, because they well not be available for translation on https://localize.drupal.org/ . An exception is when the variable is loaded from a known location for translatable strings, eg. configuration YML files.

jhodgdon’s picture

The note is OK; maybe it could be clearer with an example of what not to do though, and more prominent? And it could use a copy edit for minor punctuation, but no worse than the rest of the page... I'll make an edit now.

The patch looks OK too. It doesn't satisfy the issue summary since it is just the one spot being documented, but I think the idea was to get approval for the format before proceeding with the rest of the patch. If so, I think it's OK but maybe we should wait a day or two for others subscribed to this issue to respond.

I'm also going to add an alias to https://www.drupal.org/node/2133321 -- I guess it should be https://www.drupal.org/developing/api/8/localization for consistency with other pages in that section and the 7.x page. So you can update the patch to use that URL (shortly).

jhodgdon’s picture

Status: Needs review » Needs work

Setting this patch to "needs work" since it needs to be expanded, and the URL needs to be updated. See comment #16.

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.

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.

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.

quietone’s picture

Status: Needs work » Closed (outdated)

Since this issue was created there have been many patches to improve and correct the usages of t(). The documentation not directs the reader to https://www.drupal.org/node/322729 which explains the correct usage. That seems a much better approach than having to add comments to each usage of t().

Therefore, closing as outdated.

Thanks