Wikisource

Wikisource:Scriptorium/Archives/2017-03

< Wikisource:Scriptorium‎ | Archives
Warning Please do not post any new comments on this page.
This is a discussion archive first created in , although the comments contained were likely posted before and after this date.
See current discussion or the archives index.

Announcements

Proposals

Bot approval requests

Repairs (and moves)

Other discussions

Index:An Answer to the Declaration of the American Congress.djvu

This is using an experimental template {{sn-paragraph}} which has got sufficiently complex that it's no longer understandable. I've reverted my attempts to fix it back to the previous contributors attempt. I am of the view that someone ought to just nuke the incomplete effort and start again with the ONE approach that's seemingly been agreed upon for sidenotes, (even if it seems to be broken in page namespace display). ShakespeareFan00 (talk) 23:07, 2 March 2017 (UTC)

The process for that would still be WS:PD not here. — billinghurst sDrewth 01:50, 3 March 2017 (UTC)
Starting a new disscusion there then ShakespeareFan00 (talk) 02:28, 3 March 2017 (UTC)

Archaic spelling in titles...

In giving something a second look I thought it might be worth noting some things in regard to older titles. - Page:Public General Statutes 1896.djvu/34

However {{SIC}} to me would seem to be more for printer errors, which isn't what's happening here. There did not seem to be an {{archaic}} to mark titles/spellings which whilst correct are not necessarily modern usage.

Would it be reasonable to consider forking {{SIC}} so that an additional note can be added in the popup?

The thought was to write some like {{oldspell}} or something. ShakespeareFan00 (talk) 13:38, 2 March 2017 (UTC)

I was also wanting to ask how tooltips are implemented because I might want to use them to add certain annotations in portal space. ShakespeareFan00 (talk) 22:20, 2 March 2017 (UTC)
Wikisource:Annotations is your guide here. I am not sure why we need to make any commentary whatsoever. If the term is uncertain then link to Wiktionary for the meaning where they will mark the definition as archaic. — billinghurst sDrewth 22:37, 2 March 2017 (UTC)
Also I would be very reluctant to use tooltips for things because they're incompatible with mobile devices. But if you really want to, you can use the title= parameter on the HTML tag. See, for example these last few words which have a tooltip. (But as you can see there's no outward styling on the previous sentence to indicate that there might be a tooltip -- something else to keep in mind. The principle of "discoverability" is very important in usability/user interface design.) --Mukkakukaku (talk) 01:27, 3 March 2017 (UTC)
@Mukkakukaku: when you say incompatible, do you mean that they don't show, or they break something? The former is perfectly acceptable as it leave the work in a natural state; the latter is not acceptable and if happening should be raised for resolution. — billinghurst sDrewth 01:54, 3 March 2017 (UTC)
When I say "incompatible", I mean that doing it the standard way with just a title attribute doesn't work on mobile devices. Since it's fundamentally impossible to hover over an element using a touch screen, such interfaces are fundamentally incompatible. The {{tooltip}} template, as far as I can tell, implements just a title attribute as well, plus some styling to let you know that you can hover over the box.
If we had a template that provided both a hover tooltip and a tap-to-show tooltip, that would be compatible with mobile devices -- but we don't as far as I know. --Mukkakukaku (talk) 16:58, 5 March 2017 (UTC)
I agree with user:billinghurst that there is no need to mark up archaic spelling in any way. I would also like to point out to all interested that {{tooltip}} exists. —Beleg Tâl (talk) 01:13, 4 March 2017 (UTC)

Announcement: Change to transclusion checker tool

Tracked in PhabricatorTask T159095Resolved

Following a change to ProofreadPage in January, the transclusion checker tool needed to be updated. Then change is that the transclusion checker (available from each Index: ns page) now only reports for transclusions in the main namespace. I will need to go back and check each rechack each work we have changed a works status to either proofread and validated to ensure that they have been properly transcluded, and will get to that over the next week or so. — billinghurst sDrewth 01:34, 5 March 2017 (UTC)

What is the impact of this change? The only other namespace that I am aware of where Indexes get transcluded is Translation space, and there are a number of ProofreadPage features that are lacking there, so to me this says nothing beyond "transclusions to mainspace are still checked as before". —Beleg Tâl (talk) 02:31, 5 March 2017 (UTC)
The notification is here primarily as a courtesy. It means what it means. The practical difference is nothing for most eyes who hadn't noticed that the tool check was problematic for a period (as said there is a change in the tool due to the changes in ProofreadPage). The only thing that most may notice from December is that pages that are transcluded to the Index: page (ToCs) would show then, not now. If we want Translation: ns checked then we can ask to have those included. — billinghurst sDrewth 05:08, 5 March 2017 (UTC)

HTH moment

It's amazing what happens when you do something else entirely for a bit.

I've found out why some of my templates didn't work... because they would have NEVER worked as intended. So I was about to start converting all uses of them into something else when, I found something... buried in the documentation for {{left sidenote}} was a note about dynamic layouts ( in effect Wikisource's version of CSS stylesheets?) and following the help there I "tweaked" the sample to be roughly the same as the inlined CSS in the template that was creating so much difficulty, I put the custom layout in my Vector.JS and, so far it worked as designed. Well in mainspace at least, I can't say it's working in Page and User: but that may be due to Ui elements being called different things.

8 years of being wrong.. 8 Years! (Sigh). ShakespeareFan00 (talk) 22:17, 5 March 2017 (UTC)

Tech News: 2017-10

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

  • You can now search on English, French, Hebrew and Greek wikis and find words even if you forget the diacritics. It also works if you use diacritics in your search but the wiki doesn't. [1]
  • When you use the mobile view and click on a link to an article in another language you will see that article in the mobile view. Previously it changed to the desktop view. [2]

Problems

  • Some watchlist gadgets didn't work for a period of time last week. This has now been fixed. [3]
  • Admins who click on "mass delete" on a user's Special:Contributions will be taken directly to a list pages created by that user. It has worked like this before, but not lately. [4]

Changes this week

  • The way you switch between wikitext and the visual editors in the desktop view has changed. It is now a drop-down menu. This is the same as in the mobile view. [5]
  • The "flag the edit in the abuse log" checkbox will be removed from the abuse filter interface. This is because the edits are always flagged in the abuse log. [6]
  •   The new version of MediaWiki will be on test wikis and MediaWiki.org from 7 March. It will be on non-Wikipedia wikis and some Wikipedias from 8 March. It will be on all wikis from 9 March (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 7 March at 20:00 (UTC). See how to join.

Clarification

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

23:23, 6 March 2017 (UTC)

Overview #2 of updates on Wikimedia movement strategy process

Note: Apologies for cross-posting and sending in English. This message is available for translation on Meta-Wiki.

As we mentioned last month, the Wikimedia movement is beginning a movement-wide strategy discussion, a process which will run throughout 2017. This movement strategy discussion will focus on the future of our movement: where we want to go together, and what we want to achieve.

Regular updates are being sent to the Wikimedia-l mailing list, and posted on Meta-Wiki. Each month, we are sending overviews of these updates to this page as well. Sign up to receive future announcements and monthly highlights of strategy updates on your user talk page.

Here is a overview of the updates that have been sent since our message last month:

More information about the movement strategy is available on the Meta-Wiki 2017 Wikimedia movement strategy portal.

Posted by MediaWiki message delivery on behalf of the Wikimedia Foundation, 19:43, 9 March 2017 (UTC) • Please help translate to your language • Get help

Problematic work Indian Copyright Law

@Hrishikes, @Mahitgar, @Ciridae: Somewhere, somehow, under the general watch of this community, the work at Indian Copyright Law stopped being an edition and has become a bit of a mess as an annotated document. WS:WWI clearly states that we are not trying to have "current" law or dynamically adapt works; we have editions. It would seem that we need to pare back that work to an edition, and to get it named for the edition, then look to disambiguate as required for other versions of the law. — billinghurst sDrewth 01:35, 10 March 2017 (UTC)

The dynamic law is required, for linking from various copyright templates and also for generally citing the law anywhere. If an "edition" is needed, then the version at http://copyright.gov.in/Documents/CopyrightRules1957.pdf can be added here and used as the source file; this version, however, is updated upto the 1999 amendment and does not incorporate the 2012 amendment. Should I add it? Hrishikes (talk) 01:48, 10 March 2017 (UTC)
Now added: Index:Indian Copyright Act, 1957 (updated upto 1999).djvu. This may serve as the edition. Hrishikes (talk) 02:14, 10 March 2017 (UTC)
We do not limit the number of (differing) editions of a work that can exist, they just need to be of a point in time. We are not trying to be the site that is for the law as it is today, we are not that reliable. We do serve a purpose of "as a day here is what an edition said". So I have to challenge your statement that dynamic law is required, maybe it is, however, it if it is here, then it is a string of editions to the current, not amending a single version here. — billinghurst sDrewth 05:29, 10 March 2017 (UTC)
Also to note that if a version is available as an electronic document, then we do not need to step through transcription process against a scanned version. Just put it into place and we mark it as electronic. (and I/we need to fix up that approach.) — billinghurst sDrewth 05:34, 10 March 2017 (UTC)
@Billinghurst: I am still confused, things are not clear to me. Indian Copyright act 1957 has 6 amendments, So what do you mean by edition is
  1. Indian Copyright act 1957 + 1'st amendment = Second edition after amendments (Since Indian Copyright act 1957 initself amounts to be first edition.)
  2. Indian Copyright act 1957 + 1'st+2'nd amendment = Third edition after amendments
  3. Indian Copyright act 1957 + 1'st+2'nd + 3rd amendment = Fourth edition after amendment
  4. Indian Copyright act 1957 + 1'st+2'nd + 3rd+ 4th amendment = Fifth edition
  5. Indian Copyright act 1957 + 1'st+2'nd + 3rd+ 4th+ 5th amendment = sixth edition
  6. Indian Copyright act 1957 + 1'st+2'nd + 3rd+ 4th+ 5th + 6th amendment = seventh edition
What do I mean by edition is as above. Now problem before online (even ofline) Indic community is all these editions either are not available and where those are available are usually copyrighted; since this edition creation is usually done by non-govt agencies or indivisuals is usually copyrighted and fair dealing provisions can not be used easily, And many Indic wikimpedians suffer much more and end up using some wrong editions from online. Getting copyright free versions of these editions is not an easy job. My personal experience is Indian leagal fraternity still doesnot look wiki projects favourably enough.
So we need to develope these editions for supporting Indic wiki community for sure. We need to know whether and to what extant english wikisource allows this edition creation on english wikisource itself. To that extant we will keep here the rest of the activity we will need to find some other project if en-wikisource declines to allow the same.
As far as acuracy is concerned undersigned plans to create and cross-verify these editions with help of copyrighted sources. With the help of various law colleges from Maharashtra. Basically other copyrighted versions do have copyrigh mainly due to their arrangement and style. Since wikiprojects will be creating editions indipendantly and follow a separate style guide system we will not have copyright issues when we use copyrighted versions just for cross confirmations of accuracy only.
Please do guide me exactlly which points of above can not be covered in en-wikisource and we need to look for some other arrangements.
Mahitgar (talk) 06:32, 10 March 2017 (UTC)
Yes, there need to be (eventually) multiple editions. However, they should be disambiguated by year. i.e.
Beeswaxcandle (talk) 07:00, 10 March 2017 (UTC)
Although it seems you are concurring my perception, still would like to confirm for clarity further. In case of these Indian Copyright act 1957, subesequent amendment's text passed by parliament does not include base law/previous edition rather it is assumed. Uptill now some professionals did this job of creating a new edition and market the same. It is first time wikipedians are creating editions on their own on en-wikisource, and that you concur with me that it is possible. From the billinghurst' openion that we can not officially claim these editions to be dynamic, but we can certainly create editions.
And as you say we need to name these editions some thing like below. and link them in [Portal:Copyright law/Copyright law of India]]
1. Indian Copyright Act 1957 (1st edition) (transcription project)
2. Indian Copyright (1st Amendment) Act 1983 (transcription project)
2.1 Indian Copyright Act 1957 (1983 edition) (i.e. 2nd edition →page constructed by wikisource editors)
3. Indian Copyright (2nd Amendment) Act 1984 (transcription project)
3.1 Indian Copyright Act 1957 (1984 edition) (i.e. 3rd edition →page constructed by wikisource editors)
4. Indian Copyright (3rd Amendment) Act 1992
4.1 Indian Copyright Act 1957 (1992 edition) (i.e. 4th edition →page constructed by wikisource editors)
5. Indian Copyright (4th Amendment) Act 1994 (transcription project)
5.1 Indian Copyright Act 1957 (1994 edition) (i.e. 5th edition →page constructed by wikisource editors)
6. Indian Copyright (5th Amendment) Act 1999
6.1 Indian Copyright Act 1957 (1999 edition) (i.e. 6th edition →page constructed by wikisource editors)
7. Indian Copyright (6th Amendment) Act 2012 (transcription project)
7.1 Indian Copyright Act 1957 (2012 edition) (i.e. 7th edition →page constructed by wikisource editors)


Please do correct if I am missing any thing in my perception.
Mahitgar (talk) 09:13, 10 March 2017 (UTC)


@Hrishikes: I doubt your uploading of http://copyright.gov.in/Documents/CopyrightRules1957.pdf . this file uploading may not get covered under fair dealing, since file contains annotations without giving name of the author so it is separately copyrighted for sixty years there upon -without fairdealing protection in this case as per my personal openion- if I am not wrong.
Mahitgar (talk) 05:15, 10 March 2017 (UTC)
@Mahitgar: These annotations are of informatory nature, i.e., footnote references about which later act inserted which provision (The provisions themselves, being taken from parliamentary acts, are exempt under section 52). Are such annotations sufficient for fresh copyright? I don't have enough knowledge about such matters. However, if not permissible, then the file should be deleted, of course. Hrishikes (talk) 07:44, 10 March 2017 (UTC)
@Hrishikes: While it will take much longer time to cite particular court decesions, but to my knowldge usually Indian courts believe that adding such information needs special skill and effort so who so ever does such job or their employer as the case may be gets the copyright.
To my knowledge only the bare act as created by legislature or a bare judgement as written by the court is copyright free (i.e. fairdealing); whenever some one else puts any additional effort on that, that becomes copyrighted again.
This issue needs to studied with latest judgements and all; but over all my impression and advice is to avoid (emphasis added) using such documents on wiki projects.
Thanks and warm regards
Mahitgar (talk) 08:18, 10 March 2017 (UTC)
@Hrishikes: after limited google search I came across following reference material ref 1, ref 2 and ref 3. Frankly for want of time I could not read them again before citing here. But yourself or some one may go through such judgements to take the best decesion in this respect.
Mahitgar (talk) 08:33, 10 March 2017 (UTC)

@Mahitgar: I am saying a published edition — however published, whenever published. Each different published edition can be hosted here. We (Wikisourcians) do not munge or create works, that is out of scope, we just reproduce. Also don't get hung up in what went through parliament as they are Bills, not Acts. Think what is published as a result of a Bill in Parliament (noting that a Bill in Parliament can alter numbers of pieces of legislation at once). You will probably find a fully published edition per Bill. For example if you look at http://www.legislation.vic.gov.au/Domino%5CWeb_Notes%5CLDMS%5CPubLawToday.nsf you will see lots of mentions of versions, go to an Act, and the twisty at the bottom has all the published versions. — billinghurst sDrewth 11:24, 10 March 2017 (UTC)

@Billinghurst: Thanks, atleast it is clear that, we would not be able to construct editions on english wikisource atleast. So project of constructing edition may be needed to shift to some other project (In any case Indic wikipedians and Indians would need that), or we will need to give space on some marathi language wiki. I will ask wikiversity community if they can support in first step. Please bear with me untill I trasfer the project somewhere else.
I know diff bttw bill & act, still thanks for the info.
Mahitgar (talk) 13:20, 10 March 2017 (UTC)
@Hrishikes, @Mahitgar, @Billinghurst: I think every published document of the Copyright Act, including the amendments, either separately or together, should be present in Wikisource as long as it is free of copyright. What I'm not sure about is whether Indian Copyright Law, as it currently is, should exist since it does not seem to be a single published document. Ciridae (talk) 13:39, 10 March 2017 (UTC)
@Mahitgar: If a single document is needed that agglomerates the various published pieces of Indian copyright legislation, I would suggest that Wikibooks would be a good place for it. —Beleg Tâl (talk) 13:43, 10 March 2017 (UTC)
Thanks I will ask at their discussion page if they allow.
Mahitgar (talk) 13:49, 10 March 2017 (UTC)
@Mahitgar: The document Indian Copyright Law may be shifted to Wikibooks if they would allow, then amended as needed. As for copyright office file, you may propose deletion if you think that is proper. You seem to be more knowledgeable, so I leave it at your discretion. Hrishikes (talk) 14:21, 10 March 2017 (UTC)

Index:The pilgrims progress as originally published by John Bunyan ; being a facsimile of the first edition (1878).djvu

I appreciate that the aim isn't to mirror exactly what's printed, but there having been no decision on this, I've hard-coded the long-s, which may be against the style manual.

However, once a suitable font which can do the change automatically can be put on English Wikisource I'm more than happy for someone with AWB to run a search and replace on this turing the long-s back into conventional ones.

One possible typeface for displaying older works like this is Junicode ( which has an Open Font License), but I was having considerably difficulty in getting it to behave exactly like the rules apparently used in the scans. Namely ct/st ligatures long-s mid word but not end-word and so on.

There also appears to be variable levels of support for the various glyphs needed in different versions of the font. (and the rounded top lower case k variant used in italic form.)

I've tried, but feel this needs an expert looking into it.

There's no problem with the scans though. ShakespeareFan00 (talk) 17:49, 11 March 2017 (UTC)

@ShakespeareFan00: Having run into long (loooong, sorry) discussions of this issue: the long s is not a violation of the MoS. It's a special case, and for some people it is tolerated more than allowed, but long s is specifically permitted. Other historical ligatures, such as the ct-ligature, are being forcibly removed as mere typographic puffery (note that I've been unable to find policy support or previous consensus to support this, but that's the observable practice in any case).
That being said, I think the basic problem here is really the atrocious support for historical ligatures (and related features of relevance to us) in current web browsers. The CSS and OpenType standards have support for pretty much everything we'd need (that I've checked), but web browsers simply have not implemented those features. If they did, we would be able to enable correct use of ct-, ffi-, and sh-ligatures, &c., in CSS even absent use of explicit such templates in the page text. I still like to mark as many of these as I am able to pick up when proofreading, in case it turns out we will need to mark them for the styling to work in practice, but overall my current thinking is that this is an issue that will be dealt with in CSS, proper fonts, and web browsers rather than templates.
In particular, I don't think using a special font and forcing an alternate glyph will help at all until browser support is in place: the font can't do this properly without cooperation from the font renderer (the web browser). --Xover (talk) 07:46, 12 March 2017 (UTC)
Some font's allow for historical ligatures to be selected by font-features: . I've started a phabrictor ticket asking for the support in mediawiki/extensions that would allow for such font's to be provided for Wikisource use.ShakespeareFan00 (talk) 10:04, 12 March 2017 (UTC)
What we're talking about is (primarily) the Open Type font feature option hlig, which is supported in the CSS standard by using font-variant-ligatures: historical-ligatures. There are plenty of fonts that support this Open Type feature; but browsers do not yet support enabling those font features, and operating system font engines do not support displaying them. Thus, having the font available is a necessary precondition, but it is not in itself sufficient. --Xover (talk) 10:20, 12 March 2017 (UTC)
Owing to some views expressed elsewhere I'll consider converting the hard-coded long-s back to standard ones, at least until there's "appropriate" support for older texts. At least the text will render on anything under that.ShakespeareFan00 (talk) 14:03, 12 March 2017 (UTC)
I would suggest not to. Last month's featured text, The Clandestine Marriage, uses hard-coded long s throughout. BethNaught (talk) 14:09, 12 March 2017 (UTC)
Yes, which will break on some devices I've been told (not on wiki though).ShakespeareFan00 (talk) 14:16, 12 March 2017 (UTC)
Where does it break? First time I've heard of this. It should be ok on any device I think. Jpez (talk) 16:27, 12 March 2017 (UTC)
{{ls}} and hardcoding long-s should eventually be un-necessary as it could be handled by a font-features choice at a much higher level. I'd rather break stuff ONCE then several times, as I explained in the discussion that was had a month ago. ShakespeareFan00 (talk) 14:32, 12 March 2017 (UTC)
Long-s is one archaic character that is widely supported by browsers. It is the archaic ligatures (joining of letter pairs such as ct or fl) that are not generally supported in browsers. There should be no technical problems with long-s. --EncycloPetey (talk) 16:51, 12 March 2017 (UTC)
Another issues is that searching for s doesn't also recognise ſ that's another reason why I am unhappy about hard-coding it. The following site :

