MediaWiki talk:Longpagewarning

From Wikipedia, the free encyclopedia

Contents

[edit] Link to documentation

We may want to link the part of the documentation in the message, e.g.

[[Wikipedia:Page size|WARNING: This page is $1 kilobytes long]]; some browsers may have problems editing pages approaching or longer than 32kb. Please consider breaking the page into smaller [[Wikipedia:Section|sections]].

--User:Docu —The preceding unsigned comment was added by Docu (talk • contribs) 20:19, 20 December 2003 (UTC).

I gave it a shot. Let's see if anyone complains :) Dori | Talk 19:10, Jan 3, 2004 (UTC)
Having this warning in a small green font made it completely unnoticeable. If anything, a warning should be larger and in a stronger color than the default text. I've removed the size and color to make it more noticeable and delinked the word Warning so it appears black not blue or purple. Angela. 18:48, Jan 4, 2004 (UTC)

[edit] Reduce visibility

This warning used to exist primarily for technical reasons. Can we tone it down a little now that it is not a technical issue? Maybe replace "WARNING:" with "Note:"? —Christiaan 15:40, 27 Feb 2005 (UTC)

I agree, we should tone it down. "Note:" would certainly be an improvement; perhaps also shrinking the size of the text?
James F. (talk) 16:37, 27 Feb 2005 (UTC)
PROPOSAL
Note: This page is $1 kilobytes long. Under current article size guidelines, articles that exceed 32KB are considered undesirably long. Such articles should eventually be restructured in some way, perhaps by making them into a series of shorter, related articles. However, such major changes should be made with due deliberation in consultation with other active editors of the page. Read the guidelines for further information.
I don't think the type size needs to be reduced. What I think is necessary is to get rid of the upper-case word WARNING, the apparently-underlined-and-highlighted "This page is ### kilobytes long," and the language that can be taken to imply that something must be done about this right now.
(The article size guidelines should incorporate some policy advice on how best to reorganize long articles...)
If nobody screams too loudly, I'll put this (or any better suggested alternatives) in tonight (i.e. about six hours from now). Dpbsmith (talk) 19:49, 27 Feb 2005 (UTC)
OK, here goes. I've had some more thoughts about the wording. This is what I'm going to use:
Note: This page is $1 kilobytes long. Under current article size guidelines, articles that exceed 32KB are considered to be too long. It may be appropriate to restructure this topic into a related series of shorter articles, or split off a section of it as a separate article. However, these are major structural changes which should not be made hastily, and should be made by consensus decision of other editors of the page. See the guidelines for details.
In the last sentence, I'd change "which" to "that". Our article on restrictive clauses says that many writers would use "which", but quite a few of us consider it substandard. I agree with the toning down. JamesMLane 04:34, 28 Feb 2005 (UTC)

How's this?

Note: This page is $1 kilobytes long. Under current article size guidelines, articles which exceed 32KB are considered to be too long because of technical and Internet connection limits, along with some stylistic considerations. It may be appropriate to restructure this topic. However, this is a major structural change which should not be made hastily, but instead by consensus agreement among editors of the page. See the guidelines for details.

For only a few extra words, it succintly explains why this limit is in place, which I think would be quite helpful in persuading people. Johnleemk | Talk 09:55, 28 Feb 2005 (UTC)

