Wikipedia talk:WikiProject Wiki Syntax/archive01

• Maybe we need to start a Wedipedia:Do Not Call list? --pjf 02:38, 11 Nov 2004 (UTC)

• Well i think anybody trying to abuse this list will get more bad publicity than help. Besides, Wikipedia is community project, so everybody with an account here could be viewed as 'susceptible' :) - JohnyDog 15:59, 11 Nov 2004 (UTC)

• Not sure of the current status, but there's been a lot of debate about dashes, including whether the wiki software could "automatically" convert double-hyphens to em-dashes or en-dashes, whether there should be an official proclamation on the One True Dash in the style guide, and so on. I'd avoid making dashes part of this particular project, as it's focused specifically on problems with wiki syntax, not style guide issues (which are inherently a lot more controversial). I recommend you head over to Wikipedia:Manual of Style (dashes) for the latest on this topic. -- Avaragado 21:17, 11 Nov 2004 (UTC)

• Good idea! As part of the third batch I've done a search for articles that look to include that text rather than being in the 1911 category as preferred. There were 52 articles all up, so I've made them into a list, and added the list to the main project page. All the best, --Nickj 22:52, 29 Nov 2004 (UTC)

• Ok having actually read the project page I see now that some of these "issues" are addressed on it. Just not effectively enough apparently. I also see you are recommending the "nowiki" insertions, not sure I agree with this. I think they are confusing at best and problematic at worse. Paul August 19:10, Nov 11, 2004 (UTC)

:*I tend to agree with you on this matter. I came across those the alst time this dump was ran and left them as is. the problem now has arisen that someone, such as myself, who is trained in math and realize when they are right and wrong, could have put int he nowiki tags and prevented someone who is untrained from invalidating what used to be good equations. I did ask to have the warings added (which you found) but I have been thinking that the best thing to do would be to nowiki tag them as to alert people that the author knew what he was doing when he wrote it that way. Cavebear42 19:50, 11 Nov 2004 (UTC)

::*Nowiki is unfortunately a long tag, and it can reduce readability. But I agree that if it's not used, there's no way to tell between a legitimate open bracket and a malformed external link. We should add nowiki to math pages and other pages which use brackets and braces. Rhobite 20:04, Nov 11, 2004 (UTC)

:* Yes. As the main page grows longer and longer, I suggest moving the FAQ to separate page (maybe rewritting some questions to guidelines, along with sample problems and solutions, as you're suggesting) and linking it to top of all syntax-* pages (like "Before fixing anything please read the guidelines"). As for the math, most of the brackets should be now fixed (huge portion of problems are now quotes) so it shouldn't be that much of a problem for future - JohnyDog 20:24, 11 Nov 2004 (UTC)

Estel 19:18, Nov 12, 2004 (UTC)

• If you scroll down to the bottom of the How Does This Work? section you'll see a completed pages bullet which shows the pages done so far. JohnyDog cleaned the page yesterday. I'll bold it to make it clearer. -- Martin TB 20:17, 12 Nov 2004 (UTC)

• the ordinary brackets pages were removed by Nickj few days ago with (Cull all but one ordinary brackets - probably better to fix the other types of problems first). I'm the one who 'massacred' main page yesterday, but i've double checked that nothing is missing :) - JohnyDog 20:21, 12 Nov 2004 (UTC)

• Yes, I removed the links to the ordinary brackets (parentheses) pages. Currently these are all valid pages:

:

:* ordinary-brackets-001

:* ordinary-brackets-002

:* ordinary-brackets-003

:* ordinary-brackets-004

:* ordinary-brackets-005

:* ordinary-brackets-006

:* ordinary-brackets-007

:* ordinary-brackets-008

:* ordinary-brackets-009

:* ordinary-brackets-010

:* ordinary-brackets-011

:* ordinary-brackets-012

:* ordinary-brackets-013

:* ordinary-brackets-014

:* ordinary-brackets-015

:* ordinary-brackets-016

:* ordinary-brackets-017

:

:Additionally, I've got files here that would cover the range ordinary-brackets-018 through to ordinary-brackets-134 inclusive (but these aren't in the Wikipedia yet). My thinking was that the other things (i.e. just quotes at the moment) were maybe better to fix before these. Most of the ordinary brackets problems seem to be things that have been scanned-in or created in a text editor, with new lines every 80 characters or so - so most of the time it's a question of just removing the new lines (although maybe about 15 to 25% of the time there really are mismatched parentheses). Also the sheer number of ordinary-brackets pages is pretty huge (and so would probably takes ages and ages to get through), and (if you want to be really pedantic) parentheses aren't a wiki syntax (although they're easy to find if you're already looking for the other stuff). One possibility is to add the links to the ordinary brackets lists to the main page, but only after the quotes are done, and then to not to hold up the next run if there are still ordinary brackets that aren't fixed (i.e. outstanding unfixed ordinary brackets would not block the next run). Another thing I was unsure about was maybe dropping the searching for mismatched parentheses entirely from the next run, but I'm really not sure. One other complication is that intentional mismatched parentheses shouldn't really be put in nowiki tags, unlike the other kinds syntax (since they're not a wiki syntax) - which means that if there are valid uses of mismatched parentheses, then those things are likely to turn up over and over in successive runs. What do you folks reckon? Should ordinary brackets be part of the Wiki Syntax project or not (or should they only be done for a few runs, and then dropped)? If yes, should other types of problems take priority? Should a new run be blocked if there are outstanding unfixed ordinary brackets? All the best, Nickj 23:36, 12 Nov 2004 (UTC)

:* Should the case where the (ordinary) brackets are separated by newline really be considered as error ? From wikipedia POV it's perfectly valid syntax. In most cases (as you said) it's more problem of the whole article - removing one newline really won't help anything, and fixing all newlines in article is IMHO far beyond the scope of this project. As we cannot exclude valid uses from showing up again and again, i'd say lets drop it for now. Also, does the script list pages with problems like "[link)" in both ordinary-brackets and square-brackets ? If yes, it's another reason for at least postponing it for next run. - JohnyDog 01:56, 13 Nov 2004 (UTC)

::Re: "From Wikipedia POV it's perfectly valid syntax" - Didn't know that, and that's a very good reason to not fiddle with them.

::Re: "Also, does the script list pages with problems like "[link)" in both ordinary-brackets and square-brackets?" - No - the categories and exactly what they included are:

::* "ordinary-brackets", array("(", ")")

::* "double-quotes", array("''")

::* "triple-quotes", array("'''")

::* "square-brackets", array("]", "[", "", "", "[ and ]]", " and ]", "[ and )", "( and ]", "( and ", "] and )", "]] and ", "( and [", ") and ]", "( and ", " and )", " and ]]", "] and [")

::* "headings", array("==", "====", "===", "== and ===", "==== and ==", "== and ====", "=== and ==", "==== and ===", "=== and ====")

