Hi, thanks for this great module.
Recently I found out, that I am able to update to newer translations than the version of my core and modules is.

For example I am currently using Drupal version 7.17, but when I check for translation updates, there is a translation for core Drupal version 7.18. What's the point of updating strings from a module/core version I don't use? Can't this mess up things?

I am not able to select which translations I want to download, and I don't want to use some modules in newest versions 'cause it messes other modules that are dependent etc....

Is there a way to check if the translation version is the same as the version of modules I use, not newer? Thanks.

Comments

I have not seen this behaviour. Can you attach screenshot(s) of where you found this information (7.18 and 7.17).

StatusFileSize
new106.86 KB
new99.59 KB

OK, both screenshots made today.

As you can see, I am using Drupal 7.16, but in the Translation update I have automatically downloaded translation for Drupal 7.17 and it recommends me to download translation for Drupal 7.18, which is the newest version.

@constantinejohny, this is a great question. I think you're right that this can mess things up.

In our case, we are trying to use Panopoly, which doesn't necessarily use the latest version of modules all the time. Our solution was to use hook_l10n_update_projects_alter to specify which versions we use for each module. I think that's the solution you're probably looking for.

However, I found a problem with the hook. It works great for most "projects" (contributed modules, themes, etc.), but it doesn't work correctly for the drupal project itself. In my case, I specified drupal v. 7.17, but the update still incorrectly says I want 7.19. I logged #1899128: hook_l10n_update_projects_alter Can't Update List for drupal Project for that issue and you can see details there. I'm not sure I understand @Sutharsan's response correctly there, but apparently the intended purpose of this behavior is for dev releases. That actually makes sense to me, but it still gives me problems for our use case.

The attached patch should make sure the translations matching the installed core version is downloaded. The check for HEAD in the version number can be removed Since CVS is not used, this is no longer found.

Thanks for the patch. I'm in the process of seeing if it will solve my issue at #1899128: hook_l10n_update_projects_alter can't modify drupal core version number.

If I understand this issue summary correctly, constantinejohny wanted to specify the version of the translation for each module. If so, I think use of hook_l10n_update_projects_alter will resolve this issue. (See #3 for details.) Maybe constantinejohny can tell us if it will work for him.

FWIW, I think this issue and #1899128 are related, but not strictly duplicate issues in all cases. For instance, someone using hook_l10n_update_projects_alter might not need to specify a core version number. In that case, he won't run into the bug reported at #1899128.

Version:7.x-1.0-beta3» 7.x-1.x-dev
Status:Active» Fixed

Committed to 7.x-1.x-dev

Apparently the commit to D7 failed. Now committed.
Attached patch for backport to D6. Patch also committed.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.