Wikisource:Scriptorium/Archives/2013-10

Please do not post any new comments on this page. This is a discussion archive first created in October 2013, although the comments contained were likely posted before and after this date. See current discussion or the archives index.

Announcements

Wikisource's 10th Anniversary

AdamBMorgan introduced an enormous Wikisource page for book anniversaries and for that he deserves our grateful appreciation. But there is one anniversary he didn't include.

Wikisource itself was founded on November 23, 2003. And in honor of our 10th anniversary, we will be holding a contest: Whoever contributes the best book by that date will win free pancakes. ResScholar (talk) 19:31, 2 September 2013 (UTC)

Correction: AdamBMorgan did include this anniversary, under "Launch of Old Wikisource". But he didn't mention the pancakes. ResScholar (talk) 20:40, 2 September 2013 (UTC)

Say it in Shakespeare. I have been here a very long time on a daily basis and even longer on Wikipedia. No wonder I have gotten older and only remembered it on my last birthday when my wife reminded me. Time flies when one is busy. Well, we're all getting old here together--we're all dying here together. "Adam" of the Old Testament & 1st one here should have started a Wikisource Graveyard long ago for all of the people that have come and gone. Working here no person needs "pancakes" aka flapjacks--we all get older and fatter just sitting and typing. Barbecued chicken would be good though. Signed, X(his mark), Shakespeare, Lazarus, Sam Hill, his brother Bunker Hill, & —Maury (talk) 01:54, 3 September 2013 (UTC)

Htonl: nomination for checkuser

Following the recent resignation of one of English Wikisource's checkusers, there has been a nomination by Beeswaxcandle (talk • contribs) for Htonl (talk • contribs) to undertake the role, with the community now at the minimum required level of two checkusers. The Wikimedia's policy and implementation is particular about the approach and the duties, and they can be read at checkuser, Wikisource has some specific components that we add on top and they are expressed at Wikisource:Restricted access policy.

As the role is one of those with access to information not available to all users, and as such is one of elevated trust, it requires a candidate to be older than 18 years of age, and to identify themselves to the Wikimedia Foundation; and for a successful candidacy it also requires a higher acceptance rate by the community. The community invites you to have an opinion over the nomination, either in support or in opposition, with contributions at Wikisource:Administrators.

In closing, I would like to thank Pathoschild (talk • contribs) for having undertaken that role for such an extended period. It is one role that is important though somewhat thankless when just bashing spambots. — billinghurst sDrewth 09:52, 7 September 2013 (UTC)

Proposals

To change a configuration setting concerning images

As some of you are already quite aware of, I've been toying with finding new ways to enhance the rather limited, collaborative-friendly approach currently in place for image File: rendering -- which "works" just fine for Wikipedia & Commons folks as well as for forums like this one on Wikisource. But at the same time (and more often than not), the current approach has been a headache of sorts to say the least for many of us when it came to the task of reproducing formally published (i.e. static) works as faithfully as possible. The "differences" in one day meeting our hopes that images could easily "mimic" the presentation(s) found in the original nppks, etc. we are working on and the vastly larger, more complex needs of Wikipedia et al. to incorporate images into their ever-changing, collaborative-driven, mainspace articles & talk page discussions without Users having to "learn" a lot of coding in the process has always put us somewhere way down on the list of coding priorities; specifically when it came to image rendering.

It seemed like for the longest time, the thumb, framed & frameless automated approach, as annoying as applying them has been at times for many of us, was something we've all come to accept as the cards we were going to be dealt while moving forward; to forever do battle those 3 limited options thanks to their popularity & familiarity by folks primarily contributing anywhere & everywhere but here.

Well a couple of weeks ago, when the core wiki-markup started to move closer to meeting the HTML5 specification, that "status quo" between their needs & our hopes became too much to continue to just meekly accept for me (See the efforts to circumvent the wikicoode with FreedImg if you haven't already). In a nut-shell, the head-honchos in charge of further developing the wikicode, quietly "activated" a part of the HTML5 specification dealing with automated image resizing but left the part to make it function as designed all the way to your monitor's rendering in the off state.

This means every image file, even the smallest of emoticons all the way up to the largest of world maps, have continued to display themselves at the default (or manually forced) image sizes as they've always have before As well as incorporate this newly added HTML5 spec. portion(s) -- which, in short, is the calling for the generation of 3 additional "zoomed copies" of the image file (or thumbnail of an image file) at 1.0, 1.5 & 2.0 times that "displayed" resolution -- but without any of the actual coding to allow mouseover/browser resizing/change in font settings/etc. thought to utilize these "best-fit" substitutes to be allowed to work as advertised!

If that isn't enough to get your back up, future plans have the nerve to complain about the current "drain" on resources re: Image: file rendering and are going about finding a way to implement changes that will alter the manner (as some of you've probably guessed) in which image [re]sizing is to be calculated from now on to resolve the current issues.

That preface-to-the-proposal now having be laid out before you folks, let me be clear about what I'm not proposing we do about any of the above or any other Image: file related matters first; I'm not here to ask for opinions on such moves to drop previous standards like ImageMagick, to discuss or to quantify the merits of such a changes or even to ascertain what this means to our adventures-in-image-wrangling in the coming future specifically. I don't want to usurp or supersede anything having to do with wikicode's familiar handling of Image: files past, present or future. I don't even want the ability to use images hosted anywhere but within the Wikifoundation's circle of trusted files.

All I'm asking for is the ability for the wikicode to recognize the <img /> tag if a User wants to use it in their contributions to Wikisource (external images remain excluded as they are now). Please support enabling the tag. TIA. -- George Orwell III (talk) 02:54, 23 July 2013 (UTC)

