How does importing a contrib module's translations work?

Drupal version: 9.3.13

Basically, I'm trying to understand how using a contrib module's translation works. I want to be able to download and use the translations from the Drupal infrastructure, and can't seem to get this to work.

I have a site with two languages, English and German (Default). I did run "drush locale-check" and "drush locale-update", and that imported the German core language file (which now is saved at "web/sites/default/files/translations/drupal-9.3.13.de.po"). If the current interface language is German, I do see all kinds of core features translated to German.

Active modules:

• Configuration Translation
• Interface Translation
• Language

I then installed a module, first loading it via composer and then installing it via the "admin/modules" page. I made sure that a string of the module was used in a page, that this string is translated on localize.drupal.org for the current version of the module and that it showed up under "admin/config/regional/translate" as untranslated afterwards. Then I ran both the translation commands again. The output says, that translations for one project were checked and that nothing was changed. No translation showed up for my test string.

I just tested this on a fresh Drupal installation with the "drupal/cookies" module (version 1.0.18, https://www.drupal.org/project/cookies). The module's page on localize.drupal.org shows lots of translated Strings: https://localize.drupal.org/translate/languages/de/translate?project=cookies&status=2&release=531668&search=&author&context=all&limit=10&sid=0

What I am aware of:

• My own custom modules use .po files, and those are loaded just fine.
• There seems to be a bug that causes new versions of modules not being picked up (https://www.drupal.org/project/drupal/issues/2575945). That is also bad, but here no translation for the module is loaded in the first place.

I tried to debug this and got as far as checking "locale.project" and "locale.translation_status" from the "key_value" table. Both only contain Drupal core on my test site. In the production site, all the custom modules are also contained, but none of the contributed modules.

So the question is: What am I missing here? How is this supposed to work?

После долгой отладки я решил эту проблему, сравнив поведение Drupal с совершенно новой установкой. Конечно, "drush locale-update" должен получать переводы для модулей contrib!

Здесь произошла эта строка в composer.json:

"конфигурация": {
     «отменить изменения»: правда,
     "предпочтительная установка": "источник",
     "сортировать-пакеты": правда
},

Оскорбительная линия «предпочтительная установка»: «источник». Это было совершено некоторое время назад, никто не знает, почему, и композитор получает код из git вместо загрузки zip-файла из Drupal.

Это не имеет большого значения, за исключением того, что Drupal обычно добавляет информацию в файл info.yml модулей:

# Информация добавлена ​​скриптом упаковки Drupal.org 2021-04-02
версия: '8.x-1.2'
проект: 'фубар'
дата: 1617351415

С git checkout это отсутствует! И когда Drupal позже проверяет переводы, он проходит через все модули и пытается получить имя проекта. Судя по всему, в Drupal переводятся проекты, а не отдельные модули. Некоторые модули содержат множество подмодулей, которые используют одно и то же имя проекта и, следовательно, одну и ту же базу перевода. Поскольку все мои contrib-модули были получены из git, а не из расширенного zip-файла, это означало, что Drupal пропустил их все при «drush locale-update»! Никакой информации об этом не выводилось, их просто незаметно пропускали.

Решение для меня состояло в том, чтобы изменить оскорбительную строку на это:

"предпочтительная установка": {
    "друпал/*": "расстояние",
    "*": "источник"
},

Также обратите внимание, что вам необходимо удалить модули из web/modules/contrib и переустановить их через composer. Просто изменить вышеперечисленное и запустить «установку композитора» недостаточно!