User:Sanbeg/Wikisource:Scriptorium/Archives/2016-08

Visual Editor now in article space

visual editor is now a beta feature for article space editing. check it out and leave feedback. here is the fabricator task https://phabricator.wikimedia.org/T48580 -- Slowking4♡RAN's revenge 16:28, 7 April 2016 (UTC)

visual editor is now a beta feature for page space editing. get your comments in. Slowking4 ‽ RAN's revenge 13:40, 1 July 2016 (UTC)

Connecting SCOTUS documents on Wikisource (and then, Wikidata)

Dear all, at the end of May, a small conference was host in Berlin, called meta:WikiCite 2016. The core topic of the conference was "citations", meaning Wikipedia references, and how to manage those data in a structured way. Ideally, in the next years, we'll have Wikidata (or another project) full of items representing bibliographic records, articles, books and documents.
During the conference, and as a fundamental step in the roadmap, we created d:property:P2860, a property dedicated to citations between documents. If document A cites document B, than we can use that property. Of course, this property is perfect also for Wikisource, to illustrate citations between texts.
A great example are Category:United States Supreme Court decisions, which are

already on Wikisource
already on Wikidata with their own item
most of them have wikilinks to other SCOTUS decisions.

I'd love to use the corpus of SCOTUS decisions as a testbed for this kind of property. It would be amazing to generate a "citation graph" of all documents connecting to each other... Moreover, it would be amazing to use Wikisource, setting an important precedent and show the reaso of the world the potentiality of this project ;-).
I started gathering data and I think this can be done quite smoothly. I'm writing to you, before writing to all other people in the dedicated mailing-list (please, join, you're welcome), because I think the Wikisource community should be involved in this. One part of the work is extract citations from the page: meaning, for example, that we need a list of all the SCOTUS decisions cited by Caldwell's Case. Luckily, the API allow us to do that, but then we'd need to "clean" the data. Also, it would be fantastic to be sure to have all the relevant wikilinks in place (many decisions have not wikilinks, even though they cite other decisions). Also, I'm not sure that a simple wikilink is the best strategy: in it.source we have a proper template to handle citations, and maybe you could use it too. Maybe a bot could parse the SCOTUS decisions and insert wikilinks or templates?
I will probably start a page on Meta to coordinate this effort, you're welcome to help :-) Aubrey (talk) 13:24, 13 June 2016 (UTC)

Also: here you can find a document with:

WIKIDATA ITEM
TITLE
URL on WIKISOURCE
QUERY URL for getting the wikilinks inside the page

Aubrey (talk) 13:37, 13 June 2016 (UTC)

There is Wikisource:WikiProject U.S. Supreme Court cases, so @Slaporte: and maybe @Tarmstro99: — billinghurst sDrewth 15:53, 13 June 2016 (UTC)

This project looks fantastic! I'll sign up. stephen (talk) 01:42, 3 July 2016 (UTC)

Zines?

Does Wikisource accept zines or fanzines? I have not been able to find a category for those kinds of works, which I'm sure a part of them are licensed under free Creative Commons licenses. Is there any particular reason there doesn't seem to be zines included in this library? NMaia (talk) 15:47, 21 June 2016 (UTC)

Why We’re Not Digitizing Zines; Zine Librarians Code of Ethics: Use; but if you have done the copyright search, go for it. Slowking4 ‽ RAN's revenge 16:09, 21 June 2016 (UTC)

@NMaia: Zines are very underground and usually unprofessional so the copyright issues are the biggest obstacles but this library would definitely be enhanced with some! Do you have any in mind? —Justin (koavf)❤T☮C☺M☯ 20:07, 21 June 2016 (UTC)

@Koavf: Not particularly, and an initial web search for "Creative Commons zines" wasn't very fruitful. But I might look into this in the near future :) NMaia (talk) 21:49, 21 June 2016 (UTC)

@NMaia: our criteria is WS:WWI, so clearly we need the copyright issue, then we have the nub of the question of being peer-reviewed production. — billinghurst sDrewth 03:31, 22 June 2016 (UTC)

It might be worth pointing out for comparison that many university libraries have zine and other similar media collections. It would be a case by case thing but in principal I think there's a good argument for this kind of media having historical interest. Prosody (talk) 23:54, 21 June 2016 (UTC)

Importance I definitely think they are important and especially so at documenting certain subcultures and scenes. The problem is just the licensing--not a lot of thought was put into it in the first place. We need to reach out directly to the creators and owners. —Justin (koavf)❤T☮C☺M☯ 01:06, 22 June 2016 (UTC)

@Koavf, @Prosody: Today I accidentally bumped into this zine. What do you think, is it hostable? NMaia (talk) 03:45, 22 June 2016 (UTC)

@NMaia: It already is! If you want to work on it, that is fantastic. If you need help, let me know. —Justin (koavf)❤T☮C☺M☯ 03:48, 22 June 2016 (UTC)

@Koavf: Well, this will be pretty challenging, so I welcome your help for proofreading it :) NMaia (talk) 03:50, 22 June 2016 (UTC)

@NMaia: The best course of action would be to email me in a week--my free-est day is Wednesday. Thanks! —Justin (koavf)❤T☮C☺M☯ 03:53, 22 June 2016 (UTC)

@NMaia: http://www.openculture.com/2016/07/legendary-west-coast-punk-music-zines.html —Justin (koavf)❤T☮C☺M☯ 00:20, 14 July 2016 (UTC)

@Koavf: neato petito! Would you like to work on those? I have a pretty big plate right now at the Portuguese Wikisource and some work here as well. NMaia (talk) 02:20, 14 July 2016 (UTC)

Duplicate book

Hi, I found Index:Dictionary of Christian Biography and Literature (1911).djvu from 'random transcription', and did a fair amount of work on it before realizing that it's a duplicate copy.... the same source file has already been transcribed as Dictionary of Christian Biography and Literature to the End of the Sixth Century (which is the full title). It's rather broken, as the first index page I linked shows the work as not having been worked on, while it's completely transcribed and proofread under the second one. If someone could fix this (I'm assuming the correct way would be to make the pages under 'Dictionary of Christian Biography and Literature (1911)' either go away or be redirects) that would be nice. Thanks in advance. 2602:304:CEEB:4D60:C0EE:C65F:5D42:C37F 17:29, 27 June 2016 (UTC)

