Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
Drupal Translations Website doesn't support dev releases.
Proposed resolution
Drupal allows to identify how recent a dev release is now, the version string looks like this: "7.x-1.0-alpha1+29-dev". We should be able to fall back to "7.x-1.0-alpha1" and download translations for that. That would allow people to download 8.x-dev as soon as an unstable/alpha/whatever release is out and download translations.
Remaining tasks
- Clarify the Problem/Motivation
- Discuss options for resolutions
- Updated Proposed resolution once one seems agreed on
User interface changes
Initial thought: no UI changes. Maybe... some helptext somewhere?
API changes
Likely. @todo write something here. (API changes/additions that would affect module, install profile, and theme developers, including examples of before/after code if appropriate)
Original report by Berdir
Initially from #1861360-1: Refactor localization update test so people can just enable the test module to test
I had a completely different idea right now that would not only help with testing but also when actually using it. In 7.x, l10n_update doesn't support dev releases, I guess that's still true now? Drupal allows to identify how recent a dev release is now, the version string looks like this: "7.x-1.0-alpha1+29-dev". We should be able to fall back to "7.x-1.0-alpha1" and download translations for that. That would allow people to download 8.x-dev as soon as an unstable/alpha/whatever release is out and download translations. Should we open an issue for this?
Comments
Comment #1
YesCT CreditAttribution: YesCT commentedCan we/Should we have also fallback to previous releases, like from 8.x to 7.x?
Comment #2
Gábor Hojtsy#1001554: Make it possible to fetch .po files for dev modules/core is the same issue in the 7.x branch of l10n_update, the code should be possible to port from there.
Comment #3
YesCT CreditAttribution: YesCT commentedGuessing this is more difficult than novice, but there is code to use as a basis to start, so tagging medium. This one is available for someone to jump into. Just post if there are questions about what approach to try.
Comment #4
Gábor HojtsyThere is a fallback system now in the installer and dev releases work with translation downloads using that fallback.
Comment #5
hansfn CreditAttribution: hansfn commentedI remember that we added the fallback for the installer, but does the fallback work when checking for translations for installed modules? I just tested with my own module Views Send. The module was checked out from Git and enabled, but no translations downloaded (after multiple tries from the website and with Drush). Adding
to the end of the info.yml and suddenly the translation was updated.
I think it should have worked without this info added to the info.yml file.
Comment #6
Gábor HojtsyYes it should have worked.
Comment #7
hansfn CreditAttribution: hansfn commentedHm, then it seems we have a regression. I tested again with Drush -
drush locale-check. Without the version/project info in the info.yml file, locale-check just ignores Views Send (and another module that is checked out from Git). I will investigate further.Please let me know if it is better to file a new report for this issue.
Comment #8
Gábor HojtsyI think a new bug report would be important. Prior art at #2113955: Rely on proper server side version fallback for translations and #1832946: Runtime translation download fallback works different from installer translation download fallback but those are also fixed (please don't reopen but mark as related issues).
Comment #9
hansfn CreditAttribution: hansfn commentedReverting changes I made to this issue.
New issue: #2844202: localization fallback so people can test translations with non-packaged modules