http://www.yourphotocard.com/Ascanius/Gladsmuir.htm# uses a font called Junicode and a font-feature "hist" to do long s forms, but due to apparent limitations in mediawiki, it was as I said not possible to have that font installed locally, and in-line it so that it behaved like the text on the scans in all instances (medial long s, final short s) in both italic and non-italic instances. If someone is willing to write yet another 'kludge' template rather than fixing the underlying lack of support in mediawiki, they are welcome, but it would nice for once to fix the root problem rather than continually writing yet more "un-necessary" formatting templates. (Sigh). ShakespeareFan00 (talk) 17:16, 12 March 2017 (UTC)

long s searches fine on google which is the most used search engine and I also just tried it on our own search engine and it worked fine. Compatability on devices and search engines isn't an issue I think. The only problem I could see with the long s is end users difficulty in reading texts that use it. Jpez (talk) 17:28, 12 March 2017 (UTC)
Can you find words inside the work concerned then? Just by searching using the modern presentation? If so there's less of an immediate concern.ShakespeareFan00 (talk) 17:46, 12 March 2017 (UTC)
Yes, text searches using modern "s" in the word will return results using long-s. Google and books.google have supported this for years now, so long-s is no longer a technical issue for users as it was a decade ago. --EncycloPetey (talk) 17:54, 12 March 2017 (UTC)
So technically, {{ls}} could now be mass subst? and the ſ character added to CharInsert (or the other relevant toolbars) There was some objection to that the last time it was suggested.
It's still not possible to type long-s directly from a standard keyboard when transcribing though, meaning it's take longer if hard-coding it directly.
{{ls}} has to be typed precisely, The number of times I've played hunt the bracket, when previewing due to unclosed s invocations is quite high. Only needing to type ONE s form that can't mismatch brackets etc is less error prone.
{{ls}} isn't a very complex template so it's easily processed, but for a long work using it, there will eventually be the issue of transclusion limits. I'm not sure if anything has yet hit it but.
Thusly, I still think it should be possible to just not have to worry about long-s and let a font/mediawiki backend handle it. However any prospect of that at the current time seems to be vapourware like many other thing that would make Wikisource a better platform.( Like sidenotes that flow better.) (sigh) ShakespeareFan00 (talk) 18:24, 12 March 2017 (UTC)

Publishers logos are being reorganized on the Commons

There are two main categories on Wikimedia commons that identify some 400 publisher logos. They are Logos of publishing houses and Publishers' marks. I am hoping that eventually I can merge the two categories and make "Publishers' marks" a redirect. Before creating or looking for book logos, please check these categories. Moreover, if you have already placed logos in other commons categories, please add to it the Logos of publishing houses category as well. Thanks. — Ineuw talk 16:11, 13 March 2017 (UTC)

Book downloads with the Featured download template

I'm not sure if this has been discussed/noticed previously but the downloads using the Featured download template only provides the main page of the work. Since most texts are split over multiple sub-pages, this isn't very ideal and defeats the entire purpose of having the download links since no one can easily get the full work. I do know that the tool isn't perfect and the download can still be very badly transcribed but something is better than nothing. Will it be possible to tweak the template to also transcribe all sub-pages as well? Ciridae (talk) 19:35, 16 March 2017 (UTC)

@Ciridae: It should provide the whole work. When you are on the work, are you getting the same result from the [download] option in the left sidebar? Which format are you downloading? — billinghurst sDrewth 02:46, 17 March 2017 (UTC)
@Ciridae: Not to worry. I have found and fixed the problem. [/me mumbles and mutters again about these dotted templates]. — billinghurst sDrewth 03:07, 17 March 2017 (UTC)
This section was archived on a request by: — billinghurst sDrewth 03:07, 17 March 2017 (UTC)

Search failure

Although Poems of Nature (1895) was listed as a "New text" in January 2017, and appears first on the list at Wikisource:Works/2017, a search in the WS namespace does not turn up this link. Has this problem been noted before? --EncycloPetey (talk) 18:39, 12 March 2017 (UTC)

I'm guessing this is a caching or job queue issue. It's now showing after I gave it the relevant pages a barrage of purges and null edits. BethNaught (talk) 20:38, 12 March 2017 (UTC)
I wonder how many of our pages are failing to show up in searches for this reason. --EncycloPetey (talk) 17:37, 16 March 2017 (UTC)

Tech News: 2017-11

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Changes this week

  • You will be able to show references from <references /> tags in more than one column on your wiki. This is the list of footnotes for the sources in the article. How many columns you see will depend on how big your screen is. On some wikis, some templates already do this. Templates that use <references /> tags will need to be updated, and then later the change can happen for all reference lists. mw:Editing/Projects/Columns_for_references[7]
  •   The new version of MediaWiki will be on test wikis and MediaWiki.org from 14 March. It will be on non-Wikipedia wikis and some Wikipedias from 15 March. It will be on all wikis from 16 March (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 14 March at 19:00 (UTC). See how to join.

Future changes

  • Some old web browsers will not be able to use JavaScript on Wikimedia wikis in the future. If you have an old web browser on your computer you can upgrade to a newer version. [8]
  •   CSS in templates will be stored in a separate page in the future. [9][10]

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

15:25, 13 March 2017 (UTC)

Action items

  • The above components about CSS are very pertinent to us. We should be looking to get our heads around what is happening, especially as 1) much of what we apply inline is styling, rather than structural, 2) we style tables! I need to do some more reading and thinking. Others more expert please feel welcome to throw in your opinions. To me it will over us the change to overhaul what we do.
    Good news, with the planned change we can start to utilise nth-child type css, and other CSS3, formatting at a template level, rather than just globally (per common.css). What that will mean is that where we can finally style a column of a work rather than have to format every cell in the column (yippee). We will have some work to do to set up something like template:table style and its subsidiary. We will also want to look at what we consider good template styles, and what we consider problematic. [We probably should review what bloat we have created and should put centrally anyway,eg. making some of our static formatting templates just be classes and move the formatting centrally. And yes, I should create a separate section :-/ ] — billinghurst sDrewth 02:52, 15 March 2017 (UTC)
  • With regard to references. I don't believe that we would have many, if any, uses of references presented in columns. If we do, we should be looking to identify these and determine where we want to take these. — billinghurst sDrewth 23:46, 13 March 2017 (UTC)
