Once again I took the fight with Koha to try to make it work with non ASCII characters. I've set the the following variables for MySQL, Apache and PHP: vim /etc/apache2/apache2.conf AddCharset UTF-8 .utf8 AddDefaultCharset UTF-8 vim/etc/php5/apache2/php.ini default_charset = "utf-8" vim /etc/mysql/my.cnf [client] character_set_client=utf8 [mysql] default-character-set=utf8 [mysqld] init-connect = 'SET NAMES utf8' character-set-server=utf8 collation-server=utf8_swedish_ci /etc/rc3.d/S19mysql restart mysql> SHOW VARIABLES LIKE 'character_set%'; +--------------------------+----------------------------+ | Variable_name | Value | +--------------------------+----------------------------+ | character_set_client | utf8 | | character_set_connection | utf8 | | character_set_database | utf8 | | character_set_filesystem | binary | | character_set_results | utf8 | | character_set_server | utf8 | | character_set_system | utf8 | | character_sets_dir | /usr/share/mysql/charsets/ | +--------------------------+----------------------------+ 8 rows in set (0.01 sec) mysql> SHOW VARIABLES LIKE 'collation%'; +----------------------+-----------------+ | Variable_name | Value | +----------------------+-----------------+ | collation_connection | utf8_general_ci | | collation_database | utf8_swedish_ci | | collation_server | utf8_swedish_ci | +----------------------+-----------------+ 3 rows in set (0.00 sec) However when I try to add an item it cuts of the text at the non ASCII char. Please look at the pictures here to see what I mean: http://thommym.blogspot.com/2009/01/koha-and-utf-8.html Also in I add text for members etc. with non ASCII chars in it it is cut at the non ASCII position. So, anyone to my rescue???
Thommy M. Malmström a écrit :
Once again I took the fight with Koha to try to make it work with non ASCII characters. I've set the the following variables for MySQL, Apache and PHP:
hey, it's it koha 2.2.x !!! there were a lot of problem with diacritics handling in 2.2.x It worked quite correctly with latin1 and Unimarc, but not with utf-8 or marc21 You must upgrade to 3.0 ! HTH -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
paul POULAIN wrote:
Thommy M. Malmström a écrit :
Once again I took the fight with Koha to try to make it work with non ASCII characters. I've set the the following variables for MySQL, Apache and PHP:
hey, it's it koha 2.2.x !!!
there were a lot of problem with diacritics handling in 2.2.x It worked quite correctly with latin1 and Unimarc, but not with utf-8 or marc21
You must upgrade to 3.0 !
I can't upgrade as my users are just fine with 2.2.9. It's just to big a step to change it... So what you say is that I should go for latin1 at all config parameters? My z3950 server is MARC21 so I suppose I've to stay with that... I'll give it a try...
Thommy M. Malmström wrote:
paul POULAIN wrote:
Thommy M. Malmström a écrit :
Once again I took the fight with Koha to try to make it work with non ASCII characters. I've set the the following variables for MySQL, Apache and PHP:
hey, it's it koha 2.2.x !!!
there were a lot of problem with diacritics handling in 2.2.x It worked quite correctly with latin1 and Unimarc, but not with utf-8 or marc21
You must upgrade to 3.0 !
I can't upgrade as my users are just fine with 2.2.9. It's just to big a step to change it...
So what you say is that I should go for latin1 at all config parameters? My z3950 server is MARC21 so I suppose I've to stay with that...
I'll give it a try...
Here's the changes I did and it seems to work. THANKS, BIG THANKS to you Paul. You really saved my day. Send me your address and I'll send you some flowers. vim /etc/apache2/apache2.conf ----------------------------- #AddCharset UTF-8 .utf8 #AddDefaultCharset UTF-8 AddDefaultCharset ISO-8859-1 AddCharset ISO-8859-1 .iso8859-1 .latin1 vim /etc/php5/apache2/php.ini ---------------------------- #default_charset = "UTF-8" default_charset = "ISO-8859-1" [client] default-character-set=latin1 #[php-cgi] #default-character-set=latin1 [mysql] default-character-set=latin1 #[mysqladmin] #default-character-set=latin1 [mysqlcheck] default-character-set=latin1 [mysqldump] default-character-set=latin1 [mysqlimport] default-character-set=latin1 [mysqld] init-connect='SET NAMES latin1' character-set-server = latin1 default-character-set = latin1 collation-server=utf8_swedish_ci
I was to quick to say YES (Sorry Paul, no flowers). All my problems wasn't solved by setting it Latin1. As there are so many parameters it's almost impossible to keep track of all changes. I'm doing the standard thing of changing just one parameter at the time but it grows to a three that is extremely big. There are at least 4 different major places to set the character encoding schema and that yields 4!=24 different combinations. It's just to much as I have to kill the database and start the perl installer.pl part over each time... Thommy M. Malmström wrote:
paul POULAIN wrote:
Thommy M. Malmström a écrit :
Once again I took the fight with Koha to try to make it work with non ASCII characters. I've set the the following variables for MySQL, Apache and PHP:
hey, it's it koha 2.2.x !!!
there were a lot of problem with diacritics handling in 2.2.x It worked quite correctly with latin1 and Unimarc, but not with utf-8 or marc21
You must upgrade to 3.0 !
I can't upgrade as my users are just fine with 2.2.9. It's just to big a step to change it...
So what you say is that I should go for latin1 at all config parameters? My z3950 server is MARC21 so I suppose I've to stay with that...
I'll give it a try...
Hi Thommy, On Tue, Jan 6, 2009 at 7:19 AM, "Thommy M. Malmström" <thommy.m.malmstrom@gmail.com> wrote:
I was to quick to say YES (Sorry Paul, no flowers). All my problems wasn't solved by setting it Latin1. As there are so many parameters it's almost impossible to keep track of all changes. I'm doing the standard thing of changing just one parameter at the time but it grows to a three that is extremely big. There are at least 4 different major places to set the character encoding schema and that yields 4!=24 different combinations. It's just to much as I have to kill the database and start the perl installer.pl part over each time... 3.0 is the only UNICODE safe version of Koha. Getting 2.2.9 in a UNICODE safe state would require a lot of effort, modifications to the database definitions, templates, and Perl modules. I'd highly suggest you upgrade to 3.0, which has a lot of other improvements.
Cheers, Josh -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
Joshua Ferraro wrote:
Hi Thommy,
On Tue, Jan 6, 2009 at 7:19 AM, "Thommy M. Malmström" <thommy.m.malmstrom@gmail.com> wrote:
I was to quick to say YES (Sorry Paul, no flowers). All my problems wasn't solved by setting it Latin1. As there are so many parameters it's almost impossible to keep track of all changes. I'm doing the standard thing of changing just one parameter at the time but it grows to a three that is extremely big. There are at least 4 different major places to set the character encoding schema and that yields 4!=24 different combinations. It's just to much as I have to kill the database and start the perl installer.pl part over each time... 3.0 is the only UNICODE safe version of Koha. Getting 2.2.9 in a UNICODE safe state would require a lot of effort, modifications to the database definitions, templates, and Perl modules. I'd highly suggest you upgrade to 3.0, which has a lot of other improvements.
Well, I suppose I'll have to give up on 2.2.9, however my users (librarians) are not easy to convince. I also think I'll have another set of million problems as I have to convert the current database (in latin1) to the new and utf8. This is NOT easy and the docs seems not accurate. But I'll give it a try later...
I also think I'll have another set of million problems as I have to convert the current database (in latin1) to the new and utf8. This is NOT easy and the docs seems not accurate.
You are correct this is a burdensome task. The wiki describes how to handle the conversion in-place in the same DB version. Last I checked, it did not describe migrating and converting at the same time. I would suggest approaching the UTF8-conversion as a separate task from the Koha upgrade. I'm not sure which order would be best, but I would be tempted to work on the data conversion before the upgrade so that you can identify any problems from that in a version of Koha known to you. Perhaps someone who has done more 2.2 -> 3.0 upgrades can offer their wisdom.... -Joe
Joe Atzberger a écrit :
I also think I'll have another set of million problems as I have to convert the current database (in latin1) to the new and utf8. This is NOT easy and the docs seems not accurate.
You are correct this is a burdensome task. The wiki describes how to handle the conversion in-place in the same DB version. Last I checked, it did not describe migrating and converting at the same time. I would suggest approaching the UTF8-conversion as a separate task from the Koha upgrade. I'm not sure which order would be best, but I would be tempted to work on the data conversion before the upgrade so that you can identify any problems from that in a version of Koha known to you.
Perhaps someone who has done more 2.2 -> 3.0 upgrades can offer their wisdom....
We (BibLibre) have done more than 20 2.2-> 3.0 upgrades with what the wiki describes (http://wiki.koha.org/doku.php?id=22_to_30), and I never had any problem -the most recent one being this morning !). However, I'm UNIMARC, maybe that explains... -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
participants (5)
-
"Thommy M. Malmström" -
Joe Atzberger -
Joshua Ferraro -
paul POULAIN -
Thommy M.