More thoughts. Howzabout this? Dpbsmith (talk) 13:35, 28 Feb 2005 (UTC)
Note: This page is $1 kilobytes long. Pages considerably over 32KB are considered undesirable because of issues with page loading speed and readability. A former limit of exactly 32KB, prompted by technical limits in a few now-seldom-used browsers, no longer applies. Structural changes, such as replacing very long articles with several shorter articles, might be appropriate, but should be made carefully and with proper discussion beforehand. See Article size for details.
Any of the three versions here look okay to me; I was just providing my own version. I prefer keeping it as short as possible, though. Johnleemk | Talk 14:12, 28 Feb 2005 (UTC)
The current version is waaay too long.. five lines on my screen... and reads like it has all the faults of a design by committee.. can't we have "This page is longer than 32kb long. Please see [appropriate link | this page] for why this may be a problem and how to address it." ? Pcb21| Pete 14:19, 28 Feb 2005 (UTC)
Indeed - I came across the new warning earlier and was surprised at how it had grown (see similar length debate on MediaWiki talk:Copyrightwarning). I got half way through posting a similar message a while ago before my browser (guess which one) crashed.
Since this message goes at the top of the page, conciseness is critical. Would not something like "Note: This page is [ ] kilobytes long. Pages over 32KB are undesirable: see Article size for details. Please consider replacing a long article with two or more shorter articles." be better? -- ALoan (Talk) 14:55, 28 Feb 2005 (UTC)
We need to keep tinkering, I guess. I agree that conciseness is critical. I wanted to keep the details in Article size. Some think the message is better if it at least gives a hint as to the reason for the limit. The problem I have with your version is that what I think is important is to make it clear 32KB should not be considered a hard limit any more, and that something should be done about long articles but that people shouldn't feel its urgent to do something just because a page is 33K or 35K. I'm trying to get away from ill-considered splits justified by "the 32K devil made me do it."
Note: This page is [ ] kilobytes long. Pages much over 32KB are undesirable: see Article size for details.
or
Note: This page is [ ] kilobytes long. Pages much over 32KB are undesirable: see Article size for details. It may be appropriate to start discussing how this article could best be replaced with two or more shorter articles. Dpbsmith (talk) 15:14, 28 Feb 2005 (UTC)
Just now you actually plumped for:
Note: This page is $1 kilobytes long. There's no longer a hard-and-fast limit, but pages much longer than 32KB are undesirable - Wikipedia:article size for explanation. It may be appropriate to begin a discussion with fellow editors about whether this topic should be covered by two or more shorter articles, and if so, how they would best be organized.
but to me this sounds like that sort of awkward NPOV language you see in articles so often. Is
It sounds like it because, uh, well, it is... Dpbsmith (talk) 23:36, 28 Feb 2005 (UTC)
This page is $1 kilobytes long. Please see Wikipedia:Article size for why this could be too long, and how to fix it.
no good? Pcb21| Pete 22:45, 28 Feb 2005 (UTC)
I'm happy with it. Dpbsmith (talk) 23:36, 28 Feb 2005 (UTC)
Make it so. -- ALoan (Talk) 09:58, 1 Mar 2005 (UTC)
It is so. Pcb, thank you for cutting the Gordian knot. Dpbsmith (talk) 13:11, 1 Mar 2005 (UTC)
Looks good. - Ta bu shi da yu 12:48, 1 Mar 2005 (UTC)

The new message sounds awkward to me. It's also strange to say "fix it" when the message doesn't even really get across the idea that there's something that needs to be fixed. I'd suggest:

This page is $1 kilobytes long. Please see Wikipedia:Article size to learn why it could be too long and how to shorten it.

Same ideas presented in the current version, just worded a little differently. – flamurai (t) 13:55, Mar 4, 2005 (UTC)

If we really want to change it again, how about:
This page is $1 kilobytes long. Wikipedia:Article size explains why this could be too long and how the article could be shortened.
OTOH, I quite like the present versions snappy informality. -- ALoan (Talk) 14:46, 4 Mar 2005 (UTC)
As do I. I had been brooding about the wording still being too strong, and the contradictory messages of "why this could be too long" (tentative) and "fix it" (imperative). But to heck with it. It's short and sweet. We can wordsmith any nuances we like at Wikipedia:Article size, for the tiny fraction of editors that actually care and click on the link. The message has been toned down to the point where the average reader will ignore it, which is what I wanted. I mentally tried to come up with a replacement for "and how to fix it" and everything I came up with sounded like "the sort of awkward NPOV language" that Pcb21 disliked. Dpbsmith (talk) 16:10, 4 Mar 2005 (UTC)
I will support the shortest, least urgent possible candidate for replacement of this warning, in the interests of preserving screen real estate and reducing overall stress level. I think the warning is especially inappropriate when shown on Talk pages, which are often edited by newbies asking for help and which should probably not be boldly restructured by them (us). --Xiong 18:17, 2005 Mar 13 (UTC)

Note The old warning, after several changes, was replaced PCB's suggestion, namely:

This page is ### kilobytes long. Please see Wikipedia:Article size for why this could be too long, and how to fix it.

This change was made on March 1st.

Xiong, are you commenting on this latest version? Is it OK? It is certainly short. Do you think it is still too urgent? Dpbsmith (talk) 20:08, 13 Mar 2005 (UTC)

I like it. --Xiong 04:58, 2005 Mar 14 (UTC)
I do not think the "and how to fix it" is needed.
I suggest:
This page is ### kilobytes long. This may be longer than is preferable, see Wikipedia:Article size.
zoney ♣ talk 22:58, 15 Mar 2005 (UTC)
I do, too. Although I'm not 100.00% sure it's grammatical. Let's try it and see what happens. Dpbsmith (talk) 23:44, 15 Mar 2005 (UTC)
Agree. But please don't put comments out of order when adding your own. I liked the last version at 04:58, 2005 Mar 14. Now the entire point has become moot, as Somebody has fixed the engine so that it no longer invokes this template at all. (Thank You!) I'm unwatching this page, Talk to me if you like. — Xiong (talk) 02:33, 2005 Mar 16 (UTC)

[edit] Div tag

Please take extra care to close the <div> tag on this template, as well as any other HTML tags you use. Unclosed tags can do strange things to the other elements on the page. Rhobite 00:01, Mar 3, 2005 (UTC)

Ugh, can someone put some bottom margin on the div? It shows no space between it and the macro graphics. I'd be in favor of just removing the div border too, ugly. Splarka (rant) 08:32, 14 March 2006 (UTC)
True, it is much better to remove the div border. It does not look pleasing to the eye. --Siva1979Talk to me 02:04, 14 July 2006 (UTC)

[edit] Applies only to these two users?

Is it true that this applies ONLY to Firefox and Google Toolbar users. What about other toolbar users? --Siva1979Talk to me 20:42, 1 August 2006 (UTC)

Isn't this issue definitely fixed now anyway? I've not had the problem for some weeks. Are there many examples of page truncation coming through on Recent Changes lately? — sjorford++ 13:33, 14 August 2006 (UTC)

Should probably be modified to say "This issue has been fixed for the newest versions of the Google Toolbar, please upgrade if you have not yet done so." --Splarka (rant) 07:24, 15 August 2006 (UTC)
I think the Toolbar upgrades itself automatically, but I've altered the message anyway. — sjorford++ 08:57, 15 August 2006 (UTC)

[edit] Reword

People don't actually read what you tell them to, so we need to be a little bit explicit here. The worst is when newcomers see this tag and think "It is urgent that I delete material from the article to make it shorter!" I've actually seen that happen several times. I tried to clarify that it's not urgent at all, and that you're supposed to split it; not "trim" it. — Omegatron 14:21, 20 October 2006 (UTC)

[edit] 64kb extra-long article proposals

I would also like to recommend implementing the use of “long-page warning” banners unique to each category of long page, e.g. 32-63kb (extra-long), 64-96kb (super-long), etc. Presently, the only warning pages have is the following, which pops up for pages longer than 32kb when users click on the edit button:

Note: This page is XY kilobytes long. It may be appropriate to split this article into smaller, more specific articles. See Wikipedia:Article size.

Now, for articles in the range of 32-64kb, I will admit, there is room for some gray area as to article size. For articles more than 64kb, i.e. twice the recommended maximal size, however, I would recommend that we code a page such that “readers” (not editors), in a quick and easy manner, can cast their vote as to whether or not they feel an article is to long, such as:

Note: This page over 64 kilobytes long. It is strongly recommended that this article be split into smaller, more specific articles. See Wikipedia:Article size. If you feel that this article is too long click YES if not click NO.

In this manner we can collect data as to which articles readers feel are getting too long. Editors, conversely, usually have a thorough knowledge of the topics they edit and may never potentially feel that an article is too long. Please comment. Thanks: --Sadi Carnot 00:42, 5 December 2006 (UTC)