Actually, looking closer, I guess it's not that simple... the 'existing' copy was apparently imported by a bot, instead of being transcribed here, and the pages aren't transclusions... see the source and history of Dictionary of Christian Biography and Literature to the End of the Sixth Century/Abercius, bp. of Hierapolis. Not quite sure, now, what to do, unless the 'correct' answer is to go ahead and transcribe them, and then transclude them onto the existing pages... 2602:304:CEEB:4D60:C0EE:C65F:5D42:C37F 17:34, 27 June 2016 (UTC)

If the source is the same, I would go for this last option.— Mpaa (talk) 18:33, 27 June 2016 (UTC)

Might I point out Talk:Dictionary_of_Christian_Biography_and_Literature_to_the_End_of_the_Sixth_Century#Structure_change. This is an incomplete match-and-split exercise apparently still in progress (though after this amount of time presumably stalled. A quick survey indicates none of the substantive editors have been active here since 2013.) AuFCL (talk) 22:34, 27 June 2016 (UTC)

@AuFCL: Thanks. The text on the 'source' pages appears, indeed, to have been patched together from the non-transcluded 'articles' (including a few cases where an article was pasted into the same page twice), and the 'source material' is pretty obviously identical to the djvu. Really, most of what the part I've looked at so far needs is some formatting and double-checking of the greek transcriptions (there are a lot of diacritical marks), and then to be transcluded back over... it's not, by any means, 'raw ocr'. After my moment of 'oh crap, it's already done', I'm intending to keep running through the pages (in the page namespace) and then transclude the individual articles back into the main namespace 'article' pages, using something like the DNB as a model... though that {{DCBL}} header template is meh, as it does not allow you to add the individual contributor for each article like the DNB one does. 2602:304:CEEB:4D60:C0EE:C65F:5D42:C37F 23:17, 27 June 2016 (UTC)

Usage of {{DCBL}} is currently exclusive to this work so is safely modifiable without conflict. If you need help please just ask. AuFCL (talk) 23:46, 27 June 2016 (UTC)

@AuFCL: (nods) It's dependent on {{Collective work header}}, which (a bit oddly, tbh) doesn't support the 'contributor' field like {{header}} does.... since {{collective work header}} itself depends on {{header}}, it would probably make more sense (imo at least) to alter them both to pass the field through. I know how to do it, and could do so, but I'm not being 'me' for a while, and I doubt an IP can edit them. 2602:304:CEEB:4D60:C0EE:C65F:5D42:C37F 00:16, 28 June 2016 (UTC)

@AuFCL: Not protected, actually... please double-check diff and diff, if you don't mind. Thanks. 2602:304:CEEB:4D60:C0EE:C65F:5D42:C37F 00:26, 28 June 2016 (UTC)

All three(!) changes look reasonable to me. More to the point they work too. I have slight misgivings about the nesting depth but that is not of your design. AuFCL (talk) 01:03, 28 June 2016 (UTC)

Having finally gotten around to looking at some of your detail edits I have to admit some of the Greek diacritic issues are well beyond my limited abilities (though in general please note this work uses Latin phi (ϕ) not modern Greek phi (φ).) May I recommend consulting with either Beeswaxcandle or EncycloPetey, both of whom are likely to be far more confident in this area?

Oh, and please be aware that {{small-caps}} (a.k.a. {{sc}}) is only effective upon content containing lowercase. AuFCL (talk) 01:45, 28 June 2016 (UTC)

I agree that the Greek is above my head... I'm mainly just catching a few where a character or diacritic was 'obviously' missing, it really does need a scan by someone who has more knowledge of Greek (this was a 'random transcription', lol), and I don't think I've changed a phi, though I likely missed fixing some (and thank you for pointing that out, I'll keep an eye on it...it was not an issue I was looking for). As far as the smallcaps, I was aware... the unedited text has most of them all in capitals, if I left one that way it's because I simply missed it. Because I'm editing as an IP, I'm not actually marking any as 'proofread' anyhow (I can't) so they will, hopefully, eventually, get further passes. I do intend to go ahead and transclude them, but they will be a step up from what is already in mainspace, so... it's not going to be any worse, lol. 2602:304:CEEB:4D60:C0EE:C65F:5D42:C37F 02:41, 28 June 2016 (UTC)

@AuFCL: In a Greek text, the difference between "Latin" phi and "Greek" phi is a matter of typeface. Just like the difference between the lowercase Roman "a" that has a short curved ascending top versus the one that is a round letter without a "hat" of any kind. Always use the phi from the Greek character set of Unicode within a Greek text. The "Latin" phi is (I assume) intended only for mathematical use, such as in three dimensional angle measures for astronomy. --EncycloPetey (talk) 04:28, 28 June 2016 (UTC)

@EncycloPetey: I was somewhat dreading tracking down again (let me face it: made merely in passing) a chance observation; but in (for example) Page:Dictionary of Christian Biography and Literature (1911).djvu/25: "Africanus, Julius (Ἀφρικανός)" certainly does not resemble the scanned "Africanus, Julius (Ἀϕρικανός)", and if you cannot see the difference then any intent for wikisource to represent the "text as actually presented in the scanned image" is clearly a comprehensive farce—quite aside from my primary unrelated concern, which was the representation of breath diacritics not simply representable by direct Unicode. AuFCL (talk) 05:40, 28 June 2016 (UTC)

@AuFCL: I really don't know what you're talking about for that page. The Greek text you've directed me to has the correct breathing mark and the correct sequence of letters. If you are seeing a difference between the printed text and the proofread text, you can always use a different font in your browser. As I say, the difference you are perceiving between the two is purely a matter of the choice of typeface, just as we don't worry in English about the two typographical variants of lowercase "a", or the two typographical variants of lowercase "g". Letters have different apparent forms in different fonts that are not in any way meaningful for coding the text. --EncycloPetey (talk) 12:56, 28 June 2016 (UTC)

This is correct. Unicode has separate code points for a and ɑ, but the latter is for IPA and the former is the letter of the alphabet. Using ɑ in transcription to match the scan would be incorrect. For the same reason, many Greek letters have alternate versions (β/ϐ; γ/Ɣ; δ/𝛿; ε/ϵ; κτλ.) The one in the regular Greek alphabet range is correct in most cases. —Beleg Tâl (talk) 13:34, 28 June 2016 (UTC)

I have (finally) re-tracked down the page wherein the real issue lies: Page:Dictionary of Christian Biography and Literature (1911).djvu/43, and that is with the representation of (?)lower-case upsilon (Ὓ) within the (self-evidently wrong) fragment "Ἀμφιγοχίῳ Βασίλειος", not representable through simple Unicode, though presumably might be through the use of some combining-character which I hope somebody may be able to provide. AuFCL (talk) 06:23, 28 June 2016 (UTC)

