Last modified: 2007-11-30 17:13:00 UTC
I've been upgrading MW 1.8alpha installations to MW 1.9-svn on the following languages: uncyclopedia:pt:, uncyclopedia:ja:, uncyclopedia:fi: so far and all show the same problem - the infamous <searcharticle> text (which should be the "go" in the [Go] [Search] buttons under the search box) and similar errors in displaying other common messages such as: MediaWiki:Searcharticle MediaWiki:Editundo MediaWiki:Badaccess-group1 MediaWiki:Lastmodifiedat MediaWiki:Templatesusedpreview MediaWiki:Mypreferences MediaWiki:Protectedpagetext MediaWiki:Viewsourcetext MediaWiki:Pagecategories MediaWiki:Pagecategorieslink MediaWiki:Randompage-url The install script (and the maintenance/update.php script) are not creating these messages in the MediaWiki namespace. Using Special:Export to grab the missing messages from another wiki (such as a Wikipedia in the same language) and then XML importing these is a suitable workaround, but it seems odd that maintenance/update.php is missing so many new messages. I doubt this is even specific to a single language, as I've been through three of these installs and they're all exhibiting the same issues until the extra messages are added to the database.
If this is the case, then check that the messages themselves are defined in the i18n files - MediaWiki should be falling back to these if other sources fail. Check that you've updated every file in the package.
Make sure: 1) you have a current, correct 'languages' subdirectory 2) the 'serialized' directory either doesn't contain .ser files for messages or is up to date If you have old Messages*.ser files in there, either remove them or regnerate current data. You can genreally do this by running 'make'; this requires a working command-line 'php' in the PATH.
Removing them isn't going to fix the problem - if they haven't been generated (with make) the new messages are missing. If you use a current, correct 'languages' subdirectory and the 'serialized' directory doesn't contain .ser files, the problem appears. That's with a clean install of the current set of /phase3 files to a new subdirectory, retaining and using just the database, images and some extensions from the previous MW1.8 installation. Typing '''cd serialized;make''' to generate the .ser files causes the problem to goes away. The translated [Go][Search] buttons then display as [Go][Search] in that language instead of [<searchindex>][Search] or its equivalent. I don't recall any of the previous MW versions having required '''cd serialized;make''' in order to get the complete set of localised strings, but this is good to know in order to ensure smooth MW1.9 upgrades of other language wikis on the site. Thank you, Carl
No, if the serialized files are not there the live PHP files are used. It's only when stale serialized files are present that the defaults in the PHP files are ignored. It is not required to generate serialized files to operate the wiki properly; only having stale files is a problem.
The wiki will operate if the serialized files are not present, it's just the newly-added messages for MW1.9 that are missing (based on using maintenance/upgrade.php or the install script to migrate an existing database from MW1.8).
No, they are *not* missing in that case. If they were missing in that case, we would notice this during development when things are added to the files and there are no serialized files present. In fact however we do not notice this effect, because it does not happen. The new messages do in fact show up as expected.
On a clean install to an empty database, everything looks fine. Only time I see these issues is on upgrade from 1.8 - and, in those cases, using make to build the serialized files fixes everything.
(In reply to comment #3) > Removing them isn't going to fix the problem - if they haven't been generated > (with make) the new messages are missing. That is *exactly* the caveat referred to at the bottom of the README file in the serialized/ directory. That is *exactly* how it works. We *may* want to make the software skip serialized cache files where they are apparently out of date, i.e. where the original messages file appears to be newer. I'm refocussing the bug to that.
It now checks by default since r27983.
