The download link on the release in the database is supposed to contain the whole URL to download the release. If your database does not contain that, then that is some other issue in a module which filled that up.
Committed the $output patch. Setting back to 'active' for the remaining issue.
The download_link is not the home link, but it still should be the whole download link where the file can be obtained. It might not be a drupal.org hosted project. The Gallery2 or the Open Atrium project uses l10n_server to translate projects hosted elsewhere, so the core l10n_server code should not make assumptions on where a project is hosted / from where it is downloadable. Therefore we should not compute this on display. If the file is downloadable locally, then a local file path is just right. l10n_localpacks can also translate non-drupal.org hosted code, like Gallery2 or Open Atrium, so it might not be best to assume a drupal.org download path either. Therefore there is this l10n_localpacks_home_link setting, which controls a similar behavior for the home link. Maybe we can just generalize (rename/retitle) that and apply to both the home link and the download link too. But I think a local download link is not an issue, as long as you are not deleting files after being parsed.
Comments
Comment #1
gábor hojtsyThe download link on the release in the database is supposed to contain the whole URL to download the release. If your database does not contain that, then that is some other issue in a module which filled that up.
Comment #2
tobiasbThe download link is not the homelink (http://drupal.org/project/drupal).
In l10n_localpacks.module line 146
$path -> drupal-6.x-dev
line 160
But what is the download link
http://ftp.drupal.org/files/projects/drupal-6.x-dev.tar.gzorhttp://example.org/foo/drupal-6.x-dev.tar.gz?Comment #3
tobiasbComment #4
gábor hojtsyCommitted the $output patch. Setting back to 'active' for the remaining issue.
The download_link is not the home link, but it still should be the whole download link where the file can be obtained. It might not be a drupal.org hosted project. The Gallery2 or the Open Atrium project uses l10n_server to translate projects hosted elsewhere, so the core l10n_server code should not make assumptions on where a project is hosted / from where it is downloadable. Therefore we should not compute this on display. If the file is downloadable locally, then a local file path is just right. l10n_localpacks can also translate non-drupal.org hosted code, like Gallery2 or Open Atrium, so it might not be best to assume a drupal.org download path either. Therefore there is this l10n_localpacks_home_link setting, which controls a similar behavior for the home link. Maybe we can just generalize (rename/retitle) that and apply to both the home link and the download link too. But I think a local download link is not an issue, as long as you are not deleting files after being parsed.
Comment #5
gábor hojtsySo can we somehow find out how did any of your projects end up without download links?
Comment #6
gábor hojtsyAlso, this might be highly related to #588604: Download link not properly set in l10n_localpacks.
Comment #7
SebCorbin commented6.x is now discontinued
Comment #8
SebCorbin commented