Where would this yes/no information be stored? --TheParanoidOne 06:31, 5 December 2006 (UTC)
It could be on a separate page or, for example, as a page length meter on the talk page. The monthly data could be crunched out to give a result to the effect that, for example, it might say: “66% of readers feel this article is too long” or “10% of readers feel this article is too long”, etc. --Sadi Carnot 11:20, 5 December 2006 (UTC)
Voting: no; separate warnings: unnecessary. —Doug Bell talk 22:55, 6 February 2007 (UTC)
Agree with Doug. —Mets501 (talk) 01:06, 7 February 2007 (UTC)

[edit] When does this "longpagewarning trigger"

When does this page warning trigger and where is the template coding for the other kb warnings? --Sadi Carnot 18:14, 11 December 2006 (UTC)

32 KB, and this is the only one. Older browsers truncate forms longer than 32 KB, but those browsers are becoming less and less used so it is no longer important, and articles inevitably need to be longer than 32KB, so it is just used to recommend splitting up articles, etc. when the page is is 50KB or more, which can be changed. —Centrx→talk • 09:20, 20 December 2006 (UTC)
Actually, it appears at 30KB, based on further experimentation. —Centrx→talk • 04:57, 22 March 2007 (UTC)

[edit] Let's try and get this fixed once and for all

There is something of a low-grade edit war (edit guerrilla?) going on over the phrasing of this particular message. I'll put forth a few of the versions proposed (feel free to add more) and start the discussion over their pros and cons. Before we get any further, it is crucial all understand that the mediawiki software invokes this message with a numeric argument which is measured in multiples of 1024 bytes (hence the debate).

We'll set aside whether the message should include a link or not, although if some feel this is part of the solution, it should certainly be put forth.

Urhixidur 15:13, 22 May 2007 (UTC)

"This page is $1 kilobytes long."

  • The term « kilobyte » is ambiguous, having a meaning of sometimes 1024 bytes, sometimes 1000 bytes.

"This page is $1 kibibytes long."

  • This is technically correct and unambiguous, although some seem to feel the relative newness of the term (less well known than "kilobyte") is problematic.

"This page is $1 kb long."

  • And its variants ("kB", "Kb", "KB").
    • The sheer lack of standardisation over the symbol to use seems to make this version even worse than the previous ones.

"This page is $1 Kib long."

  • And its variant ("KiB").
    • Although there is no problem with the prefix symbol, there remains one with the putative symbol for "byte".

" "

  • This is the solution reached recently on the French Wikipedia. A quick translation of the reasons put forth follows:
    • The message is needlessly scaring away beginners
    • It is ignored by the experienced users: almost all articles of quality are larger than this threshold
    • It is naïve (in its original full length version, which recommended corrective action be taken), since a user who wanted to, say, fix a typo, won't launch into the considerable effort of splitting the article or paring it down
    • It is almost undoubtedly obsolete, as any web browser suffering from such a problem must be relegated to a tiny minority of user by now