::* "miscellaneous", array(") and (", " and )", "( and ", " and (", ") and ", "]] and ", " and ", "] and ==", " and ] and )", " and ", " and [[", " and ", " and ]", " and )", ") and ", "( and ==", "[ and (", ")|" // Comment open and close

. "(====)|(===)|(==)|" // Wiki headings

. "(<math>)|(</math>)|" // Math tags

. "(<nowiki>)|(</nowiki>)|" // Nowiki tags

. "()|()|" // Code tags

. "()%i"; // div tags

$matches = preg_split ($pattern, strtolower($string), -1, PREG_SPLIT_DELIM_CAPTURE | PREG_SPLIT_NO_EMPTY);

foreach ($matches as $format) {

if ($format == "<nowiki>") {

if ($in_nowiki == false) addRemoveFromStack($format, $format, false, $formatStack, $string);

$in_nowiki = true;

}

else if ($format == "</nowiki>") {

if ($in_nowiki == true) addRemoveFromStack($format, "<nowiki>", false, $formatStack, $string);

$in_nowiki = false;

}

else if ($format == "<math>") {

if ($in_math == false) addRemoveFromStack($format, $format, false, $formatStack, $string);

$in_math = true;

}

else if ($format == "</math>") {

if ($in_math == true) addRemoveFromStack($format, "<math>", false, $formatStack, $string);

$in_math = false;

}

else if ($format == "") {

if ($in_comment == true) addRemoveFromStack($format, " [[test Fix wikilink syntax blah blah blah". Then we don't have to go to each article to search every small thing you changed to find bad "fixes". - Omegatron 04:55, Mar 12, 2005 (UTC)

Can you please be more specific about what we did that was bad? For example, is there a particular error that we're misdetecting? If so, please let me know. Please realise that we're not perfect, but we're honestly not trying to introduce problems.

With the current batch, there's just two types of errors listed at the moment, namely:

• Redirects that had slightly bad syntax (e.g. "#REDIRECT(Blah)", instead of "#REDIRECT [[Blah"; For these the suggested summary is "Fix Redirect Syntax".
• Redirects that were double redirects (e.g. A → B → C, which gets changed to A → C); For these the suggested summary is "Fix Double Redirect".

Which one of these was wrong? They're both fairly straightforward transformations, and hopefully neither should introduce new errors (but for example in the double-redirect case, if it was wrong for A to redirect B, and we then change A to redirect to C, then the source of the error was that A redirected to B, not that we changed A to redirect to C). -- All the best, Nickj (t) 07:42, 12 Mar 2005 (UTC)

• Yes, please do remove these from the list. Fixing this is on the to-do list. Basically the Wikipedia wants normal links to start and end on the same line, but image tags are allowed to run over multiple lines. A special case needs to be added to detect "Nickj (t) 23:13, 23 Mar 2005 (UTC)

::As long as this is corrected before the next run; otherwise, we'll be removing them from the list over and over... (Especially since they end up appearing twice; I had to get rid of something like 15—20 occurences on 001.) Fbriere 00:38, 24 Mar 2005 (UTC)

comment

and should probably be ignored, as they're valid and a complete waste of time to "fix".

--Jshadias 23:07, 23 Mar 2005 (UTC)

• :-) Interesting! That's a somewhat tricky one to parse correctly (at least with the current KISS approach, which will detect it as two open comment tags, rather than an open and then a close). It is valid HTML. However, it's definitely quicker to change a handful of articles than it is to change the parser (at least from my perspective), given that the total number of articles in the Wikipedia that use this construct must be quite small (e.g. less than 10). Do you have the titles of the articles that use this, and I'll get them changed? -- All the best, Nickj (t) 23:31, 23 Mar 2005 (UTC)

::eh, I'll just change them when I come across them. As long as it's uncommon it's not a huge deal. --Jshadias 14:36, 24 Mar 2005 (UTC)

:recipient of the Victoria Cross, the highest and most prestigious award for gallantry in the face of the enemy that can be awarded to British] and [[Commonwealth forces.

Would it be possible to create a bot to take care of these? (Though I notice [http://www.google.ca/search?q=site:en.wikipedia.org+%22recipient+of+the+Victoria+Cross%22+%22United+Kingdom+British%22&filter=0 Google] only shows 20 such articles. If this is accurate, I guess manual work would still be cheaper...)

: Probably not worth adding a bot for this by a long shot. Getting permission to run and operate a bot is a political process (see Wikipedia:Bots). You need to two levels of permission / non-objection (one from en, one from meta). The burden of proof that the bot is non-harmful is on the author. Many more regulations on bots have been discussed and may be added at some point. For 20 articles, it's (IMHO) really really really not even remotely worth the grief, hassle, and red tape. -- All the best, Nickj (t) 01:26, 24 Mar 2005 (UTC)

It's commonly accepted in software development that it's a lot cheaper to fix a bug before the product is released than to release it and then have to go back and fix problems. It seems we would do well to do this sort of syntax checking right on the edit page (make it part of the "Show preview" function) instead of finding them in batch mode later. --RoySmith 01:02, 26 Mar 2005 (UTC)

:I agree. The functions that provide the Wiki Syntax checking are in the #Source code section above (just added licensing to indicate that they're under the GPL), and I plan to release a very slightly updated version of those functions soon. I would like the see these incorporated into MediaWiki in some way (e.g. either a "Check Wiki Syntax" link in the "toolbox" section, or as part of "Show preview"), as the GPL licensing would allow this, and I encourage the MediaWiki developers to add this. Even with this though, there are still going to be errors that need to be cleaned up in batch mode, but it would be an improvement. -- All the best, Nickj (t) 04:27, 26 Mar 2005 (UTC)

• msg001.
• msg002.
• msg003.
• msg004.
• msg005.
• msg006.
• msg007.
• msg008.

:—Ævar Arnfjörð Bjarmason 02:05, 2005 May 15 (UTC)

:In that list there are a lot of user pages, talk pages, and pages that have nowiki around the msg template. Should we just delete those out of your list or what? --Kenyon 05:08, May 16, 2005 (UTC)

:: Looks like a bot has been written / is being written to resolve these (i.e. it now has an SEP field around it) -- All the best, Nickj (t) 02:55, 3 Jun 2005 (UTC)

: I had a go at it, hope it's fixed now, but if it's not I guess we'll know because it'll turn up in the next batch. ;-) -- All the best, Nickj (t) 02:55, 3 Jun 2005 (UTC)

: I don't feel too strongly about it, but by having a separate table, plus striking out, it makes sure that the uncompleted stuff is quite visible and all grouped together, and by also striking completed pages out it makes it doubly-clear that those things are already done (in case people are just skim-reading). (In other words: Yes, it is redundant, but maybe the redundancy is sometimes helpful). -- All the best, Nickj (t) 02:55, 3 Jun 2005 (UTC)

I've generated another list of double redirects as of the 20050516 database dump at User:triddle/double_redirect/20050516. I did not want to edit the project page since I'm not a member of this project. Perhaps someone else knows the best way to try to integrate my list with this project? Thanks. Triddle 21:18, Jun 23, 2005 (UTC)

: Hi Triddle, Go for it! Please feel free to edit away to add your double redirect list. I'm not precious about what people list (as long as it's relevant, which this clearly is), and I tend to be pretty slack about running the current script that finds the syntax problems and generates the lists (typically I run it once every 2 or 3 months), so any help with producing up-to-date lists is more than welcome. In terms of integrating them, maybe just edit the pages (example) and add the updated lists (if you're happy to do this), and update the main page accordingly. Also, please be sure to add yourself to the "credits - software" section of the page. Add if you're feeling like doing some other extra stuff, two related things that may interest you are the listing of malformatted redirects, and broken redirects (i.e. redirects that point to something which isn't there). (e.g. [http://en.wikipedia.org/w/index.php?title=Wikipedia:WikiProject_Wiki_Syntax/non-existent-redirect-000.txt&oldid=12880795 to illustrate, here's an old example that's already been fixed up]). The trick with the malformed ones is just applying a regex to all redirects and listing what doesn't match, and the main trick with the second is that people sometimes include a # in their redirect targets, so everything after the # has to be ignored. All the best, Nickj (t) 02:21, 27 Jun 2005 (UTC)

I've been getting pretty good at analyzing the dump files with perl and getting useful stuff done. I am curious if I could help work with this project? How are you preparing your lists? If you are having problems beating really hard on SQL databases then I might be able to help by having it done through analysis of the dump files. Let me know if you think I can help. Triddle 06:42, Jun 26, 2005 (UTC)

: Absolutely you can help! The current problem finding script is a serious mess, as it integrates three different projects into the one script (suggester.php), so it lacks the clean separation that it really should have (and I tend not to have the time to do anything with it for extended periods, including add the separation that it really requires). It's also got quite slow (probably as a result of doing too much at once, plus I think I've maxed out the memory on the box I'm using, so it's starting to thrash to disk), taking now around 7 or 8 days to do a complete run. The current code is in PHP, but a cleaner and quicker reimplementation (in any language, such as perl) would be a very good thing. You can [http://home.swiftdsl.com.au/~npj/Wikipedia/Wiki%20Syntax,%20LinkBot,%20Redirect%20suggestions.zip get the current source code here]. This includes the source code for preparing the lists (in output_malformed_pages.php). All the best, Nickj (t) 02:21, 27 Jun 2005 (UTC)

For example, for the [http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Usability usability project], I suggested that there might be value in adding to the Tool box.

I just edited this page, please run some standard software to identify common typing errors, that I could fix right now.

AlMac 4 July 2005 18:56 (UTC)

:Smack - read this page. JesseW 16:22, 24 July 2005 (UTC)

::Thanks. I didn't figure to look there :) --Smack (talk) 02:55, 25 July 2005 (UTC)

:::You want either of the output_*.php files from the ZIP file. They both generate a series of text files that can then be copied and pasted straight into the Wikipedia as lists of things that need doing. (I never got around to writing a bot to upload the files without human intervention). If you're suggesting disambiguations then probably the most similar file will be output_malformed_pages.php - you probably want the "outputToFile" function, and the global defines, and then delete the rest of the file, and then go from there to add the stuff that's specific to disambiguations. Hope that helps. All the best -- Nickj (t) 06:49, 30 July 2005 (UTC)