I'm not seeing an upsilon in either the scan or the proofread text. Nor do I understand what you mean by "self-evidently wrong fragment". The scan and the proofread text match. If you believe there is some sort of error here, you will have to explain in more precise detail what the error is. --EncycloPetey (talk) 13:02, 28 June 2016 (UTC)

Ἀμφιγοχίῳ should be Ἀμφιλοχίῳ, but it looks like a γ in the scan as it is transcribed. It could be a mistake (which I have seen many in the scans we work on, especially in older texts) or maybe a typographical character which we're not aware of for λ. Also from what I can tell φ and ϕ are interchangable and I can't see a reason not to use φ if you want your formatting to remain faithful to the original scan. Google sees no difference and firefox doesn't either if you perform a find (ctrl F) using any of the two. Jpez (talk) 18:17, 28 June 2016 (UTC)

My guess is that the gamma in place of lambda is a mistake, but it is not clear whether the mistake occurred in the printed text, or is an error in the Greek text referred to. It does not look like a variant of lambda. As far as φ and ϕ, please refer to w:phi; the two are not interchangeable. The latter is intended solely for mathematical notation. Yes, internet searches will work either way, but that is to allow for errors. --EncycloPetey (talk) 00:03, 29 June 2016 (UTC)

@AuFCL: Only realized much later, when starting to transclude the "A"'s, that the smallcaps uses you were probably talking about were where I had used {{sc|A.D.}} instead of {{sc|a.d.}}. I didn't catch until now that they were not rendering correctly, and am fixing them as I go back through transcluding the first section (the A's) into mainspace. 2602:304:CEEB:4D60:2031:6A59:D3C1:38B1 05:05, 4 July 2016 (UTC)

(this is the same IP editor, I'm not 'static') Could someone please move Dictionary of Christian Biography and Literature to the End of the Sixth Century/Anastasius II, bp. of Rome to Dictionary of Christian Biography and Literature to the End of the Sixth Century/Anastasius II., bp. of Rome, in order to make it's title consistent with that of other articles from the same work? The 'standard' naming of the article pages (which, tbh, is itself not something I'm entirely happy with, as it is not 'identical' with the naming used in the work) has a '.' after the roman numerals in such names.

Unfortunately, the method used for actually 'naming' articles in the original work is not unambiguious... there are, for example, multiple articles 'titled' "Alexander" that are only discriminated between by the text following the title ('of Byzantium', 'of Alexandria'), and cases where one article refers to another only by the 'ambigious' part of the title, and you have to attempt to figure out which it is referring to by reading the articles. It's more checking of this kind of thing, and verifying that I've correctly identified the contributors, that this work needs as 'proofreading' more than actually checking the text itself, which is quite clean. 2602:304:CEEB:4D60:2031:6A59:D3C1:38B1 05:59, 4 July 2016 (UTC)

Pages not part of text

Hesperian thought "maybe we can get this fixed". I have brought this up previously (see related discussion), but no removal was made. To recap, DJVU pages 293 to 296 (labeled as "ERR") in this Index are not part of the original text. The Tintern Abbey image/caption is the frontispiece to an edition of A Walk Through Wales (1798) as per an IA version. Thanks, Londonjackbooks (talk) 01:58, 28 June 2016 (UTC)

Personally: not going there again. Opinion already expressed. AuFCL (talk) 02:28, 28 June 2016 (UTC)

Pretty much looking for a removal this time. Londonjackbooks (talk) 02:37, 28 June 2016 (UTC)

Unfortunately (having messed with them in the past) actually 'editing' a djvu is non-trivial. Probably the easiest answer is to poke the Internet Archive, have them fix their source file, and then re-upload their fixed version at Commons. 2602:304:CEEB:4D60:C0EE:C65F:5D42:C37F 03:01, 28 June 2016 (UTC)

IA no longer generates djvu files. Although we might get their copy fixed, it will not solve the problem in our djvu. --EncycloPetey (talk) 00:06, 29 June 2016 (UTC)

It's easy to get rid of the pages and reupload to commons. All the proofread pages after ERR will have to be moved back a couple of digits though. Poems by William Wordsworth (1815) Volume 1.djvu/297 to 293, Poems by William Wordsworth (1815) Volume 1.djvu/298 to 294 etc.. Jpez (talk) 18:47, 28 June 2016 (UTC)

call me simple, but why can’t you just skip the ERR pages in the index? there is no content on them, and the toc is good without them. Slowking4 ‽ RAN's revenge 13:28, 30 June 2016 (UTC)

Label them with empty, eg. 293to296=empty and renumber pages as necessary. It is just working space. — billinghurst sDrewth

That's exactly how it was before I interfered and pushed it back to problematic as a faulty file. If consensus is to leave it broken, since there's a trivial workaround, then just revert me. Hesperian 01:28, 1 July 2016 (UTC)

At present Help:Index pages says not to use this solution (in the green box) as it is an unacceptable practice. Beeswaxcandle (talk) 08:19, 1 July 2016 (UTC)

Fixed.— Mpaa (talk) 16:35, 2 July 2016 (UTC)

Thanks for that. Londonjackbooks (talk) 18:32, 2 July 2016 (UTC)

Template:hyphenated word start and italics

I just fixed some unwanted bolding issues at The Strange Voyage and Adventures of Domingo Gonsales, to the World in the Moon by removing italics around two calls to Template:hws. However, those individual pages no longer are technically correct in their individual display, since the italics are now missing there. I suppose I could fix it with some noincludes wrapping double-apostrophes, but I'm wondering whether some option like having a named parameter "italics" in the template would be a better fix (in which case I'd need someone to wave the magic wand). Or I might be looking to reinvent the wheel. Opinions? Wnt (talk) 11:21, 1 July 2016 (UTC)

Done. But what was the problem with the original edit anyway? Hws is a no-value template and its contents do not get transcluded (only hwe does). So if the product of hws looks good on the page namespace, that should suffice. Hrishikes (talk) 12:32, 1 July 2016 (UTC)

Oh, OK! I wasn't sure what all was being done with the stuff inside the template, so I was afraid to mess with it. Wnt (talk) 12:38, 1 July 2016 (UTC)

@Hrishikes: I've changed the documentation to hopefully make it clearer in case, um, some idiot doesn't read all the way down to the bottom... Wnt (talk) 12:46, 1 July 2016 (UTC)

Minor bug in the main namespace header template

Assuming that the footer is part of the Template:Header, then there must be something wrong with it. The footer is missing the green background. For me, this is so with any main namespace page. It's minor, and just curious if others have the same issue. — Ineuw talk 21:36, 1 July 2016 (UTC)

It's been fine for me. I'm not having that problem. --EncycloPetey (talk) 21:47, 1 July 2016 (UTC)

I am seeing no issue (Firefox, monobook) — billinghurst sDrewth 00:25, 2 July 2016 (UTC)

@Ineuw: In point of detail only parts of {{header}} are copied by MediaWiki:DisplayFooter.js to construct the footer—so I would be looking for some kind of javascript error. Please check your browser console for error logs. The green-ish colour is being drawn indirectly via CSS class="footertemplate" (which is created by the DisplayFooter script above) so presumably that is not happening correctly. AuFCL (talk) 00:27, 2 July 2016 (UTC)

Will do, thanks /missing signature/

@AuFCL: Before I create a bug report, please see this screen capture File:Missing footer color - console output.jpg

The first line of the console is <html class="client-js ve-not-available" dir="ltr lang="en"> but the the MediaWiki:DisplayFooter.js and the console code says background:trsnsparent.
CSS class="footertemplate" couldn't find. — Ineuw talk 04:37, 2 July 2016 (UTC)

Went a step further and checked the page in Google Chrome debug console. The footer has the background color, found the "footertemplate" reference but didn't see the CSS details yet. — Ineuw talk 04:48, 2 July 2016 (UTC)

@Ineuw: Just going back to Firefox, regrettably the screen capture cuts off the very line I was referring to (at the top.) For your reference the (working) section looks like:

<div class="printfooter">…</div>
<div class="footertemplate ws-noexport noprint" id="footertemplate" style="margin-top:1em; clear:both;">
  <div style="width:100%; padding-left:0px; padding-right:0px; background-color:transparent;">
    <div style="text-align:left; float:left; max-width:40%;">
      <span id="footerprevious">←<a href="/wiki/Popular_Science_Monthly/Volume_26" title="">Volume 26</a></span>
    </div>
    <div style="text-align:right; float:right; max-width:40%;">
      <span id="footernext">
        <a href="/wiki/Popular_Science_Monthly/Volume_27/May_1885/Can_Man_Be_Modified_by_Selection%3F" title="">Can Man Be Modified by Selection?</a>→
      </span>
    </div>
    <div style="text-align:center; margin-left:25%; margin-right:25%;">
      <a href="#top">Return to the top of the page.</a>
    </div>
  </div>
  <div style="clear:both;"></div>
</div>
<div id="catlinks" class="catlinks" data-mw="interface">…</div>

I've chopped a bit out (marked …) of the context <div>s. In any case it was the error log I thought might be a bit more informative (try control-shift-J on Firefox.) AuFCL (talk) 06:07, 2 July 2016 (UTC)

@AuFCL: My console output is identical and includes the first line in of the above snippet. However, I don't know how you got that snippet copied. I tried, but being more than a bit ignorant, (and more than a bit tired), all I managed to copy finally is the log contents of [control-shift-J], and pasted it in User:Ineuw/Sandbox4. In any case don't waste your time. My recent experience with bugs, reports, and Maniphest tells me that sooner or later it will show up elsewhere, just as my previous bug did. :-). — Ineuw talk 07:10, 2 July 2016 (UTC)

@Ineuw: Just an irrational feeling that this has something to do with either your version of Firefox (you have 48.0; I have 47.0 and the latter works O.K.) or some extension utility one of us has (or has not.) Something is generating (for example)

Expected 'none', URL, or filter function but found 'alpha('. Error in parsing value for 'filter'. Declaration dropped.Our_Recent_Debts_to_Vivisection

but not for me. Whatever is triggering that error is likely to be the tripping point. Apart from that I am all out of ideas. AuFCL (talk) 08:01, 2 July 2016 (UTC)

Thanks to all for the help. While the problem seems minor, it's nearly impossible to locate the problem because both Firefox and Chrome have the same problem, but I don't believe it's Wikisource. The steps taken to find the source is too long to list here, so it's best to give up, because time is becoming too valuable to waste on this. Thanks again. — Ineuw talk 18:17, 2 July 2016 (UTC)

Tech News: 2016-27

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

A daily email summary of notifications could be sent even when there were no notifications from the wiki. Now no email will be sent if there is no activity. [1]

Changes this week

The "⧼citoid-citefromidtool-title⧽" button in the visual editor's toolbar will move into the "Insert" menu except for Wikipedias, Wikibookses and Wikiversities. This is to make it less prominent on wikis that don't use it as much. [2]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 5 July. It will be on non-Wikipedia wikis and some Wikipedias from 6 July. It will be on all wikis from 7 July (calendar).

Meetings

You can take part in the next office hour for Wikidata on IRC on July 8 at 16:00 (UTC). See how to join.

Tech news prepared by tech ambassadors and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

19:45, 4 July 2016 (UTC)

Page move

Please move Dictionary of Christian Biography and Literature to the End of the Sixth Century/Barsumas,Syrian archimandrite to Dictionary of Christian Biography and Literature to the End of the Sixth Century/Barsumas, Syrian archimandrite... it's missing a space. Thanks. 2602:304:CEEB:4D60:8D04:B964:B11B:2FF4 03:51, 5 July 2016 (UTC)

Done, I hope rightly. Charles Matthews (talk) 04:03, 5 July 2016 (UTC)

@Charles Matthews: Indeed, thanks. 2602:304:CEEB:4D60:8D04:B964:B11B:2FF4 04:14, 5 July 2016 (UTC)

Open call for Project Grants

Greetings! The Project Grants program is accepting proposals from July 1st to August 2nd to fund new tools, research, offline outreach (including editathon series, workshops, etc), online organizing (including contests), and other experiments that enhance the work of Wikimedia volunteers. Whether you need a small or large amount of funds, Project Grants can support you and your team’s project development time in addition to project expenses such as materials, travel, and rental space.

Submit a grant request or draft your proposal in IdeaLab
Get help with your proposal in an upcoming Hangout session
Learn from examples of completed Individual Engagement Grants or Project and Event Grants

Also accepting candidates to join the Project Grants Committee through July 15.

With thanks, I JethroBT (WMF) 15:21, 5 July 2016 (UTC)

hyphenated word across multiple pages

While proofing Cassell's History of England, I came across a hyphenated word at the end of a page, and with a picture only page in between. Would hws/hwe work, or do I have to jiggy with it? - Tannertsf (talk) 21:37, 5 July 2016 (UTC)

Do you mean Pages 72–74? If so, that is fine to use hws/hwe on. It is pretty robust under transclusion (after all that it its intended purpose) and will have the effect (after transclusion in this example) of moving "consequence" entirely after the plate. AuFCL (talk) 21:55, 5 July 2016 (UTC)

Thank you very much! That is the intended use, so this will work well. - Tannertsf (talk) 22:13, 5 July 2016 (UTC)

Are all works here in the public domain?

There are a few old Mark Twain books here on wikisource that are available in both english and spanish which I would like to combine to create bilingual editions for sale via CreateSpace or Lulu.

CreateSpace, at least, always requires the name of the translator and year of translation, presumably to make sure that not just the original, but also the translation occurred long enough in the past to be in the public domain.

For these works, though, I have not been able to ascertain who the translator was or when they performed the translation. I have actually made a couple of changes to the translation myself (changed "MountBlanc" to "Mount Blanc" and a couple of things of that ilk).

So my question is: Is the fact that the translation is available in wikisource in and of itself evidence that the work is in the public domain or otherwise "fair game" for the use described above? —unsigned comment by 12.163.72.42 (talk) .

Works on Wikisource are free content: some of them are public domain, but others have various free licenses such as CC-SA or GFDL. The license should be listed at the bottom of the work's front page. All of them should be usable for the purpose you mention, at least in the USA. That being said, some works fly under the radar which are actually copyrighted; if you have concerns about a specific work, you can bring it up at WS:Copyright discussions. —Beleg Tâl (talk) 17:44, 8 July 2016 (UTC)

In addition. Any work at English Wikisource in our main namespace will have been published in English either as the original language (and free content) or as a published translation from the original language (original and translation both free content). If we have translated a work it will appear in our Translation namespace (free content in original, and all our contributions to translate being free). We cannot provide exacting comment on the licensing used at Spanish Wikisource, though it should be similar. — billinghurst sDrewth 06:03, 10 July 2016 (UTC)

Author pages, templates are all messed up. . . . ?

I may have missed any discussions, about the author namespace pages but on my screen the template is messed up, regardless of the author's page, not just PSM. Don't know what others are seeing, I will post a screen capture. — Ineuw talk 03:01, 9 July 2016 (UTC)

This is how authors' pages look to me File:Ellis Paxson Oberholzer.jpg. Is it the same for others as well?? — Ineuw talk 03:17, 9 July 2016 (UTC) ---> Author:Ellis Paxson Oberholzer

Author pages are displaying fine for me. @Ineuw: some links would be helpful rather than a general non-specific statement. Further, with your proliferation of these sorts of (false) issues, it would be really useful for you to report that you have checked these logged out (quickest way to rule in or out personal settings), or even in an alternate account without all your gadgets and common.js modifications, also to note that these can be skins issues, or browser issues, so checking such prior to reporting and what you have checked, means that we don't need to rush around like headless chickens chasing ghosts. — billinghurst sDrewth 03:20, 9 July 2016 (UTC)

@Ineuw: As an administrator it would be worthwhile you updating yourself on the components of author pages and to note that elements are now provided from Wikidata, not manually entered, and are not required in the header, filled or empty. — billinghurst sDrewth 03:26, 9 July 2016 (UTC)

You are right on both points, and am aware of my limited technical contribution, but if I spend time to learn (and do) site management, I will never complete the project I am working on. I also realize that this may not sit well with the community, but I also noticed that there are admins here who prefer to focus on, and challenged by problem solving more than by proofreading, and I thought to take advantage of that (respectfully ).

As for the Authors' page display problem, it is definitely related to my account login. When not logged in, the page looks fine. When logged in I get this. This applies to all author pages, not just PSM contributors.

This is not the only display issue I have when logging in, but the other issue is too minor to bother anyone with it.

Tested both my accounts, (Ineuw and IneuwPublic) by removing all cookies and logins from the browsers, as well as removing the common.js and .css contents, but the login results were the same with both accounts. Personally, I suspect that it may be the global login, but I can't disconnect from that. Ineuw has 98 and IneuwPublic has 19 global accounts.

I won't create a bug report until I come across issues which interfere with my proofreading. — Ineuw talk 13:53, 9 July 2016 (UTC)

As it is a display issue, it sounds like an issue related to .css. I would suggest that you comment your local .css so they are inactive, and let any cache issues resolve themselves, and see if a fix occurs. Also check if you have formatting at m:special:mypage/global.css. — billinghurst sDrewth 05:50, 10 July 2016 (UTC)

@Billinghurst: Unfortunately, it is not a display issue but another bug in the wiki software again working with Firefox. ~~It is not a problem in Google Chrome.~~ The global .css and .js are empty - so far never used it. Saved the contents and then deleted the all my .js and .css files. This includes any empty file existed under any skin I previously used. Now I will check the error console and will post another bug with all the required info (learned from my last bug report). — Ineuw talk 22:50, 10 July 2016 (UTC)

Additional comment: removed {{authority control}} to see what happens, but the display still contains wikidata?. — Ineuw talk 23:03, 10 July 2016 (UTC)

Wikidata entry is controlled from the other end from the left sidebar, and controlled at our end though plain sister template, and is no different between header and author templates. Authority control template is a local template, that similarly just receives data from another site. Note that I am not having issues with Firefox, (any of four independent installs on four different devices) and at this point no one else is speaking about Firefox issues, so it is not solely mediawiki and firefox issues. You may have a local cache issue, or a local installation issue. — billinghurst sDrewth 03:39, 11 July 2016 (UTC)

The problems were resolved. The "Site: General utilities needed by the templates and portals of this wiki project." was not checked. I didn't even know about its existence and thus its importance which makes me ask, why does this even appears as a gadget if it's so important??? — Ineuw talk 04:26, 11 July 2016 (UTC)

Working with an archive

Hi,

I have been in contact with the City Archive of Umeå. They are about to start improving Wikipedia with information and sources from their collections.

The idea is that they will add the information to Wikipedia, as part of their workflow, when they already have digged out some relevant information that has been requested by e.g. a researcher, journalist or citizen.

During our last meeting they were curious to know more about how we look at archival material on Wikisource. There was a few questions raised that I would love some inputs on:

Do we want a scan of every document that is used as a source on Wikipedia? If so, is it enough with a scan of the specific page in question - and not the entire body of text (something they can hardly commit to)?
When it is hand written documents, would you demand a transcription of the document from the archieve (as OCR might not work at all). This is a tedious work and would mean that much fewer documents would be added - if any.
Has there been a cooperation with an archieve providing source material before? If so, is there any information about it somewhere that you could point me to?

I have posted about this also on sv.wikisource, but I would love as much inputs as possible.

Kind regards, John Andersson (WMSE) (talk) 11:23, 9 July 2016 (UTC)

Wikisource typically would like "complete" works, i.e a 'letter' ,' journal issues' etc. ShakespeareFan00 (talk) 12:42, 9 July 2016 (UTC)

@John Andersson (WMSE): We can only talk about our process at English Wikisource, as each Wikisource will have variations on exactly what they include. Our criteria are expressed at WS:WWI, though I cannot see a link to svWS's thoughts.

For how I would express an opinion at enWS, you are discussing historical documents, not published works. We would always be looking for having a transcription for the item in its entirety rather than a snippet, though we do accept that we may not show the entire work transcribed, though we present a part available in the concept of the entire work, eg. Historical_document/part_A.

1. Yes we do desire every document referenced is available at Wikisource, however, desire does not equal reality. Scans become authoritative, and can have usable transcripts, be they local or in a book. You can have a look at the Wikisource:WikiProject NARA and talk to Dominic (talk • contribs) about what he was able to achieve when a Wikipedian in residence at NARA.

2.We would ask for the scan to be at Commons, and no requirement for a transcript, though they are helpful. We would hope that svWS would have their native language transcript organised through proofreading Index:/Page:; and eventually a translation here at enWS in our Index:/Page: being transcluded into our Translation: namespace, all based on the same File: (frWS, deWS, … can all do their own translations and presentations in their wikis) Hoping that you see the benefit of the structure. This schema also gets crowdsourced transcriptions and translations of historical documents, which is what Dominic was looking to garnish from the image uploads of NARA.

3. Yes, answered above. Has it been hugely successful, not yet, the thing once dry up is done, it is always available. Admins tidy up and add components that users work upon through time. — billinghurst sDrewth 05:44, 10 July 2016 (UTC)

Thank you for your thoughts and insights, billinghurst! I will keep them in mind in future communication with the archieve. Best, John Andersson (WMSE) (talk) 08:18, 12 July 2016 (UTC)

How to handle notes at the end of book

In this index, Index:The Mythology of All Races Vol 1 (Greek and Roman).djvu, the notes are at the end of the book. What is the way I should format/set up these? - Tannertsf (talk) 18:01, 10 July 2016 (UTC)

You could always do this with a relative {{anchor}} link in the Index section. --EncycloPetey (talk) 22:52, 10 July 2016 (UTC)

@Tannertsf: Are they references that are used through the work? Specifically numbered? Or are they more general? If you need to refer to them individually, you can do anchors as suggested. If you need to pull them more specially, you can do what I have painfully set up in {{IrishBio ref}}. It is more general, then you can just have a recurring note for each chapter that just points to the Index section, and lets them onwardly refer. In (long) indexes in general, there is always value in anchors for A, B, C, ... Z and adding something like {{compactTOCalpha}} or some of the other TOC templates. Numbers of options available, it all depends on how it works through the work, and how the end notes are configured. — billinghurst sDrewth 00:57, 11 July 2016 (UTC)

They are numbered and used throughout the whole work and then put in a 'Notes' section at the end of the book. For the anchor point though, how do I actually use it? This is something new to me in my 5 years of WS :) - Tannertsf (talk) 12:09, 11 July 2016 (UTC)

