Enable Localization Update to install versions of .po translation files that are older than installed versions of modules/core

1) Are some modules not getting translations anymore?

No, but sometimes the creation of po files by localize.drupal.org fails. Check out the issue queue: https://www.drupal.org/project/issues/localizedrupalorg

2) Is there a way to install a .po file through this module for older versions?

Currently not.

Same problem here, also with some modules that have been recently updated. If you install a new module that have been updated some days ago you can't get automatic updates.

I think that if captcha-7.x-1.1.es.po can't be downloaded the module must download the latest file captcha-7.x-1.0.es.po (this is just one of the modules that updates some days ago and I must install captcha-7.x-1.0.es.po manually to get it translated to spanish).

In other sites, in which I have Captcha module before it updates to 1.1 the translations are ok.

The Captcha module is just an example, actually I have this issue with Drupal core (if I install a fresh one) and with some other recently updated modules.

Changing the version to 7.x-2.x. Feature request for 7.x-1.x will no longer be accepted.

@jmsosso, can you update the issue summary and title to match your feature request.

This is needed for the features translations module to work correctly (thus exporting all the translations instead of just the overridden ones)

What I usually do is import the .po file manually, copy it along the other .po files (if they are stored locally), and then add/adjust the l10n_* tables manually in the database.

@PascalCanimateur, Can you explain what features translations module does with po files, how it relates to module versions and why you need this feature. I am not familiar with features translations module.

From the features translations description page: "The module can use l10n_update to reduce the set of exported strings."

Say you want to export the translated strings from your site into a feature-based module in order to reproduce them on another site or simply have them version controlled using git.. Normally features would export ALL of the translated strings (even those imported from l.d.o), thus creating a huge module (1 Mb or more) for no practical reason. This is where features_translations comes in... You simply configure l10n_update to keep local copies of the .po files in files/translations (for example) and features_translations will automatically segregate imported strings from manually-translated ones, allowing you to export only the latter in a much smaller module.

This is why l10n_update's ability to import older .po files is so important to people depending on features_translations for their localization workflow.
To fix that problem manually, I add an entry in the l10n_update_file table as if the .po file had been successfully imported (you can get that entry from a site running the older, l.d.o translated version of the module) and another one in the l10n_update_project table associating the module's or core's actual version with the path of the .po file (which I copy manually in the same directory used by l10n_update)

As far as I understand the original feature request, this issue is about downloading other translations than the ones currently installed on the site. For example:
* Installed: Views Slideshow is 7.x-3.1
* l10n_update can not find a translation for this version.
* l10n_update tries to download a translation for 7.x-3.0
* l10n_update download, import and registers Views Slideshow is 7.x-3.0 translation

This is why l10n_update's ability to import older .po files is so important to people depending on features_translations for their localization workflow.

@PacalAnimateur, sorry I fail to understand what l10n_update does not do, apart from the above scenario. If your site has 7.x-3.0 installed, it should again look for a 7.x-3.0 translation. It does not look for the latest version.

@PacalAnimateur: reading the explanation of your functionality, it sounds like better would be to integrate with potx and parse the generated feature code for getting the exact strings shipped instead of trying to approximate that by removing strings from a huge set that are from elsewhere.

@Sutharsan, the original feature request is exactly what I need... I was simply stating that it's also important in the context of features_translations.

@Gábor Hojtsy, I'm not sure I understand the approach you're proposing, but features_translations works great as it is (but a little slow to check / rebuild the feature... but I can live with that).

@PascalAnimateur: I think Gábor is talking about using potx to generate a po/pot file from the feature module, for example to work on translations in Poedit. I needed this ability, so I made a small commit to features_translations to support it: http://cgit.drupalcode.org/features_translations/commit/?id=ea0069f.

@infojunkie: thanks for the clarification, I'm currently looking into the potx / potx_exportables modules to replace my current features_translation workflow ... but I find that potx doesn't export the context (msgctxt) which I need with localize_fields (features_translations does export the context correctly though). If I understand your patch correctly, it allows to export the non-translated (but translatable) strings along with the feature created using features_translation? Is there another, more relevant thread somewhere for this l10n_update / potx / features_translation stuff?

#2473457: Support translatable extraction using potx

The same problem occurs after installing Drupal core, version 7.x-dev, with recommended release 7.38. After installing a non-English language, no translations are downloaded.

On page /admin/config/regional/translate/update, the following is shown:
Missing translations for: Drupal core (7.39). File not found at http://ftp.drupal.org/files/translations/7.x/drupal/drupal-7.39.nl.po nor at translations://drupal-7.39.nl.po

But the version 7.39 does not exist yet!

No activity, no support for this feature. Closing the issue.