pdhanda wrote:

Hi Tisza,

The article size is configurable on a site wide basis as far as I can tell.
http://www.mediawiki.org/wiki/Manual:$wgMaxArticleSize

Does that not work for you? Or did I misunderstand your issue?

-p

(In reply to comment #1)

Hi Tisza,

The article size is configurable on a site wide basis as far as I can tell.
http://www.mediawiki.org/wiki/Manual:$wgMaxArticleSize

They're not the same. MaxArticleSize (2M by default) is the upper limit on the size of a page, but the longpagewarning is the thing that pops up above the edit box and says "This page is nn kilobytes long. Some browsers may have problems handling pages approaching 32 kb." (paraphrasing). The 29K limit used for toggling this message is requested to be configurable.

$wgMaxArticleSize is a hard limit (2MB)

But I think he wants to change the limit at wikipedia, not at his personal wiki.

I remember brion wontfixing a similar request some years ago. Even if those browsers
are not popular now, they are still affected. I'd be reluctant to change that limit.

Yes, I would like to change it at Wikipedia eventually (or at least at some wikipedias, based on the preference of the local community). Even if there are browsers like Netscape 4 or Opera 6 in a significant amount (which I doubt), and even if we decide to care about them (which we have no reason to - unlike the workplace lock-in for IE6, there is no legitimate reason to still use something like NS4, and if you do, it is your own problem if websites suck), the message is little help for them if it is not followed, and well-developed articles are usually way above 32k. The only thing it does is confuse newbies, thus it is usually hidden in some way (on enwiki it is changed in a totally pointless statement about current size if the text size is below 70k).

and if you do, it is your own problem if websites suck

The problem is not viewing the website badly, but having the browser silently? remove a large chunk of page because it can't handle large textareas.
A capability check would be preferible, though.

pdhanda wrote:

doh! I see what you mean now.

A few possible solutions:

• make it configurable
• investigate the limit on various browsers and display a better message only for those browsers
• find a workaround for the browsers that have a problem (may be more trouble than it is worth)

Any thoughts?
-p

mike.lifeguard+bugs wrote:

(In reply to comment #4)

the message is little help for them if it is not followed, and well-developed
articles are usually way above 32k. The only thing it does is confuse newbies,
thus it is usually hidden in some way (on enwiki it is changed in a totally
pointless statement about current size if the text size is below 70k).

This is certainly true. The warning seems to serve no purpose, since it is never heeded. Shouldn't it simply be removed?

A quick look at how the 3 biggest Wikipedias dealt with this message shows that 2 of them have modified it to only show the size of the page (en, de) and one of them (fr) even removed it completely because it is "useless and scares new editors".

We have some browser statistics < http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm > and information about problematic browsers ([[Wikipedia:Article size#Web browsers which have problems with long articles]]; it might be worth investigating how many users can be affected by this limit (keeping in mind that these stats are for all users, and afaict the limit is only about text areas in /edit/ mode).

Overall I would lean towards removing the message completely. Most users don't care about the size of the page. Even an configurable option to enable it on a per-wiki basis seems overkill; people who really need to know a page's size can still use the {{PAGESIZE}} magic word (see [[mw:Help:Magic_words]]).

Using {{PAGESIZE}} for that would be ugly. The proper way would be to use a gadget, like http://es.wikipedia.org/wiki/Usuario:Platonides/TamArticulos.js

I've previously talked about just removing the feature, but the users I was talking to complained that a warning was still needed for editorial policy purposes. If we want to take that approach, the size should be configurable, the warning should be off by default, and the message name should be changed so that the localised messages can be rewritten to indicate that the size warning is about policy, not browser compatibility.

I too would prefer the warning to be kept (with a configurable lower limit, off by default) for policy warnings. (Guillaume: at least on enwiki, the warning does have useful content, but it is hidden with parser function constructs unless you view it on a page that is over 70K or so.)

As for backwards and mobile compatibility, a capability check in the strict sense (actually performing POST requests) is not an option; the server could send the page size instead and the browser could send it back, and both could make a sanity check based on that, but the server counts in bytes and the browser in characters, and converting between the two is probably slow. Alternatively, the browser could attach some unique string to the end and the server check for it, but that only works if the text is truncated on posting and not on populating the textbox, and I would expect the opposite to be true.

Hard coded limit for long page warning removed with r77148. New message [[MediaWiki:Longpage-hint]] (empty per default) can be used instead. Parameters: $1 shows the formatted textsize in Byte/KB/MB, $2 is the raw number of the textsize in Byte

Why not simply remove the hard-code and change
($this->kblength > 29) to ($wgMaxRecommendedArticleSize > 0 && $this->kblength > $wgMaxRecommendedArticleSize)
It would be more efficient than using a message and especially parser functions for users who want to keep the warning.

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