Tracked in PhabricatorTask T33597
We don't use references in columns, but we do use {{reflist}} and {{smallrefs}} an awful lot. Will this change affect those templates? --Mukkakukaku (talk) 04:13, 14 March 2017 (UTC)
both templates have coding for columns and that will need to be updated, (or maybe we just remove it?) — billinghurst sDrewth 11:04, 14 March 2017 (UTC)
Added the phabricator tracking. It seems that there will be an ON group of wikis and an OFF group, though the process for which is not stated. I have asked the question. We will need to work that option into our templates. It will probably mean that we will need to move the style components of templates into Mediawiki:common.css though I will leave that to those who play that space better than I. — billinghurst sDrewth 11:17, 14 March 2017 (UTC)
Opt-in. So we can update at our leisure. — billinghurst sDrewth 14:16, 14 March 2017 (UTC)
There's definitely no rush.
For now, you can turn this feature on for any individual page (requires >10 refs to see a change). If you ever want that to change (in which case, you could turn it off on any individual page), then please file a task in Phabricator, or talk to me. My goal is for the default setting at your wiki to be the best setting for your wiki – not the best setting for some hypothetical average wiki. Whatamidoing (WMF) (talk) 21:38, 14 March 2017 (UTC)

Decoupling CSS from dynamic templates?

How are templates that style dynamically, like {{Numbered div}} intended to be done correctly, if CSS is being "decoupled"? ShakespeareFan00 (talk) 15:11, 15 March 2017 (UTC)

The above said, some aspects of what numbered div does could ideally be implemented with CSS counters in any event.ShakespeareFan00 (talk) 15:44, 15 March 2017 (UTC)
That is the discussion that we have to have. Basically the change is going to be equivalent to html where we can have <style> sections or separate style sheets. It is a big change and we are going to have to work out what we want to do. We may choose to not do anything at this point of time as most of our templates are pretty set. You especially need to settle! Running amok changing templates and adding further complexity and tangentially to what the community decides would not be ideal. — billinghurst sDrewth 13:47, 16 March 2017 (UTC)
If the existing inline styles will still work, then there's no need to change anything (which was the impression I got from the TemplateStyles documentation). However, if there is a general consensues that "decoupling" style and content, is a good thing, then it should be seen as a chance to massively overhaul many templates.
For example, currently we have {{p}},{{tf}},{{ts}} that essentially all do the same thing, albeit for different HTML elements. Would it not be a more sensible approach to have one central style/parse to handle the short codes, rather than 2 or more, and to have the short codes/expansion stored separately from the parse portion of the template? That way to add new codes, it wouldn't need to necessary to modify the parse template (which could be protected.) and instead there could be a page which was used as a lookup table for the style codes.
I am also of the view that are some templates (mine included) DO need to be massively overhauled. ShakespeareFan00 (talk) 14:16, 16 March 2017 (UTC)

Wiki 4 Coop

Hello everyone,

I come to you to invite to re-read the submission of a new partnership project between the Wikimedia movement and the Belgian NGOs. The project is titled Wiki 4 Coop and I invite you to discover its submission page on Meta-Wiki. Do not hesitate to endorse the project if you like it and even correct my English if you have a little time. A beautiful end of day for all of you, Lionel Scheepmans (talk) 12:06, 17 March 2017 (UTC)

Edit window limitations

Do we have a new vertical size limit on the edit window? Today, I can't extend the window to the same size as the neighboring DjVu page image, which I was able to do as recently as yesterday. Today, I drag the size down, and hit a sticking point beyond which it will not extend. --EncycloPetey (talk) 04:05, 9 March 2017 (UTC)

Firefox 51.0.1 allows me to expand the edit box to the same height as the image, which is not unexpected in a table or div. — billinghurst sDrewth 05:54, 9 March 2017 (UTC)
My Firefox 51.0.1 allowed me to do so yesterday (and in all times past), but not today. Now, my edit window is limited to a height which is decidedly shorter than the image. --EncycloPetey (talk) 05:57, 9 March 2017 (UTC)
Have you been using Visual Editor, or have you upgraded to Firefox 52.0 ?

ShakespeareFan00 (talk) 19:56, 9 March 2017 (UTC)

Neither. --EncycloPetey (talk) 02:43, 10 March 2017 (UTC)
I have checked in Chrome (56.0.2924.87) and Firefox (51.0.1), the edit window can be dragged to bigger size vertically than the scanned page. So the problem may be local. Hrishikes (talk) 03:11, 10 March 2017 (UTC)
I've been having this problem on two different computers, running different OS (Windows / MacOS) but with Firefox. Lately the situation has changed slightly. I still get a maximum size at which point I can't increase the size of the edit window, however it's no longer always shorter than the accompanying image. Previously, the sticking point was always relative to the size of the image at about the same place (~90% of the image size). But now the sticking point seems to be at a fixed size irrespective of the size of the image. So now, my edit window can sometimes go larger (but only so far), and sometimes only short, depending on the djvu file I'm working with. --EncycloPetey (talk) 17:42, 16 March 2017 (UTC)
I wonder if it's related to this recently reported problem, which was ultimately blamed on a long-forgotten user script. Whatamidoing (WMF) (talk) 16:54, 18 March 2017 (UTC)
If so, it's a different tweak than it is here. I have no such code in my common.css to cause that problem. Also, my issue is a maximum size when I change it, not an externally forced window height that needs to be adjusted. --EncycloPetey (talk) 17:20, 18 March 2017 (UTC)

Proofreading

U.S. Government Printing Office Style Manual 2008 is nearly completely proofread. I have found an earlier copy to fix the last Problematic pages. The proofreading has been done by ShakespeareFan00 and I over the last year, and is frankly a bit erratic. We’ve both been trying different approaches as we’ve worked through it. I think it now really needs a thorough editorial eye passed over it as it is validated.

My intention is to use this text and Cowie's Printer's Pocket-Book and Manual as proofreading reference books/exemplars/training material so I want them to be reflective of WS standards, especially demonstrating that there are different approaches to "solving" proofreading "dilemmas". I would really appreciate erudite discussion referencing these books. I think we could use Page discussion to detail the finer points and then link them to Help pages.

Any takers for a thorough review?

Cheers, Zoeannl (talk) 01:28, 16 March 2017 (UTC)

@Zoeannl: can you describe the different approaches in style? Maybe we can get a bot to go through and either check or adjust some of the differences. — billinghurst sDrewth 13:40, 16 March 2017 (UTC)
@Billinghurst: You have clearly not even looked at this transcription before sounding off. It is a demonstration piece of the limits of typography and as such a robotic solution can only be detrimental at best. 101.174.28.34 23:12, 16 March 2017 (UTC)
Absolutely I didn't check it on the limited moments that I had, which is why I asked for an expanding on the comments so that people can better understand prior to venturing to the work. Start with open questions to better have the issues defined, so we don't all have to work it out. Mention some of the possible solutions, so the thinking is shared with a common approach. Running a bot through is always possible at this stage if there are style differences. — billinghurst sDrewth 02:23, 17 March 2017 (UTC)
Specifically, I have issues with font size mark-up both in terms of consistency between proofreaders and as faithfully representing the text which specifies things like "7 point" in places (as a printing standard).
Generally … SF came up with a template specifically for the project which is pretty cool and worth discussion. The book covers a lot of stuff like non-English fonts, symbols, tables, poetry etc so as I am proposing would provide a great exemplar for what we should/could/would do for proofreading and formatting.
Cheers, Zoeannl (talk) 07:32, 18 March 2017 (UTC)

commons poty banner

i see we are getting a commons banner here. [11] anybody comment or consent to this? Slowking4 ‽ SvG's revenge 14:07, 18 March 2017 (UTC)

We are? I never see banners here. Gadgets win! — billinghurst sDrewth 14:58, 18 March 2017 (UTC)
Yeah, that just popped up for me on the Community Portal. Can't say I like the idea that people visiting a page like that are greeted by a huge banner that directs them to another project. --EncycloPetey (talk) 16:49, 18 March 2017 (UTC)
there is a global turn-off "following code to your common.css page: #siteNotice {display: none;} " [12] cheers. Slowking4 ‽ SvG's revenge 00:44, 19 March 2017 (UTC)

On Pearl Buck

How come I cannot find Pearl Buck as an author? Billingsmell 21:56, 18 March 2017 (UTC)

Primarily because nobody has created an author page for her yet. Based on her Wikipedia page, all her writings were in the 1930s or later, which means they are all (probably) copyright. If there are no public domain works by her, there is no point in creating an author page for her anyway, and any author page would probably be deleted. —Beleg Tâl (talk) 22:07, 18 March 2017 (UTC)
But she is very famous and a page has to be devoted to her.Billingsmell 22:14, 18 March 2017 (UTC)
Famous has nothing to do with it. Most Wikisource projects (English or otherwise) only create Author pages if there are works written by that person that are in the public domain. If a person has not written anything, or all their works are under copyright, we do not create an Author page for them. the purpose in having an Author page is to provide a list of what we have on Wikisource, not simply for the sake of having a page. --EncycloPetey (talk) 22:30, 18 March 2017 (UTC)
That is it. I also searched for "Karen Blixen" but I could not see her name here. I had book written by her and I wish to edit her page if it exists.Billingsmell 22:35, 18 March 2017 (UTC)
I can only find three of her works published before 1923, and those were published in Danish. Have you tried Danish Wikisource? --EncycloPetey (talk) 23:15, 18 March 2017 (UTC)
i suspect we have some orphans that may not have been renewed, but it is too hard. you could build the author and bibliography, (or grab from wikidata) and then start with the hathi trust search of the pdfs. [13]; and copyright search [14] Slowking4 ‽ SvG's revenge 00:51, 19 March 2017 (UTC)

Changes in Preferences Editing settings & other issues

The textarea window row size setting from Preferences/Editing settings was removed with one of the recent wmf software updates.

Also noticed that {{rule}} and table borders etc., are not rendered and this causes some confusion when previewing. Had anyone else noticed these issues? — Ineuw talk 20:42, 18 March 2017 (UTC)

The rendering of {{rule}} is platform specific. When I view pages from home, rules and table borders render just fine. When I view pages at work, rules and table borders render only sometimes, but often not. This is true whether I preview an edit or simply view a page. I use Firefox at both locations, but have issues at work because it runs Windows. --EncycloPetey (talk) 21:28, 18 March 2017 (UTC)
Thanks, I will check this issue in Linux. However, the lines do show up eventually on the same platform (Windows 7 & Firefox) and this was never an issue before. — Ineuw talk 04:28, 19 March 2017 (UTC)

New Page that I created

Please start contributing to the page I just created: https://en.wikisource.org/wiki/Authors_whose_work_are_part_of_their_or_someone_else%27s_epitaphs Thanks. Billingsmell 22:55, 18 March 2017 (UTC)

That's not the sort of thing Wikisource does. We don't create new works or articles, but re-publish works that have already been published, and create indexes/categories/catalogs so that people can find those works on our site. --EncycloPetey (talk) 00:24, 20 March 2017 (UTC)

Re-reading previously proof-read..

I've decided to take another look at some stuff I proofread earlier this year, and in previous years. I am not finding many big errors, but I am finding a lot of tiny single character or format errors, on pages I was sure I'd checked at least twice previously. So if I am somewhat quieter for a while or I seem to be making a LOT of minor edits don't be surprised, The aim is to try and push the page quality as far as I reasonably can before it gets validated (And that reminds me, I should probably check some of those as well). ShakespeareFan00 (talk) 23:01, 18 March 2017 (UTC)