At present $wgAllowImageTag allows any images (including external files), irrespective of $wgAllowExternalImages (and friends), so I have raised bugzilla:54306 as a prerequisite for this change. If I understand correctly, the main problem is that we can't currently add 'style' or 'class' attributes directly onto an IMG tag, and each image doesn't even have an ID attribute, making it difficult to style. We should raise/find bugs for those problems. I'm concerned that all options require code changes, and it is unlikely WMF is going to put resources into them. I am happy to support anyway. In addition, as George Orwell III has pointed out, there is also img srcset, which MediaWiki only has partial support for (it supports high-dpi, but doesnt support width and height). John Vandenberg ^(chat) 03:47, 19 September 2013 (UTC)

p.s. Another approach is to use mw:Extension:CSS (or similar) so that each work can have its own styling, but that still requires that each image is wrapped in a div to which an ID/CLASS can be added. John Vandenberg ^(chat) 04:01, 19 September 2013 (UTC)

To clarify; the primary issue at hand is not the inability to add a class element to an image file under the wiki-markup ([[File:...]]) approach - that is easily acomplished by using the correct [but poorly] documented parameter for that; [[File:...|class=foo]] - but the 2 or 3 class definitions being applied to the image file by it's container elements composed of DIV wrappers regardless of the type (thumb/frame/frameless/blank) in play in addition to any defaults set for the IMG element itself.

For our goal of as-faithful-as-possible transcriptions, these predefined settings - called via class definitions found in the DIVs wrapping the IMG tag - frequently hinders our ability in reaching that goal. Of course, nullifying these predefined settings in our local class definitions is possible but not without creating a huge Christmas tree of new definitions that, in the end, still cannot be customized well enough to meet each and every contributor's needs for each and every situation concerning images. Being able to use <img/> tags instead of the [[File:...]] approach simply strips all the predefined wrapping container settings -allowing Users to apply their own containers for one-off image instances as well as template-tize repetitive image rendering.

The other stuff about srcset "bloat", lack of caption customization and the rest are all "happy" benefits secondary to that primary need. --> And if the same stand-alone, wrapper-less image rendering can be accomplished via LUA or something, I'd gladly let the coding folks off the hook and withdraw the entire matter.

I'm also tempted to propose adding mw:Extension:CSS regardless of any of this even though it would not help the primary issue at hand here very much. What do you think? -- George Orwell III (talk) 23:39, 20 September 2013 (UTC)

Thank you for these clarifications. I'll need to throw a few more questions at you in order to properly understand the current limitations wrt the classes; I will do that elsewhere as I don't want to complicate this vote section.

The problem remains that we cant add 'style' to individual images, which means only site-wide classes can be used. Page-wide classes would also solve that problem, so I would support a request to add mw:Extension:CSS to Wikisource. It has not been deployed on a WMF project yet, so it probably hasn't undergone a security audit by the WMF devs. However there is only one bug listed (bugzilla:35820), and it is about the security being too tight rather than too lax - a good thing. John Vandenberg ^(chat) 00:33, 21 September 2013 (UTC)

I'm leary of making that mw:Extension:CSS proposal without resolving this proposal first, if possible. It seems like the same external-site or other security issue(s) would still prevent any "sane" adoption of the extension just like enabling the IMG tag would currently seem to.

Still, I find it rather odd that all these $wg load-settings and/or Extensions aren't already subject to obeying auch an obvious security consideration such as denying/allowing imports/calls from/to external sites of any type or manner by design. -- George Orwell III (talk) 22:40, 21 September 2013 (UTC)

"However, allowing external images in any manner will allow anyone with editing rights to snoop on your visitors' IP addresses and so forth, if they wanted to, by inserting links to images on sites they control. Hence enabling this setting can represent a privacy risk to your visitors." —Maury (talk) 08:25, 21 September 2013 (UTC)

Thanks for pointing that out Maury.

If allowing external images does indeed become a mandatory prerequisite to enabling the IMG tag as proposed in this section, then a third setting, $wgEnableImageWhitelist, would also be needed & enabled to overcome the security issue you cited above. This "whitelist" ability would, of course, never point to any site outside the current family of WikiFoundation domains we already use for image/source file storage (i.e. Commons) - defeating the mentioned security issue in the process. -- George Orwell III (talk) 22:24, 21 September 2013 (UTC)

---

https://www.mediawiki.org/wiki/Manual:$wgAllowExternalImages (leave set to 'false')

https://www.mediawiki.org/wiki/Manual:$wgAllowImageTag (change setting to 'true')

Tracked in PhabricatorTask T56144

Tracked in PhabricatorTask T56306

 Support — George Orwell III (talk) 02:54, 23 July 2013 (UTC)

 Support — but only if external images are excluded (t.i. if <img/> tag can only display images stored into Common or into ns File:), img tag being merely a different, much more comfortable syntax for [[File:...]] pointing to the same files. --Alex brollo (talk) 07:45, 23 July 2013 (UTC)

 Support — if this is best way to achieve this, AdamBMorgan (talk) 16:34, 24 July 2013 (UTC)

 Support — Ineuw talk 17:56, 24 July 2013 (UTC)

 Support — At present $wgAllowImageTag allows any images (including external files), irrespective of $wgAllowExternalImages (and friends), so I have raised bugzilla:54306 as a prerequisite for this change. John Vandenberg ^(chat) 03:47, 19 September 2013 (UTC)

 Support — Clockery Fairfeld (talk) 09:10, 21 September 2013 (UTC)

Proposal to simplify help

The following discussion is closed:

Passed as supported by the community. This proposal has been open for over a month with no opposition, following a previous proposal for the same thing that was archived without much activity. "Scriptorium/Help" chosen as the primary page, with "Requests for assistance" to be merged into it. - AdamBMorgan (talk) 23:00, 20 September 2013 (UTC)

I propose to merge the Wikisource:Requests for assistance and Wikisource:Scriptorium/Help pages, and retaining whichever title is most relevant. I find that two pages are redundant, adds to maintenance and "Requests for assistance" has four posts in the past two months. To me, this indicates that users prefer to post in "Help". — Ineuw talk 20:29, 4 August 2013 (UTC)

