Hello, Xeno told me that this external revision history search tool is on history pages by default, but I cannot find it.
Hello, Xeno told me that this external revision history search tool is on history pages by default, but I cannot find it.
See [[User talk:Xeno#Searching]] for more info and screenshots. Our history pages appear vastly different... [[User:BlazerKnight|BlazerKnight]] ([[User talk:BlazerKnight|talk]]) 07:54, 4 October 2009 (UTC)
See [[User talk:Xeno#Searching]] for more info and screenshots. Our history pages appear vastly different... [[User:BlazerKnight|BlazerKnight]] ([[User talk:BlazerKnight|talk]]) 07:54, 4 October 2009 (UTC)
:The links are present only in English interface, not in British English. Haven't you changed your language to British English in your [[Special:preferences|preferences]]? [[User:Svick|Svick]] ([[User talk:Svick|talk]]) 10:06, 4 October 2009 (UTC)
The technical section of the village pump is used to discuss technical issues aboutWikipedia. Bugs and feature requests should be made at the BugZilla.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.
No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.
No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.
If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.
If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.
I don't know what you mean exactly but in my opinion, we should first enable the passive part, to have time to get used to the system and have enough reviewers, so as to be ready when we enable the active, opt-in part. Also, if we have only the active part for the trial, we won't be able to see how they work together, yet both would be needed in an implementation, as they have different and complementary purposes, one local protection, the other global monitoring. Cenarium (talk) 17:54, 23 September 2009 (UTC)[reply]
Not sure what you mean by "passive part"; there'd be noting to show on pages that haven't had flagged mode enabled on them. --brion (talk) 23:58, 24 September 2009 (UTC)[reply]
By passive part, I mean 'patrolled revisions', reviewers can review any article, no sysop is required to enable this, but there is no precedence, so it's just for monitoring, kind of enhanced patrolled edits; there would be indeed nothing to show, it would be silent. Cenarium (talk) 16:13, 26 September 2009 (UTC)[reply]
In general, this page should be created and edited by (insert Anon IP)
So, I went to move a {{SharedIP}} 'plate from my talk page to my user page, as technically I use a static IP, and I get this message:
Unauthorized
Wikipedia does not have a user page with this exact title. In general, this page should be created and edited by User:209.6.238.201.
But, actually, anon IP's currently cannot create their own User page, AFAICT. So, "in general" I'd be happy to create it, but specifically, I can't.
Can some technocrat either fix the language of the internal template or fix the reality? I don't think I have a strong preference either way, but I'm pretty sure a year or two ago I could actually create my own user page and did so on previous IP accounts (which is especially handy when you have multiple IPs you want to declare, lest WP:SOCK accusations appear). Maybe this has been an issue with spammers or vandalism, I don't know, but the language is obviously out of whack. -- 209.6.238.201 (talk) 08:00, 29 September 2009 (UTC)[reply]
Anons haven't been able to create subjectspace pages since 5 Dec 2005, I believe. So since then you won't have been able to create your user page.
This situation can't be changed without a change to the software settings. There is Template:Bug open which requests that the restriction be lifted for non-article namespaces.
The message could probably be changed. I'm not sure which parser functions work in the interface (not many I think) but a {{lc:{{PAGENAME}}}}={{uc:{{PAGENAME}}}} check could possibly be used to detect when a page is an IP's user page and change the message accordingly.
There are many people whose usernames have no Latin letters, such as User:172 and people with unicode usernames, so the above code would have some nasty side effects. Graham8714:36, 29 September 2009 (UTC)[reply]
OK, thanks for looking into this, Martin. I expect the wording could be changed without worrying about parsing if only IP editors will see this, excepting some rare deleted/protected user pages for which it's not really important that someone else should be "creat[ing] and edit[ing]" it. I guess the message, were an IP to accidentally try to start someone-else's User page, is meant to sound nice about saying no. Anyway, I just thought it was an interesting oddity. -- 209.6.238.201 (talk) 00:10, 30 September 2009 (UTC)[reply]
Hopefully someone here will tell us where this message is held and then we can think about how it can be improved. — Martin (MSGJ · talk) 15:10, 30 September 2009 (UTC)[reply]
Not sure if this is the right place or not, but is the edit notice:
Please note
When you click Save, your changes will immediately become visible to everyone. If you wish to run a test, please edit our Sandbox instead.
Please post only encyclopedic information that can be verified by external sources. Please maintain a neutral, unbiased point of view.
Please do not copy and paste from copyrighted websites – only public domain resources can be copied without permission.
Any text that you did not write yourself (apart from brief citations) must be available under terms consistent with Wikipedia's Terms of Use before you use it.
If you do not want your writing to be edited, read or redistributed by other people, then do not submit it here.
new or larger than it was before? Or is it in a different place? I've had to shrink my edit window by 10 lines (down from 40 lines) in order to be able to see the "Insert"/"Wiki markup"/etc. section when editing (and I use that a lot). — Bellhalla (talk) 16:40, 29 September 2009 (UTC)[reply]
I suspect that including any script which is hosted off WP would be a huge security risk and would be intentionally blocked by the interface. 706:17, 30 September 2009 (UTC)[reply]
That assumption is incorrect. Scripts can be loaded from any place (as allowed by the HTML standard) and responsibility lies thus with the author of the local .js file. —TheDJ (talk • contribs) 09:01, 30 September 2009 (UTC)[reply]
ImportScriptURI(url) is a JavaScript function that you can call from another JavaScript code. I don't know about a way to add JavaScript code to Wikipedia page that would work for all users, not just you, other than changing MediaWiki:Common.js which is exteremely unlikely to be accepted for this. Svick (talk) 19:40, 30 September 2009 (UTC)[reply]
If you do find a way to add javascript for all users (besides being an admin and editing MediaWiki-namespace pages such as MediaWiki:Common.js, of course), please report it to security@mediawiki.org. Anomie⚔12:26, 1 October 2009 (UTC)[reply]
Error when editing protected pages
Quite often when I edit a fully protected page I receive, after a long delay, the Wikimedia Foundation Error notice. The edit always succeeds but the browser does not reload the page. I use Firefox 3.5. I was just wondering if this happened to anyone else? The technical output of the most recent occurence is below.
Request: POST http://en.wikipedia.org/w/index.php?title=Template:WikiProjectBannerShell&action=submit, from xxx.xxx.xxx.xxx via knsq23.knams.wikimedia.org (squid/2.7.STABLE6) to 91.198.174.39 (91.198.174.39)
Error: ERR_READ_TIMEOUT, errno [No Error] at Wed, 30 Sep 2009 17:55:13 GMT
The xxx bit is my IP address, hidden by me. Thanks in advance. — Martin (MSGJ · talk) 18:00, 30 September 2009 (UTC)[reply]
Twice in less than five minutes, I made edits to (Wikipedia:Articles for deletion/Log/2009 October 1) that ended up accidentally undoing the edit just prior to mine. I was unaware of this accident until I was notified about it on my talk page. Seeing that the situation had not yet been corrected, I attempted my own correction here, which resulted in another similar accident. In neither case was I given an automated edit conflict notification, and the edits just went through as if there was nothing wrong.
Was I given a free pass against edit conflicts by a bureaucrat or something like that, giving my edits priority over everyone else's when there's a conflict? Because if that's the case I'll willingly relinquish that "privilege" any time. -- Blanchardb-Me•MyEars•MyMouth- timed 16:59, 1 October 2009 (UTC)[reply]
There's no free pass. I'm not sure if that should've caused a conflict, or just gotten merged automatically. Either way, though, it seems like something went wrong in the merging somewhere. -Steve Sanbeg (talk) 21:57, 1 October 2009 (UTC)[reply]
I've seen this happen several times today, on several different pages; is it possible there's a problem with the edit conflict detector? --Floquenbeam (talk) 23:01, 1 October 2009 (UTC)[reply]
Yes, there are known issues with the edit conflict detector (at least, other people have reported the same problem). It seems to affect some editors more than others, either because of some nebulous browser issue or because of different editing patterns. I do not know if there is a bug filed about it. — Carl (CBM · talk) 00:57, 2 October 2009 (UTC)[reply]
Is it possible that magic words (like lc:) might be returning stuff in ascii when the rest of wikimedia is using UTF8? Or anything similar to that scenario? RichFarmbrough, 20:36, 1 October 2009 (UTC).[reply]
Yes, possible. I know that PAGENAME behaves a little strangely with punctuation marks. For example
During a period of low loads, the job queue might be zero. At Wikimedia, the job queue is, in practice, almost never zero. In off-peak hours, it might be a few hundreds to a thousand. During a busy day, it might be a few million, but it can quickly fluctuate by 10% or more.[1] The job queue length is reported at Special:Statistics.
Yesterday night I checked the job queue every ten seconds for two minutes, and it jumped from 9 to 24 and 243 thousand, back and forth. I repeated this with the same result (just different numbers) today. Would you have an explanation for that? It almost looks as though there are three job queues, and you get a random one. Debresser (talk) 21:49, 1 October 2009 (UTC)[reply]
Each time you fetch the page with the number of jobs in the queue, it is reported by one of the second-tier servers, which lag behind the master server. So when you see the number oscillate like that, it means your different requests are being handled by different servers, which are not in sync with the main server. So there is only one real job queue, but which secondary server answers your question is, essentially, random.
There is no direct way to query the master server about how long the job queue really is, but there isn't really a need to do so. On Wikipedia, we have system administrators who will fix things if the job queue gets too long. The Special:Statistics page is more useful for Mediawiki installations that do not have multiple second-level servers, in which case the number would be completely accurate. — Carl (CBM · talk) 01:06, 2 October 2009 (UTC)[reply]
This isn't quite right, but it's right where it's important – you should not worry about the job queue, we'll do that. — Werdna • talk09:05, 2 October 2009 (UTC)[reply]
Actually my answer was completely wrong, and I need to thank Domas for explaining it to me (although any errors here are entirely due to my own misunderstandings). I also looked at the code for Special:Statistics, which I should have done before.
It turns out that, for performance reasons, it is not practical to actually count the number of rows in the database table that holds the job queue. Therefore, the code for Mediawiki only estimates the number of rows. Because the estimate is written to be very fast but not very exact, it can vary wildly from moment to moment. The difficulty is that rows are constantly being added and removed from the job queue, so counting the rows that are "really" in the table is not as simple as it sounds. — Carl (CBM · talk) 13:16, 2 October 2009 (UTC)[reply]
I can tell you that the job queue is a subject that editors are interested in. Not worried about, but interested in. We see it as a measure of how well Wikipedia is coping with our edits. How healthy Wikipedia is at any given moment, so to speak. Apart from that, it gives us a sense of accomplishment. If I edit a widely used template, for example, I want to see the queue go up. I want to know whether my changes will be processed sooner, or later. And for all that I look to the job queue. I am not talking about myself alone, but about the community. Giving us such a false idea of the actual job queue, is disappointing. Can that be made to be more accurate? Frankly speaking, otherwise we should just not have it. Variances from 9 to 243 thousand are a mockery. Debresser (talk) 13:31, 2 October 2009 (UTC)[reply]
I've thought for a long time that we should just remove it, at least on Wikipedia. Make it do SELECT COUNT(*) so it's accurate for small sites, say, and then have an option to turn it off entirely for big sites. Even if it were accurate, it's useless to editors, and putting it on Special:Statistics misleads them into thinking they should care about it. —Simetrical (talk • contribs) 13:52, 2 October 2009 (UTC)[reply]
I agree it could be disabled, since (1) the number is not particularly accurate in the first place and (2) the system admins would tell everyone they should ignore it even if it were accurate. — Carl (CBM · talk) 13:59, 2 October 2009 (UTC)[reply]
FWIW, the reason you get a few different counts is because you're getting a few different counts. The count comes from InnoDB table statistics on whatever slave happens to run the query, and each slave calculates its own statistics. So it should be reasonably stable if you get the same slave, but two different slaves might have wildly different numbers (since it's a rough estimate). —Simetrical (talk • contribs) 13:55, 2 October 2009 (UTC)[reply]
I edited the interface so that it at least says "Estimated job queue length", so that new editors will be less likely to be mislead by the number. But disabling it seems like a better long-term solution. — Carl (CBM · talk) 14:00, 2 October 2009 (UTC)[reply]
In fact it has provided comfort when editing widely used templates to see the job queue deal with it, especially when WP seems to be going through one of it's medium term problems with resources. It may be an estimate but it is more concrete than WP:PERF. RichFarmbrough, 14:07, 2 October 2009 (UTC).[reply]
Removing information is generally a bad idea. But this is not information. Anything that can fluctuate within 5 seconds 2700% is not information! You call that a "detail"? Debresser (talk) 14:12, 2 October 2009 (UTC)[reply]
I updated the help page. I would suggest that it would be a possible solution to do a SQL COUNT periodically and store the result to be severed on special:statistics. I haven't the information to say whether this should be every 10 seconds, every minute or every second. If there are actually three or more separate queues then list them all, or the total. RichFarmbrough, 14:18, 2 October 2009 (UTC).[reply]
There are three different counts for the job queue. Each of them is consistent (doesn't fluctuate). Just now I had 3000, 348000 and 281000. Debresser (talk) 14:25, 2 October 2009 (UTC)[reply]
list indentation
Lists arent indented very much and lists of lists with many subsections can be difficult to read. Is there any way to increase the indentation for a particular list? Lemmiwinks2 (talk) 01:18, 2 October 2009 (UTC)[reply]
You can't use wikitext list to do this, and have to use HTML and inline CSS. E.g:
<ul><li>
foo
<ulstyle="margin-left: 5em"><li>
bar
<ul><li>baz</li></ul></li></ul></li></ul>
foo
bar
baz
Note that the second level list has bigger indentation, but the third has default. You have to set it for every <ul> (or <ol> for ordered list). But make sure this is necessary, because it lowers readability of the page source for other editors. Svick (talk) 20:41, 2 October 2009 (UTC)[reply]
You can do a lot with WP lists but not alway what you expect
Part of the default thumbnail issue above stems from the technical limitation of not being able to use percentage widths for images. It should not be a big problem to automatically scale thumbnails widths to a certain percentage of the article width automatically. This would make the default widths independent of browser window sizes and zoom factors.
Therefore, I hereby officially propose to create and add such a rescaling script to the site JavaScript. E.g., the default relative rescaling width could then be specified as ~16% for the 180px user preference default. Adjustments can then be done by changing the preferences pixel width as usual. For users without scripting support the old pixel-based width would still work without change.
As for the finer implementation details, the script should run before image fetching because we neither want to let the browser to blow up the fetched images (because it would lead to artifacts) nor would we like to load different resolutions from the server for the same page (maybe this needs some server-side help). To keep the server-side image scaling and caching at the current resource level, the script would scale image sizes in the current steps of resolution (e.g. 180px, 220px...) Rescaling the browser window would either not change the width (to preserve the resolution - exactly as for the current implementation of fixed image withs) or would rescale (with possible artifacts) and then load larger sized images through a background server request (browser window resizing does not happen very often, so this would not have a noticeable effect on network traffic). Cacycle (talk) 02:29, 2 October 2009 (UTC)[reply]
Images are resized server-side on-demand, and that demand is dictated by the server-side MediaWiki code running on the cluster's Apache servers. The images are stored in obfuscated file directories and links are resolved internally as the page is rendered. You cannot use JavaScript to demand an image in an arbitrary size because 1) the image will not exist in the desired size until an Apache server has requested it in the 'normal' fashion, and 2) even if the image does exist, the JavaScript will not be able to find it unless it is told by an Apache where the image in that particular size is located. Neither of these problems are insurmountable, but they only scratch the surface of the problems with percentage-scaling of images, and raise the question: what advantages would percentage-scaling offer that are so bounteous as to justify all this effort? Happy‑melon15:37, 2 October 2009 (UTC)[reply]
Actually, those would mostly be easy to bypass. The directory is based on md5 hash of the filename; it doesn't change for different thumbnail sizes and there's no actual randomness. If an image doesn't exist at a request size, it will be automatically generated (see transformVia404 in mw:Manual:$wgLocalFileRepo). The main problems I can see are:
Small images. The server will not scale images larger than their actual size. If MediaWiki determines that the requested size is larger than the actual size, it puts the full image in the page and lets the browser scale it. But it will refuse to thumbnail it. This seems like it could cause problems for percentage widths where JS doesn't know the original image size.
Is it actually possible to run code after you know what images are on the page, but before the images are loaded?
Is it possible to determine the actual window size, or are we just going to get the screen resolution (does that work in every browser?) and assume people are using a full window?
if someone is using a mobile browser, but not the mobile site, will images even be usable? The iPhone has a 320×480 screen, so an image set at 16% is going to be at most 76px wide.Can you tell what this is without looking at the image name or clicking? I can't.
1. This might need a server-side software change so that the server send the original size image instead which would be displayed without browser rescaling. I do not think that this would break or interefere with any existing application. Alternatively, it might be possible to catch that error message and to dynamically load the unscaled image.
2. Yes, that is possible, the <script> tag must be in the header for that so that the code is executed immediately before page rendering. We might need some polling code that checks the incoming page code (?) and this might need some more detailed testing to figure out if it is possible to be faster than the requests and/or if the requests are somehow canceled by changing the url. Does anybody know more about this?
3. It is no problem in JavaScript to get the window size in px and all we want to do is to scale the images px-wise relative to the window (or the content element).
4 Since this is a JavaScript approach we can build in any intelligence and special-case handling it needs to work for every imaginable possible situation.
LiquidThreads is a next-generation discussion system for MediaWiki, which turns talk pages into a real forum, while maintaining the essential aspects of a wiki that make them so effective. It was originally developed as a Google Summer of Code project by David McCabe, and I've spent the last 4 months preparing it for deployment on Wikimedia sites, under contract from the Foundation.
Presently, we're waiting for the labs project to become relatively stable, and have all the features we need. Once that's been done, we will commence a staged roll-out of LiquidThreads on various Wikimedia sites. It should be noted that LiquidThreads has a mode in which it can be switched on or off per-page. My intention is to activate it on this site in that mode, and allow users to discuss pages that would benefit from the enhanced discussion management (I'm thinking of high-traffic noticeboards and discussion pages). Once it's been rolled out and people are familiar with it, we can think about the possibility of turning it on for all discussion pages.
LiquidThreads is very much a work in progress, and your feedback is essential for it to get to a point at which we can deploy it on this wiki. Please do send any and all constructive feedback to the feedback page on the test wiki, and I will do my best to accommodate it.
I'm very excited about the opportunity to bring this technology to Wikipedia, and to give our discussion pages a long-needed overhaul. — Werdna • talk09:16, 2 October 2009 (UTC)[reply]
If it means no more edit conflicts any more, then I'm all for. (Is any work being done in your labs on getting alphabetical order working? It's just that, well, this software is being used for dictionaries and encyclopedias and things, and it still thinks that AB comes before Aa...)--Kotniski (talk) 10:21, 2 October 2009 (UTC)[reply]
To little fanfare, the usability folks (who are, I suspect, either brewing an official announcement, or too modest to announce it) have deployed their latest usability improvements to English Wikipedia, code-named "Babaco".
The new improvements are:
Navigable TOC The "Navigable Table of Contents", a pane to the right of the edit window in which you can easily jump from section to section. (Activate in the "Editing" tab of preferences).
Content generation Content generation systems, which streamline common content generation, such as inserting links and tables. Also adds a powerful new search and replace system. Available for all users with the experimental editing toolbar activated.
Sounds great, but (another moan this time): is there some reason this sort of thing is not announced publicly via top-of-page or top-of-watchlist messages? Or perhaps it will be?--Kotniski (talk) 10:42, 2 October 2009 (UTC)[reply]
Why does this only appear when I am editing but not when I am browsing? When I edit, I edit one section, and so the "navigation" is somewhat trivial. — Carl (CBM · talk) 12:07, 2 October 2009 (UTC)[reply]
We already have a TOC for reading. This new editing-TOC will be best for newbies, who will often hit "edit" at the top of the page and go looking for the section they want. In a long article, that's useful even for veteran editors if there's a long article with problems across multiple sections. {{Nihiltres|talk|edits}} 13:03, 2 October 2009 (UTC)[reply]
The 'Enable enhanced editing toolbar' only works if wikEd is disabled—they seem to be incompatible. 'Enable help for adding advanced wiki text' does not seem to have any effect. 'Enable navigable table of contents' does not work for me. I tried several skins, but do not see any 'Navigable table'. Ruslik_Zero13:28, 2 October 2009 (UTC)[reply]
Unable to reproduce on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3. — neuro14:07, 3 October 2009 (UTC)[reply]
This may be the same problem I had: the announcement made me think this would be visible at all times, but it is only visible during editing. — Carl (CBM · talk) 14:13, 3 October 2009 (UTC)[reply]
I love thoses features.
Still, I wish there was a TOC on the right when browsing long pages. I use the TOC to find the section I want to read, then I may want to use the TOC again, to find another section I would like to read. I am obliged to return to the top of the page, and return to the article afterwards, and so on and so forth. A navigable TOC always on the right would be really helpful. Dodoïste (talk) 14:28, 3 October 2009 (UTC)[reply]
The 'Enable navigable table of contents' does not work for me either - there's just a black space to the right of the (narrower) edit window (IE 8.0.6001.18702, Windows XP).Nigel Ish (talk) 14:23, 3 October 2009 (UTC)[reply]
It does not work with IE 8.0 on Vista. Though I would say it's only normal to have bug with IE and people should stop using an outdated browser. It is working fine on Opera 10 and 9.64. Dodoïste (talk) 14:36, 3 October 2009 (UTC)[reply]
Video tutorials—viability?
I'm really interested in creating some tutorials on using Wikipedia. I haven't really fleshed out this idea yet, but I would probably combine screen recording with voice over, and produce short clips of a few minutes on different areas and aspects of editing. I'd start with the basics, of course, but I could move on to introducing things like adding inline citations, uploading images, DYK review, etc.
I discussed this with another editor, and he pointed out that flash would probably work best for screen capture, and that it isn't supported on WP. Hurdle number 1. Assuming that I could use an alternative to flash that would be supported on WP, would the community accept video embedded on Help pages? If it couldn't be embedded, would it be ok to host the videos elsewhere and link to them from help pages? Instead of embedding help pages with videos specific to the content (which would be restricting for me), would it be viable to create a separate help page devoted to the videos? Would the community want to vet them first? How would it be established that they were appropriate?
Another aspect I am wondering about is privacy concerns. Would there be objections to screen shots that would, inevitably, show dozens of user names and some of their associated edits? Would I have to cover up the WP logo?
Has this idea been tried or suggested before and failed?
I hope that's not too many questions for one post! I'm really curious to know if this would work and am interested in hearing feedback. I really think that videos could help us retain editors who find WP initially bewildering. Plus, it would be fun to make them! Also posting to Village pump (proposals) Maedin\talk18:40, 2 October 2009 (UTC)[reply]
I did think of doing this ages ago, but never got around to it. I would suggest that videos would be a good idea on help pages, a lot of people seem to find the technical side of Wikipedia hard enough, and I can only imagine videos would soothe the situation. — neuro20:34, 2 October 2009 (UTC)[reply]
This is weird. My contributions say that an edit I made is not at the top of the page, when it clearly is. Checked 3 times, cleared cache each time, still the same.
Quite a number of revisions of United Parcel Service seem to have vanished. The problem starts about Jan 2005 and runs at least up to May 2005. The edit summaries are present, but the actual text of the revision (and correspondingly, the diffs) are missing. Is this something that can be solved, and if so, to whom and where should it be mentioned? 128.54.68.114 (talk) (really, User:JesseW/not logged in) 01:30, 3 October 2009 (UTC)[reply]
I am currently using the code {{:List of bla bla}} code to bring in the ifnormaiton from a sub page which was split out of the main article back to teh main one. however the code bring the entire page of the article into the mai article so meaning i can not make the indvidual articles serparate and ther eown articles. what i liek to know is there any way ot alter the code so it only brings in the table from the serperate article?--Andrewcrawford (talk - contrib) 12:44, 3 October 2009 (UTC)[reply]
You can create a template that contains only the table and then transclude it to both articles. E.g. you create Template:foos, containing only the table, and then place the code {{foos}} to both of them. Svick (talk) 12:56, 3 October 2009 (UTC)[reply]
OR: you can place <onlyinclude> before the table, and </onlyinclude> after it (that's if I've understood the question right).--Kotniski (talk) 13:00, 3 October 2009 (UTC)[reply]
The onlyinclude seems to work great although i wouldnt mind learnign how to make the template so that if a article is edited the information itn teh template would be alter as well--Andrewcrawford (talk - contrib) 13:10, 3 October 2009 (UTC)[reply]
In general, templates should not be used to simply show text split out into a subpage. It should either be put back into the main article or left in the subpage. — neuro14:18, 3 October 2009 (UTC)[reply]
Problem is the list was over 130kb before splitting but after splitting peopel complained because they had to look in other places for the informaiton this way the artilce is within size but suits everyones--Andrewcrawford (talk - contrib) 16:58, 3 October 2009 (UTC)[reply]
It's only "within size" in that it is easier to edit - the page itself is still just as big - or possibly a little bigger. There is currently no good solution to this:
Sub-pages are deprecated
Content in template space is frowned on (except navboxen)
Transcluding bits of one article into another using "onlyinclude" is not scalable, and is also obscure.
Replicating the text (as advised by some essay WP:ABUNDANT?) means either two sets of things to update or they drift apart.
Imnot suggestign editing a template just when i read the information above that how i udnerstood it, maybe the page explain about template need ot be updated to be simpler to understand esipcally for peopel liek myself with reaidng diffuculties--Andrewcrawford (talk - contrib) 18:12, 3 October 2009 (UTC)[reply]
incategory: search
Anyone know why
incategory:"Stub-Class Canadian communities articles"
Because the category is added by a template, rather than appearing directly in the wikitext? (Although someone else was claiming recently that the incategory function didn't work, and I'm not sure that that was the problem in that case.)--Kotniski (talk) 17:52, 3 October 2009 (UTC)[reply]
Nope to the first I set it explicitly on an ns0 page and that didn't work either (could have been lag) - even if it had very very likely that the software does not interrogate the pages themselves.
I have no idea where to appropriately mention this, but this seems like the best place. It would be nice if the Wiki software could somehow incorporate a spell-checker in the "Edit summary" field as it does in the body field. I always try to be as detailed as possible in my summaries and feel quite retarded when I have to tab off the page to go to Google to check my spelling for a comment in the field (as I sometimes have to use "big" words with complicated spelling to get across my point in the limited characters). Anyway, maybe someone else here will get my point. Spell check = good. Especially in a field which can never be fixed or edited again once you see the stupid mistake you've made.
PS I just realized I wouldn't have to tab out to Google like I always do to check my spelling; I could just input it in the body field right above. Don't know why I didn't figure out that little simplicity before, but to each his own. But perhaps the suggestion is still worthwhile.
MediaWiki doesn't have any spell checking support. If your using Firefox you can activate the background spellchecker by right click on the edit summary field and selecting "Check spelling". — Dispenser17:38, 3 October 2009 (UTC)[reply]
I would like to have the three names evenly split on the collapsible header bar as they are now, but with the three words on the same line as the hide button.
Thanks for the suggestion Izno. The above is a very simplified example. The creator, nominator and editor count actually have names and information attached to them. I would like an editor to be able to see that creator, nominator and editor count information, but spaced evenly along the bar, even if the template is collapsed. Thanks. I have tried span tags, can't get it right, and div tags don't work.Ikip (talk) 21:00, 3 October 2009 (UTC)[reply]
StuffMoarStuff
Almost centered. The issue is that that the [close/open] takes up some space, so we have to set the width on the div to be less than article width less close width. This breaks down when we get to res's of about 600px, but that should be alright for our purposes, I suspect. --Izno (talk) 21:14, 3 October 2009 (UTC)[reply]
The link doesn't get on the best location, but that's probably a bug on the collapsible tables, which add it to the last cell instead of the first. Platonides (talk) 21:17, 3 October 2009 (UTC)[reply]
Maybe it could be that when you add an article to category, the counter increases, and when you remove it from the category, it decreases. But when you delete an article, the counter doesn't get updated. And because in the category you mentioned, articles are deleted regurarly, the count increases over time. This is just a guess, but it makes sense to me. In any case, this is certainly a bug and I filed Template:Bug (that is a duplicate of Template:Bug). Svick (talk) 23:13, 3 October 2009 (UTC)[reply]
