Fetch available module versions before Update module does.

The latest release which includes #1001554: Make it possible to fetch .po files for dev modules/core should have fixed this issue. Is it not working for you?

Localization Update server only supplies po files for releases, not for dev-packages. If you have a dev release installed, Localization Update module falls back to the most recent release of the same branch. In your case the 7.x-1.0-beta7 translation is the fallback for 7.x-1.0-beta7+21-dev module version. This is by design behaviour. If the translation of the beta7 release got update, it will be imported by Localization Update. But it will only contain the string of the beta7 release. More recent string additions/changes in the module (between beta7 and beta7+21-dev) are unknown to the Localization Update server. And what is not there can not be imported.

beta3 does include this functionality. While reproducing your situation I got the same behaviour after downloading and enabling the dev-release of Media Gallery. No beta7 tranlation was indicated. It turned out that Update module caches its results. After visiting the available updates page at example.com/admin/reports/updates the translation update page was giving the expected results.

It needs investigation. If you like to get into it, you can start here:
l10n_update.project.inc, line 50

  if (module_exists('update')) {
    $projects_info = update_get_available(TRUE);
  }

Changed to bug report and modified issue title.

I agree that option 3 is the best solution. Preferably only for those cases where we have a dev release on your hands.

+++ sites/all/modules/l10n_update/l10n_update.project.inc	(revision )
@@ -47,12 +47,19 @@
+    if (!isset($projects_info[$name])) {
+      _update_process_fetch_task($data);
+      $available = _update_get_cached_available_releases();
+      if (!empty($available[$name])) {
+        $projects_info[$name] = $available[$name];
+      }
+    }

Code looks good, but it needs some explanation why this special action is taken.

@jurgenhaas, can you follow up this issue?

Patch committed, thanks.
I've trimmed the comment lines to 80 chars as per coding style guide.

This breaks when enabling a module while the update module is disabled.

Fatal error: Call to undefined function _update_process_fetch_task() in l10n_update.project.inc on line 59 
module_enable( )../install.core.inc:1571
module_invoke_all( )../module.inc:499
call_user_func_array ( )../module.inc:899
l10n_update_modules_enabled( )../module.inc:899
l10n_update_project_refresh( )../l10n_update.module:138
l10n_update_build_projects( )../l10n_update.project.inc:150
l10n_update_get_projects( )../l10n_update.project.inc:37
l10n_update_build_projects( )../l10n_update.module:322

_update_process_fetch_task() and _update_get_cached_available_releases() are now called at a time when the update module which defines it may not be enabled yet.

Perhaps the first line should be extended to if (!isset($projects_info[$name]) && module_exists('update')) {

JvE, yes we should do that.

The right patch...

Patch solves the problem.

#20 committed.