• Support JeepdaySock (AKA, Jeepday) 10:21, 5 August 2013 (UTC)
• Support I think this came up before but the discussion was archived before anything was done. Which reminds me that the archives of the redundant version will need to be merged too. I agree that "Requests for assistance" should be merged into "Help", which is the most visible of the two anyway. - AdamBMorgan (talk) 13:24, 5 August 2013 (UTC)
• Support —Clockery Fairfeld (talk) 13:45, 5 August 2013 (UTC)
• Support--Mpaa (talk) 18:18, 5 August 2013 (UTC)
• Support - Moondyne (talk) 06:27, 6 August 2013 (UTC)

Display of characters in their natural order

I am proposing that the WikiEditor's "Special characters" list of characters be displayed in the natural order of their origin, regardless of the language setting. - To clarify; the selector's display direction is dependent on the language set by the user in Preferences. In our case this defaults to English which is written from left to right (LTR). Thus, non-Latin languages like Hebrew and Arabic, which are written from right to left (RTL), are also displayed LTR. This is the equivalent of a display direction for Latin characters as J I H G F E D C B A. Proofreading documents which contain these characters, in addition to unfamiliarity, makes the task nearly impossible. The Bugzilla bug report link is below for anyone interested to comment. I am posting this proposal at Wikipedia as well. — Ineuw talk 12:38, 21 September 2013 (UTC)

Tracked in PhabricatorTask T56310

 

I think your wording might be making things more complicated than they really are here. I believe what you're asking for is for each character-set to have their own RTL/LTR setting added to WikiEditor rather than defaulting to any particular User:s current language setting and, thus, the left-to-right or right-to-left letter direction for that language as well, right? -- George Orwell III (talk) 22:58, 21 September 2013 (UTC)

I am proposing that the user's language settings should not affect the character display and they should be hard coded in their natural order. Latin characters should be displayed left to right, Hebrew and Arabic should be displayed right to left, no matter what the user's language preferences are.— Ineuw talk 03:41, 22 September 2013 (UTC)

@GO3. I was told by Amir E. Aharoni of the language support group that Bugzilla is the place to bring it to the attention of Wikimedia developers. — Ineuw talk 06:25, 22 September 2013 (UTC)

Gotcha but my point was that you probably didn't need community consensus/awareness to be reached/achieved by this proposal rather than just a notice of the issue at hand, etc., in this case. This really isn't a request to change settings, etc. that could affect our community adversely but more so drawing attention to something that shouldn't be "broken" like that to begin with regardless of the community you happen to be participating in. IOW, I'd be surprised if all the domains opting to use WikiEditor & it's character-sets aren't behaving just as 'incorrectly' as our's is. -- George Orwell III (talk) 07:31, 22 September 2013 (UTC)

Yes, I follow and missed responding to that portion of your comment. Made it a proposal it because I wasn't sure, wanted the community to be aware of the issue, and because I noticed that the Bugzilla people do scan and comment on our posts.— Ineuw talk 11:04, 22 September 2013 (UTC)

 Support — We were on the same page after all. In fact, I don't even think you need this proposal to justify opening the bugzilla to resolve this - its something that should have been set as the default behaviour for character sets in WhateverEditor by design (imho). -- George Orwell III (talk) 05:41, 22 September 2013 (UTC)

 Support —Clockery Fairfeld (talk) 06:14, 22 September 2013 (UTC)

Other discussions

Gibberish text in PDF of California 9th Circuit Court decision

Hi. It seems that a California 9th Circuit Court case decision PDF is obfuscated. It looks like we don't have this document on Wikisource. It's PD; both the PD-CAGov and PD-EdictGov templates, as found at commons, apply. The PDF I get at http://www.gpo.gov/fdsys/granule/USCOURTS-ca9-10-16696/USCOURTS-ca9-10-16696-3/content-detail.html looks like the one from http://www.scribd.com/doc/80680002/10-16696-398-Decision scribd visually. Both appear to be the same document, out of the PACER system. Both appear to be obfuscated: If I try to copy the text out of either one, I get gibberish (like this: "”À“‹ ŸÚ fiŒ—...“Ù ÷ÆÚÙ ·2 ̧· ±oo·1⁄2·ø¥ 1⁄2ø°ø1⁄2· ̈ß ø Ÿ±TMaÆ2±Æ ±o ›ø¥·o±Æ2·ø ’fl”fl‘fl ‹Ú ÿf… ̈"). Searches don't work, and these are key sources of, e.g. [1]. I did find a copy of the text at http://www.danpinello.com/Perry.htm Someone else reported the same issue with this decision, saying "For some reason it’s not possible to copy and paste quotes."

So, are obfuscated PDFs like this common? Has anyone asked or figured out what's going on or why? The "PDF Producer" is "iText 2.1.7 by 1T3XT". What do we do about 'em? I'd guess that they'd OCR nearly perfectly. Upload 'em to commons? …? --Elvey (talk) 15:27, 29 July 2013 (UTC)

