Jump to content

Wikipedia talk:WikiProject Wiki Syntax

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Nickj (talk | contribs) at 01:28, 10 January 2006 (Question). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Double prime

In the section What do I do if I encounter valid unclosed square brackets, or other wiki syntax?, the page says:

  • The use of '' as a symbol for inches or arc minutes

which I believe to be wrong. The two apostrophes should be a double prime symbol (Unicode U+2033 DOUBLE PRIME, HTML ″ or ″, looks like ″, as in a 15″ screen). Shouldn't this be fixed, even though the error's common? (I don't propose we go through and change all the nowiki'd versions, but that future versions, instead of being nowiki'd, are ″'d or ″'d.) Felix the Cassowary 10:44, 1 August 2005 (UTC)[reply]

Sounds good to me. I've updated that description, and suggested that people replace these with ″ which renders as ″ and is probably easier to remember than ″ -- All the best, Nickj (t) 03:38, 9 December 2005 (UTC)[reply]

Bad table format

This page has a big table box for Completed items that does not render properly in Firefox. It does the right thing (aligning to the right with the long box down the right-hand side of the page) only if the Firefox Sidebar is dismissed. When the Sidebar is open (displaying my bookmarks, e.g.) the Completed box overlaps the right-hand box. Oops. Someone should fix this. 216.237.179.238 00:20, 21 November 2005 (UTC)[reply]

well, i fixed it; the "nowrap" attribute on every row was making the first column take up way too much space; but now it makes the center column pretty narrow on most window widths... but at least it's readable in firefox on screens less than 1280 wide. 216.237.179.238 20:54, 30 November 2005 (UTC)[reply]
okay, i put back the nowrap style on the center column; looks cleaner now. it still has overlap problems on the right when the window gets very narrow, but it's much better than it was; if i knew how to limit the center column to three columns of numbers or so, i'd do that and make it about as good as it could get... hope it helps whomever starts the next round of syntax edits. 216.237.179.238 21:11, 30 November 2005 (UTC)[reply]
Thank you! I asked at Template talk:Active Wiki Fixup Projects if anyone knew how to fix this (as I didn't know how myself), but drew a blank, so it's great that you were able to find a way to fix this. -- All the best, Nickj (t) 23:33, 30 November 2005 (UTC)[reply]

Succession boxes

I just went over some of the triple quote items, and a lot of them are missing quotes in the {{succession box}} template. What seems to happen is that the fields are bolded by the template itself. However, sometimes someone wants to give further information about the person in the field that should not be bolded. So people have been added closing triple quotes, which are being found as errors because the opening quotes come from the template. (Of course, there really is an error: the original closing quotes in the template become opening quotes without closing quotes.) I've been fixing these by adding '''  to the end of the field. (See [1] for an exmaple of this.) The   is because otherwise transclusion yields a string of six quotes which the wiki parser does not interpret as wanted, and the fields seem to have extreme whitespace characters truncated, so we have to use this.

Anyway, I'd like to encourage everyone to use this solution. If anybody thinks of another way to handle this that might be better, please mention it here. Eric119 05:39, 6 December 2005 (UTC)[reply]

Eek, what a complicated mess the page authors have created! Hmmm... so to recap, the succession box authors have tried to be helpful by opening and closing the bolding, but the users have overridden that to close the bolding in order to have plain or italics text after the person's name - except they have stuffed it up, in that they haven't then closed their overidding, which means that the quotes are unbalanced. Given this, I don't know what else can be done other than what you have done; Maybe it would be marginally better if they had two succession box templates - one that works like the current one, and one that takes an extra argument for the stuff that the user wants in plain text or italics, which is just printed as-is on a new line after the name without any extra formatting. Then again, it might not be worth it, I'm honestly not sure. -- All the best, Nickj (t) 04:53, 7 December 2005 (UTC)[reply]

Things for the bot to remember on double brackets

It needs to recognize line breaks (<br>) in links, as well as when the <nowiki> tag is used inside links (certain characters mess up links, requiring this usage). Ral315

Open quotes in infoboxes

There are about 20 pages listed in double-quotes-009.txt with open double quotes inside infoboxes. Closing the quotes adds a blank line to the infobox, which is probably what the articles' authors wanted to avoid. The Infobox_templates page suggests using "some_field=&nbsp;" for empty parameters but this also adds a blank line. Is there a preferred method of handling these? - Gimboid13 23:00, 8 December 2005 (UTC)[reply]

An example of this is Ballindine, and deleting the unbalanced italics quotes in the "motto_latin" and/or "motto_english" fields. It uses Template:Ie citytown infobox. I just inserted some extra quotes, and that seemed to display OK (no extra blank lines), and it's valid wiki syntax, so maybe see if this works elsewhere too? -- All the best, Nickj (t) 03:21, 9 December 2005 (UTC)[reply]

Template:Election Summary Begin leading to unopened |}

The Template:Election Summary Begin, used on several dozen elections-related pages, includes an opening {|, but no closing |}. This seems to be because the table needs to continue beyond the template, and is only closed after including some other stuff. See, e.g., Hinckley and Bosworth Council election 1999 for an example. Hence, the closing |} is always included explicitly in the article itself, obviously resulting in incorrect Wiki syntax. I'm not yet experienced enough here to know of a good solution. Anyone else have any ideas? ··· rWd · Talk ··· 11:29, 16 December 2005 (UTC)[reply]

