Comments

Maksym Kozub’s picture

Maksym Kozub CreditAttribution: Maksym Kozub commented
Title: "Error importing interface translations" bug during installation » "Error importing interface translations" during installation
catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented
Title: "Error importing interface translations" during installation » Interface translation import times out during install
Version: 7.0 » 8.x-dev
Component: language system » locale.module
Issue tags: +Needs backport to D7

This will need to be fixed in 8.x first, then backported.

How long is your nginx timeout set at?

Are you able to log into the MySQL command line and run SHOW PROCESSLIST while the translations are being imported?

Do you have any experience with profiling tools like xdebug or xhprof? If so it would be interesting to see the results.

There are probably two things we could do here:

* use the batch API for importing translations, this would likely fix both issues but I haven't looked into it.
* try to optimize the import itself.

Also there are a lot of inserts done with this - could you post your setting for innodb_flush_log_at_trx_commit?

I'm leaving this at critical for the moment, because it effectively breaks the installer altogether for non-English installs, and the other report suggests this is affecting at least two people.

Maksym Kozub’s picture

Maksym Kozub CreditAttribution: Maksym Kozub commented

How long is your nginx timeout set at?
send_timeout 180 s
proxy_read_timeout 300 s
proxy_connect_timeout 150 s
client_body_timeout 180 s
client_header_timeout 180 s

nginx serves as a proxy for Apache here. PHP works as CGI (not as mod) under Apache. In such environment, nginx's fastcgi_..._timeouts seem to be irrelevant. However, if you still need those or any other timeouts, please let me know and I will ask the hosting guys.

Regarding your other qustions, I am on a shared hosting. It is a good commercial one, and their technical support guys are really helpful and and cooperative, but there certainly are some limitations about console tools, logs, etc. When I have time, I will try and check with them what can be done.
I never used profiling tools, but I believe I can (relatively quickly) learn how to use them. Again, this is a question of me getting some spare time, and maybe my hosting provider letting me do something beyond the scope of their standard client tools.

Also there are a lot of inserts done with this - could you post your setting for innodb_flush_log_at_trx_commit?
The guys just confirmed it is set to 1. (I believe they just never changed the daefault value, which AFAIK is 1 in MySQL 5 :).)

...for the moment, because it effectively breaks the installer altogether for non-English installs...
Funnily enough, the non-English interface selected by the user _is_ installed, and the installation process with that non-Enflish interface continues (seemingly) OK after the user clicks on that 'error page' link. I.e., the only real effect at the moment seems to be about inexperienced users probably getting scared etc. — not about the istallation finally breaking in the middle with no chance to continue.

P.S. Of course I meant "critical", not "crucial" :).

Maksym Kozub’s picture

Maksym Kozub CreditAttribution: Maksym Kozub commented

I have just asked the hosting provider's tech support guys, and they have confirmed that they can play with server timeouts within reasonable limits upon my request, if I need it for some testing.

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented

I'm sure this is down to innodb_flush_log_at_trx_commit = 1 then - that makes innodb inserts and updates extremely slow, so could easily lead to a timeout.

Could you ask your hosting provider to change that to either 0 or 2 then try again?

Now that we default to installing with innodb, we are going to be running into this issue more and more often - so should look at adding a hook_requirements() check for it. There are very few Drupal websites that need to run with this set to 1.

Maksym Kozub’s picture

Maksym Kozub CreditAttribution: Maksym Kozub commented

Could you ask your hosting provider to change that to either 0 or 2 then try again?
Will do that either tonight or tomorrow.

Now that we default to installing with innodb, we are going to be running into this issue more and more often - so should look at adding a hook_requirements() check for it.
Do you mean checking that innodb_flush_log_at_trx_commit is not set to 1? If so, it may be difficult to handle shared hosting environments: somebody else may just need it set to 1.
(Real-life example here. Yesterday I found out that my hosting provider runs PHP with register_globals on. I called them and asked "Why not switching it off and make those who strictly need it swith it "on" themselves for their sites, instead of making me copy php.ini and add "register_globals off" to it?". The answer was "You know, _many_ old clients have their scripts written in such way that they need "register_globals on", and we do not have many clients unhappy with it, like you are. So, we do not want to force that majority to set up any extra parameters"...)

