Page MenuHomePhabricator

Ignore out-of-date serialised message caches
Closed, ResolvedPublic


Author: carlb613

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:


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.

Version: unspecified
Severity: normal



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:33 PM
bzimport set Reference to bz8396.
bzimport added a subscriber: Unknown Object (MLST).

robchur wrote:

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.

carlb613 wrote:

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

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,

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.

carlb613 wrote:

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.

carlb613 wrote:

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.

robchur wrote:

(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.