Yes - PDFs dealing with non-SCOTUS court cases frequently have issues with their text-layers so its not something you're doing that is causing it. I don't know what the cause of stuff like that is however. The only thing that can be done is to re-OCR the PDF - either by using a more traditional program like Adobe Pro locally or using an online service like IA & their version of AABBY to do it. If you give me a couple of days to work it into my list things to do, I might be able to straighten it out (or the alternative, create a DjVu from it that can be used to transcribe the opinion here on WS much like United States v. Windsor's slip-opinion was). -- George Orwell III (talk) 20:38, 29 July 2013 (UTC)

Thanks. I often see court case PDFs with missing or otherwise less-than-useful text-layers, but gibberish is new to me; you see it frequently? I don't have local access to state-of-the-art OCR software. Go ahead if you haven't already. --Elvey (talk) 02:16, 8 September 2013 (UTC)

Template:Parameter

I see that Template:Parameter is being used on template documentation pages to render parameter names inside of {{{triple braces}}}. This is a Very Bad Idea, IMO, since the triple-braces notation is meaningful only inside template code, not when a {{template call |is=placed on a page}}. Since template documentation is intended for regular template users, not template coders, this triple-braces rendering will probably only serve to confuse people. Also, the template uses a blue color, which makes the result look somewhat like a link. Any objections to changing these things? (In particular, I suggest using bold code with no surrounding delimiters and, uh, maybe green for the color. FYI, it'll probably be at least a few days before I do anything, even if no one objects.) - dcljr (talk) 10:08, 31 July 2013 (UTC)

I'd display an equals sign after the parameter name, like this: name = .--Erasmo Barresi (talk) 13:35, 31 July 2013 (UTC)

Probably some of my dabbling in earlier days of tidying up documentation. Always happy for anyone to disambiguate my efforts. — billinghurst sDrewth 14:41, 31 July 2013 (UTC)

Done--Erasmo Barresi (talk) 16:25, 12 September 2013 (UTC) I removed the equals sign because it has been added manually so far.--Erasmo Barresi (talk) 16:31, 12 September 2013 (UTC)

Creating a brochure for English Wikisource

Working as the Wikimedian Ambassador for Jisc, I notice that there's a lot of enthusiasm for open content and for engaging with Wikimedia, but not always enough awareness of Wikisource. This is not for any lack of good help materials: they just need to be digested and disseminated, which I'm happy to do. I'm going to create a short brochure for Wikisource using Scribus, to convince managers of archival projects in the UK to engage with it. The idea is that project managers will read a short summary and set their team on actually contributing. That's an admittedly narrow focus and audience, but the idea is to use open-source techniques and the Bookshelf wiki so that others can repurpose the material.

I welcome input from the community on: 1) what are English Wikisource's greatest achievements? I've looked at Category:Featured_texts, but what to highlight? What has Wikisource done well that similar projects haven't done? The Dictionary of National Biography springs to mind, and is a nicely UK-specific example.

2) What are en-wikisource's proudest collaborations? What should I highlight to show mutual benefit between Wikisource and an established cultural institution? The British Library books uploaded by Andrew Gray spring to mind, and of course the NARA collaboration (where there's a UK angle because of Winston Churchill's correspondence). Thanks in advance for any suggestions, MartinPoulter Jisc (talk) 15:35, 20 August 2013 (UTC)

This sounds cool. I'd like to help but I'm not sure how much assistance I can be. We had a brief discussion about the project highlights in June but it didn't get very far. We have lots of eclectic things but not many classics (we have Shakespeare and Dickens but they aren't our best quality works). American poet Florence Earle Coates was mentioned and we have a wide collection of her work now. Roman poet Catullus gets some attention online but our translation system is still in flux at the moment (although hopefully not for much longer). How important is the UK angle? How high-brow do you want this?

The DNB is probably one of our biggest and most successful projects; another would be Popular Science Monthly, which is still going well but is not UK related. As you've mentioned, the NARA collaboration and British Library contributions worked well. There are similar projects about the Gerald Ford Presidential Library (not a lot of widespread interest) and the State Library of Queensland (just started), but neither are as big (yet) nor are they British. - AdamBMorgan (talk) 23:55, 20 August 2013 (UTC)

I would think that we have angled away from the reproduction of works of Shakespeare, and of Darwin, as these famous/specialist subject matters and generally already done in other places by those passionate aficionados. For older works, I think that our strength is about works supported by the original text, and that any one can do any work at any time. This enables us to be a reference centre for quotes, or for encyclopaedia, for whatever. We are a crowdsourcing approach to look at works where the volunteer effort that can be a casual, determined or a project. This allows topics on the serious, the popular, the obscure, the quirky, the particular. We have the ability to extract images, and put them in situ within the work, but this also makes the images available across the internet to be used by any site (when uploaded to Commons).

We have about one million pages (content namespaces) made up of

• between 200 & 300k pp main namespace
• 21k author pages
• 5.7k scanned works in one of the three stages of preparation (validated, proofread, not proofread)
  • which is approaching 900k pp in those stages.
• 2k portal pages where we try to create some order

Noting that exacting statistics are notoriously difficult to determine due to transcluding pages. — billinghurst sDrewth 02:11, 21 August 2013 (UTC)

Thanks both - really useful replies. I will definitely emphasise crowdsourcing and openness, and I'll include something about Popular Science Monthly, because I think the use of WS to share historical papers and support research will play well with the intended audience. Having big headline figures is good for my dissemination work, though I'm not sure whether to include them in the brochure since (I hope!) they'll be soon out of date. MartinPoulter Jisc (talk) 09:34, 21 August 2013 (UTC)

Wonderful project! Creating a brochure to educate and encourage more contributors from the UK and beyond is an important step forward. I think the impact and scope of this project is best understood when looking at the contrast from other digital alternatives. Consider how Wikisource differs from similar projects like Project Gutenberg and the Internet Archive. WS is more comprehensive in its scope than PG including U.S. Supreme Court Cases and Constitutions for many world governments. WS is more assessable than the IA for people with disabilities. Our navigation aids including portals and categories provide "some order" as billinghurst so rightly expressed. To get an idea of the depth of the materials on offer, look at the index of titles on the Lord Byron author page and the A Dictionary of Music and Musicians by Grove. Not complete, but this opens the door to let in more contributors. Let me know if I can help you in anyway to further your work toward outreach. - DutchTreat (talk) 11:48, 21 August 2013 (UTC)

Thanks very much for this, DutchTreat - just the sort of advantages and examples I was looking for. I'm boiling all this down to a brochure with few words (the audience being managers, remember ;) ) but I'll announce here as soon as I have a draft. I suppose a follow-up question is which are the most graphically attractive frontispieces from old books that I can include for visual interest. MartinPoulter Jisc (talk) 16:57, 29 August 2013 (UTC)

For attractive frontpiecs, I recommend Burma and Russia and Greece both considered as Proofread of the Month, but not undertaken yet. For a tradition Latin text la:Fasciculus:NewtonsPrincipia.jpg. Also a nice example at Page:Japanese_plays_and_playfellows_(1901).djvu/8 - DutchTreat (talk) 11:32, 8 September 2013 (UTC)