Frankly, blanking the message seems the most appealing solution by now. Urhixidur 15:13, 22 May 2007 (UTC)

  • I don't understand the need to have this message be so carefully unambiguous. Any kind of person who would care about the difference between n \times 1024 vs n \times 1000 (a 2.4% difference??) would understand what "kb" might mean in this context. (Also, how are we supposed to connect bytes to content length? Is that compressed? Counting HTML escapes? UTF-8 or UTF-16? Counting metadata? Does it round up, down, or truncate to the nearest integer?) The minuscule gain in accuracy is not worth the confusion that terms like "kibibytes" can cause. But I also think the confusion that any form of message causes is not worth the information it might impart: I think the case for "" is spot on. Unfortunately I don't know how to bold the empty string to head off my vote, but that's what it is. ;) — brighterorange (talk) 16:01, 22 May 2007 (UTC)
    To answer the question as to why the message should be unambiguous: because this is an encyclopaedia. Its only purpose is to get the facts straight. Urhixidur 02:12, 30 May 2007 (UTC)
    You can bold an empty string like this: . Using nothing at all does seem like a reasonable option, at least for articles. There are other cases where the number could be useful (e.g. the 'you might want to archive this page...' message on Talk pages, etc.), but now that it's available in the page history, that's less important. --ais523 10:58, 23 May 2007 (UTC)
    Why not have a warning for very long articles at least? —Centrx→talk • 04:22, 24 May 2007 (UTC)
    Would it be possible to use the ParserFunction #ifexpr: here to show the warning only when $1 is greater than say 100? –Pomte 22:56, 25 May 2007 (UTC)
    That would certainly help, though it wouldn't resolve the "kb" issue. If we think the message is important, perhaps there could be qualitative statements like, "this article is long" or "very long" "extremely long" for various ranges instead of numeric values, which would be less confusing to most users and would sidestep the controversy over units. — brighterorange (talk) 01:05, 26 May 2007 (UTC)
    It has to be done through helper templates. So the 50 in Template:MediaWiki longpage message could be changed to some other number. —Centrx→talk • 02:49, 26 May 2007 (UTC)
    On the kb issue, a compromise I think is to link kilobyte, so editors can click on it to understand what the number means and to find out about the ambiguity. "Very/extremely long" is vague and allows for limited comparison value compared to numbers. –Pomte 10:05, 26 May 2007 (UTC)
    I don't think it's that important. Wikipedia is not a tool for getting people to learn random things unrelated to the article at hand. The exact size of the page does not matter for this message. The message does not even give exact sizes; its granularity is at 1024 bytes, it does not say 37.8 KB, it does not say 38707 bytes, and it does not matter because the difference is so small that it makes absolutely no different to someone editting or organizing an article. —Centrx→talk • 16:16, 26 May 2007 (UTC)
    Right, and the length of the wiki code is not very closely related to the length of the article. There is too many factors for the number to be very meaningful. — brighterorange (talk) 20:10, 26 May 2007 (UTC)
    MediaWiki:Longpagewarning was created because certain older browsers and browsers with the old Google Toolbar, truncated pages that were too long byte-wise. That is no longer much of a concern, and this has been usurped for the purpose here. It was not created for reporting on article size in the context of Wikipedia:Article size. —Centrx→talk • 20:53, 29 May 2007 (UTC)
Let's put this to the vote: Should the message be blanked?
SupportUrhixidur 02:12, 30 May 2007 (UTC)
Sure though it looks like there's nobody that opposes this currently looking at this page, so I'm not sure a vote is necessary. — brighterorange (talk) 02:28, 30 May 2007 (UTC)
Decisions on Wikipedia are not made by voting. —Centrx→talk • 05:11, 30 May 2007 (UTC)
Indeed, they're supposed to be made by consensus. Voting is a means of ensuring consensus is reached. Please vote (for, against, abstain) so we can settle this. Urhixidur 02:01, 10 June 2007 (UTC)
Voting does not "ensure consensus"; in fact, even assuming that voting were a correct measure of consensus, premature votes of the form "Let's vote: Should we do this?" stifle and conflict with consensus. Especially on a page like this, and an issue like this, you will find that if you actually have any consensus the decision is clear and a vote is pointless. You have not justified the reasons for blanking, nor have you participated in the discussion above—actually looking back it appears that no reason whatsoever has been given for blanking. —Centrx→talk • 07:12, 10 June 2007 (UTC)
I don't like this degenerating into personal attacks, but I still need to straighten the record. Learn to read, Centrx, I did not say that "voting ensures consensus" but that it is "a means of ensuring consensus is reached". As for participation, I bloody well started the discussion (as I was tired of seeing the message being yanked in all sorts of directions with no end in sight), and I provided the reasons for blanking at the outset (see the bit where I mention the solution reached recently on the French Wikipedia). Urhixidur 02:41, 14 June 2007 (UTC)
You started a discussion about binary prefixes. Looking back on it, your reasons for blanking were put under the cleverly named section " "; otherwise it looked like your only reason for blanking was that you didn't think people were going to agree on which prefix to use.
  • I do not see any reason why this would scare away beginners. They can, and do, simply ignore it.
  • If the threshhold is bad, change the threshhold. If it is truly the case that many featured articles are larger than 80 kilobytes, change it to 90 or 100, but is it truly the case? I changed it from 32 to 50 in October 2006, and I changed it from 50 to 80 two weeks ago, that is after you originally posted this message. Is it still such a problem?
  • I don't see any reason why someone who is correcting a typo cannot simply ignore the message, or why editors in general may not be notified about issues with articles. We do have, for example, cleanup tags and all sorts of other tags that are placed directly on the article, which readers who are not even correcting typos, see, and those tags are large and bold and colorful. Also, this message is not shown for section editing, which is the kind of editing naive typo-fixers, or typo-fixers in general, use.
  • The original size that triggered the warning was 32KB, which has now been changed to 80. 100KB articles are still a problem, and ~20% of global Internet users[1] (20% U.S. also) are on dial-up; that's not miniscule and regardless are we to have 200KB or 300KB articles without warnings?
