This issue is about modules (and/or themes) checked out from a drupal.org Git repository and getting their translations. Currently you can test translations for packaged dev releases - ref #1862622: localization fallback so people can test translations with dev releases - but not for checked out modules because the project and version keys are missing in the info.yml file.

The relevant code is located in the locale.compare.inc.

  1. In the function locale_translation_project_list the list of modules are run through ProjectInfo::processInfoList() which removes modules that don' have the project key set. This can quite easily and robustly be work-around by extending the existing function _locale_translation_prepare_project_list and guess a project key. (This could be done in the function ProjectInfo::getProjectName() too, but that change is harder to get through I suppose.)
  2. In the function locale_translation_build_projects 'version' has an empty string as default (when the key is missing) and hence we get "invalid" download URLs because the pattern is
    http://ftp.drupal.org/files/translations/%core/%project/%project-%version.%language.po
    which results in
    http://ftp.drupal.org/files/translations/8.x/modulename/modulename-.somelanguage.po
    This URL is not accepted - the server returns 404. One ugly workaround is to set '1.x' as the default for 'version' so you get a valid URL, but that doesn't work if the project doesn't have 1.x release - like Rules. Not sure if this is better resolved by adding more redirects to the server. (An URL like "[...]/files/translations/%core/%project/%project-dev.%language.po" could redirect to the latest translation and version could be set to 'dev' as default.)

I'm happy to write a patch for 1, but 2 needs discussion.

I think this would be a very useful feature for all module developers that want to test translations with their module. Downloading the po files manually and putting them in the translation directory on the server is a work-around, but not very developer friendly.

Comments

hansfn created an issue. See original summary.

hansfn’s picture

hansfn commented
Issue summary: View changes
hansfn’s picture

hansfn commented
Title: localization fallback so people can test translations with non-package modules » localization fallback so people can test translations with non-packaged modules
gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented

Oh, my immediate response based on our prior issue discussion was to set this to bug report, but that projects and versions cannot be identified from git checkouts is a known problem / missing feature. The contrib https://www.drupal.org/project/git_deploy module serves this need given that every module dealing with project/version data such as the update status module has the same problem. I am not sure what would be the reception of a proposal to move git deploy to core, but that is what is effectively needed here IMHO.

hansfn’s picture

hansfn commented
Status: Active » Closed (works as designed)

Hm, I had read about the Git deploy module, but without really paying much attention. So I wasted some time on this ... I guess I learnt some thing ;-)

Git deploy probably solves my problem on Linux - didn't help me much on Windows because git isn't in the path.