Translation/localization import bug (Drupal 4.6.3, Fedora 4)

It might be that the php execution limit was reached. I need mroe information about this. What do you mean by "The blog fields are all empty"?

There seems to be somethig broken somewhere...

I have new install of Fedora Core 4 with all updates (so, Apache is 2.0.54-10.2, PHP is 5.04-10.4, MySQL 4.1.12-2).

I've ported a web site from a working FC3 server, also up-to date (Apache 2.0.53, PHP 4.3.11, MySQL 4.1.12 or later, with 3.23.58 shared-compat...), to a new one and expected it to work as it should. Instead, there is a screen with just some blocks, without a menu and content. Error at unserialize() (in bootstrap.inc on line 130) is logged.

Therfore, I made a clean install of Drupal 4.6.3 and tested it. As soon as I've entered accented characters (ČŠŽčšž), the problems started to appear. Entered string is displayed almost OK, just the letter č seems to be problematic (some weird 2 characters instead of it - utf8 -> 8-bit). As expected, in the database characters are not UTF-8 (database itself and a table are OK!). If I enter proper UTF-8 characters in the database directly, string is not displayed anymore through drupal, and the same error about unserialize() issue is logged/displayed again. So, obviously somewhere in the process of data transfer between browser and database, drupal converts UTF-8 characters into 8-bit ones. The same happens in the oposite direction (when displaying such characters).

On the same machine, latest CVS version of phpMyAdmin (and, older 2.6.2-pl1 as well) works OK (I am using UTF-8 everywhere, collation is utf8_general_ci, so there should be no problem about a conversion anywhere...). Therfore, I presume it is something in drupal (like some deprecated function...).

If it helps - I see in htaccess.txt you are expecting sapi to be available with PHP5 - sapi_apache2 has been available on FC3 (PHP4), but is now there on FC4 install, as SAPI shall be built-in, as I've read on PHP web site... Therfore, I've replaced mod_php4 with mod_php5 (which is there). Could this be a problem? Or, maybe mod_mysql module (I've read there are problems with mod_mysql and mod-mysqli in such a combination...)? Client API on the old machine was 3.23.58 as mentioned, but is on a new system 4.1.12.

In any case, there is something to be done about, as drupal for us, non-English users became impossible to use on a new system. And, I have to change the server ASAP.

http://drupal.org/node/29948

Simillar problems with Bulgarian. S.th. must be wrong with Drupal's dealing with character sets.

MySQL 4.1 ... character sets...? hmmm you sure your database is set up correctly? 4.1 have funny things. Also, I am not sure about mod_mysql and 4.1... I will call out for clarification on DrupalCon.

cant impot language (portguese)... nothing happens.. same problem...

i get a blank screen

am talking about the cvs version

mestre, I think your problem is related to http://drupal.org/node/34882 and not this issue

I think this issue is indeed related to character sets and collation. Drupal still supports mysql 3 and there fore does not make any use of this features. Some user reported success after changing character set to latin1.

Can those people that reported the issues please retry this and then have a look in their apache error logs.
I have a feeling this is either due to a timeout, or memory limits. At least, that I what I had, when importing locales, drupal needs a lot of time and even more resources. If this is the problem, we could add some more verbous error reporting.

bump.... 24 hours till I close this as a duplicate of the mysql collation issue.

24h long passed