Excellent suggestions: thanks very much. I'm working on a number of things in parallel, but will keep this thread updated with progress on this brochure. MartinPoulter (talk) 12:50, 12 September 2013 (UTC)

Looking forward to seeing your draft. In case you are still looking for elegant frontispieces, I found Le elegie romane (1905) by Annunzio, Gabriele, (1863-1938) [2]. This text is published with a bold, beautiful graphical style written in both Latin and Italian. I recommend reviewing this excellent work to see if you can find a place for it in your brochure. - DutchTreat (talk) 11:28, 14 September 2013 (UTC)

Move to the Translation namespace

The ProofreadPage backlinks (the "Source" tab at the top of the page and the floating page numbers) are not available in the Translation namespace yet. Nonetheless, can the move to the Translation namespace begin? The page numbers could be added simply by editing the local PageNumbers.js script, while a change to the ProofreadPage extension is needed to add the "Source" tab.--Erasmo Barresi (talk) 21:35, 28 August 2013 (UTC)

•  Support: We can't really wait for Proofread Page to be updated to accommodate this; that might not happen for months or years. We have the namespace ready to use and everything else appears to work. Proofread Page can catch up with us later. - AdamBMorgan (talk) 21:32, 31 August 2013 (UTC)

Done: set as the MotM task for September.--Erasmo Barresi (talk) 08:40, 2 September 2013 (UTC)

New wiki search in trial resolves issue

For years when people have been undertaking searches at the Wikisources, main namespace pages with text from transcluded pages have failed to show in search results. Well the design and trialling of the new search engine seems to have resolved this problem, eg. "raikes" search. Something for which to look forward. Others may want to put components over at test2wiki: to trial, some of the additions are increased flexibility with searches including intitle: and incategory: searches, and combining these in searches with regular text. More detail in wikitech-l archive. — billinghurst sDrewth 10:26, 29 August 2013 (UTC)

An additional issue with version 1.22wmf14

The vertical layout below the textarea was extended so that the original .djvu page and the character selection is not visible together EVEN IN FULL SCREEN MODE (F11) making proofreading of non-Latin text impossible.— Ineuw talk 03:46, 30 August 2013 (UTC)

Gadget "authority control" failing, with bleeding edge browsers

I have found that the gadget for adding authority control fails in Firefox 23 and the current Chrome browsers. With Inductiveload we have tracked it down to https: and http security mismatch, where I operate in secure mode in WMF whereas VIAF only feeds data in insecure mode. With that mismatch the browser disallows the operation in the call for data when trying to run the gadget. On a page by page basis, one can override the browser behaviour to allow the communication to occur. [rider: I may not have all the security speak exactly according to Hoyle, I am just trying to comunicate the issue]. Anyway, I intend to email OCLC through their VIAF email address and let them know about the issue, though I have no expectation of any quick resolution. — billinghurst sDrewth 22:50, 30 August 2013 (UTC)

you could also mention this to Ocassi & Max Klein see also [3]. Slowking4 (talk) 01:47, 31 August 2013 (UTC)

Apologize for my ignorance, but feel that I must ask. Does this issue also relates to the difficulty in loading the .djvu scan page and the custom toolbar? — Ineuw talk 00:37, 2 September 2013 (UTC)

I don't think so. That all comes from within Wikimedia, which has all be upgraded to the secure protocol (and all exists within the same set of computers anyway). This problem is with external sites using the standard, insecure protocol; which is possibly being dismissed by the Wikimedia servers as a potential security hazard. - AdamBMorgan (talk) 01:34, 2 September 2013 (UTC)

@ABM it is browser level rejection, not servers and comes with recent upgrades in Firefox and Chrome versions with regard to mixed content pages. Nothing to do with the djvu. — billinghurst sDrewth 11:57, 4 September 2013 (UTC)

I'll try and find out if there will ever be a https version of VIAF. Maximilianklein (talk) 02:03, 4 September 2013 (UTC)

Assuming that billinghurst's response was to my question, again forgive my ignorance - Can you please clarify the following?

1. What is @ABM?
2. Does it mean that loading the .djvu is a browser issue? FYI, the .djvu load problem was resolved somehow in the past few days. I don't know how, it's just loading.
3. Not loading the custom toolbar is also a browser issue? — Ineuw talk 12:31, 4 September 2013 (UTC)

ABM = my initials. - AdamBMorgan (talk) 17:05, 4 September 2013 (UTC)

Thanks :-) . . . which makes my other questions irrelevant. In addition, I found a secondary toolbar button solution for those who use Firefox and need to insert characters or text during proofreading. I am posting the info in Wikisource:Scriptorium#Anyone_using_custom_edit_tool_buttons?, the relevant section. — Ineuw talk 18:31, 4 September 2013 (UTC)

Hansard_(Commons)/566/40

I've recently added this, but would appreciate some assistance in getting it to a proof-read or validated state.

I've got no objections to the portions being split to further Subpages. ShakespeareFan00 (talk) 22:28, 31 August 2013 (UTC)

Copyright status of Hayakawa's Language in Action

I recently came across the book on archive.org, and I was wondering: Is it really PD?--Frglz (talk) 15:03, 2 September 2013 (UTC)

For starters, IA has it wrong when they infer the 1941 registration was never renewed - Hayakawa renewed it in 1968. see also [4]

Pretty sure that means it won't be PD until 2036 (1941 + 95) but, as always, a double-check by someone else could verify that 100%. -- George Orwell III (talk) 15:45, 2 September 2013 (UTC)

Why do we have two version?

Index:Wind in the Willows.djvu is inocmplete, but Wikisource already has a completely transcribed 1913 edtion? ShakespeareFan00 (talk) 16:35, 4 September 2013 (UTC)

See Wikisource:Versions. The incomplete project is the first American edition, and thus highly notable; the complete project uses a 1913 edition of less importance, though still notable for the Paul Bransom illustrations. Hesperian 00:50, 5 September 2013 (UTC)

Grey text

