Changed component to SpecialPages. Not an i18n issue.

(In reply to comment #0)

I'm getting a Fatal Error when viewing Special:AllMessages:

Fatal error: Allowed memory size of 52428800 bytes exhausted (tried to allocate
954416 bytes) in
/home/yourwiki/htdocs/html/w/includes/specials/SpecialAllmessages.php on line
208

This should be fixed by adding pagination or something like that. This is
reproducible if you have a lot of modified system messages.

Does r45141 work for you?

alexfusco5 wrote:

no same error still happening (and yes I did svn up)

(In reply to comment #3)

no same error still happening (and yes I did svn up)

Try setting memory_limit = 80M in php.ini

ayg wrote:

AllMessages *seriously* needs to be paginated. It's way too big, not just from a memory usage standpoint.

Updated summary to reflect need for pagination.

Created attachment 5634
Test patch against r45241 adding some debug lines checking mem usage

Here's the memory_get_usage() results I get on my installation during various points of the rendering using this patch:

memory 1: 13744240 near start of special page
memory 2: 26570352 +13M after $wgMessageCache->loadAllMessages();
memory 3: 27037696
memory 4: 27037704 +0.5M after merging extensions, sorting to $sortedArray
memory 5: 31358432 +4M after creating $messages
memory 6: 33826000 +2.5M after rendering HTML output

By far the biggest memory-user is just loading all the message texts to begin with, eating 13 megabytes. Yeowch! This is potentially hard to trim, as it could require changing the localization infrastructure.

Building the array of sorted & transformed messages adds ~4 megabytes, and another ~2.5 megabytes gets used up making the HTML output. These could be reduced relatively easily by using a more compact rendering and/or doing some paging.

(Your sizes will vary depending on system architecture, installed extensions, and what's in your localized messages.)

If paging is done, we'll want a better integrated search, so it's still at least as easy as now to find a particular message based on name or content substring.

attachment messages-mem-profile.diff ignored as obsolete

• Bug 17800 has been marked as a duplicate of this bug. ***

• Bug 15389 has been marked as a duplicate of this bug. ***

dasch wrote:

I think the problem is that with a rising number of extensions and personal changes the whole thing gets to big, I think the sugestion from Bug 15389 is a good beginning to solve this problem

dasch wrote:

I think there should be two things made

1. The messages should be grouped by extensions, so every extension and the mediawiki core messages should all get a single page
2. The messages should be paginated, maybe the way that there are only 50 or 100 messages per page

I think this is a very critical point so there should be created a solution very soon

• Bug 18439 has been marked as a duplicate of this bug. ***

• Bug 18610 has been marked as a duplicate of this bug. ***

happy.melon.wiki wrote:

Paginate Special:Allmessages using TablePager, against r50159

I've been working on a complete solution to this and related bugs, using the TablePager class that is used in, for instance, CodeReview and the AbuseFilter. This framework provides a nice way to paginate large data sets such as Allmessages. Notable features include:

*Server-side filtering by customisation state (modified, unmodified or all), and by prefix
*Integrated language selection
*No horizontal scrolling
*No javascript :D

The one aspect of the implementation that I'm not entirely happy with is the need to pretend, for the benefit of TablePager and its parent IndexPager, that the data was drawn entirely from the database. To do this, I had to write a FakeResultWrapper class that could be loaded with the message array and that would then spit out the results in the manner IndexPager expects from a real database. The alternative was to overload so many of IndexPager's core methods (extractResultInfo, getBody and formatRow, at least) as to rather defeat the object of using the framework in the first place. With the FakeResultWrapper, new features would have to be implemented to ResultWrapper itself, and utilised in TablePager, in order to cause breakages.

The only breaking change is the removal of the variable output formats; only HTML is now supported. Both PHP and XML-formatted lists are now available through the API; this should certainly be the access point for scripts that need a machine-readable list of the messages. The PHP output was added almost exactly five years ago (r3454), from the time when message defaults were still specified in the database, XML 18 months ago (r27389). I'll CC both committers, but I think that this functionality should be accessed through the API. Admittedly there is currently no way to get the 'original' message through the API, but that's a separate bug.

comments/criticisms would be much appreciated. The patch only blanks phase3/skins/common/allmessages.js for some reason; that file is actually now unused and can be deleted.

attachment bug16497.txt ignored as obsolete

Applies cleanly and works well here. Have a strict standards bug though, on line 92 of the patched SpecialAllmessages.php:

"Non-static method TablePager::getHiddenFields() should not be called statically, assuming $this from incompatible context"

happy.melon.wiki wrote:

Revised patch, still against r50159

Hmn, I guess this could be resolved by calling the method from the TablePager instance that's actually created? This revised patch should do this. I've also added some replacement CSS; this resolves bug7006.

Attached:

happy.melon.wiki wrote:

Anyone planning on doing anything with this?

Glad something is going to be done soon, else it is the click of death
(well, 5 minute freeze) for my browser (emacs-w3m), so I was going to
say maybe make php the default output mode, instead of the giant HTML
table).
$ for i in php html xml; do echo -en $i:\\t

GET -P ...title=Special:AllMessages\&ot=$i|Ac -c; done

php: 164635
html: 1586231
xml: 209453

happy.melon.wiki wrote:

PHP was once the default mode, but was replaced with the human readable form because, well, it's not the human-readable form :-D It's a human-facing page, ergo it should have pretty human-readable content. For a machine-readable form, go to the API.

Even with the limit set to 5000, so all the entries display, the TablePager version is still significantly more compact: I make it 1.31Mb vs 2.27Mb; not sure how that meshes with your stats, but it would be a significant saving even if it were only 200kB.

Done in r53286

folengo wrote:

I had asked for this in duplicate bug 15389, and I must say that it works fine now. Thank you.