There are options for you on how you wish to present the works, and you can use reasoned argument. 1) Reproduce solely as is, and just refer people to the endnotes from the notes section, this would leave the reference points somewhat unfunctioning. Benefits, it is easy, and won't break. 2) You can put section markers around each section and transclude the respective notes section to the end of each chapter. This would be somewhat similar to how we have added DNB errata to the DNB articles. Benefits, puts the notes with the chapter, provides flow, not too complex, just wrapping larger sections, some that spa pages. Negatives, still not clean use of refs, and the source links on a page are hosed. 3) Set up sections per reference as done at Page:A Compendium of Irish Biography.djvu/614, then call them in situ using customised Template:Authority reference so they become actual references that will transclude as proper references, that can be end notes using a {{smallrefs}}. Benefits, it looks neat and all works in a wiki. Negatives, it differs somewhat from the book layout, and has increased complexity (thogh not overly burdensom) and requires formatting notes section section first. — billinghurst sDrewth 12:54, 11 July 2016 (UTC)

Use anchors by: (1) Place an {{anchor}} template at the start of an item in the End Notes to create an "anchor" for a link. The anchor only requires a name or number as a parameter, to make the link target unique. (2) Then use normal wikilinks to point to the note. So if you have a note on "Mythology/Index" that has {{anchor|5}}, then a wikilink might look like <sup>[[Mythology/Index#5|5]]</sup>. But there is more than one way to do this. The key part is creating an anchor point to serve as the target of the link. --EncycloPetey (talk) 12:34, 11 July 2016 (UTC)

Thanks for the advice! I'll tinker with these ways and see what comes out of it. - Tannertsf (talk) 13:37, 11 July 2016 (UTC)

Also see Help:Footnotes and endnotes. Beeswaxcandle (talk) 07:15, 12 July 2016 (UTC)

Tech News: 2016-28

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

A new image scaler fixed a number of bugs for showing SVG files. Some new problems turned up. [3][4][5]
Notifications are grouped by types. They are now counted by number of notifications and not by unread groups. That change may increase the number of notifications displayed. The earlier way of counting was often incorrect. Unread notifications will also be displayed first. [6][7][8]
Special:Notifications now has a maximum width for the notifications list on desktop computers. This allows long titles and descriptions to be cut properly. Notifications are now also better parsed. [9][10][11]

Problems

On 5 July Wikimedia Commons had problems and could not be edited for 20 minutes. For a short while after that the recent changes log and some gadgets were not working properly. It affected administrative actions on other projects too. [12]
Users who have multiple unread notifications can mark them as read by visiting Special:Notifications page on their wiki.

Changes this week

The new version of MediaWiki will be on test wikis and MediaWiki.org from 12 July. It will be on non-Wikipedia wikis and some Wikipedias from 13 July. It will be on all wikis from 14 July (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 12 July at 19:00 (UTC). See how to join.

Tech news prepared by tech ambassadors and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

15:14, 11 July 2016 (UTC)

List formatting for accessibility and sensible HTML

I've had a rather frustrating conversation with User:EncycloPetey today, about this reversion. The list formatting he's reverted to does not produce the "one list of five items" that he thought it does; it produces five separate lists, each of which contain two items (a main item and a subitem that is also an association list), and which are interspersed with two other items (one <pre>formatted paragraph and one double definition list (:: – that thing about "use colons to indent your talk page replies" is a case of w:en:Lies to children. There is no simple indentation code in either wikitext or in HTML). In other words, it's a complete mess, and the HTML is both non-compliant with the relevant standards and bloated to boot.

My request: Is there anyone here who understands HTML lists and would like to help work out a decent solution here? I'd like the list formatting to not be broken in HTML terms. I'd be happiest if we could do this while keeping the pretty appearance and without filling the page with a bunch of <div>s.

(If you don't know anything about HTML, but you're interested, then that's great, too, but you might want to read w:en:WP:LISTGAP or other sources to get an idea of the most common issues first.) WhatamIdoing (talk) 02:44, 13 July 2016 (UTC)

Please refer to the conversation on my user page: User talk:EncycloPetey#Do you understand what you did? As I pointed out there, the text in question that is generating all this concern is part of a draft guideline for proofreaders, and the fact that colons are used to indent paragraphs for readability. That guideline concerns norms for proofreading text from scans. Any persons who are unable to cope with the simple bullets and indenting in the guideline will certainly not be able to make use of the edit window to correct OCR gibberish against image file scans. This is a waste of time to solve a problem that does not actually exist. Our time would be better spent producing content instead of building windmills to tilt at. --EncycloPetey (talk) 02:51, 13 July 2016 (UTC)

It's not a question of people being "unable to cope with". People who are affected (beyond the slight performance costs of needlessly bloated HTML file sizes) will be quite familiar with the need to "cope with" broken HTML. But there is no good reason to require "coping" when we could instead have "fixing". You intend that to be a single list of five bullet points; there's no good reason for it to be five separate lists.

Also, the same problems and the same solutions are relevant to reading Wikisource texts, not just help pages. If this is how we're formatting documents in the mainspace, then we're screwing up and failing our readers. WhatamIdoing (talk) 06:02, 13 July 2016 (UTC)

Interesting points. Fortunately in the main namespace we generally utilise simpler inline formatting that replicates the work, usually straight paragraph text. That said there are examples where we fiddle-faddle with wikitext and code to present a look outside of the pureness of html. This is predominantly due to the inadequacies of wikitext/html compared to freedom of paper formatting. Similarly our use of tables can have issue, especially where we have continuing tables over multiple pages.

From my viewpoint, while I understand the point of view of WhatamIdoing, it isn't my priority for fixing wikitext/html conundrum for formatting on the page that she demonstrated, there are bigger things that I would like to see fixed

sidenotes
column formatting in tables (bloat central!)
ability to properly and progressively indent works with sequential numbering that flows over transcluded pages (thought that may be somewhat related)
dotted tables with their really ugly code bloat, and transclusion limit blowers

and so on. These clearly visually and bloatily affect our users, and we have tried for extended periods to get assistance. The long term (ab)use of colon (dt/dd) formatting through the wikis now haunts us through the wiki, though general here it is in Wikisource: ns. and some in Help: ns.

To the specific example, the protagonists compare a level of ugliness over a level visual cleanliness; code bloat v. code cleanliness They say have contra-opinions on whether that someone who reads the page with a lesser browser should be catered for when that lesser browser will not be able to undertake the tasks of the page. The talk then skews to the same impact in the main ns, though that is a leap of faith, though probably with elements of truth, rather than a demonstrated fact. In short, it was quickly turned into a pissing competition of opposition, rather than trying to agree on what they did, and resolve what they did not.

I know that we would like some solutions to our problems, and I know that we try to keep it simple. The end game here is generally people want to transclude, and want the simplest formatting that enables a work to flow like the original. The politics of html interests few of us, most of us just want an easy solution, and we will go with what is easy and sustainable. — billinghurst sDrewth 09:06, 13 July 2016 (UTC)

@WhatamIdoing: I made the instructions into a definition list. Is that acceptable? --Erasmo Barresi (talk) 09:26, 13 July 2016 (UTC)

With a tweak to make a paragraph break visible. However, the loss of bullet points means that the items lose their visual impact. I am not in favor of this change. --EncycloPetey (talk) 11:11, 13 July 2016 (UTC)

I like this change. It looks good, is well structured, and uses semantically correct markup? Well done! (Also, thanks for showing me the existence of ; (text) : (text) to do definition lists; I didn't know you could do that!) —Beleg Tâl (talk) 11:41, 13 July 2016 (UTC)

as much as i like aesthetic arguments, i agree with @Billinghurst: - we have some other formatting problems that are progress stoppers - preventing texts getting done; we might want to fix those, before spending energy on those formatting issues that are not. Slowking4 ‽ RAN's revenge 14:46, 13 July 2016 (UTC)

EncycloPetey, if you want the "visual impact" of a bullet point, then we could add a dingbat (as a small inline image) at the start of each line. WhatamIdoing (talk) 17:33, 13 July 2016 (UTC)

That would shift the text line to the right, reducing the hanging indent. We would then need something to increase the indent of the subordinate text. This issue then becomes more complicated than it is worth. --EncycloPetey (talk) 17:43, 13 July 2016 (UTC)

Billinghurst, I think that the problem with columns inside tables would be addressed by phab:T95739, about which my realistic recommendation is not to hold your breath.

Depending upon what exactly is happening with the lists over transcluded pages, then it might be possible to fix that by specifying the correct list number at the top of each transcluded section, i.e., # <li value="100">The 100th item in a multi-page list</li> (all following numbered list items use normal formatting). WhatamIdoing (talk) 17:33, 13 July 2016 (UTC)

@WhatamIdoing: Thanks for the numbering cheat, that is valuable and not one that I have seen utilised before, and far better than my using <ol><li> then with or without a start parameter in the header component. Re complex formatting, I was more referring to the cheats that I used for the look at Copyright Act, 1956 (United Kingdom)/Part 6, which is more problematic, as it describes the above and more relates to a live scenario. Re columns, I was more thinking of older discussions like phab:T2986. — billinghurst sDrewth 01:52, 14 July 2016 (UTC)

Self-closing HTML tags being now being tagged for future obsolescence maintenance

Some amongst us may have noticed the recent introduction and gradual population of Category:Pages using invalid self-closed HTML tags. After a bit of searching I have identified a phabricator ticket (subsequently turns out it has already been referred to in local talk page discussions.) However my initial concern is that {{anchor}} utilises one of the deprecated structures and this response explicitly states there is no alternate solution. Has anybody got any good ideas how to properly address this situation? AuFCL (talk) 21:41, 14 July 2016 (UTC)

Sounds like a misunderstanding. Self-closing HTML tags are NOT being tagged for obsolescence, INVALID self-closing HTML tags are being flagged for MAINTENANCE. It looks like people are putting TEMPLATES inside HTML tags. Beleg Tâl did it here: diff. I brought this up on BT's talk page. BT's reply was incomprehensible to me. Outlier59 (talk) 02:09, 15 July 2016 (UTC)

Read the ticket in detail. It is fairly confused but not all tags are deprecated. If I read the code changes to Sanitizer.php correctly (that is a big ask!) these tags are explicitly excluded (i.e. will continue to work as before: <br />, <wbr />, <hr />, <meta /> and <link />. The list is slightly mad as it includes tags which users cannot enter anyway!

@Outlier59: I restored the struck-out portion of the heading as my current understanding is that this is but Phase 1—in the longer term flagged tags such as <span/> (yes, it is used!) may stop working altogether.

The change you indicated is not relevant apart from the fact it is probably the first edit to that page since the changed rules came into play. The real problem line is right at the top of Wikisource:Administrators and has been there for a very long time: <span class="interwiki-oldws" id="ar1" title="Wikisource:Administrators" style="display:none;"/> AuFCL (talk) 06:04, 15 July 2016 (UTC)

Equal sign template is meant to be used in that way, i.e., to prevent the equal sign to be interpreted as code. That is not a matter of self-closing tag. Except possibly the nowiki tag (when self-closing), most other self closing tags are being deprecated, that is why they are being marked as obsolete by putting them in that category. Mentioned in the phabricator ticket: Use of self-closing tags like <div/> and <span/> to mean <div></div> and <span></span> is being deprecated. Existing uses of these tags in templates and pages should be fixed as appropriate. Once phab:T134423 is resolved, these tags will parse as <div> and <span> instead, as per HTML5 semantics. The Anchor template uses the self-closing span tag, so it will be affected. Another big problem will be the self-closing break tag, used in poems. Hrishikes (talk) 02:28, 15 July 2016 (UTC)

At least with the self-closing break tag ( <br /> ), I presume that <br> will be available, and that a global search-and-replace will correct that issue. However, we'll have a real problem across several projects if <ref /> does not function. --EncycloPetey (talk) 02:40, 15 July 2016 (UTC)

One of the reasons that we have and utilise the templates is that they can be readily updated, and at least we have an opportunity to template those pages that have done it raw. FWIW {{anchor}} may even do well to be converted into a module by some clever person, otherwise it should not be overly complicated to make it have an opening and closing span. — billinghurst sDrewth 05:28, 15 July 2016 (UTC)

According to the ticket an opening and closing span is going to fail as well, and when queried upon this precise issue:

“	Got it (although it does say above that <span class="foo"></span> would be stripped). Are there any void tags that can be used instead of <span id="foo"></span> to create anchors? Nope.	”
—ssastry, in response to Wikitiki89, ticket T134423 fragment

—which is right back where I came in asking for suggestions. AuFCL (talk) 06:04, 15 July 2016 (UTC)

Returning to EncycloPetey's concern regarding <ref/> another fragment of the the same ticket states that registered extension tags (i.e. things like pages, ref, section etc.) will have no concerns. AuFCL (talk) 06:11, 15 July 2016 (UTC)

There is the statement ... No, Tidy won't strip tags with attributes. <span id="foo"></span> vs. <span></span>. The former is left behind and latter will be stripped. so seems that there is some hope. Otherwise we use a span and wrap it in some non-displaying character. — billinghurst sDrewth 12:01, 15 July 2016 (UTC)

Updated {{anchor}} as it seems to be the issue predominately, and its issues crowd out other issues. We will see what it looks like in several hours after the systems purges itself. — billinghurst sDrewth 12:16, 15 July 2016 (UTC)

I have updated the description in phab:T134423 and hopefully it is clearer and eliminates any confusion around what is invalid and what is not. Note that <span id='...'></span> can be used for creating anchors if you wish. SSastry (WMF) (talk) 16:54, 15 July 2016 (UTC)

WMF announcement: Stripping Question Marks From Wiki Searches

“

Stripping Question Marks From Wiki Searches

Do you ask questions on Wikipedia? Would you like better results?

Summary: Because the large majority of question marks are used to ask questions by users unfamiliar with bash-style wildcards, the default behavior for CirrusSearch will now be to ignore question marks (replacing them with a space). Escaping them with a backslash (\?) will preserve their wildcard meaning. Regular expressions in insource: will not be affected and should not be escaped. This option can be modified on a per-wiki basis if needed (see $wgCirrusSearchStripQuestionMarks).

When people ask how old is tom cruise? on Wikipedia they almost certainly don't expect the question mark in cruise? to match an additional letter. They aren't looking for the words cruised, cruiser, or cruises—but that's what they get, and it keeps them from finding the information they are really after.

Search on Wikipedia (and other Wikimedia projects) includes a lot of features that most users don't know about. Most require special keywords, and some even require specialized knowledge, such as familiarity with regular expressions. It's pretty difficult to invoke these special features by accident.

But search also supports two particular bash-style wildcards without any special syntax: * will match any number of characters, and ? will match exactly one. Asterisks do come up from time to time, but people use question marks all the time—because they like to ask questions!

A recent review of query-string features called out quotes and question marks as the two largest-impact predictors of unsuccessful queries on Wikipedia. In a follow-up survey of queries with question marks in six of the top ten Wikipedias (by search volume), most question marks are being used to ask questions (the other four of the top 10 were not reviewed). In all ten of the top ten, stripping final question marks dramatically decreased the number of ?-final queries that got either no results, or very few results (i.e., less than 3). The improvement was around 10-45% for ?-final queries, depending on the wiki. The overall impact is much more modest (less than 0.5%) because queries with question marks are not terribly common.

As a result of this analysis, we've implemented a change to search which will by default replace question marks with spaces (to preserve the word boundaries they intend in queries like how?why?). This setting can be changed on a per-wiki basis, and other options include (i) only stripping question marks at a clear word boundary (such as before a space), (ii) only stripping question marks at the end of the query, and (iii) leaving the question marks alone.

For the rarer users who do use question marks as a one-letter wildcard, when question mark stripping is enabled, question marks can be escaped with a backslash (e.g., wiki\?edia) to preserve their original wildcard meaning. Power searchers who use insource: won't need to do anything special; queries withinsource: will not be modified.

Here's a screenshot of the former question mark behavior, where it is treated as a wildcard. Note that "living?" only matches the name "Livings", leading to two very unsatisfactory results.

Here's a screenshot of the new question mark behavior, where it is ignored. Now the question and part of the answer can be seen in the snippet for the very first result, and all of the top three results seem relevant.

”

—Trey Jones , Discovery-L mailing list