Your proofreading is passable. Even on Project Gutenberg things get missed after 6 rounds of proofreaders have been through. Which is why WS has an advantage as we can continue to improve once "published". PG’s process for fixing mistakes is arduous. Because of this Distributed Proofreaders, where the books are processed, has a very vigorous training program that I would really recommend for everyone here at WS. It doesn’t take long to get through their first stage (P1) and they have projects and feedback specifically for beginners. It is 95% relevant to what we do here, and even the differences help train the eye. They have tutorials and quizzes too. I notice they have 300+ active users in the last 24 hours, about the same as WS in the last month … They do know what they are doing re proofreading. I think it’s a real shame that their end product is IMHO so inferior to WS. Cheers, Zoeannl (talk) 01:13, 19 March 2017 (UTC)
@ShakespeareFan00: I recommend you to install typoscan.js by AuFCL. It highlights a of typos. — Ineuw talk 04:35, 19 March 2017 (UTC)
@ShakespeareFan00: have a look at Page:The Holy Bible (YLT).djvu/55, and read through it a bit. This is how you've been proofreading this whole work. It's a page I randomly picked which I remember working with you for a bit, and I remember your proofreading there was as if you just speedily went through it. Also check some of the pages I've validated and compare history from your proofreading. I thought of bringing it up to you many times, but I don't like putting down someone who after all is just trying to help, but in the end is it help? or would it have been better if no help was provided at all, since in this circumstance my validating was as if I was proofreading and in the end the true validation is lost, since I'm sure I've left many mistakes behind myself. So I must say your proofreading is unacceptable in this work. As I said I wouldn't have mentioned this at all (probably should of though) but it seems you're looking for critique and and your work here Index:The Holy Bible (YLT).djvu speaks for itself. Sorry. Jpez (talk) 05:11, 19 March 2017 (UTC)
@Jpez: Added to my re-read list. If you find others LMK.ShakespeareFan00 (talk) 09:36, 19 March 2017 (UTC)
Cassell 3? Although there you're not the only one missing lots of stuff. I agree with Jpez about how difficult it can be to raise issues needing to be raised. BethNaught (talk) 11:05, 19 March 2017 (UTC)
Thanks, Any objections to a complete re-read of all volumes of this completed so far?ShakespeareFan00 (talk) 11:26, 19 March 2017 (UTC)
Why would anyone object to anyone rechecking their own work? BethNaught (talk) 11:42, 19 March 2017 (UTC)
@Ineuw: , I may already have typoscan.js installed, I am not going to rely on automated tools to spot "errors" though. ShakespeareFan00 (talk) 09:36, 19 March 2017 (UTC)
I'm glad you're taking steps to recheck your work, but I would recommend you follow Zoeannl's advice re PG training. I haven't done it but it looks helpful; your rechecks are still missing quite a bit, see my randomly sampled page [15] vs. [16]. BethNaught (talk) 11:05, 19 March 2017 (UTC)
I can't promise 100% ever. This is EVEN with the typo script, the spell-checker in Firefox, and page preview. Was there a plan to add further text-check' tools, to look for mismatched brackets, quotes and s/e template mismatches? ( Kind of like a Wikisource specfic set of checkwiki hurestics.)ShakespeareFan00 (talk) 11:26, 19 March 2017 (UTC)
I never asked for 100%, and I would never claim that I never make errors. Nevertheless you clearly have a blind spot for punctuation, which spell-checkers won't help with. Try using the MS Word (or equivalent) spell checker as that also checks grammar. But really when so many of your works have problems, you should consider that there may be a fundamental problem with your proofreading, which may need to be fixed with e.g. the PG training. BethNaught (talk) 11:42, 19 March 2017 (UTC)
Quite. I will also note at one point, I was marking pages I'd effectively only cleaned up from OCR as "Not-proofread" until someone queried why I was creating a backlog, and why I was apparently asking for 2 proofreads as well as the validation step. If scan errors and typos are being missied in sufficient number (on the initial entry and) re-checking as well, it clearly needs at least 3 (independent) people. I'm thusly also not happy that it's possible to mark as proofread directly on new page-creation, as barring someone that's done a LOT of proof-reading previously, it's unlikely all the errors will be removed on a first-pass. ShakespeareFan00 (talk) 12:13, 19 March 2017 (UTC)
Also:
  1. If anyone finds anything they want "re-read" drop a note on my talk page. I won't be starting 'new-projects' (other than stuff I already have watchlisted) until June.
  2. I will be marking 'new-pages' as 'Not-Proofread' (given my concerns)
  3. I obviously have no objections to other contributors correcting scan errors that have been overlooked/missed (Letting me know so the entire work can be "re-read" would be appreciated.)
  4. The spell-check dictionary in most software doesn't like archaic spellings or long-s. Would there be any interest in people slightly more able than me developing an 'archaic' list for older word forms? ( and yes I'm well aware that until a certain date English spelling was NOT uniform.)

ShakespeareFan00 (talk) 12:33, 19 March 2017 (UTC)

Is there any kind of agreement in the community as to an acceptable error rate, or to what level the formatting should to be accurate, in order to mark a page as proofread? I always understood it to be "as perfect as possible", but accepting that an error every couple of pages, more if pages are very long or complicatedly laid out, will happen. I often feel when checking or validating others' work (not just SF00, and not naming other names) that others have different standards. BethNaught (talk) 11:42, 19 March 2017 (UTC)

Let's just say that finding 2-3 typos per PAGE on a recheck is probably too high. The speed at which proofreading/validation occurs has also been a concern raised. (There was at one time a suggestion that to validate needed two people to independently flag an unchanged page (i.e no changes) as such, but the outcome of the disscussion was that it wasn't feasible in the software.)ShakespeareFan00 (talk) 12:13, 19 March 2017 (UTC)
Might I suggest a method for processing a page, which would include proofing, validating, revalidating as many times as you like? There was someone many years ago at Distributed Proofreaders who was having some difficulty in catching OCR misinterpretations, publisher typos and punctuation mishaps despite the use of Wordcheck. It was suggested to the user that the method of using Ctrl+right arrow key might help. I too was having the same issue. Originally I was just moving my mouse over the text but when I checked my diffs I found I was missing too much and it was obvious stuff. Then I started using the Ctrl+right arrow key method and things started to improve. Although that may sound time consuming, it really isn't once you get used to it. I like to "read" as I proof (or maybe in this case, "proof" as I read) as I am doing both. Somewhere in my past, I recall a statement that "the eye follows movement". Do you ever find yourself watching the movement in the background of a TV interview instead of the non-moving person in the front? Not to say that this is the best method (I'm sure I still miss the occasional thing) but something you could try. Humbug26 (talk) 18:00, 19 March 2017 (UTC)
I've found myself using that technique, especially with some old texts that needed special formatting inserting, I still can't do non-latin text (sigh) .ShakespeareFan00 (talk) 18:43, 19 March 2017 (UTC)
  • BethNaught, I am glad to see your mention of Cassell’s and to that I would state that if you see a mistake anywhere please fix it. That is "as perfect as possible" - helping one another create a better Wikisource and not only on one’s personal projects. The situation you are seeing on Cassell’s v.3 came about as a speed reader (guess who) went through that volume and because of the swift marking of "proofread" I came behind and missed many mistakes while I did get as many as possible while trying to keep up (my mistake) with the speed reader who often makes many mistakes although I have seen that same person edit with perfection. I don’t know why he speed reads but he has been notified by several people and sometimes he has stated he was going to take a "break" but that break doesn’t last very long. My idea includes to going over all of the 9 Cassell volumes once fully done and especially vol.3 My basic job, as agreed upon at the outset among 4 of us, was to insert all images in proofread text plus look over the text. Your comment, "Is there any kind of agreement in the community as to an acceptable error rate, or to what level the formatting should to be accurate, in order to mark a page as proofread? - is an excellent point in my opinion. Speed reading causes more harm than good in my experiences. I have followed and have seen many pages marked "proofread" yet filled with mistakes. Speed dominates that person but he is not a bad person. Also, some do not format pages. When looking into the edit mode one easily sees those. Best, —Maury (talk) 19:27, 19 March 2017 (UTC)

@ShakespeareFan00: Where did you get the idea that it's automated? All it does is highlights possible errors, then it's up to the user to check the context. For example. ii, li, Av and St, are possible errors depending on their context. The Regex for the errors were ones suggested by other users who found them in the scans. — Ineuw talk 21:47, 19 March 2017 (UTC)

Is there a page to suggest new patterns to look for? ShakespeareFan00 (talk) 21:59, 19 March 2017 (UTC)
In old-school printing you got this Page:U.S. Government Printing Office Style Manual 2008.djvu/21 when checking proof's. Is there a way to do something like that in UI/digital terms for Wikisource pages? (i.e noting errors with a carret in the text, and the actual errors down the side.). I am also thinking in terms of VE stuff... ShakespeareFan00 (talk) 22:11, 19 March 2017 (UTC)
On the topic of punctuation: the Wikisource:WikisourceMono font can help with making it easier to see differences between commas, dashes, colons etc. Sam Wilson 23:15, 19 March 2017 (UTC)

pagelist for two page scans

I have a book scanned as two page spreads. How do I configure the pagelist tag to number it correctly in such a situation? Is there any workaround? --Prateek Pattanaik (talk) 07:22, 19 March 2017 (UTC)

You'd probably have to do it manually: 1=1 2=3 3=5 4=7 etc. —Beleg Tâl (talk) 12:11, 19 March 2017 (UTC)
That is how I have managed it in the past. — billinghurst sDrewth 00:16, 20 March 2017 (UTC)

WIkisource Tutorial ?

In a previous thread it was mentioned that there was a tutorial/quiz on the Distributed Proofreaders website. Given that it was possible to implement the "Wikipedia Experience" tutorial on English Wikipedia, would it be possible to implement a "Wikisource Tutorial" based on the DP example? (noting that some of the formatting is done slightly differently on English Wikisource).

I couldn't come up with a name other than tutorial, unless someone knows what an apprentice scribe or typesetter was called way-back. ShakespeareFan00 (talk) 16:46, 19 March 2017 (UTC)

/* By Request */

ShakespeareFan00 has told me on my talk page that there was some sort of editing conflict. So, I repeat what I previously wrote without the highlight and this is copy/pasted from that highlight.

BethNaught, I am glad to see your mention of Cassell’s and to that I would state that if you see a mistake anywhere please fix it. That is "as perfect as possible" - helping one another create a better Wikisource and not only on one’s personal projects. The situation you are seeing on Cassell’s v.3 came about as a speed reader (guess who) went through that volume and because of the swift marking of "proofread" I came behind and missed many mistakes while I did get as many as possible while trying to keep up (my mistake) with the speed reader who often makes many mistakes although I have seen that same person edit with perfection. I don’t know why he speed reads but he has been notified by several people and sometimes he has stated he was going to take a "break" but that break doesn’t last very long. My idea includes to going over all of the 9 Cassell volumes once fully done and especially vol.3 My basic job, as agreed upon at the outset among 4 of us, was to insert all images in proofread text plus look over the text. Your comment, "Is there any kind of agreement in the community as to an acceptable error rate, or to what level the formatting should to be accurate, in order to mark a page as proofread? - is an excellent point in my opinion. Speed reading causes more harm than good in my experiences. I have followed and have seen many pages marked "proofread" yet filled with mistakes. Speed dominates that person but he is not a bad person. Also, some do not format pages. When looking into the edit mode one easily sees those. Best, —Maury (talk) 19:27, 19 March 2017 (UTC)

Further, BethNaught has shown me a page he corrected where five people did not catch all words in proofreadig for which I thanked him and thank him again. Best regards, —Maury (talk) 21:02, 19 March 2017 (UTC)

Collaboration products newsletter: 2017-03

Latest news from the Wikimedia Collaboration team, about Notifications, Flow and Edit Review Improvements. Please tell other users about these changes. Not all changes will affect you.

What's new?

We have focused all our efforts on the New filters for edit review. You will discover these filters on your wiki soon (see below).

Edit Review Improvements [More information • Help pages]

Recent changes

Future changes

  • We will release the ⧼eri-rcfilters-beta-label⧽ beta option on Portuguese and Polish Wikipedias March 28. This beta option adds powerful filtering and other tools as well as an improved filtering interface to the Recent Changes page (and Recent Changes Linked). To try out these new tools on these two wikis, go to the Beta tab of the Preferences page (after the 28th) and select ⧼eri-rcfilters-beta-label⧽.
  • In the weeks following the initial release to Polish and Portuguese Wikipedias, the New Filters for Edit Review beta will go out to the following list of Wikipedias in waves (schedule to be done):
    • Persian, Dutch, Russian, Turkish, Czech Wikipedias and Wikidata. [17]
    • English Wikipedia. [18]
    • All other wikis. [19]

Flow [More information • Help pages]

Recent changes

  • <math> <hiero> <score> <syntax> <source> <ref> shortcuts are now working on Flow visual editing mode. Type a shortcut in the visual editing mode will open the control panel for the chosen option. [20]
    • Concerning <ref>, footnotes will be automatically included at the end of the message, unless if they are displayed elsewhere in the message by the appropriate template.
  • Flow has been removed from Metawiki. [21]

Future changes

  • The way you switch between wikitext and the visual editors in the desktop view has changed. It will be a drop-down menu. This is the same as in the mobile view. [22]

Collaboration team's newsletter prepared by the Collaboration team and posted by bot • Give feedback • Subscribe or unsubscribe.

17:02, 20 March 2017 (UTC)

We invite you to join the movement strategy conversation (now through April 15)

This message, "We invite you to join the movement strategy conversation (now through April 15)", was sent through multiple channels by Gregory Varnum on 15 and 16 of March 2017 to village pumps, affiliate talk pages, movement mailing lists, and MassMessage groups. A similar message was sent by Nicole Ebber to organized groups and their mailing lists on 15 of March 2017. This version of the message is available for translation and documentation purposes