The same thing happens with Template:Election FPTP begin, used on some 280 pages, and Template:Election box begin, used on 1000+ pages. The solution is simple, really, as mentioned on Template talk:Election box: use Template:Election box end to close the table, rather than |}. ··· rWd · Talk ··· 12:30, 16 December 2005 (UTC)[reply]
I noticed this as well. I'm not sure this project is workable for me at the moment. The first page I went to (GeForce 4) was huge and would be time consuming to find the error, if it still existed. The second I very nearly I made removed an opened <nowki>|}</nowiki> that would have completely broken the page. If extra unopened/unclosed brackets don't break things, is there really a strong argument for removing them all? Stevage 22:55, 19 December 2005 (UTC)[reply]
I suppose the argument is that most of the syntax problems are real; Most of the rest are at least messy (e.g. using {| to start a table, and {{end}} to end it). In the case you mention, I suspect the solution would be replacing |} with {{end}}, which will most problably result in the number of {| matching the number of |}, and the number of {{ matching the number of }}, which is what the syntax checker is looking for in this category. As for whether this is a strong argument, I'll leave that value judgement up to you, but there are 3 things that I should point out:
  1. The braces/tables category is the trickiest and fussiest category, and if you don't enjoy it or see the value then by all means don't do that category.
  2. Problems that aren't fixed will pop up in the next run, so on one hand it's good to fix them so they don't come up again; but on the other it's a case of just do you best, and if there's something that gets missed, then don't worry about it because if it's something we check for it will get listed again.
  3. Braces/table problems can be the ones that cause the most content to be hidden (e.g. I've seen malformed tables lead half of the content in an article to not be visible; and fixing them brings that content back). They may have updated the MediaWiki parser though to make it more tolerant of malformed tables, but I've certainly seen this happen in previous runs.
Hope that helps answer your question. -- All the best, Nickj (t) 01:23, 10 January 2006 (UTC)[reply]
Similar problems with pages that use Template:election dual-member and Template:CanElec1 - fixed by creating Template:election dual-member end and Template:CanElec1 end Kcordina 10:10, 23 December 2005 (UTC)[reply]
The {{end}} template contains the requisite characters to close a table, although intended primarily for succession boxes, it could also be used for other templates that need tables closing Kcordina

Question

This one appears to be a false positive:

http://en.wikipedia.org/wiki/Cattle#Biology

The |} seems necessary for formating. So either it should be done another way to avoid the false positive or the script should handle this case as valid. Perhaps the template at the top of the section needs editing? — Preceding unsigned comment added by WilliamKF (talkcontribs) [moved from project page by zenohockey 23:47, 24 December 2005 (UTC)][reply]

This was fixed by Kcordina, and the problem was that the table was started with {{wrapper}}, but ended with |}. Changing the end to {{end}} instead results in the number of {| equalling the number of |}, and the number of {{ equalling the number of }}, which is what the syntax checked is looking for (i.e. it wants a table to end the way it is started - either with the wiki table syntax for the start and end, or with templates for both the table start and table end). -- All the best, Nickj (t) 01:28, 10 January 2006 (UTC)[reply]

Suggestion - Category redirects

Maybe you want to add this to the next go-round. AFAIK, Category pages should never be redirected in the normal way (i.e. with #REDIRECT ). They should be redirected with the {{category redirect}} template. I've come across various ones that are not done the way they should be. It seems like it would be easy to generate a list of these bad Category redirects, and post them for people to run through and fix. Or this might even be done by a bot, if there aren't any sneaky corner cases to worry about... JesseW, the juggling janitor 08:24, 9 January 2006 (UTC)