“Update translations” button missing, HTTP error

Same problem

Same problem for me on a Linux installation (Drupal 7.50, PHP 5.6.14). This is the error message in log:
Error occurred when trying to check http://ftp.drupal.org/files/translations/7.x/views/views-7.x-3.14.it.po: Error opening socket ssl://ftp.drupal.org:443.

Same here. It finds translations on the server for my modules but doesn't show me a "Update translations" button.

Screenshot.

You need to click on the "Missing translations for ..." to get more details.

The normal behavior is that 'Missing translations for ..." is displayed when modules are defined as 'project' but are not available at drupal.org as project. This is usually the case with features, but can also occur with custom modules.

In case of custom modules, remove the line "project = ..." from the MODULE.info file. In case of features add the feature machine name to 'Project' at admin/config/regional/language/update > Disable update.

If you have contributed modules in the list of missing translations, this can mean two things: If the list consists of all your modules, the webserver has no access to ftp.drupal.org. Contact your hosting to allow access. If only a few of your modules are in the list, Copy the URL of the .po file (for example "File not found at http://ftp.drupal.org/files/translations/7.x/views/views.hu.po") and check in a browser if the file is available. If it is not available, contact a translation administrator of your language at https://localize.drupal.org/.

@charly71, your problem is different. Contact your hosting.

Hi, sorry for the bad screenshot, here's better:

(truncated)

Additionally, all modules are contributed (project) modules installed through drush, no features.

My server has no problem accessing files from the drupal servers. I tried to wget the "Calendar" .po files from my server through ssh and it worked just fine. Command bellow for reference.

wget http://ftp.drupal.org/files/translations/7.x/calendar/calendar-7.x-3.5.de.po

When I try to update translation through drush it fails as well (which means to me that it is not a problem of my webserver's UNIX user www-data not having enough rights).

drush l10n-update-refresh

Output:

Checked translation for auto_entitylabel.                            [ok]
Checked translation for calendar.                                    [ok]
Checked translation for ctools.                                      [ok]
Checked translation for date.                                        [ok]
Checked translation for devel.                                       [ok]
Checked translation for drupal.                                      [ok]
[truncated]
Checked available interface translation updates for 27 projects.     [status]

Then:

drush l10n-update

Output:

Fetching update information for all projects / all languages.        [status]
No languages to update.                                              [warning]
All project translations up to date                                  [status]

Checking my website, no translations have been downloaded.

Note: my /sites/all/translations is owned by www-data, in my user's group.

I ended up downloading each .po file one by one and feeding them to the "Import" interface, so my problem is sort of fixed. But I'm happy to keep digging to help figure out what causes this behaviour.

@gramoun_kal, is your site behind a proxy? See: #750000: Failed to fetch information when behind a proxy
Is there any information in the watchdog log that gives more details?

The server is a linode VPS with its own IP and not behind a proxy. If I ping one of my sites, i get replies from its IP (is that a good test?)

The drupal log (recent log entries) doesn't record anything related. It does work though because it logs login events of node updates fine.

I'll check the apache log next time I'm home.

Faults are logged under the type 'l10n_update' in the log. If logs does not show any, your last resort is debugging the code. l10n_update_batch_status_check() and l10n_update_http_check() are probably the best places to start looking.

I clicked 'check manually', and after that the update button appeared.

I'm having the same problem: translations are neither downloaded nor imported. sites/all/translations has www-data group with write permissions, but the folder remains empty. Error message for currently 102 projects is like this:

Drupal core (7.52). File not found at http://ftp.drupal.org/files/translations/7.x/drupal/drupal-7.52.de.po

But I can download that file manually. It's actually exactly the same as in #8.

@yan, If you can download the file (from your computer), but the website can not, then it may be a firewall or reverse proxy problem.
Check if the file it can be downloaded from the server. If you have command line access to the server use curl or wget to check

@sutharsan I can download it just fine using wget on the server.

You should either debug the code yourselves or provide more details. You can start by adding three lines of debug code and investigate (or share) the result that is displayed on admin/config/regional/translate/update.

Add the following to the l10n_update.admin.inc file:

  $status = l10n_update_get_status();

// == Start debug code == 
debug(array_keys($project_data));
debug($languages);
debug($status);
// == End debug code == 

  // Prepare information about projects which have available translation
  // updates.
  if ($languages && $status) {

I did what Sutharsan suggested in #16. The result is attached.

I forgot to change the status back.

@yan, Sorry for not responding sooner. Thanks for sharing the data. It tells me that, for some reason, the translations are marked as 'local' while the URL's are from remote. Was the database in the past used with local source? Does the Translation source (local/remote/both; at /admin/config/regional/language/update) value gets overridden in settings.php?

The problem can probably fixed (once, but may return) by changing the Translation source, submitting the form and changing it back (at /admin/config/regional/language/update).

For me the issues was related to curl: https://stackoverflow.com/questions/35638497/curl-error-60-ssl-certifica....

Once i pointed to cert file checking manually for translations gave me the button to update. Without curl set up correctly this silently fails; unlikely check for available module updates which tells you that there is a curl issue.

This is a core bug.