Check version before update [#1883154]

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.

Comment	File	Size	Author
#8	l10n_update-use-correct-version-D6-1837704-8.patch	535 bytes	Sutharsan
#8
#5	l10n_update-use-correct-version-1837704-5.patch	587 bytes	Sutharsan
#5
#2	Drupal-7-16.png	99.59 KB	constantinejohny
#2	translation-7-18.png	106.86 KB	constantinejohny

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

Sutharsan CreditAttribution: Sutharsan commented 8 January 2013 at 17:04

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

Comment #2

constantinejohny CreditAttribution: constantinejohny commented 9 January 2013 at 07:50

File	Size
translation-7-18.png	106.86 KB
Drupal-7-16.png	99.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.

Comment #3

inkling CreditAttribution: inkling commented 28 January 2013 at 16:36

@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.

Comment #4

Sutharsan CreditAttribution: Sutharsan commented 12 February 2013 at 17:22

Duplicated by #1899128: hook_l10n_update_projects_alter can't modify drupal core version number.

Comment #5

Sutharsan CreditAttribution: Sutharsan commented 12 February 2013 at 17:28

File	Size
l10n_update-use-correct-version-1837704-5.patch	587 bytes

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.

Comment #6

inkling CreditAttribution: inkling commented 18 February 2013 at 21:52

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.