Large documents can be brought in more easily if there are no constraining margins, left or right. However, the result is "grey" text, making the work difficult to read. This wasn't such a problem when our monitors were smaller , but now we have a very long line.

The reader would benefit if the margins, left and right, were constrained, uniformly. It is only a practical issue: can we do it?Fconaway (talk) 20:20, 4 September 2013 (UTC)

This point of view has been put forward before, and is countered with the argument that readers should not be forced to waste large areas of their screen real-estate on empty margins if they do not wish to. Personally, when I'm reading online I ramp up my font size until the lines are a good length and I can sit back and relax and read at a distance. Hesperian 00:38, 5 September 2013 (UTC)

That point of view also assumes that all readers will have a large monitor. Most schools and universities have older monitors, because cost is a major constraint. As a result, most students do not have large monitors available through their schools. Further, if the margins are constrained, then elderly readers who need to use a larger font size will suffer from having lines that are too short. --EncycloPetey (talk) 01:28, 5 September 2013 (UTC)

Fconaway, have you seen the "display options" link that appears in the sidebar when reading works? This might be what you are looking for. Hesperian 03:33, 5 September 2013 (UTC)

There are also issues with constraining left and right margins (discussions in archives of this page), which we have seen when the works are taking to smaller screens like on mobile devices. So we went to the layout toggle option, and also knowing that people can resize their browser to the width that they want. Also do look at the Epub export formats which can be most useful for reading works. — billinghurst sDrewth 10:47, 5 September 2013 (UTC)

A mediawiki error message

I got the following error message when I tried to clear the Index page cache. Does this mean anything important? — Ineuw talk 00:45, 8 September 2013 (UTC)

A database error has occurred. Did you forget to run maintenance/update.php after upgrading?
See: https://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script
Query: SELECT 1 FROM `image` WHERE img_name = 'Popular_Science_Monthly_Volume_82.djvu' LIMIT 1 FOR UPDATE
Function: LocalFile::lock
Error: 1205 Lock wait timeout exceeded; try restarting transaction (10.64.32.29)

I couldn't replicate it when purging or editing, so I would hazard a guess that it was a transitory issue. If it reoccurs, then we can pursue it. — billinghurst sDrewth 12:46, 8 September 2013 (UTC)

Thanks for looking into it.— Ineuw talk 17:09, 8 September 2013 (UTC)

If the problem happens again, it would be nice if somebody who has this issue could send the software bug to the 'Bugzilla' bug tracker by following the instructions How to report a bug. This is to make developers of the software aware of the issue. If you have done so, please paste the number of the bug report (or the link) here, so others can also inform themselves about the bug's status. Thanks in advance! --AKlapper (WMF) (talk) 15:37, 9 September 2013 (UTC)

Handling pages that require specialist skills for validation

We currently have a range of templates for pages that cannot be proofread without specialist skills; e.g. {{chinese missing}}, {{greek missing}}, {{missing score}}, etc. These pages, having been flagged for specialist attention, are eventually proofed by a specialist, and the templates removed... leaving us with pages that cannot be validated without specialist skills, and no way of tracking that.

For example, most of us would not be able to validate this short page, yet we currently don't have a way of flagging that page for specialist attention.

We could create a bunch of new templates — e.g. {{chinese requiring validation}} — but this would mean marring many perfectly good proofread pages with template messages, which doesn't seem to me like a particularly good idea.

Any thoughts? Hesperian 12:03, 8 September 2013 (UTC)

Manually categorise? Stick the template in the header/footer? Have the template remain but if the page is proofread, then the behaviour of the template? — billinghurst sDrewth 12:42, 8 September 2013 (UTC)

I'm also concerned that some of these pages are being validated for the sake of completion by editors who don't have the required specialist skills. I'm thinking particularly of some complex scores that have been validated in under a minute each by editors who don't read music.

wrt to Hesperian's question, I'm inclined to go with a template in the footer. Beeswaxcandle (talk) 21:24, 8 September 2013 (UTC)

In cases of foreign language characters, I think it should be possible to have such text always included in a special wrapping template. The template could then include a separate parameter that gets changed when the text in question is validated. That is, we might have a template {{Chinese}} with a parameter that separately tracks the validation, say proof=1, 2, 3, 4. This would need to be edited manually in the page text, and separately from the tracking normaly used, and I think that would be a God Thing^TM in this situtation. The status of the parameter would then place the text into the appropriate proofreading category. --EncycloPetey (talk) 02:04, 10 September 2013 (UTC)

In reference to statements about validation, I often see entire works proofread with one or perhaps a few more validated and are also transcluded and then just left for others to validate. I have also seen many pages in a row just marked as proofread when they have not been spell-checked, or formated their pages, or even worked on. It appears those will just let someone else happen along while they go elsewhere for yet another proofread and transcluded text. That allows a person to complete several books while leaving several non-validated works behind them. I think what we need is a team working together just as one would do with a partner. People do not get their works validated enough or validate another's works unless there is a partner of sorts where at least two will work together. I have been recently) working with three partners. They help me and I validate their works in return. Beeswaxcandle is a good example of this working together. So are three others I work with. We exchange with each other. Shakespearfan00 is another I work with. Kathleen is good at validating for anyone and everyone and I try to do the same. —Maury (talk) 02:38, 10 September 2013 (UTC)

75%

Hi,

I would like to suggest to repaint the 75% image in blue:

This image is used for the development stages:

The order of the colors is not logical. It is too close from 25%. It's confusing at a glance. Ftiercel (talk) 20:35, 11 September 2013 (UTC)

This is also being discussed on Commons (here and here) and on en Wikibooks. --Avenue (talk) 22:47, 11 September 2013 (UTC)

This Wikisource no longer uses the tracking system that used those icons. Any usage here is legacy / mess. I think it is probably best to leave the discussion at Commons; anyone here who wants to participate can do so over there. Hesperian 01:31, 12 September 2013 (UTC)

/* /* New Zealand vs New Zeland */ */