Dear Wikimedians/Wikipedians:

Today we are starting a broad discussion to define Wikimedia's future role in the world and develop a collaborative strategy to fulfill that role. You are warmly invited to join the conversation.

There are many ways to participate, by joining an existing conversation or starting your own:

Track A (organized groups): Discussions with your affiliate, committee or other organized group (these are groups that support the Wikimedia movement).

Track B (individual contributors): On Meta or your local language or project wiki.

This is the first of three conversations, and it will run between now and April 15. The purpose of cycle 1 is to discuss the future of the movement and generate major themes around potential directions. What do we want to build or achieve together over the next 15 years?

We welcome you, as we create this conversation together, and look forward to broad and diverse participation from all parts of our movement.

Sincerely,

Nicole Ebber (Track A Lead), Jaime Anstee (Track B Lead), & the engagement support teams

05:09, 18 March 2017 (UTC)

I have started a discussion relevant to Wikisource to which I encourage people to add comments, especially regarding the value and impact behind integration of Wikisource with Wikidata, Wikipedia, and Libraries. --EncycloPetey (talk) 16:52, 18 March 2017 (UTC)
@EncycloPetey: Thanks for that.
I've also created a local page for this at Wikisource:Wikimedia Strategy 2017, if anyone would prefer to participate here instead of on Metawiki. Please let your fellow editors know, in the optimum locations for you. Looking forward to your input! :) Quiddity (WMF) (talk) 01:04, 22 March 2017 (UTC)

Tech News: 2017-12

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

  • The Save page button now says Publish page or Publish changes on the Wikimedia wikis except for Wikipedias and Wikinewses. This change will come to Wikipedias later. The point is to make it more clear that the edit will change the page immediately. Publish page is when you save a new page and Publish changes when you edit an existing page. [23]
  • DMOZ no longer works. Templates that use DMOZ can be redirected to archive.org or another mirror. DMOZ has been removed from the RelatedSites extension on Wikivoyage. [24]
  • You can see monthly page views when you click on Page information in the sidebar. Developers can also get monthly page views through the API. [25]
  • The Linter extension is now on smaller Wikimedia wikis. It helps editors find some wikitext errors so they can be fixed. It will come to other Wikimedia wikis later. The extension will be able to find more errors later. [26]
  •   The MediaWiki-Vagrant portable development environment has been updated to use Debian Jessie. This means local development and testing will be more like on the majority of Wikimedia production servers. [27]

Problems

  • On 15 March some interwiki links to other languages were not correctly sorted. This has been fixed. If you still see pages where the interwiki links are not sorted as they should be, they should be fixed automatically with time or you can edit the page and save it without changing anything. If this doesn't work, please report it. [28]

