The original form for the /download route is not yet ported: https://git.drupalcode.org/project/l10n_server/-/blob/7.x-1.x/l10n_packa...
Check the initial repository for the logic and port it in the 3.x branch.
Identical logic port for now.
The Downloads section should be populated with the intended results as on https://localize.drupal.org/download.
None
None
Show commandsStart 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:
compare
Comments
Comment #2
fmb commentedComment #3
teebeecoder commentedComment #4
drupalvikingComment #5
teebeecoder commentedComment #6
teebeecoder commentedComment #7
donquixote commentedThe paths in the issue summary are a bit wrong.
In the code of the Drupal 7 module, in l10n_packager_menu(), I see 'translate/downloads' path.
In localize.drupal.org I get:
- On https://localize.drupal.org/download -> 5xx server error.
- On https://localize.drupal.org/downloads -> page not found
- On https://localize.drupal.org/translate/downloads -> 5xx server error.
- On https://localize.drupal.org/translate/download -> a list of translations.
- On https://localize.drupal.org/translate/abcdefghijklmnopqrstuvwxyz -> the same list of translations.
In 3.0.x in l10n_packager.routing.yml, I see path '/downloads', mapped to L10nPackagerDownloadForm which seems like a stub that does not do anything meaningful.
Both in D7 version and in 3.0.x, that downloads route is protected by 'access localization community' permission, which is defined in l10n_community.
In the Drupal 7 version, l10n_packager depends on l10n_community, probably for that exact reason.
Comment #8
donquixote commentedOn https://localize.drupal.org/translate/downloads?project=token I get the table with downloads.
This aligns with what I see in the code: The page needs a query parameter.
On https://localize.drupal.org/download?project=token I see the same.
Maybe a url alias?
Comment #9
teebeecoder commentedComment #12
gábor hojtsyPorted the Drupal 7 page. As #2 found, the Drupal 7 path is
translate/downloadswith the project in theprojectquery parameter, which is where the "Download translations" project page block and the "More downloads" link of the language page already point, so the route moves there and the placeholder form is gone.The page is the Drupal 7 one: a project picker (radios up to 5 projects, a select up to 30, an autocomplete beyond that) that leads to
?project=uri, and for the project a table of the translation languages by major branch with the latest packaged file of each branch, its size, generation date and the "up to date as of" date. Without a project the highlighted project of l10n_community is shown, unknown projects get the Drupal 7 warning. The table is render cached on the packager file and release list tags instead of the Drupal 7 hour long cache.On the way: the "Download translations" block linked to a route that does not exist, the top downloads block now passes the table headers to the per project rows and only offers "More downloads" beyond 20 projects like Drupal 7, its expand links carried a Drupal 7
#hrefand rendered nothing, the branch grouping uses the Drupal 7 regular expression (1.2.3 is 1.x, 8.x-1.0-beta1 is 8.x-1.x, the old one produced 1.2.3x for semantic versions), the Drupal 7 CSS and JS come along as a library, and the highlighted project lookup no longer warns when the configured title does not exist.Tests: Drupal 7
testDownloadsPage()first (access, picker, table contents and links, picker submit, unknown project), the portDownloadsPageTestchecks the same plus both blocks. Note the 5xx on the live site without a project is the Drupal core table for a hundred languages, not a code path difference.LLM was used to find, diagnose explain and fix this issue. With human review.