Contrib.social

Locale method for building list of projects always return "all" for version

Open on Drupal.org →
Created on 18 June 2020, over 4 years ago
Updated 21 February 2023, about 2 years ago

Problem/Motivation

For an unknown reason the function locale_translation_build_projects always returns "all" for the "core" key on Drupal 8.8.x branch and later.
That causes errors when update localization on custom pattern.
As example, pattern http://test.com/%core/%project/%language.po will result http://test.com/all/mymodule/en.po. It was expected http://test.com/8.x/mymodule/en.po (see doc)

<!--break-->

Proposed resolution

Rollback to previous verification.

// core/modules/locale/locale.compare.inc

function locale_translation_build_projects() {
    // ...

    // For every project store information.
    $data += [
      // ...
      'core' => isset($data['info']['core']) ? $data['info']['core'] : \Drupal::CORE_COMPATIBILITY,
      // ...
    ];

    // ...
}
📌 Task
Status

Closed: won't fix

Version

9.5

Component
Locale  →

Last updated 4 days ago

Created by

🇫🇷France donaldinou

Live updates comments and jobs are added and updated live.
  • Needs subsystem maintainer review

    It is used to alert the maintainer(s) of a particular core subsystem that an issue significantly impacts their subsystem, and their signoff is needed (see the governance policy draft for more information). Also, if you use this tag, make sure the issue component is set to the correct subsystem. If an issue significantly impacts more than one subsystem, use needs framework manager review instead.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment about 2 years ago →
    🇺🇸United States smustgrave

    This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request → as a guide.

    Even though this is a task it seems like it needs a test to show the issue.

  • Status changed to Needs review about 2 years ago
  • Comment about 2 years ago →
    🇺🇸United States xjm

    I still think this issue is works as designed. Let's not spend time writing test coverage or working on this issue when it is regressing a deliberate change in Drupal 9+. Drupal 8 is end-of-life and Drupal 9+ ignore this key. It is only relevant for Drupal 7.

    I think this is on the wrong track, but tagging for subsystem maintainer review to get better feedback.

  • Status changed to Closed: won't fix about 2 years ago
  • Comment about 2 years ago →
    🇭🇺Hungary Gábor Hojtsy Hungary

    The only mentioned use case above involved implementing hook_locale_translation_projects_alter(), see https://api.drupal.org/api/drupal/core%21modules%21locale%21locale.api.p... for docs -- this hook allows to set the server pattern itself for each "custom module on the locked SI" as mentioned. The pattern setter alter code can then consider the version of the projects being run, etc. and formulate whatever type of dynamic URL it needs, including restoring the old core key. While the core key was revoked without a deprecation period indeed, I think this is a pretty obscure part of the API and the functionality can still be achieved with the alter hook already existing.

    Adding back code for dealing with outdated information especially untested on the other hand sounds problematic.

    It is true that the behaviour was changed without a deprecation and that is not ideal, we should keep this in mind for the future.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024