Changes this week

  • When you edit with the visual editor, you will be able to switch the direction you write in from right-to-left to left-to-right as you are editing. This is especially important for editors who edit in languages that write from right to left. You can do this with a tool in the editing menu. You can also use the keyboard shortcut Ctrl+Shift+X on PCs or Cmd+Shift+X on Macs. [29]
  •   The new version of MediaWiki will be on test wikis and MediaWiki.org from 21 March. It will be on non-Wikipedia wikis and some Wikipedias from 22 March. It will be on all wikis from 23 March (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 at 19:00 (UTC). See how to join.

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

22:03, 20 March 2017 (UTC)

publish may work for wikisource communities, but i can imagine the community pushback on wikipedias. maybe an opt out? or change for VE and not wikitext? Slowking4 ‽ SvG's revenge 22:24, 21 March 2017 (UTC)

Typo words.

Hi,

Can I ask that if you find a word that looks like a scan/typing error to list it and the Page it appears in here User:ShakespeareFan00/Typo words, so I can use a regexp to find and fix them? Thanks. ShakespeareFan00 (talk) 12:39, 21 March 2017 (UTC)

It is all a bit tentative but may I suggest you liase with either da capo or da boss regarding outline of potential solution (or equivalent as I am no longer active)? Might be relevant. (ex-AuFCL) 03:11, 23 March 2017 (UTC)

Portal:War poetry cleanup

Before I have at it, I'm seeking permission to clean up the "Individual poems" section of Portal:War poetry > World War One poetry. To list all WW1 poems available at Wikisource would be "too much." Therefore, if a poem currently listed is contained within one of the Collections listed, I would remove it from the list. Otherwise, an incomplete listing such as we currently have seems pointless to me. Any suggestions would be appreciated. Just thought I'd tidy things up in light of the 100th anniversary of American involvement in the War. Thanks, Londonjackbooks (talk) 21:32, 22 March 2017 (UTC)

user:AdamBMorgan? thoughts? a subpage for loose would be a compromise. Slowking4 ‽ SvG's revenge 02:42, 23 March 2017 (UTC)
I believe AdamBMorgan is gone for a time, unfortunately. They would have been my go-to person... I will go ahead with some adjustments, and will keep in mind the words of Florence Earle Coates, to "Take not away what thou canst not restore!" Input is still welcomed! Thanks, Londonjackbooks (talk) 00:04, 24 March 2017 (UTC)

Template:...

This template states "The existence of this template has not been discussed, and the consequences have not been examined, usage is not recommended." Let's discuss and examine so that we can use, modify, or remove the template :)

The benefit I see to the current template usage (spaced dots) is simply that it spaces the dots nicely. In particular, it works well in cases where there are four dots, i.e. an ellipsis and an extra period; it then spaces them out nicely, like this. . . .

The downside is, of course, that an actual ellipsis may be preferred typography in all cases. In that case, I would support modifying {{...}} to simply place an ellipsis, and it could be used for ease of typing. —Beleg Tâl (talk) 14:00, 23 March 2017 (UTC)

I strongly and violently oppose the proposal to disfigure thousands of pages with artificially compressed ellipses. This is about more than typography and ease of editing, but also about context, rhythm, and communication. An ellipsis used simply to indicate omitted text can be compressed, certainly, but the spacing of dots in dialogue is often intended to communicate pauses of varying lengths. In this instance, the typography communicated through intervening spaces is used to indicate a longer or shorter duration of pause. Eliminating this feature from Wikisource mars the original text. The spacing of periods are also used in reconstruction of documents to indicate a lacuna in the surviving copy. The spacing and number of the dots indicates the size of the lacuna. A similar effect occurs in poetry, where the spacing and number of dots are used to visually align or space sections of text. So, claiming that the only benefit is that the template merely "spaces the dots nicely", is an empty argument that fails to account for all the various reasons that printers have used for the spacing or dots in text. --EncycloPetey (talk) 14:27, 23 March 2017 (UTC)
{{...}} doesn't currently support variable spacing and number of dots, so I think that's a little beyond the scope of the discussion, though we could of course modify the template to support some of that functionality. It's my understanding that the template is currently only used as a more aesthetic alternative where a regular ellipsis would still be appropriate. Do you have any examples to the contrary? or examples of situations where {{...}} would be appropriate, but &hellip; would not? —Beleg Tâl (talk) 15:11, 23 March 2017 (UTC)
And, of course, on researching into even my own usage of this template, I find I am completely wrong . . . . . my apologies. So: what would you say to the use of the template in cases where a regular ellipsis is appropriate? —Beleg Tâl (talk) 15:16, 23 March 2017 (UTC)
Per our Style Guide, we prefer regular ellipsis of omission as a character by default, but even the Style Guide allows that there are situations where another option is permitted. I have given examples of situations which I believe can warrant doing things differently. But when there is no need to use this template, then it should not be used. My editing style is that I prefer not to use a template at all unless either (a) a template is necessary to produce the desired result, (b) a template makes the coding much easier than without it, or (c) the template makes the document easier to adjust later should the need arise. Others may feel differently. --EncycloPetey (talk) 20:07, 23 March 2017 (UTC)

Index:The Bab Ballads.djvu

is currently the featured text. However I have found a large number of pages with errors: of the 88 I have cursorily checked so far, 32 have had at least one error, often more. That's 36%. If anyone else would help me clean up the rest I'd be grateful. (See related changes to see which ranges I have checked.) Thank you, BethNaught (talk) 15:56, 23 March 2017 (UTC)

Never mind. A hundred total edits and I've skimmed it all myself. BethNaught (talk) 20:25, 23 March 2017 (UTC)

Tech News: 2017-13

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

  • When you edit with the visual editor, you can see a visual diff as well as a wikitext diff when you review your changes. [30]

Problems

  • Special:AllPages was disabled for two days due to some performance issues. It is back, but the filter for redirects is gone as the cause of the performance problem. It still needs to be fixed. [31][32]

Changes this week

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

14:46, 27 March 2017 (UTC)

The Subjection of Women by J. S. Mill

We currently have an unsourced, non-scan-backed copy of this work. However I have almost finished proofreading this scan. Given the current copy is unsourced, could I overwrite it, or should I create a versions page?

There was a similar situation re. Pollyanna, where overwriting happened. This case is different in that there is no source, but in Billinghurst's words, "Until we have a firm statement and guidance in the deletion policy, I will seek the community's opinion where I come across these examples." BethNaught (talk) 19:30, 26 March 2017 (UTC)

How certain are you that it is/isn't the same version? That's generally the deciding question. If there's no indication of what version they are, a direct comparison of text is necessary. —Beleg Tâl (talk) 21:17, 26 March 2017 (UTC)
Yeah, we are looking for edition differences, often it will be British vs. American, in the editing. Does Special:ComparePages help? Which edition have you transcribed? — billinghurst sDrewth 21:58, 26 March 2017 (UTC)
It's London, 1869, which makes it first edition or a reprint thereof AFAICT. The IA metadata claims the scan is the author's presentation copy, although I don't know how much I believe that. The side-by-side comparison is here: our current mainspace text, as opposed to the scan, appears to: a) have many scannos, b) correct a couple of typos in the scanned text, c) consistently change -ize spellings to -ise. Would that indicate an American edition for the period in question? I can't easily see any place where major revision has happened, although I might have missed something due to paragraphing errors. (Thanks for the tip about ComparePages, I didn't know about that.) BethNaught (talk) 22:28, 26 March 2017 (UTC)
Thanks for the comparison. Looking at the comparison my opinion is to kill the old work, whether it is a different version or not as it would seem to be a significantly inferior quality transcription, and without the ability to check the transcription against the source, I propose that the scanned-backed text take its place. @BethNaught: lovely work as always! — billinghurst sDrewth 00:13, 27 March 2017 (UTC)
OK then, if nobody objects I'll do the replacement probably tomorrow. Thanks for the input. BethNaught (talk) 17:56, 27 March 2017 (UTC)
  Done BethNaught (talk) 18:40, 28 March 2017 (UTC)

Upcoming changes

There are a lot of small changes happening in the next couple of weeks, and I wanted to give you all a quick heads-up about them. Please share this information with other people/languages/projects that will be interested:

  • There's a change to how columns in reference lists are handled, at the request of the German Wikipedia. This change will improve accessibility by automatically formatting long lists of <ref>s into columns, based on each reader's screen width. (It has no effect when the references list contains fewer than 10 refs.)
    • What you need to do: Nothing visible is happening now. If your project uses the normal <references /> tag (or doesn't really use refs at all), then file a Phabricator task or just tell me, and I'll get your wiki on the list for the next config change. If your project uses a "reflist" template to create columns, then please consider deprecating it, or update the template to work with the new feature.
    • I have a few worries about this for the Wikisources. I don't know how the different Wikisources are formatting columns of footnotes in sources. I also don't whether you'll decide, in the case of a narrow printed source being reproduced on a wide computer screen, that it's better to to maintain the narrow columns of the original (which could mean many narrow columns vs two narrow columns in the original) or the number of columns in the original (which could mean two wide columns rather than many narrow ones). So I'd particularly like to hear from each of the Wikisources about whether this should be enabled on each one. If this feature is really going to break things, then we probably shouldn't enable it here.
  • The label on the "Save changes" button will change on most projects tomorrow (Wednesday) to say "Publish page". This has been discussed for years, is supported by user research, and is meant to be clearer for new contributors. (Most of us who have been editing for years don't even look at the button any more, and we all already know that all of our changes can be seen by anyone on the internet, so this doesn't really affect us.)
    • If you have questions or encounter problems (e.g., a bad translation, problems fixing the documentation, etc.), then please tell me as soon as possible.
    • When we split "Save page" into "Save page" and "Save changes" last August, a couple of communities wondered whether a local label would be possible. (For example, someone at the English Wikipedia asked if different namespaces could have different labels [answer: not technically possible], and the Chinese Wikipedia has some extra language on their "Save page" button; I think it's about the importance of previewing.) Whether the Legal team can agree to a change may depend upon the language/country involved, so please ask me first if you have any questions.
  • As part of the ongoing, years-long user-interface standardization project, the color and shape of the "Save changes" (or now "Publish page"), "Show preview" and "Show changes" buttons on some desktop wikitext editors will change. The buttons will be bigger and easier to find, and the "Save" button will be bright blue. (phab:T111088) Unfortunately, it is not technically possible to completely override this change and restore the appearance of the old buttons for either your account or an entire site.
  • Do you all remember last April, when nobody could edit for about 30 minutes twice, because of some work that Technical Ops was doing on the servers? The same kind of planned maintenance is happening again. It's currently scheduled for Wednesday, April 19th and Wednesday, May 3rd. The time of day is unknown, but it will probably afternoon in Europe and morning in North America. This will be announced repeatedly, but please mark your calendars now.

That's everything on my mind at the moment, but I may have forgotten something. If you have questions (about this or any other WMF work), then please {{ping}} me, and I'll see what I can find out for you. Thanks, Whatamidoing (WMF) (talk) 19:01, 13 March 2017 (UTC)

The time for the server switch project has been confirmed. All of the wikis will be in read-only mode for 20 to 30 minutes on two days soon:
  • Wednesday, 19 April 2017, starting at 14:00 UTC
  • Wednesday, 3 May 2017 (two weeks later), starting at 14:00 UTC
If you are a MediaWiki hacker, then please note that the normal deployment schedule has been canceled during both of those weeks.
There is more information at m:Tech/Server switch 2017, including a link to the official schedule. Please leave a message on my user talk page or "ping" me if you have any questions. Whatamidoing (WMF) (talk) 22:05, 29 March 2017 (UTC)

Use Web Fonts to improve {{cursive}}

I frequently use {{cursive}} for handwritten portions of a text (e.g. signatures), and occasionally for fully-handwritten texts such as letters. However, the default font on most browsers on Windows for cursive is Comic Sans, which looks nothing like any of the scripts used in any of the texts. Since we can use Web Fonts to provide a consistent view, I propose that we look for an easy to read, compatibly licensed script font that can be added to Web Fonts and used in {{cursive}} to improve the appearance of handwritten documents. —Beleg Tâl (talk) 21:24, 2 March 2017 (UTC)

@Beleg Tâl: We can use a combination of Web Fonts, <span style="font:XXX"> in the template itself, and changes to MediaWiki:Common.css to fix this. Additionally, individually users can change their own CSS settings in MediaWiki and their browsers. —Justin (koavf)❤T☮C☺M☯ 21:45, 2 March 2017 (UTC)
Updating MediaWiki:Common.css would be preferable, but I don't know whether Web Fonts can be used that way, and I also don't know if a better font than Comic Sans can be reliably found on all users' systems. —Beleg Tâl (talk) 21:48, 2 March 2017 (UTC)
@Beleg Tâl: In case I wasn't clear, we can use all of those options. If we change the global CSS, the CSS in the template, add in Web Fonts, and individual users change their settings on-wiki and in-browser, then that will give a large likelihood that they won't see Comic Sans (unless they deliberately choose it). —Justin (koavf)❤T☮C☺M☯ 22:03, 2 March 2017 (UTC)
We do have template:ULS though you will just have to find the right webfont that is within ULS. I have a list from ages ago, though nothing definitive. Have you looked through mw:Universal Language Selector or asked there? — billinghurst sDrewth 10:34, 14 March 2017 (UTC)
@Billinghurst: that is exactly what I'm suggesting. They don't have any cursive fonts, so we will first need to find a good one and have it added to Web Fonts (which is what ULS uses). —Beleg Tâl (talk) 11:56, 14 March 2017 (UTC)
Okay, what do we think of Petit Formal Script? It's a Google font, licensed under the SIL Open Font License, looks pretty good in a wall of text, and is pretty easy to read. —Beleg Tâl (talk) 20:28, 21 March 2017 (UTC)
Possibly. What about [33], or even [34], which looks much more like the Copperplate style penmanship I usually see. --EncycloPetey (talk) 20:36, 21 March 2017 (UTC)
I think Pinyon looks better per se, but it's not as easy to read as body text. Tangerine looks different than normal cursive that I'm used to but is very legible; it doesn't seem to do well at small sizes though. I still think Petit Formal is better for simple legibility, but I think either of those could be excellent alternatives. (It would be nice to see what they all look like side by side in our website's context though.) Here's a comparison of the three fonts in use on Wikisource. —Beleg Tâl (talk) 20:57, 21 March 2017 (UTC)
I agree that Pinyon is the closest of the three to standard copperplate in the minuscules. The swashes on the majuscles are quite spidery and would be difficult at smaller sizes. The numerals in Tangerine are inconsistent with the letters and the changing baseline for them is difficult. The very high ascenders on the minuscles really make this a display font rather than something to use for chunks of text. While the numerals in Petit Formal Script are boring, the font is still legible at smaller sizes (I can read it at 8 point) and the swashes on the majuscles aren't overbearing. If I had to choose one of the three for a general use font I would !vote for Petit Formal Script. If there was a way to restrict the usage of the cursive font to display headings only (minimum size 36 point), then Tangerine would be my preference. Beeswaxcandle (talk) 06:23, 22 March 2017 (UTC)
"Overbearing majuscules"? 60-pound minuscules? Fonts in the gym?!? We are looking at a font that has a point of difference, that then works in all the broadest available uses (sizing, numerals, kerning) though probably not something like extended character set (unless we see that we need equations and translations). If it is a point of difference, one would hope that we would look to restrict use to templates rather than direct use in main ns, so other (mis)uses could be identified and replaced as required. — billinghurst sDrewth 05:50, 27 March 2017 (UTC)
@Koavf: looking over this: it seems to me that there are two options: use inline CSS in the template, or use a class tag in the template and add an entry into Global CSS to style elements in that class. The end result of these is identical, however, and the discussion below on having dedicated separate CSS for templates makes it moot either way. —Beleg Tâl (talk) 17:10, 31 March 2017 (UTC)

Change 'plain sister' to follow edition linkages

Hi all, I'd like to suggest a new feature for the {{plain sister}} template: Module talk:Plain sister#Follow_edition_links Sam Wilson 00:07, 27 March 2017 (UTC)

@Samwilson: I think that we are going to need a higher-level explanation, rather than a technical explanation. At the minute plain sister has numbers of sister link components, through manual linking to the (parent) literary works at the sisters, and automated to the edition data at wikidata through the sister link at WD. What is the expected outcome that you would expect to see in the header at an edition page here? — billinghurst sDrewth 00:19, 27 March 2017 (UTC)

@Billinghurst: Sorry! Yes, good point. :) The problem I'm trying to solve is situations like the following and also similar situations where there are multiple editions of the same work spread over different Wikisources.

Take for example w:The Swiss Family Robinson:

In the current system, the two editions both require wikipedia = The Swiss Family Robinson to be added to their header template, because their Wikidata items do not link to Wikipedia (because only the 'work' item is allowed to do that). In fact, in this example, the second edition doesn't have that, and so its sister links don't currently list Wikipedia at all.

The fix is to use the fact that all editions have a 'edition or translation of' statement that links to the work item: we follow that link, and from there can get the Wikipedia sitelink. This results in e.g. {{plain sister/sandbox|wikidata=Q19100453}} resulting in:

(The wikidata paramter is included here because we're on the Scriptorium and not on the edition's Wikisource page; in actual usage it'd just be {{plain sister}}).

Sam Wilson 01:03, 27 March 2017 (UTC)

I'm not sure we can do that automagically. Yes, every edition will have an 'edition or translation of' statement, but not every edition will have a single value for that property. For instance, Swanwick's translation of Aeschylus' Agamemnon is a translation of Aeschylus' play, but there are four editions of Swanwick's translation. So Swanwick's translation will have a "work" item (without Wikipedia article), which will list the four edition data items, and Aeschylus' play Agamemnon will also have a "work" item with Swanwick's translations listed, and the individual editions of Swanwick will have both "work" items listed, since Wikidata does not distinguish between "edition of" and "translation of". Here's the catch: there is no article about the play Agamemnon on the English Wikipedia: it is included as a section within the larger article about the Oresteia trilogy.
If this case seems complicated, I can suggest ones that will be even worse once Wikidata catches up with its own data structure. --EncycloPetey (talk) 01:49, 27 March 2017 (UTC)
@EncycloPetey: Certainly, I'm sure there are many cases where things will be weird (I think this is called the Bonnie and Clyde problem?), but for those we can always override locally, as we're currently doing. I'm just talking about the situations in which a sitelink does exist on the work item, so we needn't repeat it here.

We could perhaps in the future look at doing more traversals, such as following 'part of' (P361) relationships (which is perhaps what would get us to Oresteia from Swanwick's translation?) But not doing that needn't stop us handling the simpler cases.

Sam Wilson 02:21, 27 March 2017 (UTC)

  •   Comment I will think about this when my brain has some thinking and play time. Now to confuse matters this approach only works well for fiction works, or the rare mega non-fiction works like EB1911 that have articles, but generally not so well for other types of works. All because the relationship between WS and WP and our laissez faire approach.

    Our other, and larger, use case we face is for biographical/encyclopaedic entries. We (perhaps a little naughtily) label as biographical/encyclopaedic articles and not editions at Wikidata, and these need to link back to "main subject", eg. Byron, George Gordon to w:Lord Byron. (If we had a complete biographical work, would we expect it to link back to the article about the book, or the article about the person?) — billinghurst sDrewth 03:56, 27 March 2017 (UTC)

    • All of those can be reasonably easily handled, I think: we'd just define a set of properties that should be followed when looking for a sitelink (and one hasn't been found yet). We could even do it on the next step as well, and get the main subject (or 'part of' or other property) of a work if that work doesn't have a sitelink.

      I don't agree that this only works for fiction works though; it works for anything that has a 'edition or translation of' property. In fact, that's all it works for! :-) I'm trying to keep it simple; we can grow the idea later, if desired.

      One complexity even with this simple case is when there are multiple values for 'edition or translation of'—but we could just list them all. Sam Wilson 04:10, 27 March 2017 (UTC)

You missed the keyword "well" as in works well with. Meaning that the vast majority of our works that have enWP articles and have editions here are primarily fiction works, ie. fiction works tend to get notability in the numbers game rather than non-fiction, so non-fiction books are less likely to have wikipedia articles. Where we have a periodicial article, the periodicial may be listed, however that tends not to cascade down to the article level. — billinghurst sDrewth 05:08, 27 March 2017 (UTC)
@Samwilson: There is another type of situation, where Wikipedia may not have an article on the specific edition or work here, but it has an article on the specific subject. Other than biographies, this is also true about mythological stories (e.g. 1) and fairy tales (e.g. 2). If the story is famous, it will be a part of many collections, in slightly different languages, rendered by different authors. Wikipedia will have a general article on the story in such cases; these need to be linked locally, because linking through Wikidata may not be possible. Hrishikes (talk) 04:13, 27 March 2017 (UTC)
@Hrishikes: good point. Would these be linked with 'main subject'? Actually, it doesn't really matter what the property is, as long as there is some connection to Wikipedia we can just follow it (we have to just define what we consider reasonable linking properties). We'd have to give each chapter in your example its own Wikidata item, but that's a pattern that seems likely to be followed for other things such as journal articles etc. so should be fine. Do you think the base idea here is okay though? That we start by just following 'edition of' properties, where they exist? Sam Wilson 04:20, 27 March 2017 (UTC)
@Samwilson: As I said, one such story will be part of many collections, some of which will be present here. For example, 1 has an image here. So Wikidata will need linking to several chapters of different works. Do you think this kind of thing is feasible? (One Wikipedia article vs. different chapters of different books in multiple language wikisources.) This will come handy for most famous stories of mythological/fairy tale genre. Hrishikes (talk) 04:28, 27 March 2017 (UTC)
@Hrishikes: I think that SW is saying above, 1) let us have a proof of concept, 2) it will have capacity to be expandable as the community considers use cases and sets rules for it to happen. Maybe like a cascading #ifexist hierarchy of links 1st "edition of" < 2nd "main subject" < 3rd ??? — billinghurst sDrewth 05:01, 27 March 2017 (UTC)
@Hrishikes, @Billinghurst: yes, that's about the sum of it! :) And the hierarchy of links is a great way to think about it. My goal with the current proposed change is just to start the journey in a small way, and to get a bit of clarity in our minds (and codes) about this work/edition distinction at Wikidata. (I think it's a pretty fundamental part of the future of bibliographic data on Wikidata, and by extension Wikisource.) I think it'll mean we link more works to their sister project pages, with no extra effort on our part. I'm not seeing any objection (to this specific change); is that right? Sam Wilson 03:13, 31 March 2017 (UTC)
I'm still unclear as to what will happen when an "Edition" is an "edition" of two different data items (e.g. edition of one item and translation of another). --EncycloPetey (talk) 03:36, 31 March 2017 (UTC)
@EncycloPetey: at the moment we do many enWS works to one enWP article, and I would think that the same would continue. As I envisage SW's plan it is to allow direct linking to the corresponding article at enWP by following the WD item and intervening item nodes back through particular Q codes. So this ultimately means we are resolving the enWS to enWP linking automatically. The only time I see we have an issue is if there are two different articles at enWP to which we may link, and nothing springs to mind for me.

While I am saying that I see that the plan as proposed is great for works of fiction (and irrespective of agreeing/disagreeing) SW is saying that his methodology is extensible, and we can work on a plan to look at linking further. This will allows us to map what links can be direct, and the varying paths. This is a first step on this track, there are plenty of further improvements to take for all the xxWSes.

