Core localization file download URL is wrong

Hi @Neil_Nand:

Could you briefly describe how to reproduce this?

I am certainly not an expert in the translation of Drupal but without a doubt that file doesn't exist. Since Drupal is written in American English, I assume such a file should not be necessary.

Thanks for reporting this issue. We rely on issue reports like this one to resolve bugs and improve Drupal core.

As part of the Bug Smash Initiative, we are triaging issues that are marked “Needs steps to reproduce“.

Since there were no specific steps provided since the issue was tagged with “Needs steps to reproduce“, I'm marking the issue "Closed (cannot reproduce)".

If anyone can provide complete steps to reproduce the issue (starting from "Install Drupal core") in the issue summary and set the issue status back to "Active".

Thanks!

This is still happening in the latest Drupal 8.9.13 and Drupal 9.1.5.

To reproduce simply enable multi language. For example English and Spanish.
Set spanish as the default.

Now go into edit English and check "Enable interface translation to English"
admin/config/regional/language/edit/en

This enables the English translations.

Now if you go to see translation updates, you will see that there are no available translations for English (because it is the default):
/reports/translations

And in the database table "locale_file" you can see that it added all the "en" files but it never finds them.

All that works as designed since English is the default language... but no errors show when you have this setup.

Here comes the problem.

Go into edit English and UNcheck "Enable interface translation to English"
admin/config/regional/language/edit/en

Problem now is that the translation updates continue to run and keep on searching for the "en" files even though that is unchecked and now it does generate error messages.

Everytime you run "drush cron" it fails to find translation files and the watchdog log starts to get inundated for these missing "en" files.

If the "Enable interface translation to English" is unchecked, it should no longer search for these files.

Haven't confirmed these steps but update the IS with them.

I have this problem on multiple installs. Watchdog is full of missing translation files – both for modules and Drupal Core. The problem persists after upgrading to Drupal 9.x

I now get the error too:
Translation file not found: https://ftp.drupal.org/files/translations/9.x/drupal/drupal-9.2.2.fr.po.

And through a browser I get:

404 Not Found
nginx

Using Drupal 9.2.7:

I see, Drupal tries to load the translations from the 9.x folder while they are stores inside the 8.x folder.

File exists:
https://ftp.drupal.org/files/translations/8.x/drupal/drupal-9.2.2.fr.po

File not found:
https://ftp.drupal.org/files/translations/9.x/drupal/drupal-9.2.2.fr.po.

Recent log message (watchdog):
Translation file not found: https://ftp.drupal.org/files/translations/9.x/drupal/drupal-9.2.2.fr.po.

That is the pattern, see below. So, is this more of an issue at this stage that this specific translation is not present in the expected place on the FTP server?

git grep 'https://ftp.drupal.org/files/translations/'
core/includes/install.core.inc:    'server_pattern' => 'https://ftp.drupal.org/files/translations/%core/%project/%project-%version.%language.po',
core/modules/locale/config/install/locale.settings.yml:  default_server_pattern: 'https://ftp.drupal.org/files/translations/%core/%project/%project-%version.%language.po'
core/modules/locale/locale.module:const LOCALE_TRANSLATION_DEFAULT_SERVER_PATTERN = 'https://ftp.drupal.org/files/translations/%core/%project/%project-%version.%language.po';
core/profiles/testing/config/optional/locale.settings.yml:  default_server_pattern: 'https://ftp.drupal.org/files/translations/%core/%project/%project-%version.%language.po'

That is the pattern, see below. So, is this more of an issue at this stage that this specific translation is not present in the expected place on the FTP server?

The original issue post was about a 8.x PO file inside the 8.x folder whereas for my comment in #10, the problem is of a 9.x file inside the 8.x folder.

But in both instance (8.x in 8.x or 9.x in 9.x), I believe the file did/does not exists on the FTP server.

The https://ftp.drupal.org/files/translations/9.x/drupal/drupal-9.2.2.fr.po file is currently not available on the FTP server (404 error). But yes, the 9.x file is available in the 8.x folder, see:

https://ftp.drupal.org/files/translations/8.x/drupal/drupal-9.2.2.fr.po

Which Drupal.org project shall we transfer this issue to?

Drupal Core should be requesting https://ftp.drupal.org/files/translations/all/drupal/drupal-9.2.2.fr.po. Now that semantic versioning is fully implemented for contrib, the core API segment makes no sense.