Index:Notes_on_New_Zeland_(1892).pdfSomehow this file I uploaded went astray at some place and I do not understand the details of correcting it. I ask a for help so that I can get the easier work done. Beeswaxcandle, AdamBMorgan, George Orwell III, Hesperian, - whomever as long as it is someone that is willing to help correct it so I can do the basic work. I have uploaded .pdf files in the past without this bad situation as suggested in the en.WS statement of "Be Bold" I apologize for my mistake and my annoyance to others. It certainly was never intended and is an embarrassment to my own self. How and where did the spelling change to New Zeland when it should have been New Zealand? —Maury (talk) 05:37, 13 September 2013 (UTC)

It got uploaded to Commons with the wrong spelling. Just request a name change there by using the rename template. {{rename|Notes on New Zealand (1892).pdf|1|Accidentally spelt wrong}} Beeswaxcandle (talk) 07:31, 13 September 2013 (UTC)

I will move it for you. - as well for the future, ask the Commons admins for moving rights. That will give you an additional tab on the page to move/rename.— Ineuw talk 07:53, 13 September 2013 (UTC)

Done Index:Notes on New Zealand (1892).pdf — Ineuw talk 07:57, 13 September 2013 (UTC)

Thank you both. Beeswaxcandle, why could you not do as Ineuw so easily and swiftly did? On my talk page I learned I am to request permisssion to do what Ineuw was able to do. It gives me an "extra tab." Beez, do you not have that permission? Anyway, Ineuw, to answer your question, the original file has every page with double space text. I renamed the file because it was named https://archive.org/details/notesonnewzealan00swaniala —Maury (talk) 08:40, 13 September 2013 (UTC)

Sure I could have moved it, but I don't like leaving redirects that will never be used, so renaming is the better option (IMO), which I don't have Commons rights to do. Beeswaxcandle (talk) 08:59, 13 September 2013 (UTC)

Just stick a {{delete}} on it, and put a reason like Wikisource only file, no redirect required. It basically takes an admin to do one or the other, and the tools generate a redirect for any linked file, so no reason to leave it for an admin there. — billinghurst sDrewth 10:33, 13 September 2013 (UTC)

It was I who moved it and I usually clean up after a few days.— Ineuw talk 10:48, 13 September 2013 (UTC)

Puck of Pook's Hill

If anyone's interested in this, I'm currently restoring all the images from the original edition. They're the JPEGs at commons:Category:Puck of Pook's Hill. Currently have 8 of 20; should be done by the end of September. Adam Cuerden (talk) 06:03, 15 September 2013 (UTC)

Illegible text and proofreading status.

I just noticed there are a decent number of proofread/validated pages in Category:Pages with illegible text. Is that cool? I was under the impression that kind of thing would necessitate a problematic status until/if it ever is given an accurate reading. But it looks like this is common practice. Opinions? Prosody (talk) 00:02, 18 September 2013 (UTC)

They then should be taken back to proofread as the maximum (if only one or two purple pages), they should not be at validated. My reason for one or two is that they can be missing some minor components, and one person has been through the whole work completely. — billinghurst sDrewth 11:09, 18 September 2013 (UTC)

I think I've validated a couple of pages in the past where there's just never going to be any hope of figuring out what the handwriting says for one or two words, but the rest is accurate. Is that an okay approach do you think? — Sam Wilson ( Talk • Contribs ) … 01:09, 21 September 2013 (UTC)

{{Talkback}} template not fully functional

The second parameter, which is to indicate the post, doesn't function. Also, it's unclear whether one should add "User:" or "User talk:" to the name. Whenever it's possible, could someone in the know please adjust the template. Thank you.— Ineuw talk 05:46, 19 September 2013 (UTC)

Hmm… it seems to work well enough here. How are you using it? —Clockery Fairfeld (talk) 06:21, 19 September 2013 (UTC)

{{Talkback|Ineuw|Native Flowers Of New Zealand (1888)}}

You are correct. I assumed that the post title was supposed to be visible in the template. Please accept my apology.— Ineuw talk 06:38, 19 September 2013 (UTC)

No problem . —Clockery Fairfeld (talk) 06:53, 19 September 2013 (UTC)

It's time to reclaim the community logo

Hello community,
this is to inform you about the (re)start of a discussion in which you might be interested. In short, myself and a few other Wikimedia editors decided to oppose the registration of the community logo as a trademark of the Wikimedia Foundation.

The history of the logo, the intents behind our action and our hopes for the future are described in detail on this page; to keep the discussion in one place, please leave your comments the talk page. (And if you speak a language other than English, perhaps you can translate the page and bring it to the attention of your local Wikimedia community?) I’m looking forward to hearing from you! odder (talk) 10:00, 21 September 2013 (UTC) P.s.: You can check whether the WMF protects the logo of your project by seeing if it's listed as "registered trademark" on wmf:Wikimedia trademarks.

What is wrong with the logo? Do you wish to replace it or keep it? Who presently holds the registration? I think it looks good. —Maury (talk) 10:30, 21 September 2013 (UTC)

Template:RunningHeader-centered

I just created this template (shortcut {{rh-c}}). It takes the table format already used for a 4-part header and uses it in a 3-part header as well. The advantage of this is that the "centered" text will now truly be centered on the page, and its position will not depend on the width of the right & left text. Also, it allows the width of the center text area to be adjusted (manually on a case-by case basis) as a percentage of the available space. --Eliyak T·C 19:57, 23 September 2013 (UTC)

Any special reason to create a new template? Any cons in modifying {{RunningHeader}} to improve the centering?--Mpaa (talk) 20:34, 23 September 2013 (UTC)

This solution was rejected for {{RunningHeader}} because it fixes the field width and thus causes unnecessary wrapping. Current implementation leaves it to the browser engine to attempt optimal layout. Hesperian 01:11, 24 September 2013 (UTC)

Plus in our current RunningHeader, the left-center field has its text aligned (floated) left & the right-center field has its text aligned (floated) right, where Eliyak's version centers the text in these two fields - so replacing the current version could alter the layouts of any number of our current 4-column instances in the process. This was the original sin in making both the 3 column and 4 column variants a single template rather than to-each-its-own stand-alone template. -- George Orwell III (talk) 01:27, 24 September 2013 (UTC)