Of course the next story is how do we link from enWP back to enWS, especially if there are multiple items at our end, however, we should separate that as a discussion (to keep this discussion on track). — billinghurst sDrewth 04:26, 31 March 2017 (UTC)

@Billinghurst: Please re-read my question. Your response does not address the issue I raised. It addresses a different issue. --EncycloPetey (talk) 04:38, 31 March 2017 (UTC)
@EncycloPetey: If there is no wikipedia article for which to link it, then we have manual overrides. If there are multiple choices then that is what the cascading criteria does. I had believed that component had been addressed. I think that the discussion on edge cases always need good mapping and problem solving, and getting into that level of detail in a conceptual argument is making for complex discussion in a general forum. I believe that is what is said above about starting the mapping, and this is a starting place. If you are asking me how I saw conceptually we would differentiate between linking to an article of an edition of a work, or link to the literary work itself, my personal opinion would be the lowest factor. How does that work in SW's plan? No idea yet, it will be fun working through such criteria and hopefully no eyeballs will be gouged during that debate. We are so going to need electronic whiteboards!!! — billinghurst sDrewth 06:18, 31 March 2017 (UTC)
@Billinghurst: Again, you have responded, but have not answered the question: "what will happen when an "Edition" is an "edition" of two different data items?" --EncycloPetey (talk) 14:10, 31 March 2017 (UTC)
@EncycloPetey: good point, sorry I do remember now thinking about that but not doing anything! I think we'd want to display all edition site links, but perhaps 'sister links' has too specific a meaning, and what we really want is to display useful interproject links as we've been discussing above. But I shall investigate what happens at Wikidata some more. Sam Wilson 05:19, 31 March 2017 (UTC)
I've attempted to lay out an example of something being an edition of multiple works at d:Wikidata_talk:WikiProject_Books#multi-work.2Fcomposite_editions. Would love some other examples too. Sam Wilson 07:13, 31 March 2017 (UTC)
@Samwilson: See my Euripides / Shelley query there. Wikidata makes no distinction between "edition of" and "translation of", and this is the cause of many problems. --EncycloPetey (talk) 14:13, 31 March 2017 (UTC)

Straw poll: How and where to have lengthy, potentially complex discussions?

It has been a while since this question has been asked, and the community personnel, and somewhat our approaches, have changed in that period since last asked. So I am asking this question to the current community, as the current community needs to have this forum best suit its needs.

Where does the community expect lengthy and potentially lengthy discussions to occur?

  1. Here in Scriptorium? or
  2. As requests for comment in a subpage to Scriptorium, and then linked from here? or even temporarily transcluded here? or
  3. On the talk page to the subject matter with an announcement here of the discussion? Probably with a concluding statements here to the announcement.

Each has its strengths and weaknesses for visibility, participation, and discoverability.

I ask as in more recent times the active discussion on numbers of issues has waned, without any indication of the passive participation, ie. people read and will contribute if they feel strongly one way or the other.

  • If it is noise to this page, then we would shift it.
  • If it is a burden to this page, then we would shift it.
Both of these cases would mean a choice of to where for the discussions.
  • If it is stopping some people from using this page from asking questions, then we can just rejig our communications and again redirect many to the "Help" subpage
  • If the open discussion is neither noise for too many, nor a burden, nor scaring off users, then we can continue as is.

— billinghurst sDrewth 23:01, 29 March 2017 (UTC)

I think the Scriptorium is the best place for it. Moving large discussions to a different page will just lower the amount of eyes on them, and there are few enough eyes as it is. —Beleg Tâl (talk) 13:04, 31 March 2017 (UTC)
seems to be working fine for me. and only one archive to search. but then i have seen way too much forum shopping and micro-voting elsewhere, so i am biased. Slowking4 ‽ SvG's revenge 23:11, 31 March 2017 (UTC)
I think here in Scriptorium is best. I dislike looking through a maze with links ("over here over there")—Maury (talk) 00:57, 2 April 2017 (UTC)
I think the Scriptorium is best, even though I forget sometimes, and post things elsewhere; maybe we can make it a bit more clear somewhere e.g. "all discussion is welcome in the Scriptorium, rather than on individual talk pages". Although, the other thing I'd say is that mw:Flow would be good to have here. It's hard to follow many different discussions sometimes. On a related note, I'd like to see just one discussion page per work (probably on it's mainspace top-level page, and the others redirecting to that one). Sam Wilson 03:14, 2 April 2017 (UTC)

Layout with justified text

Can we have a new default layout available for all users, based on Layout 1 but with justified text? Or maybe modify Layout 1 to have justified text? The current display of Layout 1 (with text just left-aligned) doesn't look very good. Ciridae (talk) 07:09, 27 March 2017 (UTC)

The main objection against justified text seems to be unequal word-spacing; but the serrated right margin of left-aligned text looks more ugly, IMHO. I also work in Bengali Wikisource, where justified text is default, and it looks fine. Here we have justified text in page namespace and left-aligned text in main space by default. I can't fathom the rationale of this dichotomy, especially when print media uses justified text and we are here to recreate printed books in the digital medium. This site advocates against other print layout parameters, like paragraph indenting (being replaced by a blank line between paragraphs) and curly quotes (being absent in the keyboard), but I never found any proper reason against justified text; and there is no written rule against it here, so I use it manually in texts transcluded by me. But default would be better. Hrishikes (talk) 04:53, 1 April 2017 (UTC)
how do you feel about layout 2 or layout 3 or layout 4 or proposed layout. you realize the number scheme is arbitrary, and the last one you choose is default? would you like a user setting or a new layout? Slowking4 ‽ SvG's revenge 01:32, 5 April 2017 (UTC)
I was talking about Layout 1 (left-aligned, full text-area width) with justified text being the primary default, that the users would see, without exercising any layout option. This is the layout of printed books, so that people get exposure to it from childhood. Other layouts have less width; good for sidenotes, but when there are no sidenotes, so much blank space looks odd. Hrishikes (talk) 05:29, 5 April 2017 (UTC)
layouts only recently got fixed after being frozen for a decade Wikisource:Scriptorium/Archives/2014-01#Fixed_page_width. getting a summer of code person to change the "default" may take another decade. i think they view it like VE / wikicode as a setting that you can toggle, not as a default. but hey - go for it. Slowking4 ‽ SvG's revenge 12:13, 7 April 2017 (UTC)
I'd rather see us introduce a new layout or use a toggle, instead of altering the primary default layout for all works. There are too many things that might go wrong. --EncycloPetey (talk) 14:46, 7 April 2017 (UTC)

Proposal: Add Wikidata to Special:Import sources

Tracked in PhabricatorTask T160403Resolved

The following discussion is closed:

consensus to add wikidata to approved list for import — billinghurst sDrewth 11:01, 14 March 2017 (UTC)

As with the recent discussion for imports from mediawiki and update to mul.wikisource, I would like the community to support the addition of Wikidata (d:) as a source for Special:Import. The primary reason for this is to allow administrators to directly update our modules for use of Wikidata. An example is that Module:Wikidata has been announced at d:Wikidata:Project chat as having been updated, and our only means to currently do that is a cut and paste. Cut and paste is less desirable, it adds new editors and doesn't clearly align with other versions which import will better do. Thanks. — billinghurst sDrewth 12:20, 11 February 2017 (UTC)

  Support —Beleg Tâl (talk) 03:17, 12 February 2017 (UTC)
  Support Seems like a no-brainer to me. --Xover (talk) 14:18, 14 February 2017 (UTC)
  Support Sam Wilson 21:20, 14 February 2017 (UTC)
  Support obviously sensible, thanks sDrewth. —Justin (koavf)❤T☮C☺M☯ 21:49, 14 February 2017 (UTC)
Now available for admins. — billinghurst sDrewth 13:51, 15 March 2017 (UTC)

Enough!

I have had it, what seems like it's the logical approach isn't. Short Titles Act 1896/First Schedule/Pre Union

The last attempt to do what was thought to be reasonably standard generated a spurios table end marker |} and I am not prepared to spend yet more endless hours going round and round in circles, because I can't cope with what appear to me to be phase of the moon issues with precisely where wiki markup/LST interact in certain ways.

This has probably already been explained many times previously, so I am not going to get into yet another argument. I am considering marking ALL my efforts on this work for speedy deletion, so that someone that is actually competent with where depending on the phase of the moon specfic syntax has to go has a clean start unencumbered by previous attempts at half baked 'fixes'.

I appreciate that this may seem like you seeing me in the middle of a burnout, but having put a lot of effort into trying to get something working, I am really frustrated when making what should be a simple simplification or change brings down the entire edifice.

This isn't the only work affected. I may be considering asking for deletion of other efforts that use overly complex templates as well. ShakespeareFan00 (talk) 18:17, 1 March 2017 (UTC)

@ShakespeareFan00: If it's any consolation, I feel your frustration and I really value all you add to WMF projects. —Justin (koavf)❤T☮C☺M☯ 21:00, 1 March 2017 (UTC)
Decided to take a break, and put my brain under a cold tap... The relevant fix was found... Sometimes it's better to stand well back from exploding contributors (sigh).ShakespeareFan00 (talk) 21:27, 1 March 2017 (UTC)
If you see a spurious |} it will either be due to there being two, so one is seen as raw text, or that it isn't seen as starting on a new line. — billinghurst sDrewth 01:51, 2 March 2017 (UTC)
and I usually find that it is not lunar phases when it happens to me, but the input at keyboard end. I can usually work it out when I have the code in front of me, though when you have to go through complex code in templates, it is a nightmare. Use Wikisource:Sandbox and simplify and test in parts. While sometimes it is quirks of references, or tags, it is usually me. Identify the signs and remember first principles. — billinghurst sDrewth 01:57, 2 March 2017 (UTC)
Well perhaps you can explain in simple terms why the technique used here Page:Chronological_Table_and_Index_of_the_Statutes.djvu/29 when implemented in like fashion here Page:Public General Statutes 1896.djvu/34 generates 2 different outcomes? We've had the same discussion about precisely how Mediawiki handles {{nop}}, table synatx at least twice previously, with no conclusive long-term fix to the issue being forthcoming. Why is it such a chore to have what should be near identical techniques work consistently when the SAME technique is applied in different content? (Sigh.) ShakespeareFan00 (talk) 15:32, 2 March 2017 (UTC)
No, I will not. You got yourself into that trouble with non-standard, overly complex templates. Expecting people to bale you out on a regular basis is not reasonable. There will be a coding error or difference there somewhere, you just haven't found it. Your total attention to detail is often not there, whether it be proofreading or templates. I simply do not have the time nor the patience to dig through crud like this.

We don't get into this sort of pickle as we don't go for overly complex, error-prone templates, we keep it simpler. — billinghurst sDrewth 22:44, 2 March 2017 (UTC)

Harsh, but fair.. and as it's unreasonable to expect anyone else to care deletion of anything using the overly complex templates (up to annd including my entire 8 years worth of effort) may be the simplest option. Having reached the limits of my own confidence, patience and expertise, it's perhaps time to just stop contributing altogether? I don't hold anyone else responsible for this at present, but will consider further disscusion pointless. It's a shame that I seem to have wasted my efforts, trying to make this project better, and that you've had to witness a rather public meltdown. As I was saying the other day, I blew it :(

ShakespeareFan00 (talk) 02:16, 3 March 2017 (UTC)

The current "fix" seems to be do with some very precise positioning of line-feed/carriage returns and in forcing additional nops on every template call, which seems like overkill to me. If someone is willing to loose their sanity reducing the templates concerned to the absolute minimum needed to get them working, I'd appreciate the attempt.ShakespeareFan00 (talk) 15:46, 2 March 2017 (UTC)
Second concern (as indicated previously), even when {{nop}} is implemented on the pages (and for each row of the table) an assembled page like - Short Titles Act 1896/First Schedule/6 Ann still apparently needs a convoluted template like {{table-page}}. That it works at all is a miracle. (sigh)ShakespeareFan00 (talk) 16:09, 2 March 2017 (UTC)
At the very least it would be nice to have documented somewhere (not by reading the source code directly), how LST/mediawiki/table is 'wrapping' what it thinks it's rendering, so that the quirks of it all can be better understood.

ShakespeareFan00 (talk) 16:14, 2 March 2017 (UTC)

And also today when I decided to when I decided to work on this Index:Chronological Table and Index of the Statutes.djvu, by reformatting the index using TOCstyle, yet more issues (albiet my own fault due to the precise paramaters calling that template needs.) when trying to input all the relevant formatting. When something is too complex for normal users to use without additional tools (like enhanced editors and so on), a fundamental rethink of certain assumptions are needed on the part of the entire community. Sadly I don't see solutions like Visual Editor being ready for Wikisource use any time before the next ice age...

ShakespeareFan00 (talk) 20:47, 2 March 2017 (UTC)