Also, even if this were now totally useless for articles—which it is not—it is still useful for talk pages and archives. And if you are basing your arguments on the previous 50KB, or the old 32KB, or even the current 80KB which is changeable, re-evaluate. —Centrx→talk • 06:05, 14 June 2007 (UTC)
If the message is truly obsolete (something I'm not technical enough to evaluate), it should be blanked. Otherwise, we have a problem, regardless of where the threshold is set (I assume threshold-setting is a high-level function, something Bureaucrats or higher can do?). A fair subset of Wikipedians feel simply using "kilobyte(s)" without caveating is unencyclopedic because the unit has been thoroughly spoiled, having a variable meaning (which makes it useless as a unit of measurement). However, another subset of Wikipedians are violently allergic to the eight-year-old "neologism" that kibibyte represents. Even simply linking to the kilobyte page, where the problem is exposed and explained ad nauseam, sooner or later gets unlinked, as the page's history shows. All sorts of options have been tried, and none seem satisfactory for anything remotely like a majority.
Maybe we should randomly rotate the message between various forms... :-)
Urhixidur 20:47, 14 June 2007 (UTC)

The current message simply conveys information on page size (granted slightly ambiguous information, but 24 bytes of ambiguity out of 1024 is not significant given the purpose of the message). The amount of prose for a given topic is highly relevant to creating good encyclopedia articles. While a word count would be much more useful, this message is currently the only easy way to measure the size of article prose (click on the printable version, select all, paste back into an edit window, trim as needed and hit preview). Blanking the message disables a part of how the site has worked for a very long time. Community consensus is needed before that is done. Again, a word count would be far better but we don't have that yet. When/if we do get that feature, then yeah, get rid of this message since those data are now saved with each edit. --mav 22:22, 14 June 2007 (UTC)