I wasn't planning a wholesale replacement, just to provide this option which I feel is "better," and I thought others might agree. Changing the existing template would have hard-to-foresee effects on the various pages which use it, a new template provides a new option to those who prefer it. If it is not wanted, it can be deleted - I have not yet applied it anywhere. --Eliyak T·C 02:41, 24 September 2013 (UTC)

Right. "We" were pretty much answering Mpaa's question without addressing your proposal first; which, in hindsight, was pretty effin' rude of "us" - sorry about that.

I have no objection to adding your template to the family of templates dealing with "headers - though we should probably discuss the pros & cons a bit further before really signing off on it.

In addition, the original {{RunningHeader}} template is a bit outside the HTML standards as it is. If you compare my Sandbox approach to the existing template ( Template:RunningHeader/testcases ), one can see how the injection of a paragraph tag (by accident?) throws the center text's vertical baseline off compared to the left & right span's baseline. In short, compare the "L" in "LEFT" with the "L" in "Lorem" in both the top sandbox version & the lower current version and hopefully one can see the unintended? offset between the two. I'd like folks to accept that 3-column change before moving on to "tweaking" the 4-column variant in addition to the possibilies of accepting Eliyak's version as it's own stand-alone template. -- George Orwell III (talk) 03:06, 24 September 2013 (UTC)

From looking at the code, it seems the only changes are:

1. to convert the center <div> into a <span> with display:block (matching the code for the right and left parts).
2. to use html comments to remove unnecessary spaces in the code.

Of those, I believe #2 is what is fixing the vertical spacing issue. (MediaWiki inserts a paragraph tag, which has a margin, otherwise). I think most browsers will display <div>s and <span>s with display:block the same, although there is, technically, a difference. I would support the sandbox version with either <span>s or <div>s, but I think <div>s are more technically correct here. I don't think there should really be an issue to incorporate this immediately into the main template. In fact, it seems the spacing issue GO3 identifies is currently affecting virtually every use of the template. --Eliyak T·C 15:05, 24 September 2013 (UTC)

Thanks for the clarifications. I have no problem with the new template, just wanted to have some background why a new one was needed.--Mpaa (talk) 15:24, 24 September 2013 (UTC)

Thanks for the analysis, Eliyak - I made the change using the appropriate div tags (a natural block element like you mentioned) instead of the spans. The next "issue" with the 3 column centering is when only Left & Center or Center & Right are invoked. See the current results below

One can easily see the CENTRE field isn't so centered when either one of the other two fields are "blank". Is there anyone who has an idea on how to rectify that? Some reverse hidden string math or something? -- George Orwell III (talk) 19:56, 24 September 2013 (UTC)

With respect the CENTER field is centered; only it is centered within the remaining space after the floated (LEFT and/or RIGHT fields) are mapped onto the line, and the space they occupy is effectively removed from further consideration. The only way I can think of addressing this is to use a table… umm like {{rh-c}} does, perhaps?

As a partial solution, adding style "position:absolute" to LEFT forces the browser to consider the field to be zero-length, but this does nothing useful for RIGHT… Any further thoughts? 121.216.113.5 08:36, 25 September 2013 (UTC)

┌──────────────────────────┘
I have a possible solution at {{RunningHeader/sandbox}}. It uses the new scripting modules (through intermediary templates) to calculate the relative size of the center div and the side divs, and sizes the divs accordingly. As you can see at Template:RunningHeader/testcases, it fails when the center div contains much more text than the side divs, which can happen occasionally, so it still needs to be tweaked a little. --Eliyak T·C 15:55, 25 September 2013 (UTC)

UPDATE: I tweaked it a bit, and it seems to behave very nicely now. However, it could still use some testing out. --Eliyak T·C 17:24, 25 September 2013 (UTC)

Right on - that was what I was thinking of (probably should have mentioned Lua script in my 'reverse hidden string math' statement in the first place). Seems to do the trick in the few instances I tested under the latest sandbox just fine as well. Move to make that the standard RH template & continue discussion/tweaking as needed. -- George Orwell III (talk) 21:53, 25 September 2013 (UTC)

Request for consultation on community logo

Request for consultation on this community logo

First, I’d like to apologize for the English. If you can, please help to translate this for other members of your community.

The legal team at the Wikimedia Foundation would greatly appreciate your input on the best way to manage the "community logo" (pictured here) to best balance protection of the projects with community support. Accordingly, they have created a “request for consultation” on Meta where they set out briefly some of the issues to be considered and the options that they perceive. Your input would be invaluable in helping guide them in how best to serve our mission.

Thank you! --Mdennis (talk) (via the Global message delivery system). 02:19, 24 September 2013 (UTC) (wrong page? You can fix it.)

Template syntax/layout problem

Hi,

There is a problem on the header of Universal Declaration of Human Rights that I can't solve myself (I guess it comes from Template:Header which I'm not allowed to edit). --Rinaku (t · c) 17:55, 24 September 2013 (UTC)

Fixed with a null edit to that page. {{header}} was changed recently and this seems to have had a bad effect on a number of pages. I am not sure if the change is still propagating and will fix itself or if further measures are necessary. --Eliyak T·C 18:13, 24 September 2013 (UTC)

RunningHeader instances with more than 25 characters

Will someone please tell me what this [RunningHeader instances with more than 25 characters in the center string] new thing is for? My running header shows Editorial Paragraphs and the page number. —Maury (talk) 13:15, 25 September 2013 (UTC)

It was to find use cases with a large center part. It was successful, and is gone now. I actually fell asleep or it would have been gone much sooner. Sorry for the annoyance. --Eliyak T·C 14:31, 25 September 2013 (UTC)

Thank you for the explanation, Eliyak, and there was no annoyance. It was curiosity. Respectfully, —Maury (talk) 18:53, 25 September 2013 (UTC)