https://git.drupalcode.org/project/drupal/-/blob/d63941bc1af2e1a31debad1... has this correct. #3016471: Make localization file download major version agnostic made this happen.

https://git.drupalcode.org/project/drupal/-/blob/d63941bc1af2e1a31debad1... looks like the likely spot that was missed.

I've made a merge request to do the potential fix I spotted. I haven't tested to see if this actually resolves the issue. I expect additional work will be needed for writing automated tests, etc.

An issue summary update with the proposed resolution is needed as well.

I created a patch for the changes mentioned in #16.

aludescher - there is no need to upload a patch file, merge requests replace patches.

@drumm: Both workflows works, either a merge request or a patch.

Of course, here we already have a merge request that needs rebase.

I see one reason to keep the patch in #25 though, even if it is not complete and does not have any tests: Add the patch to composer.json file so that Drupal is patched automatically when running composer commands.

I've cherry-picked the commit and resolved conflicts, so it is now against 9.3.x.

Changing

'%core' => $project->core 

to

'%core' => 'all'

in /core/modules/locale/locale.translation.inc didn't solve my problem. Still getting errors like "Admin Toolbar (3.3.0). File not found at https://ftp.drupal.org/files/translations/all/admin_toolbar/admin_toolba..." errors for all module translations. I also got a lot of strings in a wrong other language.

I have currently only English as language and "Enable interface translation to English" is true.

I really need a solution for this annoying problem. Running Drupal 9.5.7

sorson - that looks like an unrelated issue. We don’t have any *.en.po files to serve from Drupal.org. Core localization should not be requesting English translations. #3218674: "Translation file not found" for English when "translate_english" is false looks like the issue for that.

Rebased with main. This seems to be broken on main branch because 12.0 (or main) is not supported by localize.drupal.org.

I believe this is broken because Drupal core is still using localize.drupal.org in a way that hasn’t been supported by localize.drupal.org in 7 years, since this issue never moved forward.

Looks like the function just got deprecated, but the replacement in core/modules/locale/src/LocaleSource.php is still wrong.

Rebased with main again. By this being broken on main, I meant that it attempts to load translations from: https://ftp.drupal.org/files/translations/all/drupal/drupal-12.0-dev.fi.po

This results in a 302 redirect to: https://ftp.drupal.org/files/translations/all/drupal/drupal-12.x.fi.po, which in turn returns a 404 response.

This seems to work on 11.x and 11.3.x branches, so I assume this will work once 12.x is supported.

Thanks! I guess this still needs tests even though how core is currently using localize.drupal.org without this issue being fixed is wrong.

I looked into writing tests for this and looks like #3016471: Make localization file download major version agnostic added some test coverage for this, but I don't know if this is even an issue anymore 🤔

We've been using this patch since 2022 (Drupal 9), but I couldn't reproduce the issue in our project or any supported core branch (10.5.x, 11.x or 11.3.x).

Our internal issue at the time included the following test instruction:

Check that the Drupal core translations get loaded without errors when running drush locale:check; drush locale:update.

Now, both the UI translation page and the Drush commands work just fine.

Maybe this is dead code? It does seem this issue hasn’t been causing any practical issues.

I still experience that issue when using site install througn Drush.

In the verbose I get many file not found.

I still experience that issue when using site install througn Drush.

In the verbose I get many file not found.

For Drupal core or modules? You'll still get "Translation not found" notices for projects that don't have a translation for the given language.

For core and modules.

