I has similar problems, you can convert manually with iconv, and after try and pray for normal update. On my system fails. Do that: iconv -f iso-8859-1 -t utf-8 olddatabase.sql > new_utf9_database.sql and after try to update to 1.5.x from webbrowser directly, without upgrade1_5.php script. I was trying to use it and fails too. Other question are images, i dont know if you need to convert image names too... Tell me all result, im on same situation. All information are welcome... Good Luck ;-D Andre Oliveira da Costa escribió:

I think..... Because is OFFICIALLY UNDOCUMENTED, i dont have a specific url where i can know how to convert from iso to utf. (<jokemode> Yes im a lammer and what!... ;-P</jokemode>) If you convert your database into UTF-8 you dont need to use upgrade1_5.php script, so you can upgrade 1.5.2 directly from webbrowser. I dont have any lost information using iconv, but i dont try it with images on file system, database is a thing, and files into /image dir other, you know? ;-) And yes, to pass to 1.5.x is inevitable because is OBLIGATORY. Direct show problems.... Try to use iconv and upgrade directly like the braves.....send me all information, please. All information are welcome.... Good Luck, again.... p.d.: At this point im thinking to setup a "fucked by mediawiki software upgrades" forum....Programmers, dont be furious with me please, you are make a good work, but do all programmers do, dont document your programs....When open software will be open software with open documentation :-S.... Andre Oliveira da Costa escribió:

If you can upgrade to 1.5.x. Please write your story here: http://meta.wikimedia.org/wiki/Help:Upgrading_MediaWiki I have a spanish wiki and iso conversión are more difficult. bye. erchache2000 escribió:

Hi Brion, On Wed, 09 Nov 2005 12:23:57 -0800 Brion Vibber &lt;brion(a)pobox.com&gt; wrote: Ok, got it. Any chance this iso-8859-1 --> utf-8 problem will get fixed on future releases? Thks for the explanation. At least now I have a more precise picture of the problem... Best, Andre -- Andre Oliveira da Costa (costa(a)tecgraf.puc-rio.br)

On Wed, 09 Nov 2005 13:43:10 -0800 Brion Vibber &lt;brion(a)pobox.com&gt; wrote: Mmmh... "Houston, we got a problem" ;-) Not sure why it didn't work for me, then. Does my description of the problem on bug #3898 [http://bugzilla.wikimedia.org/show_bug.cgi?id=3898] give you any clue about what could have failed on my upgrade (and, judging by some of the replies, on others' as well)? If not, what additional info can I provide to help you track down the problem? Best, Andre -- Andre Oliveira da Costa (costa(a)tecgraf.puc-rio.br)

Brion Vibber wrote: I have tracked down (actually a co-worker has the credits for this) my reason for failing to upgrade to this: - i have no access to a shell prompt to start php scripts manually - my mysql engine is of version 4.0. so there is no ALTER DATABASE command to change from latin1 to utf8 (and no, i don't know when my provider will upgrade this version) ruud habets

Hi Brion, I was finally able to dedicate some time to this. Below I post more detailed info. On Wed, 09 Nov 2005 14:23:33 -0800 Brion Vibber &lt;brion(a)pobox.com&gt; wrote: FC4, all latets updates applied, kernel 2.6.14-1.1637_FC4 PHP 5.0.4 Should I send /etc/php.ini directly to your email address? It's quite big to be posted here... php-pear-5.0.4-10.5 php-pgsql-5.0.4-10.5 php-jpgraph-1.19-1.2.fc4.rf php-snmp-5.0.4-10.5 php-mbstring-5.0.4-10.5 php-mysql-5.0.4-10.5 (I don't use all of them, some -- like snmp -- have been installed for testing purposes; actually, I don't really _use_ PHP at home, apache is off by default) MySQL 4.1.14 ~ cat /etc/my.cnf [mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock # Default to using old password format for compatibility with mysql 3.x # clients (those using the mysqlclient10 compatibility package). old_passwords=1 [mysql.server] user=mysql basedir=/var/lib [mysqld_safe] err-log=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid I don't recall doing any tweaking to it, but I can forward it to you if you need it. I haven't applied any modification on this test setup. 1.4.0 installation has some modifications, but they are related to access rights, not content. Still, if this is relevant, I can provide them to you. - extract content from mediawiki-1.5.2.tar.gz at /var/www/html - make symlink from /var/www/html/mediawiki-1.5.2 to /var/www/html/wiki PS: [wiki] = /var/www/html/wiki - create 'wikidb' DB on MySQL - create 'wikiuser' with full rights on wikidb.* - import MediaWiki 1.4.2 DB dump (with mysql -u wikiuser -h localhost -p wikidb < wikidb-dump.sql) - copy [wiki]/AdminSettings.sample to [wiki]/AdminSettings.php, configure it with proper MySQL root user/password - copy LocalSettings.php from current (1.4.0) installation to [wiki] dir - run 'php -f maintenance/upgrade1_5.php' from dir [wiki] (I captured its output in case it helps) - run 'php -f maintenance/update.php' (captured output of this one as well) - chown -R apache:apache [wiki] After this, [host]/wiki is online, but content doesn't display right -- latin-1 chars are replaced by commas. Investigating more thoroughly the problem I guess I now have a better understanding of what's happening: commas are just the way of Firefox telling me it found chars incompatible with the page encoding (sorry for the false alarm, should have realized this). In this case, latin-1 chars were left behind during the translation, and page encoding is utf-8. If I force the browser to use latin-1 encoding, page displays fine -- well, almost, some content seems to be missing. Eg. this page: http://shadow/wiki/index.php?title=Padr%F5es_de_Programa%E7%E3o&action=… which should point to a page titled "Padrões de Programação" appears as missing (i.e. link appears as ...&action=edit). If I go to the special "dead end pages" page, I see this link there: http://shadow/wiki/index.php?title=Padr%C3%B5es_de_Programa%C3%A7%C3%A3o If I follow it, "missing" content is there, with latin-1 chars (so we're back to the "commas" issue again). Page title is utf-8, but the remaining of the content is latin-1. Judging by this, it seems the upgrade1_5.php script did convert URLs (and consequently page titles) from latin-1 to utf-8, but some or all of pages content was not converted. I hope this helps you guys understand what happened -- and fix the upgrade script so that I can migrate to 1.5.2 =) Well, I would be happy to provide configuration files for MySQL and PHP, and also output from conversion scripts. Just let me know if you guys would like to take a look at them, and where should I send them to. I can also provide some content if it will help. You're 100% right, it was a silly oversight. My bad, sorry for the confusion. Still, there is indeed some problem with the latin-1 --> utf-8 conversion process... Any ideas? Anything else I could provide? Best, Andre -- Andre Oliveira da Costa (costa(a)tecgraf.puc-rio.br)