I tried substituting a computed value in bytes (using the parser function #expr), but that doesn't work, most likely because of the way/sequence in which things are processed by the Wiki software. Dang. I suspect any attempt to use a #switch would likewise fail. Back to square one. Urhixidur 22:25, 20 June 2007 (UTC)

Just by the way, whilst you can argue the toss over kilobytes and kibibytes, the capitalisation of the abbreviations is standardised without argument. Lower-case k for kilo as per SI (followed, or not, by a lower-case i), upper-case B for byte (lowercase is bit) as per SI. I hope this is the right indent level — it got confusing. Angus Lepper(T, C, D) 22:27, 20 June 2007 (UTC)

Sadly, wrong on both counts. SI has no symbol for byte (SI B stands for bel), and the IEC binary prefix symbol is Ki, no ki. But that seems beside the point. I hazard to say there is a near-consensus that symbols should not be used, as they obfuscate the issue somewhat. Urhixidur 22:35, 20 June 2007 (UTC)

Ah, I was half-right (thought it was ki not Ki, clearly wrong) but managed to mess up the ordering of words when I was posting such that I was totally wrong. I'll now quietly bow out of this discussion. Angus Lepper(T, C, D) 22:39, 20 June 2007 (UTC)

[edit] Recent changes

When the original line (i.e., "This page is...") was removed, it caused an empty box to appear. It made the message seem broken rather than empty, and it was confusing to see. Clearing the page entirely made the message revert to its default, so I switched the page to an empty comment. I have no involvement in the above process, nor do I want to be involved, but the system message needed to be fixed. Cheers. --MZMcBride 05:01, 14 June 2007 (UTC)

[edit] Seriously

Fairly large? I don't think this message could be any less helpful if it simply states the page is "fairly large". That's quite ridiculous, so I've reverted back to the previous version. - auburnpilot talk 04:49, 29 June 2007 (UTC)

Agreed. --MZMcBride 04:52, 29 June 2007 (UTC)

I find it ironic some editors object to that form because of its lack of content (imparted information), but don't object to the use of an ambiguous unit of measurement.

I tried that form simply because some of the participants in the debate did mention that the specific size of the page did not matter, that the only important aspect was that the page was getting "too large" for some browsers. Can you propose some other generic wording along those same lines? Urhixidur 19:05, 3 July 2007 (UTC)

[edit] Uhh.. what?

I just saw <p>This page is 45 kilobytes[[kilobyte|<sup>{{{1}}}</sup> </p> <a href="/w/index.php?title=Wikipedia:Featured_article_candidates/Hannah_Primrose%2C_Countess_of_Rosebery/doc&action=edit" class="new" title="Wikipedia:Featured article candidates/Hannah Primrose, Countess of Rosebery/doc">Wikipedia:Featured article candidates/Hannah Primrose, Countess of Rosebery/doc</a>]] long. </div> Could someone please revert this to sane version or fix it? Kotepho 19:04, 3 July 2007 (UTC)

It is fixed now. The peculiar sequence in which the wiki software processes the message means most templates cannot be used within it. If subst:'ed it and it no longer breaks. Urhixidur 19:09, 3 July 2007 (UTC)

[edit] Protected edit request

{{sudo}}

That dagger thing looks silly. What's wrong with just linking "kilobyte"? – Gurch 13:15, 5 July 2007 (UTC)

I believe that it's an issue with the ambiguity between whether "kilobyte" means 1000 or 1024 as in kibibyte. I remember seeing and contributing to a Village Pump discussion on the subject. While I agree that simply linking kilobyte might look nicer, there needs to be a way to note the ambiguity there, especially since the "kilobyte" in question involves 1024, rather than 1000, bytes. Is there some way that this can be achieved? I'm drawing a blank, on 3 hours sleep. Nihiltres(t.c.s) 16:05, 5 July 2007 (UTC)
Who cares? It's only supposed to be a rough thing – "is this page about 60 Kb, about 90 Kb or about 120 Kb" – Gurch 17:22, 5 July 2007 (UTC)
For that matter, how does linking to kilobyte in a silly superscript thingy rather than the word itself resolve this non-existent "ambiguity" anyway? – Gurch 17:23, 5 July 2007 (UTC)
I agree that the dagger wsa no better than a simple link. If more precision is desired, the message could say "This page is $1 kilobytes (1024 bytes each) long." I would think everyone expects this count to agree with du -k, which means 1024 bytes per KB; I don't see the liklihood of great confusion. — Carl (CBM · talk) 17:36, 5 July 2007 (UTC)
This message should be as unintrusive as possible. The exact number of bytes (remember we are talking about a 2.4% difference) is pointless, because a variety of factors (see my comment above) mean that the number of bytes in the source are only broadly related to the size of the article when rendered—the inaccuracy is already much more than 2.4%. — brighterorange (talk) 18:48, 5 July 2007 (UTC)
Linking to kilobyte was tried, and some editors reverted it. Ask them "What's wrong with just linking". Expanding the message to disambiguate the kilobyte was tried, and reverted. The dagger was an attempt at making the link less intrusive. I even tried removing the exact number of bytes (since most editors seem to agree it's fairly pointless), and that was also reverted. I'm still searching for a solution, although I suspect there may not be one: this message may be inherently unstable because there are too many editor cliques pulling it in various directions. (And, Gurch, there is ambiguity because a fair number of people have adopted the IEC standard and use kibi for 1024, kilo for 1000, regardless of context) Urhixidur 20:35, 5 July 2007 (UTC)
But honestly what does it matter if there is some ambiguity. If I know that ~60-65 is a good size for an article, or that 120kilobytes is too long, except for articles that require a lot of coverage; why does it matter? If you change it to table lamps long, I wouldn't care so long as I know that 4 table lamps is about average, and 9 table lamps is too long. I think you're getting stuck on a detail that I imagine most people don't even think about. It's not the measurement that really matters; it's the size in comparison to other articles/standard lengths. - auburnpilot talk 22:09, 5 July 2007 (UTC)

[edit] Let's be entirely clear

I have a problem with the message saying that the article is - for example - x kilobytes long, and then completely contradicting itself by saying that actually this isn't the case at all and that it is in fact, x kibibytes long. I assume it is still the case that article size is measured in kibibytes, unless things have changed. Let's not substitute factual correctness for simplicity here. If it still is the case that kibibytes are used and not kilobytes, please let's make that the one and only form in use, seeing as the two are entirely different things.

I'm not so much concerned with the fact that including the word kilobytes makes matters less complicated, merely the fact that using the word kilobytes makes it, from what I last remember being discussed, factually incorrect. Bobo. 03:56, 17 July 2007 (UTC)

As the difference between a kilobyte and a "kibibyte" is 2.4%, and most people know what one is (even if they couldn't give you a dictionary definition), why are we so eager to confuse people for the sake of pedantry? More people know "kB" is a measure of the size of data than what a neologism such as "kibibyte" represents. Neil ╦ 22:28, 17 July 2007 (UTC)

That's fair. I hadn't changed anything on the page itself so we've reasoned it out well enough for my liking. Bobo. 01:12, 18 July 2007 (UTC)

Also, although "kilobyte" is ambiguous it is not incorrect to call 1024 bytes a kilobyte. Several standards agencies have adopted exactly that meaning, and it has also been standard use in computing for decades. — brighterorange (talk) 02:35, 18 July 2007 (UTC)

Brighterorange is correct: the use of kilobytes is not incorrect per se, just ambiguous. (And, yes, the wiki software measures the size in kibibytes) Urhixidur 14:48, 23 July 2007 (UTC)

Actually, the MediaWiki software measures the size in kilobytes, and there is nothing ambiguous about the use of the word here, and even if there were an ambiguity the difference would be no more than three kilobytes for even very large pages. —Centrx→talk • 17:25, 28 July 2007 (UTC)
Wrong, Centrx: careful experimentation has shown the "kilobytes" shown in the message are precisely 1024 bytes in size. That is what I meant when I said the software measures in kibibytes (an unambiguous statement). Urhixidur 13:27, 30 October 2007 (UTC)

[edit] Centrx's change

Although Centrx is entitled to the opinion that the Wikipedia « is not the place for neologisms » and that the ambiguity « doesn't matter », until WP:MOS is changed, we'll stick to it: "the use of parentheses for IEC binary prefixes [...] is acceptable". Urhixidur 19:02, 29 July 2007 (UTC)

Per the same MOS it should stay the way it was. Without the kibibytes. Garion96 (talk) 20:11, 29 July 2007 (UTC)
MOS lays out the style for articles, not the user interface. Also, "acceptable" obviously doesn't mean that we are compelled to do it. I would much prefer to not see "kibibytes" in this message. — brighterorange (talk) 20:36, 29 July 2007 (UTC)
So? I would much prefer to see just kibibytes, as it is unambiguous. Stalemate. Urhixidur 16:24, 12 August 2007 (UTC)
Even supposing it were ambiguous, confusion for readers and sending them to unrelated articles is worse than an ambiguity that makes no practical difference. —Centrx→talk • 22:10, 12 August 2007 (UTC)
So I'm just stating my preference (since you seem to imply that Centrx is the only one campaigning for "kilobyte") and disputing your rationale for changing it. — brighterorange (talk) 00:08, 13 August 2007 (UTC)
If it « makes no practical difference », why do you oppose so vehemently fixing the ambiguity with the correct, unambiguous term? It's a mystery to me. Urhixidur 13:25, 30 October 2007 (UTC)
Including "kibibytes" does make a practical difference: It causes confusion or distraction for readers, and if a link is included navigates them away to a page entirely unrelated to the pages they are editing. What makes no practical difference is to include "kibibyte" in order to correct ambiguity, because any ambiguity would be on the order of a couple bytes, when the message could even round off to the nearest 10 with little practical effect.
The purpose of the edit page is to efficiently let the user to edit the page. The purpose of the Longpagewarning is to indicate the size of the page above a certain threshhold, which has some practical uses and does not detract from or detracts only minimally from the efficiency of the edit page, as it contains no links and uses words that are presently and have long been well-known and in common use. —Centrx→talk • 01:39, 5 November 2007 (UTC)