plach’s picture

plach
he/him
Primary language Italian
Location Venezia
CreditAttribution: plach commented
Status: Active » Postponed (maintainer needs more info)

We are missing a feedback here.

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy commented
Status: Postponed (maintainer needs more info) » Closed (duplicate)

This is a duplicate of #569004: Add support for seek based batch import of .po files (yes, I know its not a core issue, but it belongs to a modifiable copy of the core code). I'm not sure Drupal core would allow the API changes required to fix this in Drupal 7. It is certainly to be done in Drupal 8. Until then l10n_update should be used and it's copy of the core code should get fixed.

Maksym Kozub’s picture

Maksym Kozub CreditAttribution: Maksym Kozub commented
Status: Closed (duplicate) » Active

Gábor, I would not call it a duplicate. Your 569004 is about improving the import speed/efficiency. Such improvement may eliminate the issue I described here... or it may not.
On the other hand, I have finally experimented with InnoDB parameters, and setting innodb_flush_log_at_trx_commit (which used to be set to 1) to 2 makes install run smoothly. Maybe it could be worth including a note in the documentation for 7.x? E.g. "For tecnically savvy users: when importing translations into the database as part of the installation process, a lot of database inserts are done. If you are in control of MySQL parameters, you may want to avoid setting innodb_flush_log_at_trx_commit to 1, since this may result in translation import timeouts".

marcingy’s picture

marcingy CreditAttribution: marcingy commented
Status: Active » Closed (duplicate)

The point made in last comment is a duplicate of http://drupal.org/node/817398

gravious’s picture

gravious CreditAttribution: gravious commented

After installation I had a mix of Dutch (nl) and English. Deleting and adding the language in Drupal gave a constraint violation.
I deleted nl from locales_target with delete from locales_target where language='nl' in mysql console.

Then added the language back in Drupal. The progress bar wouldn't move so I made a batch file show.bat:

cls
:start
    @[path to mysql.exe]mysql -u [username] -p[password] -e "use [databasename]; select count(1) as nrOfRecords from locales_target where language='[language code]'" 
    @timeout /t 1 > nul
    cls
@goto start

Change the following fields:

  • [path to mysql.exe] with the correct path to your mysql installation (e.g. C:\wamp\bin\mysql\mysql5.5.20\bin\)
  • [username] and [password]with the correct mysql username and password for your database
  • [databasename] and [language code] with the correct database name and language code you are

using.

The @timeout /t 1 > nul will only work on Windows 7. It will delay 1 second and then the mysql query executes again refreshing the number of records. It will slowly increase from 0 to 4668 in my case while processing the nl language file.

After finishing the user registration page now displays in Dutch completely.

justswimm’s picture

justswimm CreditAttribution: justswimm commented

Regarding Drupal 7.14-stable:
Thank you, this innodb_flush_log_at_trx_commit thing really helped. I have spent almost full 2 days trying resolving this issue and really do not understand how someone can write code that way (on drupal side) and if so then I can get that there is no fix for so long. But okay, now it works and I will count with this issue in future.

Maybe it will not work itself alone, so I have (prior this change) made additionally a raise of memory and timeout limits on both, server and PHP, side and import of translation was made by I10n_update module.

Thank you again.

Valera Tumash’s picture

Valera Tumash CreditAttribution: Valera Tumash commented
Version: 8.x-dev » 7.15

Regarding Drupal 7.15-stable
Changing MySQL my.conf setting innodb_flush_log_at_trx_commit to 2 has helped me as well:

[mysqld]
innodb_flush_log_at_trx_commit=2

It would be nice adding some info about it in profiles/translation/README.txt

MarkDQ’s picture

MarkDQ CreditAttribution: MarkDQ commented
Issue summary: View changes

I tried today installing 7.34 with the Dutch language, installation hangs at "importing interface translation".

This issue is closed (duplicate), so where to find the other issue?
The one that is mentioned, is also closed (duplicate) and refers to this issue.

Or is this issue completely abandoned?

(This is my second reaction, the first one disappeared after clicking on "preview")