Problem/Motivation

Knowing which strings in YAML files are supposed to be translatable or not can be a huge PITA, especially in standalone YAML that isn't tied to something unique and processed like in the config system.

Proposed resolution

Semi-related to #2088371: YAML discovery incompatible with translations, but more of a continuation to automatically convert strings to TranslatableMarkup found in YAML files using a custom !translate tag, e.g.:

label: !translate [ "Human readable and translatable title" ]

Remaining tasks

TBD

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

TBD

Issue fork drupal-3068483

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

markcarver created an issue. See original summary.

markhalliwell’s picture

Title: Support !translatable YAML tags » Automatically map !translatable YAML tag to TranslatableMarkup

Better title.

---

From: #2088371-40: YAML discovery incompatible with translations

FWIW, tag support has been added to Symfony finally:

https://github.com/symfony/symfony/issues/21185
https://github.com/symfony/symfony/pull/21194

Well, or even !t to keep it terse, though I was thinking in parallel to the @Translation annotation.

As much as !t would keep it relatively simple and unobtrusive, it is also at the risk of creating (or rather continuing) our existing t() Drupalism.

There is absolutely no context as to what "t" means and can sometimes be a slight hurdle for newcomers.

Along the same grain of why, in our coding standards, we don't abbreviate variable names... we really shouldn't do that here either.

I think YAML tags should be explicit.

---

This could easily be accomplished by implementing a YAML callback:

https://www.php.net/manual/en/yaml.callbacks.parse.php

For Symfony, we can essentially do the same but will have to iterate over the YAML array after parsing it to look for \Symfony\Component\Yaml\Tag\TaggedValue objects.

markhalliwell’s picture

Title: Automatically map !translatable YAML tag to TranslatableMarkup » Automatically map !translate YAML tag to TranslatableMarkup
Issue summary: View changes

https://symfony.com/blog/new-in-symfony-3-3-custom-yaml-tags#comment-21048

Turns out it, for BC reasons, tags don't work with string literals (yet).

So instead, we'd need need to wrap it in an array.

label: !translate [ "Human readable and translatable title" ]

This is actually good because then we can just pass the entire contents of the array to the method which allows context :D

label: !translate [ "Scale", [], { context: "A range of digets" } ]

Also, I'm thinking the tag name should be !translate as it reads better this way.

markhalliwell’s picture

Status: Active » Needs review
Issue tags: +Needs tests
FileSize
9.5 KB

Initial POC patch

Status: Needs review » Needs work

The last submitted patch, 4: 3068483-4.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

markhalliwell’s picture

Status: Needs work » Needs review
FileSize
12.44 KB
9.35 KB
markhalliwell’s picture

markhalliwell’s picture

FileSize
4.16 KB
10.16 KB
markhalliwell’s picture

markhalliwell’s picture

Component: language system » base system

The last submitted patch, 9: 3068483-9-test-only.patch, failed testing. View results

Status: Needs review » Needs work

The last submitted patch, 9: 3068483-9.patch, failed testing. View results

markhalliwell’s picture

Status: Needs work » Needs review

Random test failure

markhalliwell’s picture

Ping

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

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). 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.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now 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: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

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

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.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.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.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.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now 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.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now 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.

needs-review-queue-bot’s picture

Status: Needs review » Needs work
FileSize
5.4 KB

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

voleger made their first commit to this issue’s fork.

voleger’s picture

Status: Needs work » Needs review

Rerolled against 10.1.x.

smustgrave’s picture

Status: Needs review » Needs work
Issue tags: +Needs Review Queue Initiative

Didn't test but the MR has a test failure which seems valid.

Version: 10.1.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, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.