On my site on path /admin/config/regional/translate/update there are around 30 modules, including views, panels etc. All modules have status "No available translations found" except for 3 modules (admin menu, better formats and chaos tools - they are at the top of list and have "up to date" status).
When I click on "Refresh information" then after 10 seconds the page refreshes with drupal error message at the top: "Failed to fetch information about available updates from the server."
For comparison, when I go to /admin/reports/updates/update then there are some available updates but all is green, no errors or warnings. So it looks like this problem concerns localization update only.
Is there something that can help with this error/warning about no translations available?
| Comment | File | Size | Author |
|---|---|---|---|
| #19 | l10n_update-no-available-translations-found-1791100-19.patch | 611 bytes | groovehunter |
| #18 | l10n_update.inc-1791100.patch | 698 bytes | mkesper |
Comments
Comment #0.0
raincloud commentededit
Comment #1
Ace Cooper commentedSame problem here.
I'm running the latest Drupal 7.16-dev dated October 1, 2012.
I get "No available translations found" every time I try to updated translations through interface or drush.
Update translations button leads to error message: "Cannot find any translation updates."
On Refresh information I receive the error: "Failed to fetch information about available updates from the server."
See the screenshots attached: Update translations, Refresh information, Drush l10n-update
UPD. Downgrading both l10n_update and drupal by replacing file from stable versions didn't work for me.
Finally I disabled and uninstalled l10n_update-7.x-1.x-dev, installed latest stable l10n_update-7.x-1.0-beta3.
Since that the translations are downloaded correctly.
Comment #2
sutharsan commented@raincloud, your site may have a connection problem or a connection time-out due to slow data-transfer. If those three translations are a result of imports by cron, you can try to reduce the number of projects checked and downloaded during cron by changing two settings in the code. Change the code in the l10n_update.module file between approx. line 31 - 39 to:
Run cron a few times and check if any translation has been imported. Also check the log for fault messages.
@Ace Cooper, Are you sure your site can reach the translation server? Not any firewalls in between? Can you download a translation from the browser (e.g. http://ftp.drupal.org/files/translations/7.x/drupal/drupal-7.15.nl.po) and from the command line (e.g.
wget http://ftp.drupal.org/files/translations/7.x/drupal/drupal-7.15.nl.po?Comment #3
Ace Cooper commentedMy website is located on a dedicated server under CentOS 6.2 with Drupal 7.16-dev dated October 1, 2012.
When the l10n_update-7.x-1.x-dev (2012-Feb-10) said "No available translations found " I had to import Drupal Core translation manually.
But doing so for each module would be a huge step back for productivity.
So I did
drush dis l10n_update&drush pm-uninstall l10n_updatefor the latest DEV.Then I installed the latest STABLE l10n_update-7.x-1.0-beta3 and the translations became available for autodownload.
Ergo, the problem is in latest DEV (2012-Feb-10) - don't use it.
UPD. Ok, I've just created another drupal configuration for another site.
I found a conformity in unavailable translations: l10n_update can't serve translation for dev modules.
Please, see the screenshot that illustrates the problem precisely: sceenshot1.
Comment #4
sutharsan commented@Ace Cooper, this difference between the dev and beta3 release is very unlikely. The difference in code is minimal between the two and no change was made in the function that handles the version fallback. I can not explain this behaviour from the difference between the two versions.
Comment #5
hlopes commentedI have the same problem, but to add to the complexity i've installed the module on the same server, different sites.
One works, the other doesn't.
The sites are pretty much the same, beeing D5 upgraded sites (to D7), and the module version is the same between them. (beta 3)
Comment #6
sutharsan commentedWhat does the logs (Reports > Recent log messages) say? If there are no related warnings or errors, the only way to get to the bottom of this is to debug the code. And if you can't, I can do this for your. But I need ssh access and an admin account. Contact my via the contact form if you wish.
Comment #7
jezdec commentedSame troubles here. For addition, I have installed patch for proxy access listed here: http://drupal.org/node/7881. It works pretty well, but still having same troubles as other guys here. Having more than 100 modules. Running on 7.15.
Comment #8
hlopes commentedSeems like deleting the language and re-adding it solved the problem for me. Maybe something is running only when a language is added?
Also, as for the errors part, no error whatsoever either on watchdog logs nor php error log.
Comment #9
sutharsan commented@all, I can help to solve this problem, but not from a distance. I don't experience the problem myself. Unless someone is going to debug the code, this is probably not solved. I can only repeat the offer I made in #6.
Comment #10
Jazoja commentedAfter updating to Drupal 7.15->7.16, and all modules to the recommended newest version I also ran into that error.
Removing the localization_update module and importing the translation file by hand didn't solved the problem.
I think, the problem is not in the localization_update module.
However, D7 works as supposed on my XAMPP (Win7x64), it produces the error on my shared host. (Linux?)
I can reproduce the error by these steps:
I can give the FTP account and full access to the installed D7 for debug purposes. (PM)
Update:
I tried the solution in #1 (installing beta3) then hit the browser refresh button after every server timeout (about 4 times) and the language update finished successfully.
Comment #11
inkling commentedI have had the same "Failed to fetch information about available updates from the server." In my case, I had not changed .htaccess to give permissions to .po files, so the server was giving a 403 forbidden. This might be the problem for some here, but I don't think it's raincloud's problem, since he has translations for three files.
To find the problem, try checking the value of result->code here, and see if that helps:
I have a similar issue logged at http://drupal.org/node/1841730.
Comment #12
inkling commented[edited]
@Ace Cooper, I think your issue is different than raincloud's. I went through the list in your screen shot. There really aren't translations available for those dev versions. Take a look at the translations at http://ftp.drupal.org/files/translations/7.x/.
We had the same issue with not wanting to download specific versions of all the translations manually. Our solution was to generate a list of modules in a .csv file when building the distro. Then we used that list in a module that implements hook_l10n_update_projects_alter(). If anyone here is interested in it, let me know. I didn't think there would be enough interest in it to contribute it, but maybe there is after all.
Comment #13
sutharsan commented@inkling, Can you explain about "not wanting to download specific versions of all the translations manually". I am interested in your use case.
Comment #14
inkling commented@Sutharsan: Sorry, my previous comment was badly written. We only want specific versions of translations for the specific modules in our distro. We don't want to install all those modules on our localization server just to retrieve their translations; we only want to retrieve their translation files.
The use case looks very similar to the one that Jose Reyero wrote up for Open Atrium.
Comment #15
sutharsan commentedIf you want to use l10n_update as a translation collector, don't rely on the standard solutions. You are way of the standard use of the module and if you wander in unmarked territory, you should bring your own tools. In this case develop your own code based on what is available and contribute back what may be useful for others. In your case read the l10n_update.api.txt and use the alter hook described there.
For others, use the latest dev-release and check your watchdog for occurring errors. Hopefully you find some new information there.
Comment #16
inkling commentedIf #15 was aimed at me, I recognize that I'm not using the module in a standard way. Ace Cooper's case (#12) looked similar to what we were doing, and I had just been through that code, so I responded with something that I thought might be helpful for him, in an attempt to contribute. My apologies if I didn't.
Comment #17
llaumgui commentedIs it possible to use Drupal 7.17 iplementation and pass proxy ?
"Added proxy server support to drupal_http_request()." => http://drupal.org/drupal-7.17-release-notes
Comment #18
mkesper commentedThe attached path worked for me. Apparently the l10n_update_http_request has problems with proxies.
Edit: This patch is against 7.x-1.0-beta3.
Comment #19
groovehunter commentedthe patch in comment above contains
I guess that is not according to patch guidelines. But I am still learning myself about patches.
So I practices a while with diff and patch and tried to produce a p1 level patch with same desired result. at least there is just one line changed - I post it here so you please easily see if I got it right.
I also attached it. And try to apply it via makefile. But it fails and I can't check what's the prob, also because the build dir is deleted when drush exits
Comment #20
groovehunter commentedgrrr the original and new files are mixed up. hope it did not confuse anybody up to now
Comment #20.0
groovehunter commentededit2
Comment #21
dustin.nielsen.questionmark commentedSo, I had this issue come up on a fresh install of Drupal. After doing some debugging and looking into it, I discovered what the issue was for me at least. I had the Update Manager core module enabled. If that module is enabled then Localization Update uses the latest version returned by it, instead of the installed version (see lines 46-48 in l10n_update.project.inc). For me, this meant it was looking for Drupal Core 7.24, of which no translations exist for yet, even though I had 7.23 installed and had not updated.
Is this expected behavior? As it does cause some issues for us.
Comment #22
sutharsan commented@ArakTaiRoth, this problem should not occur in the latest dev release anymore.
Comment #23
sutharsan commented@mkesper, @groovehunter, these patches will fail when the module is used during installation. See the comment in the code with the
l10n_update_http_request()function. But proxy support is in (dev release) since dec. 2012. See https://drupal.org/node/1863544Comment #24
marcvangendIf it helps anyone: occasionally my Apache does not allow outgoing requests (like the calls to the localization server) for some reason. This results in the error messages described in #1. Restarting Apache solves the problem.
Comment #25
Jazoja commentedOur campus server (Ubuntu 13.10 + Apache 2.4.6) is behind a (forward) proxy.
I set the proxy settings in settings.php. (the same way as I set proxy settings in my browser or in windows)
Now Drupal (v7.24) can download and refresh modules but cannot fetch localization updates.
I have no idea why.
The same happens when I install drupal on localhost (Win7).
Without proxy (on a different network) everything works fine.
(I haven't applied any patch yet.)
Comment #26
gábor hojtsy@Jazoja: that would be due to #2124931: Update l.d.o syncing for d.o update of project data.
Comment #27
Jazoja commentedThanx! After your answer, I got in my mind that when a patch is available, then maybe it is already put into the newest dev. As I see, updating to the latest dev version (Localization update 7.x-1.0-beta3+16-dev) solved my problem.
Comment #28
interdruper commentedLast dev version of Localization update does not solve the problem for brand new v7.24 installations.
I am afraid that we have to wait for the resolution of #2124931: Update l.d.o syncing for d.o update of project data, as Gábor pointed out.
Comment #29
sutharsan commentedThe l.d.o issue has been fixed and recent (core) translations are available again. Closing the issue.
Please open a new issue if you have problems with translations not being found.