Here is a sample, taken today:

 [notice] Performed install task: install_import_translations
 [notice] Performed install task: install_configure_form
 [notice] Translation file not found: https://ftp.drupal.org/files/translations/all/better_exposed_filters/better_exposed_filters-7.0.5.en.po.
 [notice] Translation file not found: https://ftp.drupal.org/files/translations/all/block_class/block_class-4.0.1.en.po.
 [notice] Translation file not found: https://ftp.drupal.org/files/translations/all/bootstrap5/bootstrap5-4.0.6.en.po.
 [notice] Translation file not found: https://ftp.drupal.org/files/translations/all/config_split/config_split-2.0.2.en.po.
 [notice] Translation file not found: https://ftp.drupal.org/files/translations/all/configurable_views_filter_block/configurable_views_filter_block-1.0.0.en.po.
 [notice] Translation file not found: https://ftp.drupal.org/files/translations/all/csv_serialization/csv_serialization-4.0.1.en.po.
 [notice] Translation file not found: https://ftp.drupal.org/files/translations/all/ctools/ctools-4.1.0.en.po.
 [notice] Translation file not found: https://ftp.drupal.org/files/translations/all/drupal/drupal-11.2.8.en.po.
 [notice] Translation file not found: https://ftp.drupal.org/files/translations/11.x/drupal/drupal-11.2.8.fr.po.
 [notice] Translation file not found: https://ftp.drupal.org/files/translations/all/empty_fields/empty_fields-8.x-1.0.en.po.
 [notice] Translation file not found: https://ftp.drupal.org/files/translations/all/entity_reference_revisions/entity_reference_revisions-8.x-1.12.en.po.
 [notice] Translation file not found: https://ftp.drupal.org/files/translations/all/entity_translation_unified_form/entity_translation_unified_form-2.0.13.en.po.
 [notice] Translation file not found: https://ftp.drupal.org/files/translations/all/externalauth/externalauth-2.0.8.en.po.
 [notice] Translation file not found: https://ftp.drupal.org/files/translations/all/facets/facets-3.0.2.en.po.
 [notice] Translation file not found: https://ftp.drupal.org/files/translations/all/field_group/field_group-4.0.0.en.po.
 [notice] Translation file not found: https://ftp.drupal.org/files/translations/all/html_title/html_title-8.x-1.6.en.po.
 [notice] Translation file not found: https://ftp.drupal.org/files/translations/all/inline_entity_form/inline_entity_form-3.0.0-rc21.en.po.
 [notice] Translation file not found: https://ftp.drupal.org/files/translations/all/jquery_ui/jquery_ui-8.x-1.8.en.po.
 [notice] Translation file not found: https://ftp.drupal.org/files/translations/all/jquery_ui_draggable/jquery_ui_draggable-2.1.0.en.po.
 … and so on.

Site install should look for English po files.

Still, some other languages (French for me) are not found:

[notice] Translation file not found: https://ftp.drupal.org/files/translations/11.x/drupal/drupal-11.2.8.fr.po.

https://ftp.drupal.org/files/translations/8.x/drupal/drupal-11.2.8.fr.po

11.2.8 translation are stored inside the 8.x folder.

Maybe this is dead code? It does seem this issue hasn’t been causing any practical issues.

I think so, moving this issue from Major to Normal. Our sites are translated, even with a large amount of “Translation file not found” notices.

https://ftp.drupal.org/files/translations/11.x/drupal/drupal-11.2.8.fr.po is likely a symptom of this bug. The correct URL is https://ftp.drupal.org/files/translations/all/drupal/drupal-11.2.8.fr.po, replacing the old random version number component with all

Looked into this a bit.

The reason this doesn't seem to happen for the vast majority of installs is due to a bug/bogus check in \Drupal\locale\LocaleProjectRepository::buildProjects(), there core is initialized with `core: $data['core'] ?? 'all',` (in 11.x/main now, there were recent changes with this, code looks a bit different before but same issue).

But $data['core'] doesn't exist, so it's in practice always core.

I don't know what's different for sites are using this, likely either a patch or module doing something with module data. Try reproducing this on a new install.

Since this isn't something that needs to be replaced anymore, I would suggest we adjust the default pattern in \Drupal::TRANSLATION_DEFAULT_SERVER_PATTERN to use all, then we don't have to replace that with. We could also remove the core replacement completely, the tricky part is that there is a config key for this that might be set to use %core. I'd suggest keeping the replacement but removing the core key from buildProjects() and no longer setting that.

I think this doesn't need additional tests to what we have for that solution, we don't need to test a hardcoded constant.

Ah, just realized, core in .info.yml is the old core compatibility key, that has been deprecated in favor of core_version_requirement many years ago, and I only see a tiny amount of .info.yml files in contrib still using that: https://search.tresbien.tech/search?q=core%3A%20f%5C.info%5C.yml%24

If you see this, then I think you are using something alters that back in. It's easy to verify that the jquery_ui_draggable 2.1.0 release .info.yml file does _not_ contain that information for example, picking one from #47.

I suspect that after #3590050: Deprecate and replace locale_status related functions, it's even less likely to be able to reproduce this because I put a hardcoded all into LocaleTranslationSource, which should always be the object paassed into buildServerPattern.

I think I can pull the one-line change here into #3593731: Clean up locale value object where I'm starting to deprecate various duplicate/unused properties on the now typed value objects.