Make it possible to fetch .po files for modules in profiles subdirectories

problem solved with commenting line 94 in l10n_update.project.inc:
//drupal_alter('update_projects', $projects);

@SkyWombat: I looked but could not find any code that would specifically disallow modules in profiles subdirectories (or not include them for that matter). The code uses Drupal's built in methods to find enabled modules and themes. Are you sure your profile modules have proper .info files with version information and are not -dev version?

Drupal Commons implements hook_update_projects_alter() to remove the modules that come with Drupal Commons and to include information of the Commons Release module. Drupal commons want to have full control over the module versions which are used in the installation. Localization Update module also uses hook_update_projects_alter().

I see three possible solutions:
1. The profiles must provide the translations
2. l10n_update provides a hook_l10n_update_projects_alter() where module can declare their modules which are available for translation update
3. l10n_update_project_list_alter() no longer calls hook_update_projects_alter() but provides a new hook_l10n_update_projects_alter() where modules can alter the list of modules to be language updated.

Good analysis. Is there maybe a way to get the unaltered version of the list for l10n_update?

Sure, as fortis suggested in #2: removing drupal_alter('update_projects' ... in the code below.

function l10n_update_project_list() {
  $projects = array();
  $disabled = variable_get('l10n_update_check_disabled', 0);
  // Unlike update module, this one has no cache
  _l10n_update_project_info_list($projects, module_rebuild_cache(), 'module', $disabled);
  _l10n_update_project_info_list($projects, system_theme_data(), 'theme', $disabled);
  // Allow other modules to alter projects before fetching and comparing.
  drupal_alter('update_projects', $projects);
  return $projects;
}

Yeah, well, the reason we call the alter there is to be able to work cleanly with git_deploy and friends to identify module versions from git checkouts.

Ok, I've asked Peter Wolanin, who helped build the Drupal Commons and Acquia Drupal toolset for alteirng .info file data for update status simplification, and he has a decent suggestion for us to do our own hook implementer module iterator. Create either a blacklist of modules where we do not call the hook (eg. skip acquia_agent), or do a whitelist to only call modules we know are good for us like git_deploy. I think we can do with less issues if we institute a whitelist, and start with git_deploy as the only item for now unless you know other good examples :) Then we can take issues to add more in the future and put them into later releases if need be (IMHO sounds unlikely that there are lots of modules like that around minus in Drupal distros).

That sounds interesting, because I'm not aware of any changes they made to make this work better :) Anyway, I think we still have work to do on our end to be more safe here, I think @pwolanin's suggestions sound good.

No profile modules .po import for me with Drupal Commons 1.6. Tried both l10n_update-6.x-1.0-beta1 and dev (Jun 12). Have to use workaround #2.

All right. I've checked git_deploy.module and it does not in fact use update_projects alter in any way. So we are left without any modules identified that we'd need to support that implements this altering. However, it causes issues with distros. So I've decided to go ahead with @Sutharsan's (2) suggestion from #5 and added an l10n_update_projects drupal_alter() instead. So modules who want to alter OUR project list can do so, but modules who generally mess with the project list will not cause us loose information. Patch attached. Committed to both 7.x and 6.x.

Very good. Thanks a lot for your work, Gábor.

+

I've done this by temporarily disabling the "Commons Release" module in the "Other" group. This module seems to be the one locking and hiding to the update process the modules used by Drupal Commons.

Needs documentation of the new hook_l10n_update_projects_alter().

The problem is active, while i'm trying to use with Commons 6.x-2.0-beta2

Please try out a dev release before you file a bug. Dev is where all new developments happen and where your problem may already be fixed.

Feel free to re-open the issue if the dev release does not fix it. And if it does so, give us the details you think are relevant.

Back to needs work for documentation.

No activity, closing the issue. Fee free to re-open if the problem persists.