I do think there is a lot of template bloat when it comes to tables. I prefer to stick with the default syntax, {{ts}}, and a few basic special cases ({{multicol}} and {{TOC begin}} and related). I find it is generally a waste of time to try to get a giant uber-complex template to work in all cases. —Beleg Tâl (talk) 21:04, 2 March 2017 (UTC)
while i in general like the look and feel of the customization that we can do, after a certain point i have to weigh the effort versus effect. if it truly is enough for you now, then maybe it is a good time to reassess or reconsider the choices that led you here. and then adjust them a little so that your productivity / mental health is greater, even if you had to make an aesthetic compromise. if you want to establish a MOS about certain cases, set it up in user space, and we can brainstorm and have a SOP going forward. Slowking4 ‽ SvG's revenge 23:23, 3 March 2017 (UTC)

Index:Acts of the Constituent Assembly of India 1949.djvu

Transcribed the contents list in good faith, but the source file was re-aligned.

Page text for what should be page 4, is currently on page 5 Page text for what should be page 5, is currently on page 7

Pages 6 and 8 should be reset to the OCR text. Thanks. ShakespeareFan00 (talk) 09:06, 9 March 2017 (UTC)

Looks to be resolved — billinghurst sDrewth 09:30, 14 April 2017 (UTC)
This section was archived on a request by: — billinghurst sDrewth 09:30, 14 April 2017 (UTC)

Testing out the Timeless skin

Hi, I'm Isarra, a volunteer MediaWiki developer, and I've been working on a new responsive skin, Timeless, and I was wondering if you would be interested in having it deployed on your project to try it out.

It looks like this:

 

Some links:

  • A labs project for general testing and editing
  • A Beta Cluster clone of the Simple English Wikipedia, where Timeless is already deployed - you can create an account and in your preferences set your skin to Timeless and explore what it would be like on a real project
  • A grant proposal regarding doing proper research into usage of and problems associated with the current skins, and from there doing further development of Timeless to make it properly address the needs of the various Wikimedia projects

Timeless is currently undergoing review and I have a grant proposal in the works to do further work on it (see just above; any feedback on that would also be appreciated), but the end goal here is to, if not develop Timeless itself into a viable skin for all Wikimedia projects, then determine what exactly would be required of such a skin so that one may eventually be created.

I'm reaching out to you in particular because Wikisource has use cases that are very likely to totally break Timeless (and most skins), and I would very much like to see how so that this may actually be properly addressed. If there are also problems you are currently having with the existing skins that we might be able to look into, that would also be something I'd be interested in, but either way the very nature of your project would make your feedback invaluable moving forward.

So the question is, do you want to take part in this? Would you be willing to help me test out Timeless? -— Isarra ༆ 03:50, 27 March 2017 (UTC)

@Isarra: (off the top of my head) I think that a little technical detail is required for the community to consider. Please correct or expand on the following 1) this is just the skin, there are no functionality changes; 2) Means of implementation, ie. an extra skin will be added to user preferences, that will be "off" by default, and users can turn "on" to trial; 3) What period of testing would you expect to take place? How would you seek feedback on the functionality and tests; 4) What specific things should be tested, eg. a) Extension:ProofreadPage is a major part of our config; b) what toolbar changes might we expect as these are adapted by users, c) sidebar changes expected would be ...? 5) If it is not working for a user, would it be as simple as changing back to the other skin. — billinghurst sDrewth 04:42, 27 March 2017 (UTC)

Addendum. Some of us (dinosaurs) still use monobook as vector didn't suit, so you will see monobook customisations still existing in Mediawiki: ns; and some of still use the old toolbar as it is easier to code adaptations, whereas the new toolbar is an extra level of complexity. — billinghurst sDrewth 04:49, 27 March 2017 (UTC)
Do you mean the old edit toolbar? Or the action links at the top of the page? -— Isarra ༆ 05:04, 27 March 2017 (UTC)
mediawiki.toolbar with additional mw-customeditbuttons, rather than the enhanced toolbar. — billinghurst sDrewth 05:25, 27 March 2017 (UTC)
Yes, yes, and I'm not entirely sure yet, but setting up a project page here for it would probably make the most sense, or whatever you're comfortable with - it'd be great if you could just file the bugs directly, but I get that that would probably be a bit much to ask. As for what specific things you should be testing, I don't know - that's why I want you to try it. I often find the best thing for testing a skin is just use it - see what happens, what's annoying, what needs to be changed.
ProofreadPage is actually why I wanted Wikisource involved - I fully expect it to not really work, and obviously we need it to. And I doubt it's the only thing unique to the project, either.
Sidebar... mostly it's the same - other languages and toolboxes get moved around depending on screen size, but the actual content is the same as other skins, whatever you put in MediaWiki:Sidebar. What all changes do wind up happening may also depend a lot on user feedback - if a toolbox location/split is bad, that will be addressed, things like that.
And yes, if you don't like it, you'll be able to just switch back to a different skin, same as you switched to it. And that's totally fine. -— Isarra ༆ 05:03, 27 March 2017 (UTC)
All those responses sound reassuring as users can dip in and out as going about their daily/weekly tasks.

Either setting up a subpage of Scriptorium, or a project page for feedback both sound fine (guided by others feedback, and it may be something that we should flag to the broader WS community about how we compile feedback @Zyephyrus, @Micru, @Ankry, @Yann, @Aubrey, @Tpt, @VIGNERON:). Many of us are basic phabricator: literate, so we could transfer confirmed issues if you have a phab project set up, and we can create a direct link on a page for reporting anyway (and encouraging more users to have that phab familiarity is beneficial). — billinghurst sDrewth 05:27, 27 March 2017 (UTC)

There is indeed a Timeless project on Phabricator: https://phabricator.wikimedia.org/project/board/1912/ Dereckson (talk) 15:21, 27 March 2017 (UTC)
Ah, that's excellent to hear. See. You know. Also, just as a general note, a lot of the specific work I intend to do does hinge a bit [[[meta:Grants:IdeaLab/Timeless|on the grant]], so if you have specific issues you want to raise there (either with things currently that you'd like to see improved upon, or concerns with Timeless itself), that would be incredibly useful, both for showing general interest and helping to shape the direction of my work. Thanks! -— Isarra ༆ 13:15, 28 March 2017 (UTC)
Proposing to close this as accepting the offer to participate in the evaluation. I am not seeing any dissension, though throwing a last ping to the community. — billinghurst sDrewth 13:54, 3 April 2017 (UTC)
Sounds good to me. Sam Wilson 22:45, 3 April 2017 (UTC)
Tracked in PhabricatorTask T162137
I would suggest that the feedback be tracked in a separate section in general discussion, rather than up here in proposals. — billinghurst sDrewth 12:51, 4 April 2017 (UTC)
nice refresh of skins. good for readers. wikisource specific issues may be the Display options layout, and the Sidebar Flat-list gadget. Slowking4 ‽ SvG's revenge 14:54, 4 April 2017 (UTC)
Nope, at this point we're mostly just waiting on some compatibility fixes (with other extensions, where the problem is in the extensions, not even the skin itself), I think. I should probably... make sure of that, though. But you guys are good, at least. -— Isarra ༆ 04:00, 27 April 2017 (UTC)

commons:File:Don_Caesar_de_Bazan.djvu

I've erroneously included the google first page boilerplate. Could someone please excise that page for me? Thank you. LeadSongDog (talk) 21:02, 27 March 2017 (UTC)

@LeadSongDog, @Mpaa: we are currently building a tool to do that. — billinghurst sDrewth 00:13, 28 March 2017 (UTC)
@LeadSongDog, @Billinghurst: I've removed the cover page. And it looks rather likely that we could use the same system as the Indic language OCR (Google's Cloud Vision API) to determine whether a Google cover page exists or not. I've not yet done much testing, but it might be better than the currently manual selection of the cover page in IA Upload. Although, we wouldn't want it deleting the wrong thing! Sam Wilson 00:46, 28 March 2017 (UTC)
Thank you both. Just a thought, but don't these cover pages have some common features that could be simply tested for, such as the google url in the OCR'd text? That obviously should not be in any book we'd want to upload. Another option would be to give the human user a preview the first page before uploading the rest. LeadSongDog (talk) 15:49, 28 March 2017 (UTC)
@LeadSongDog: The ia-upload tool does give users a preview of the first page, and allows them to remove it. I thought you meant an easier system than that one. For an automated system, you're right it isn't too hard to at least attempt to determine if there's a Google logo, but we don't know how many false positives we'd get. Sam Wilson 00:35, 29 March 2017 (UTC)
This section was archived on a request by: — Mpaa (talk) 19:41, 28 April 2017 (UTC)

Task proposal for Wikisource-bot

I have prepared a script that can run on toollabs to replace the 'Google' page in djvu files (no pdf). The idea is as follows:

  1. tag an Index page with a template (to be defined), e.g. something like {{blank_djvu_cover}}.
  2. with the frequency we decide, the bot will modify and upload the corresponding djvu file, and blank the first Page:..../1 as 'Without text'
  3. the file will be updated locally, if not shared on Commons, or on Commons directly.

If you agree with the approach, I can take care of the above and I can first run a few tests offline as soon as taggings are done, and later on make the tool tun on tool-labs.

An item that is up for deeper discussion could be if we want the bot also to delete (only) the first page instead blanking it, specifying it via template parameter. We could limit this option for Indexes w/o pages in Page: ns, or apply it to all Indexes. In the latter case, user who tags the Index must be aware that it is up to him to make sure that the action is consistent with Index status, effects on page numbering etc.

Comments welcome.— Mpaa (talk) 20:11, 5 March 2017 (UTC)

I rather like this idea, but I have two questions:
  1. How often would this bot run this task? On demand, or would it be a scheduled daily/weekly/whatever thing?
  2. I don't entirely understand the reason for point #3, keeping the modified file local. Other than the difficulty/overhead of getting bot permissions against Commons as well as enWS, why would we want to start double-hosting Commons works at enWS?
--Mukkakukaku (talk) 22:41, 12 March 2017 (UTC)
Oops apologies Mpaa, I missed this. I would like to see the test occur. I (still) do not favour deletion of the page to shorten the file, just replacement of image and text.

To Mukkakukaku. This is the proof of concept. Talking about scheduling can follow, gut feel is check daily. Whether to move a file to Commons is not solely the Google cover page, it still needs to fit within scope at Commons, have the templates completed, etc. Moving them is not overly complex with aCommonsHelper@toollabs, or a tool like ForTheCommonGood.

Operationally, I have one to test File:Love Insurance - Earl Biggers (1914).djvu which was deleted at Commons due to this issue. One think that we should consider is categorise as having been done. That will allow us to review more easily and a touchpoint on whether to move to Commons. — billinghurst sDrewth 00:10, 13 March 2017 (UTC)

Clarification on point #3. I meant that the tagging will be done on the Index page here on WS, while the file will be updated where it is actually located.— Mpaa (talk) 18:37, 13 March 2017 (UTC)
For now, you can tag using {{User:Mpaa/x}}. I created Category:Djvu files requiring clean up and Category:Djvu files processed by wikisource-bot to follow up.
For now only first page blanking is allowed.— Mpaa (talk) 21:15, 13 March 2017 (UTC)
Is this for files that we already host? The IA Upload tool has been updated recently to allow uploaders to strip the Google page out.

For files that have not yet been started, then I favour deletion of the page, because it restores the correct right/left pagination. If proofreading is underway, then blanking is possibly the better option due to the tangle of page moves required in the Page: namespace. Beeswaxcandle (talk) 06:27, 14 March 2017 (UTC)

If it hasn't been started and it is via ia-upload, just upload the file again and strip the lead page. — billinghurst sDrewth 10:38, 14 March 2017 (UTC)
If someone could tag some images, I could test a bit more.— Mpaa (talk) 20:36, 23 March 2017 (UTC)
@Mpaa: pretty hard to find local copies of Google files with header sheets. I can find numbers at Commons, but limiting searches to local uploads ... meh! We can trial some standard files and just revert them if you need targets OR we can look to do some runs at Commons. I favour the second, and happy to run the gauntlet if necessary. — billinghurst sDrewth 06:12, 27 March 2017 (UTC)
It is OK to work at commons. If you can find some, I can run a few as Mpaa. If it is OK, the we can take the next step as ws-bot. Need to create {{Mpaa/something}} or {{ws-bot/something}}} there. What about categorisation? Still needed at Commons?--Mpaa (talk) 21:04, 27 March 2017 (UTC)
@Mpaa:I don't see the need for categorisation afterwards, though there may be some value for before, especially if the bot stops working. I think that we will need an explanation page (could be on category page), and a template, maybe {{google front page}}. Hmm, does it work for pdf and djvu, or did we just do djvu? If the latter, we may wish to be more specific with template name to avoid confusion.

... a selection needing doing and most, if not all, will be at Commons.

Djvu only.— Mpaa (talk) 18:41, 29 March 2017 (UTC)
Building list at User:Wikisource-bot/Lead google page — billinghurst sDrewth 08:02, 25 April 2017 (UTC)
@Mpaa: Did you run further tests at Commons? Is there something that needs to be undertaken there? We now right here? — billinghurst sDrewth 13:08, 4 May 2017 (UTC)
FYI, I have put this on hold for now as I am not able to follow this up as I would like. I will notify if/when I will resume this proposal.
Retrieved from "https://en.wikisource.org/w/index.php?title=Wikisource:Scriptorium/Archives/2017-03&oldid=11481771"