Hi Brion, On Wed, 16 Nov 2005 13:08:59 -0800 Brion Vibber &lt;brion(a)pobox.com&gt; wrote: ... wow, that's it? ;-) I thought it would be harder =) Thank God it's simple... I'll try it ASAP and post here the results. However, a couple of questions: - shouldn't upgrade1_5.php convert text entries as well? What's the point in "half converting" to utf-8? - will $wgLegacyEncoding be around on future releases? After all, remaining non-utf8 chars will be on the DB forever since the upgrade script didn't catch them. - would a "manual" conversion using iconv (as erchache2000 suggested on this thread) after upgrade1_5.php and update.php have been applied successfully convert all DB from latin-1 to utf-8? Could this have any side-effects that could compromise the DB? (eg. if images or any other binary data is stored on the DB, I don't know if iconv is smart enough not to mess with "latin-1 chars" it might find within binary content) I don't mind having latin-1 chars left behind by the upgrade process as long as $wgLegacyEncoding is not a temporary workaround, so if the answer to question #2 is "yes" you can forget I asked #3... ;-) Thks again for the help, Andre -- Andre Oliveira da Costa (costa(a)tecgraf.puc-rio.br)

Hi Brion, On Wed, 16 Nov 2005 13:46:40 -0800 Brion Vibber &lt;brion(a)pobox.com&gt; wrote: Ok, got the message ;-) Yeah, judging from this perspective, it makes perfect sense. And, after all, all that matters is that at the end of the day conversion (be it partial or full) works, and all content is accounted for and properly accessible after the upgrade (confirmation still pending on my case! ;-)) Cool. I rest my case then ;-) Ok. In other words: "don't do it unless you're pretty sure you know what you're doing" ;-) I didn't even know there could be compressed text records, but they're as much of a problem on this case as any binary file. As for me, I'll let it be as it is ;-) Thks for all the help. I will try the $wgLegacyEncoding at home and will report here the results. Best, Andre PS: BTW: IMHO some of this conversation could be summarized on the UPGRADE docs, it could save others some worries. -- Andre Oliveira da Costa (costa(a)tecgraf.puc-rio.br)

Andre Oliveira da Costa wrote: Parser cache? -- brion vibber (brion @ pobox.com)

Andre Oliveira da Costa wrote: No, the parser cache, which caches rendered wikitext output from the parser. -- brion vibber (brion @ pobox.com)

Well, im triying to upgrade and i do it on a 60%. I do all pass i put on meta.wikimedia.org, http://meta.wikimedia.org/wiki/Help:Upgrading_MediaWiki#Upgrading_to_Versio…. I describe all pases there, but i have a little problem, i can access all information except recent changes (i lost all of them...) and some images that contains punctuation signs (exists on english :-S...) like camión, méxico, etc... My database is very big and perhaps here is the problem :-(, i try to do rebuildall and so....without any success. Well, perhaps need to hit hard to computer ;-) Its looks a half stop on process... Please next mail you send write it more clear. It will welcome ;P Write again and good luck. And feel free to modify my comments....