| Welcome to my talk page
|
- I make plenty of errors - if you are here to complain about a tag or a warning, please assume good faith.
- If I have erred, don't hesitate to tell me, but being rude will get you nowhere.
- I will not tolerate any profanity or extreme rudeness. If used in any way, it will be erased and your message not read.
|
Hi! I am a COI editor working for a PR firm engaged by Thorsten Heins. I have prepared a new draft of his article that corrects a few errors and adds substantially more detail. Would you be willing to review my draft and make the copy go live if you feel it is constructive? The copy is in my sandbox. You can see it here [1]. Please let me know what you think. Thanks. Zooooooooom! COI (talk) 14:40, 30 August 2016 (UTC)[reply]
- Tracerzoom1973 Overall, your version is better than what is currently up. Could you add how he was named one of the worst CEOs of 2013. Also add a little more about why things went bad at BlackBerry during his tenure. While Heins becoming CEO of BlackBerry would be equivalent to him becoming the captain of the Titanic right after it hit the iceberg, Heins did make mistakes.
- Pinging @I dream of horses: so she knows I responded. Now I feel dirty for typing the word horses :) Bgwhite (talk) 19:56, 30 August 2016 (UTC)[reply]
- There is a line about an award Thorsten won and his ranking as one of the "worst CEOs." I will put that back in. I will try to find more detail on his tenure at BlackBerry.Zooooooooom! COI (talk) 09:24, 12 September 2016 (UTC)[reply]
re: Last Change here will not properly section link... the underscore is needed, or has been for over 12 years. // FrankB 12:26, 1 September 2016 (UTC)[reply]
Fabartus by just clicking on the link I think the underscore is not needed. Perhaps it has been some Mediawiki restriction many year ago but not any more. -- Magioladitis (talk) 12:32, 1 September 2016 (UTC)[reply]
- Interesting, Magioladitis. Since I still had to add them in the Wikibook project last year (when working that heavily). Actually spent a fair amount of time coding 'a few templates' that could auto-convert spaces to underscores when sections were the target of the term. (See these: Glossary and List of Notations there. Both are used extensively using a section link to cut down explanations during a related tutorial. Given the underlying code is probably automatically translated converting same for the needs of linking, the type of edit is still likely to be backwards and counter-productive. At least speaking as a computer engineer it raises my eyebrows! Similarly, IMHO, expanding {{cn}} to {{Citation needed}} is very undesirable for the opposite reason since it adds clutter to the text--parsing the text to keep meaning/comprehension and make useful phrasing reconstructions and inserts just becomes more difficult with such clutter. But that's a matter of taste. Best regards, FrankB 12:50, 1 September 2016 (UTC)[reply]
Ahem, again
Hi again, Magioladitis. On the above, note what happens inside a link in an url--the underscores are the outcome of having a space, so why change? NOT why I'm visiting today...
Ahem!
I fail to see how an edit such as this substitution edit:
- replacing html to be converted with a template call ...
- knowing template coding is translated into wikimarkup + into html ...
- so will later (in every preview and page save) need server processing cycles and expansion sub-routines ...
- All software processing which just returns an equivalent HTML/CSS command line.
So how is this needless change the least beneficial or worth the memory space and processor time it takes on the servers. If I were your boss evaluating your performance, I'd suggest a negative salary increase for the pay cycle. You're totally ignoring inefficiencies!
I think anyone running a bot has a moral responsibility to ensure your application is not needlessly changing pages. Admittedly, I'm more a hardware design guy, but don't see why this change is being made, especially since Wiki-markups system programmers are and always have been very careful (though I no longer follow those discussion streams either) to handle legacy HTML permissible code strings.
If these aren't equivalent, please tell me why:
- Form sent my browser by your version/change
<div style="clear:left;"></div>
- by my hand coding
<br clear="left"></br>
As expected, the code/form sent to my browser (IIRC, "<br clear=left>" had once been in one of the common templates from a switch parameter.)
(It's been a few years since I played in templates outside occasional Wikibooks needs!). So I wonder, are you too focused in some academia viewpoint wherein one thinks there is some authority that justifies such judgements or the real world where people actually make things happen and get the job done. Granted some things that were past practice occasionally need changed, but this sort of thing... waste of time. CSS/HTL is a mature technology. It's not going to modify such elementary functionalities at any conceivable date going forwards. I don't see any unnecessary change as anything beneficial, how about you? // FrankB 17:45, 11 September 2016 (UTC)[reply]
Fabartus nice to hear from you again.I think the reasons we do this are:
- We wont as less HTML code as possible. Maybe in some years where the Visual Editor will produce HTML output directly is not a problem but now having a mixed code of wikicode and html is ugly.
- The use of div is better than br for some reasons (Bgwite explain perhaps?)
- Templates are easier to spot
- It is easier to check whether the code is broken
And I think there was one more reason more important than these but probably Bgwhite knows it. -- Magioladitis (talk) 19:19, 11 September 2016 (UTC)[reply]
- Wanting as little HTML as possible — when that is the end product, seems like shoveling the ocean with a fork. But thanks for the answers, Magioladitis.
Not a user or fan of the visual editor, so that 'ugly' is just situation normal to me in coding of any kind. 'Course, there were some years when I worked a week (for pay!) to cut 15-18 BYTES out of Assembler/Machine Code, so any modern code is pretty handsome to me! I can remember when a Macro Assembler and, some years later, visual editors and integrated development systems were new tech. Having one worth the time on the wiki might be useful... but not if it hides more primitive code. Sometimes it's best to resort to a mix of markup and HTML tags. Did something yesterday (See the grouping of features on the same Broad Mountain) which would have been far faster had I done so.
(I think the BR vs DIV 'choice' is a philosophical bias of sorts. There is one camp thinking everything in HTML should have an end tag so you have tag-action/data-tag always. Call it a school of thought and style. The <ref name=Something /> construction must drive those people NUTS! LOL
TTFN FrankB 19:43, 11 September 2016 (UTC)[reply]
- The construct
<br clear="left"></br> is invalid HTML (because the specification for the br element states "No end tag"). It is valid XHTML (although it is explicitly discouraged in the XHTML spec), but Wikipedia has not served XHTML for several years now, since we switched to HTML5. The clear= attribute is obsolete in HTML5 (and was deprecated in HTML 4), but the style= attribute is valid in all versions since HTML 4, so a better construct would be <br style="clear:left;" />, which is valid in both XHTML and HTML5; <div style="clear:left;"></div> is also valid in both, but I see no reason why the {{clear left}} template cannot be used instead of all of these. --Redrose64 (talk) 21:17, 11 September 2016 (UTC)[reply]
- Hey there Redrose64 - me thinks you missed the question we started with. The query was why they substituted a macro (template) that the server then needed to translate back to HTML. Look at the diff I linked, this section top. The two results, one you say is invalid, is the code my firefox browser says was the streamed source code received here, both before and after their BOT changed things. As far as XML/HTML4, 5 or twenty, I could care less. The query was why make a conversion that creates more overhead. That it also junks up the history and takes another bit of hard drive space to reserve and save the previous and updated version I also find offensive as an engineer. Rather like Mr. Spock telling a joke. Not my nature as an engineer! LOL. Your answer however probably gives the reason behind the reason... that the "clear=left" construct is broken by convention. Damn Academics strike again. Think I have time to type all that extra overhead. Arrogant elitist idiots. If it works, don't break it! FrankB 04:16, 12 September 2016 (UTC)[reply]
- Templates are preferable to direct use of HTML for several reasons, first because it keeps the page entirely in Wikimarkup, so that our editors only need to learn one system. Not all of us are familiar with HTML (fewer are familiar with CSS), and for many, editing a Wikipedia page may well be the very first experience that they've had in making a Web page - we should expect them to learn template basics at the very least, so that they will know now much to remove when they replace
{{citation needed|date=September 2016}} with a ref. Another reason is that the HTML and CSS specs do periodically change (the clear=left attribute was perfectly valid in HTML 3.2), and browser vendors are not under an obligation to support features that have been marked as obsolete; when such changes occur, it's much easier to update one template than thousands of individual articles. Third, templates are almost always shorter, therefore quicker to type: {{clear|left}} and {{clear left}} are both 14 characters (and can be reduced to 13 by going through the redirect {{clearleft}}), whereas <br clear=left> (the shortest possible HTML form, albeit with an obsolete attribute) is 15. Making this non-obsolete but still as short as poss, as with <br style="clear:left">, raises it to 23 chars.
- There have been several discussions related to why
<div style="clear:left"></div> is preferable to the <br /> tag (with either form of attribute) at Template talk:Clear and at Template talk:-, of which Template talk:Clear#Why not br clear? and Template talk:-#Valid HTML5 are particularly relevant. In short: the clear: CSS property should only be used with block-level elements, and the br element is not a block element but inline (or "phrasing content" as they now call it); but the div element is a block element (or "flow content" as they now call it). --Redrose64 (talk) 09:30, 12 September 2016 (UTC) amended --Redrose64 (talk) 22:29, 12 September 2016 (UTC)[reply]
I want to tell u about u r last edit on Chi La Sow Sravanthi that u restored the SPD tag which previously deleted by me ..I removed that SPD tag by informing to the person who added that tag .He left a msg on my talk page that if I complete the update edit i can remove the tag so I removed the tag .But u restored the tag don't do that again .. If u want to say any thing please leave a msg on my talk page Joshq1234 (talk) 09:09, 22 September 2016 (UTC)[reply]
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
- The Wikimedia Commons app for Android can now show nearby places that need photos. [2]
<maplink> and <mapframe> can now use geodata from Open Street Map if Open Street Map has defined a region and given it an ID in Wikidata. You can use this to draw on the map and add information. [3][4]
Changes this week
- The RevisionSlider will be available as a beta feature on all wikis from 13 September. This will make it easier to navigate between diffs in the page history. [5]
 A new user right will allow most users to change the content model of pages. [6][7] The new version of MediaWiki will be on test wikis and MediaWiki.org from 13 September. It will be on non-Wikipedia wikis and some Wikipedias from 14 September. It will be on all wikis from 15 September (calendar).
Meetings
- You can join the next meeting with the VisualEditor team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 13 September at 19:00 (UTC). See how to join.
Future changes
Tech news prepared by tech ambassadors and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
18:04, 12 September 2016 (UTC)
 Hello, I'm ReferenceBot. I have automatically detected that an edit performed by you may have introduced errors in referencing. It is as follows:
Please check this page and fix the errors highlighted. If you think this is a false positive, you can report it to my operator.
Thanks, ReferenceBot (talk) 00:20, 15 September 2016 (UTC)[reply]
Hi there -- I'm mystified why you reversed most (all?) of the changes I made to Iyami Aje, and made some others. My changes reduced the number of flagged errors, yours not only restored those errors but created some new ones (e.g., turning a correct URL and ISBN into invalid ones). I've reverted your update, since I didn't see anything of value in it in a cursory glance, but if you can explain what you had in mind, maybe we can meet in the middle somehow. --Floatjon (talk) 06:55, 15 September 2016 (UTC)[reply]
- Floatjon I saw your revert before this message and said, "Why in the hell did I do that?" I don't know remember why I edited it. I was fixing ISBN errors from a list (
|isbn=5 800104480358), but you had already fixed it in the article. I edited it with AWB. I see "ressurecting" with wrong spelling, a "the the" and a Google book link to be shortened. I probably fixed those and saved. Every once in awhile, if AWB is saving while a connection is reset, gobbledygook ends up in the article. What's weird is the edit summary is "ce". I only do that manually, but the bad edit was done with AWB. Magioladitis, can you see any rhyme or reason? 07:27, 15 September 2016 (UTC)[reply]
- It looks to me as if Bgwhite edited an old version from the history somehow. Not sure how that happened. A good faith mistake, possibly bug-assisted, to be sure. – Jonesey95 (talk) 14:46, 15 September 2016 (UTC)[reply]
Hello, I'm ReferenceBot. I have automatically detected that an edit performed by you may have introduced errors in referencing. It is as follows:
Please check this page and fix the errors highlighted. If you think this is a false positive, you can report it to my operator.
Thanks, ReferenceBot (talk) 00:23, 16 September 2016 (UTC)[reply]
Can you please stop removing this [8] You have now done it 4 times without consensus. Best Doc James (talk · contribs · email) 17:54, 16 September 2016 (UTC)[reply]
- Doc James Egads, I left a message on the talk page. As I said on the talk page, the template seems to be broke and Wikipedia cannot be used as a reference per MOS. Bgwhite (talk) 21:16, 16 September 2016 (UTC)[reply]
- Thanks had missed it. Will continue discussion there. Doc James (talk · contribs · email) 21:44, 18 September 2016 (UTC)[reply]
thank you for your help on the page List of Prime Ministers of Australia with facial hair Christianjoe94 (talk) 10:27, 17 September 2016 (UTC)[reply]
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Problems
Changes this week
- The new version of MediaWiki will hopefully be on test wikis and MediaWiki.org from 20 September. It will be on non-Wikipedia wikis and some Wikipedias from 21 September. It will be on all wikis from 22 September (calendar). This is the version that was meant to go out last week.
Meetings
Future changes
- Wikidata will start working on adding support for Wiktionary. The Wikidata development team is now taking one last look at the development plan. [11]
Tech news prepared by tech ambassadors and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
22:08, 19 September 2016 (UTC)
Yeah, that did come out a little Swedish Chef-ed. Look OK now? Anmccaff (talk) 05:55, 22 September 2016 (UTC)[reply]
- Anmccaff I fixed a wikilink, but all looks good now. In saying thanks, I give you this pöpcørn recipe. Bgwhite (talk) 06:09, 22 September 2016 (UTC)[reply]
- PS: "MUTT" was neither an actual name, nor a contemporaneous nickname, so I re-fixed, or de-fixed that. The M151 article no longer has any mongrels in it. Anmccaff (talk) 06:13, 22 September 2016 (UTC)[reply]
I'm in a call right now that's talking about the end of Tidy.js (months from now), so I can't talk much right now. This will break some wikitext (well, it will stop unfixing some broken code). Have you followed any of this? mw:Parsing/Replacing Tidy has a list of some of the expected changes. Whatamidoing (WMF) (talk) 16:05, 22 September 2016 (UTC)[reply]
- @Magioladitis, NicoV, and Jonesey95:. Whatamidoing (WMF), thanks for the head up. I knew about some things, but not all.
- Jonesey alerted me about the self closing tags. This is now checked for in CheckWiki and there is also a maintenance category.
- The
<p> issue should not be a problem in articles. There are only 10 articles that use them.
- The
<li> issue should be minimal. We've already removed most of them. However, there are still articles with <li> laying around, mostly with lists needing to start at a different number besides 1. I'm not sure how many articles, but 500 on the low end guess.
- Some wikitext markup errors are detected. We were told about
<sup> and <sub> causing problems when there is no closing tag. We also look for <math>, <pre>, <nowiki>, <code> and comment tags not having a closing tag. We don't check for <small> or the other table issues. I have a feeling the small issue would apply to <center>. Oi vey, that would take years to cleanup and untold people yelling.
- Not sure what to say about Trailing whitespace migration
- Bgwhite (talk) 21:17, 22 September 2016 (UTC)[reply]
- We also check for unclosed tables and
<i> tags. Only one article uses <i>. We don't check tables when the beginning or ending part of the table is a template. Bgwhite (talk) 21:31, 22 September 2016 (UTC)[reply]
- If we can set up checks for them and have clear explanations of how to fix the errors, gnomes will be able to fix them. It looks like we have checks for most of them. It will take time, certainly, so we'll need plenty of advance notice.
- Wikipedia:CHECKWIKI/WPC 100 dump, which checks for problematic
<li> tags, has 3,400 pages listed, and it looks like it covers only mainspace. I expect that pages in other namespaces will break also, so we'll need to fix those as well.
- I am more concerned about other WPs; do they have gnome/maintenance communities that are at least as active as we have at en.WP? – Jonesey95 (talk) 03:33, 23 September 2016 (UTC)[reply]
- One case that I've thought of. The HTML line break tag
<br> and its XHTML-compatible variant <br /> (spaced or unspaced) are extremely common, and all equally valid in HTML5; but a significant number of people use the </br> tag instead of these, either by mistake or because they don't realise that the positioning of the slash is important. At the moment, Tidy converts all of these to <br />, so </br> currently yields a line break; but once Tidy is gone, those misconstructed line breaks will stop working. --Redrose64 (talk) 07:57, 23 September 2016 (UTC)[reply]
- There should not be any
</br> tags left in the wild on en.WP. Can you point to any? If so, CheckWiki and Category:Pages using invalid self-closed HTML tags may not be set up right. Fluxbot should have found and fixed all of the </br> by this point. – Jonesey95 (talk) 13:52, 23 September 2016 (UTC)[reply]
- There may not have been any instances of
</br> when you checked, but I have certainly come across some in the last month. Uses of the </br> tag won't show in Category:Pages using invalid self-closed HTML tags because </br> is not a self-closed tag, for which the syntax is always either <tagname /> or </tagname />, the spaces being optional. --Redrose64 (talk) 20:17, 23 September 2016 (UTC)[reply]
- Redrose64 for
<tagname /> or </tagname />, CheckWiki is checking for (in theory): abbr b br big blockquote center cite del div em font i p s small span strike sub sup td th tr tt u
- What tags other tags should be checked? Do you have any examples if it involves one of the tags above? Bgwhite (talk) 21:09, 23 September 2016 (UTC)[reply]
- By "it" I mean the specific tag
</br>. I've amended my last post accordingly. The tags that should be checked are any HTML tag that is not specifically described as a void element. --Redrose64 (talk) 22:18, 23 September 2016 (UTC)[reply]
- Redrose64, I made one or two possible errors above. First, I should have linked to Wikipedia:CHECKWIKI/WPC 002 dump in my comment above. That is the page where
</br> errors were listed, at least in mainspace. I don't know if it checks other namespaces (my second possible error in generalizing that there are no errors left). If it does not, someone will need to run that report on all namespaces if this errant closed tag something we need to fix. – Jonesey95 (talk) 05:42, 24 September 2016 (UTC)[reply]
- @Redrose64 and Jonesey95:, currently WPC only checks for main space, not the other namespaces, but I can add the option. After that, I will probably need someone to run the analysis: I'm often traveling with not so good internet connection, and downloading the 13G for pages-articles.xml.bz2 is already very difficult, but I'm not sure it contains all namespaces, so I will pass on downloading a bigger file... --NicoV (Talk on frwiki) 06:52, 25 September 2016 (UTC)[reply]
- For the
<small>...<small> mentioned at Wikitext markup errors, WPC should be catching them as #55, but CW is not (Bgwhite, do you think it should be added there ?). I'm currently running a dump analysis on frwiki for #55, result should be available soon in fr:Projet:Correction syntaxique/Analyse 055 (and I can tell it will be a huge list...). I can also run it for enwiki but with dump for August 1st. --NicoV (Talk on frwiki) 11:01, 23 September 2016 (UTC)[reply]
- As expected the list for frwiki is huge (well over the 2MB limit, so it got truncated at "F"...). I'm currently running the same for enwiki, results will be at Wikipedia:CHECKWIKI/WPC 055 dump. --NicoV (Talk on frwiki) 18:26, 23 September 2016 (UTC)[reply]
- @NicoV and Magioladitis:, CW #55 only checks if there are two small tags in a row, ie
<small><small>text. I can add a check for finding more opening tags than closing tags. Magioladitis, you have been the one fixing #55 for awhile, add check in #55 or new error? Bgwhite (talk) 18:43, 23 September 2016 (UTC)[reply]
- Bgwhite Add in #55 but this is going to be huge I guess. -- Magioladitis (talk) 18:51, 23 September 2016 (UTC)[reply]
- Huge is guaranteed.... In the logs of the dump analysis I'm running for enwiki, #55 seems to be the vast majority of errors... --NicoV (Talk on frwiki) 19:24, 23 September 2016 (UTC)[reply]
- Are you sure that two small tags in a row is actually an error? People could be using nested tags to get Small Smaller Smallest text effects. Whatamidoing (WMF) (talk) 03:30, 24 September 2016 (UTC)[reply]
- Whatamidoing (WMF) It's an accessibility error. Text can't be smaller than 85%, which is what one small tag does. Also check if there is a small tag in an image description. The description is already small Bgwhite (talk) 07:56, 24 September 2016 (UTC)[reply]
- Jonesey95 (or anyone else): How much time do you think enwiki (specifically) needs to prepare for this? This is definitely not happening until next year (i.e., some time in 2017), but I don't know how early in 2017 it might be possible.
- Most small Wikipedias (let's say that's 75% of them) have few or no gnomes and essentially no technical resources. On the other hand, they also don't have a hundred different sets of templates for creating tables, or six different sets of column-faking templates that can produce open divs or unclosed tables, so the problems may be fewer. Beyond the Wikipedias, I'm primarily worried about the Wikisources. They've got some amazing tech-oriented volunteers, but they've also got lots of templates and lots of appearance-related effects. Whatamidoing (WMF) (talk) 03:50, 24 September 2016 (UTC)[reply]
This edit undid something that I put in the Viking metal article intentionally. The website listed discusses the Viking metal article as it stood in mid-2012, which was very different than the article as it stands now. I listed the link with an oldid so that the reader can read that version of the article and understand what the author of the blog post is talking about.--3family6 (Talk to me | See what I have done) 22:28, 22 September 2016 (UTC)[reply]
Extended confirmed protection
Hello, Bgwhite. This message is intended to notify administrators of important changes to the protection policy.
Extended confirmed protection (also known as "30/500 protection") is a new level of page protection that only allows edits from accounts at least 30 days old and with 500 edits. The automatically assigned "extended confirmed" user right was created for this purpose. The protection level was created following this community discussion with the primary intention of enforcing various arbitration remedies that prohibited editors under the "30 days/500 edits" threshold to edit certain topic areas.
In July and August 2016, a request for comment established consensus for community use of the new protection level. Administrators are authorized to apply extended confirmed protection to combat any form of disruption (e.g. vandalism, sock puppetry, edit warring, etc.) on any topic, subject to the following conditions:
- Extended confirmed protection may only be used in cases where semi-protection has proven ineffective. It should not be used as a first resort.
- A bot will post a notification at Wikipedia:Administrators' noticeboard of each use. MusikBot currently does this by updating a report, which is transcluded onto the noticeboard.
Please review the protection policy carefully before using this new level of protection on pages. Thank you.
This message was sent to the administrators' mass message list. To opt-out of future messages, please remove yourself from the list. 17:48, 23 September 2016 (UTC)
18:07, 26 September 2016 (UTC)
Why would you even think about editing the title of an article from another publication used in a reference citation??? If the Alton Telegraph prints "COLLEGE MEN's SOCCER", then the reference is NOT "COLLEGE MEN'S SOCCER"; it IS "COLLEGE MEN's SOCCER" despite the typo... GWFrog (talk) 20:21, 27 September 2016 (UTC)[reply]
- GWFrog I made ~15 changes in the article including fixing a broken {{yel}} template (
{{yel}}76}} to {{yel|76}}) and changing single quotes per MOS. You reverted me saying "reverted---titles given as used in cited publications". You obviously never read my edit summary or you would have fixed the template problem with the revert. As I made alot changes to single quotes in titles, I can only assume you objected to that. You never said specifically what is wrong. You also don't revert ~15 changes for something "little" that can be fixed manually or by fixing what was wrong to begin with via the revert.
- Also per MOS:ALLCAPS,
Reduce newspaper headlines and other titles from all caps to sentence case or title case . Bgwhite (talk) 20:42, 27 September 2016 (UTC)[reply]
Hello, I'm ReferenceBot. I have automatically detected that an edit performed by you may have introduced errors in referencing. It is as follows:
Please check this page and fix the errors highlighted. If you think this is a false positive, you can report it to my operator.
Thanks, ReferenceBot (talk) 00:15, 28 September 2016 (UTC)[reply]
Hi,
Could you please tell me what references are apparently 'fake' and/or 'unreliable'?? I spent over an hour this morning going through it and making sure all of the referencing was accurate?? All the links are to valid sites? This is for a university assignment so I am making sure my referencing is accurate?? — Preceding unsigned comment added by CS-HIST3002 (talk • contribs) 04:47, 28 September 2016 (UTC)[reply]
|
