Wikisource:Scriptorium/Archives/2016-01

Other discussions

"Proofreading" toolbar not appearing

Tracked in PhabricatorTask T119324

This is what I see - File:WStoolbar.jpg, the proofreading section of the toolbar is NOT displaying. What changed recently? ShakespeareFan00 (talk) 11:46, 25 November 2015 (UTC)

I've narrowed this down to the OCR option in the Gadgets. Can someone please check for an interaction problem? ShakespeareFan00 (talk) 11:52, 25 November 2015 (UTC)

The same issue is affecting the Dutch Wikisource. I'm currently investigating on it. Tpt (talk) 15:17, 25 November 2015 (UTC)

Enabling or disabling the OCR button-gadget made no difference for me. I'm seeing the same behavior here on en.WS as I described in the Phab: ticket opened earlier. -- George Orwell III (talk) 23:42, 27 November 2015 (UTC)

Other changes have unfortunately popped up as well. The character insertion table no longer resides above both the editing window and source text in the edit window. It now appears only above the editing window, and below the header window. GRRRR. --EncycloPetey (talk) 16:40, 25 November 2015 (UTC)

In the Dutch Wikisource the toolbar is there every now and then (I am using Google-Chrome). After pushing the 'Show Preview' button it will appear.WeeJeeVee (talk) 14:14, 30 November 2015 (UTC)

Amended I have this same problem when editing at home (Mac OS; Firefox) sometimes, and sometimes at work (Windows; Firefox). That is, I sometimes have the usual tools, including the ability to zoom in on a page from the source file, but sometimes I see the same curtailed toolbar shown in the link above, and cannot zoom in. It is not the same from edit to edit, and I can see no pattern, nor find any way to reliably access the full set of tools. This is a real pain for me when working with small two-column text when I am trying to read Greek diacriticals. --EncycloPetey (talk) 05:45, 4 December 2015 (UTC)

This is really a nasty problem. For me only a very few times the "complete" toolbar appears. Most of the time I lack the "Proofread Tools". And I don't know how to get it. This makes it impossible to switch to the horizontal view (for instance). It would be great if this could be tackled! --Dick Bos (talk) 19:39, 4 December 2015 (UTC)

Daily testing for this shows that it is happening here more & more as well and am actively trying to nail down a cause or the causes as time permits. In the meantime, the only thing I can recommend trying that seems to rectify things is -- if one "lands" on a non-existant page and the edit session generates a less-than-full toolbar, hit the "edit" tab once again before you actually begin editing. -- George Orwell III (talk) 23:15, 4 December 2015 (UTC)

I have tried this, and most of the time, there is no change, which is unfortunate. Thanks for looking into this. --EncycloPetey (talk) 23:39, 4 December 2015 (UTC)

To me, it looks like the problem on en-wikisource is solved since two days or so. Most of the time (but still not always!) the large toolbar appears. I'm really glad. But on the Dutch wikisource the problem is still there. --Dick Bos (talk) 18:25, 12 December 2015 (UTC)

this problem is currently happening for me. Slowking4♡RAN's revenge 16:04, 25 December 2015 (UTC)

Community Wishlist Survey - Phase 2

Hi everyone!

We're beginning the second part of the Community Tech team's Community Wishlist Survey, and we're inviting all active contributors to vote on the proposals that have been submitted.

Thanks to you and other Wikimedia contributors, 111 proposals were submitted to the team. We've split the proposals into categories, and now it's time to vote! You can vote for any proposal listed on the pages, using the {{Support}} tag. Feel free to add comments pro or con, but only support votes will be counted. The voting period will be 2 weeks, ending on December 14.

The proposals with the most support votes will be the team's top priority backlog to investigate and address. Thank you for participating, and we're looking forward to hearing what you think!

/Johan (WMF) using MediaWiki message delivery (talk) 14:41, 1 December 2015 (UTC)

Need your attention

PLEASE take a look at list of proposals found in the latest Community Wishlist Survey; Specifically those that pertain to Wikisource such as....

George Orwell III (talk) 23:16, 1 December 2015 (UTC)

• Special Pages
  • Normalize Special: pages for batch delete/undelete and batch moves
• Wikisource
  • late Wikisource additions at Wikisource

 Comment To say the least I have grave misgivings about this process. (I certainly am uncomfortable about being solicited to vote in any fashion whatsoever; good no doubt as the motives of the prost…solicitor may be.) It is almost as if somebody has just recently read about the concept of "brainstorming" and has rushed out to try out the concept without in any measurable means having understood it. First of all there is the mysterious "endorse" process; then an unaccountable "archiving" (presumably of those suggestions easily deemable incapable of easy implementation); and now we are to "vote" upon one another's suggestions. Suffice it to say I lose faith every single step of this so-called process.

And the final nail in this virtual coffin? We are actually voting to get items already committed to Phabricator requests to be acted upon? Give me a break: haven't we just destroyed any faith anybody might once have had in the process? I may be cynical but with all kindness, prove me wrong! AuFCL (talk) 22:25, 2 December 2015 (UTC)

Point(s) taken. I initially meant just for folks to take the time out to review the options (even the late "hidden" ones) then decide to support or not themselves but I see now using "vote" might not have the best way to convey that {amended].

As for any "mystery" - hardly; Phase one (although improperly titled at first) was broadcast to all who managed to find it and is still found somewhere above.

As for the point on split avenues to achieve the same goal - the short answer is "yes", we are trying to "lock focus" on approved proposals vs. the current meandering attention given by the developer of the moment for whatever job he or she "likes" in spite of being capable of solving other reported issues. Bottom line - squeaky wheel gets the grease. -- George Orwell III (talk) 23:05, 2 December 2015 (UTC)

Thanks for taking on this point: the rebuke was by no means specific but general in nature and intent—and probably best aimed elsewhere, not that I have the slightest faith in it being taken seriously. Yes: focus; yes: squeaky wheel; however from comments already posted please don't get hopes unreasonably up that anything non-wikipedia will be seriously considered... May I suggest planting the (more honestly: encouraging any existing) concept of this community being more persistently "squeaky"? AuFCL (talk) 23:25, 2 December 2015 (UTC)

i would encourage everyone to engage with WMF, perhaps there are changed attitudes given the Wikisource User Group conference. we can always wish. Slowking4♡Richard Arthur Norton's revenge 02:33, 3 December 2015 (UTC)

Images in Index:The chemical history of a candle.djvu‎

I'd been putting these in with the original pixel widths, but apparently this was changed to a % based layout, which means that the translclusion looks ugly in places. On the next work I'd like CLEAR instructions please.ShakespeareFan00 (talk) 18:22, 3 December 2015 (UTC)

I think that I've done that! But perhaps I was wrong. I thought the "floating image"-feature to be the most important feature of the FIS-template that was used. If I'm wrong, please correct it! Greetings, Dick Bos (talk) 19:51, 4 December 2015 (UTC)

Can a version page have only one blue-link edition entry?

This is about the edits on Tom Brown's School Days. It was created as a redirect page to Tom Brown's School Days (6th ed). And there have been edit wars at Wikidata on whether Tom Brown's School Days (6th ed) should be added to Wikidata:Q7815084 (the book) or Wikidata:Q19106639 (the edition). Multiple Wikidata editors follows the Wikidata's rule to remove Tom Brown's School Days (6th ed) from Wikidata:Q7815084 once and once again, but EncycloPetey kept reverting them. As a solution I changed Tom Brown's School Days to a version page and added other red-link edition entries, but EncycloPetey still kept reverting it to redirect page and changed its protection level to allow only administrators to edit it (BTW, although I do find EncycloPetey's name at Wikisource:Administrators, it will be helpful if, in my view, he can also add the administratorship information to his user page). It's true that currently Wikisource has only one edition page for Tom Brown's School Days. But does it means that the version page should be redirected to its edition page and cannot be a separate page with some red-link edition entries? To have a separate version page for Tom Brown's School Days can fix the repeating disputes at Wikidata and does not cause much trouble. Wikisource:Versions clearly indicates that a version page can have red-link edition entries. And Terminations is also a version page with only one blue-link edition entry and was created by an administrator (Hesperian). So why must Tom Brown's School Days be a redirect? --Neo-Jay (talk) 00:26, 4 December 2015 (UTC)

Yes, a version page can have only one blue link, but there is no reason to create a version page where there is only one version on Wikisource, and no prospects for any other versions to exist. There is nothing to disambiguate if only one version exists. Creating a page here because of a policy at Wikidata is a poor choice. We don't create pages simply to have a link target from another site. The situation at Wikidata has been discussed (twice) and resolved on both occasions to the current situation. --EncycloPetey (talk) 01:06, 4 December 2015 (UTC)

@EncycloPetey: In what situations can we conclude that there is no prospects for any other versions to exist? Doesn't the 1868 edition indicate a prospect for another version of Tom Brown's School Days? Should Terminations also be redirected to Terminations (New York: Harper and Brothers, 1895)? And the disputes have not been resolved at Wikidata. Those previous Wikidata editors whose edits were reverted by you just didn't take time to argue with you. That does not mean that your POV has become consensus there. If you insist on confusing the book item with its edition item, the edit war will break out repeatedly at Wikidata in the future.--Neo-Jay (talk) 01:28, 4 December 2015 (UTC)

The 1868 edition was uploaded to Commons three years ago, and promptly abandoned. The source file is missing pages. No one has worked on it since, and no one has indicated any inclination to work on it or any other edition. The other Wikidata editors and I discussed the changes and came to a consensus, but that discussion is irrelevant for Wikisource. Do you show up here once a year just to cause problems? It sure seems that way. --EncycloPetey (talk) 01:39, 4 December 2015 (UTC)

@EncycloPetey: The only discussion I can find you made at Wikidata was with Samwilson at his user talk page (If I'm wrong, correct me). And there is no indication that Samwilson has agreed with you. He just stopped talking with you. If you think that my edits at Wikisource just cause problems, you, my dear administrator, can block me. I am just wondering, if Tom Brown's School Days (1868) is created, whether you agree to change Tom Brown's School Days back to a version page and add it back to Wikidata:Q7815084 and move Tom Brown's School Days (6th ed) from Wikidata:Q7815084 back to Wikidata:Q19106639. If so, I can proofread the 1868 edition (with just two pages missing) and create Tom Brown's School Days (1868) now. Please let me know. --Neo-Jay (talk) 02:42, 4 December 2015 (UTC)

Yes, I'm afraid I bowed out of that discussion because I didn't agree with EncycloPetey's conclusion but couldn't be bothered arguing against someone who obviously felt more strongly about it than I did (and who I think has a different view of the interrelation between the projects). I think there should be a Wikidata item for the work, and another for each edition. The work item should link to the Wikipedia page and a edition page here; the edition items should link to individual editions here. Now, the problem with this is that it's then more than one step to go from an edition page here to the Wikipedia article... but that's a scripting problem, not an ontological one. — Sam Wilson ( Talk • Contribs ) … 03:16, 4 December 2015 (UTC)

In this case, it also means that all the interwiki links from Wikisource pages for a work to any other project are broken. When there is more than one edition on Wikisource, the current Wikidata model makes some sense, but when Wikisource has only a single edition, it doesn't. The Wikidata model essentially allows only disambiguation pages on Wikisource to be linked directly to and from other projects, which is a huge issue for a smaller project like Wikisource. Cutting all our links is bad for growth. --EncycloPetey (talk) 05:25, 4 December 2015 (UTC)

You're quite right. So we have to subvert the (correct, imho) Wikidata model and add sister links (and P1957s) to the work items, to make them work. But that still means that where disambig pages exist here, they will link to sister projects and the individual works here will not. Which is a bit of a shame, but we aren't allowed to link more than one page to an item. (But sorry, this is probably getting off track.) — Sam Wilson ( Talk • Contribs ) … 06:00, 4 December 2015 (UTC)

I make a version page every time I post an edition of a work. However, I undertake the scholarship to ensure that these versions pages add value to Wikisource, rather than just being another page that a reader must click through to get to where they want to go. I would not want to see a whole heap of poor quality versions pages created here, just because Wikidata wants to be neat and tidy. So, I can see Petey's point. Hesperian 03:54, 4 December 2015 (UTC)

@Hesperian: 1. So do you think the version page Terminations you created with also only one blue-link entry adds value to Wikisource or just is another page that a reader must click through to get to where they want to go? 2. If I proofread the 1868 edition and create Tom Brown's School Days (1868), could Tom Brown's School Days be changed back to a version page? I am looking forward to a reply from you administrators so that I can decide whether to do it. --Neo-Jay (talk) 04:19, 4 December 2015 (UTC)

1. Yes. 2. Yes, if you proofread another edition of the work, then the work page would have to become a versions page. But in my opinion it won't be a very good versions page because it won't contain useful information about all the notable editions. Furthermore, I discourage you from commencing a proofreading project that cannot be completed due to missing pages in the source file, simply in order to rationalize the creation of a not-very-good versions page, so as to make wikidata neat and tidy. Hesperian 04:34, 4 December 2015 (UTC)

@Hesperian: 1. Yes what? My question is whether X is A or B. So does "Yes" mean A or B? 2. That's the deal, I will proofread the 1868 edition and create Tom Brown's School Days (1868). Thanks for your supporting to change Tom Brown's School Days back to a versions page (although it might, in your view, not be a very good versions page). --Neo-Jay (talk) 04:46, 4 December 2015 (UTC)

??? He "discouraged" you from proceeding, and you read that as "support"? --EncycloPetey (talk) 05:25, 4 December 2015 (UTC)

If you intend to proceed, then any page you mark as "Proofread" should not contain numerous errors of spelling, punctuation, spacing, mis-hypenation, etc. It appears as if you are creating a garbage transcription merely to push your agenda, without any regard for the quality of your work. --EncycloPetey (talk) 05:36, 4 December 2015 (UTC)

@EncycloPetey: Hesperian's answer to my second question is "Yes" no matter how it is qualified. Therefore I have started to proofread the 1868 edition. My work just began and I will surely improve its quality. Please don't be too eager to make your judgment. Thank you.--Neo-Jay (talk) 05:44, 4 December 2015 (UTC)

If you're going to split hairs, perhaps you should start by carefully analysing the precise question that I gave a qualified "Yes" too. Then, analyse this: I think you are behaving in a rude and dominating manner and disrupting the project. Hesperian 07:54, 4 December 2015 (UTC)

@Hesperian: Could you clarify your opinion? Do you mean that Tom Brown's School Days (1868) should not be created, or, even if it can be created, Tom Brown's School Days should not be a version page? Following EncycloPetey's teaching, I am learning to how to create an acceptable edition for Tom Brown's School Days and am working on it. Thanks for your patience. --Neo-Jay (talk) 08:10, 4 December 2015 (UTC)

From a Wikisource perspective (IMO), there are two valid grounds for creating a versions page: (1), to provide valuable high-quality information on the available editions of a work — I stand by Terminations but proffer The Tenant of Wildfell Hall as a better example. Or, for an example with only one hosted text, try The American. (2), to link to and distinguish between multiple hosted versions. Yes, if we had multiple versions, then we would have to have a versions page. No, this is not valid grounds for doing a shitty job of proofreading a shitty source file with missing pages. Doubly no when the end game of all this in tidying up a loose end on Wikidata. Hesperian 08:40, 4 December 2015 (UTC)

@Hesperian: OK, since you think that proofreading the 1868 edition (with two pages missing) is a shitty job, I stop proofreading it. But as you indicate in your point (1), Tom Brown's School Days can also be accepted a valid versions page if it provides valuable high-quality information on the available editions of a work, just like Terminations and The American. So why not decrease the protection level of Tom Brown's School Days and allow me to edit it as a versions page to see whether it can meet the standard you describe in point (1)? If we cannot solve this issue at Wikisource, the edit war at Wikidata will break out again sooner or later, just like before. Yes, I can give it up now. But someone else at Wikidata will surely bring this issue again in the future since adding the link of Wikisource's specific-edition page directly to Wikidata's book item apparently violates Wikidata's principle (however, edition item can be included in the book item's "edition" property). --Neo-Jay (talk) 09:05, 4 December 2015 (UTC)

I suggest that this page should not have been protected by someone involved in a dispute over it. Petey, please unprotect. Hesperian 14:41, 4 December 2015 (UTC)

The proposed page can be created anywhere, including in a User namespace. We can then move and merge if the created product is worthwhile. --EncycloPetey (talk) 15:23, 4 December 2015 (UTC)

Thank Hesperian and EncycloPetey very much. I have placed my proposed page at Talk:Tom Brown's School Days. It will be great if you could take time to see whether it is acceptable. Many thanks! --Neo-Jay (talk) 18:49, 6 December 2015 (UTC)

Creating pages is not the same as proofreading them. If you intend to mark pages as "proofread", then please only do so once they have been proofread. Right now, you are leaving numerous errors in every "proofread" page. --EncycloPetey (talk) 05:47, 4 December 2015 (UTC)

@EncycloPetey: OK, I will start with "Problematic" or "Not proofread" tag and change it to "Proofread" only when the page deserves it. Thank you for your teaching. --Neo-Jay (talk) 05:55, 4 December 2015 (UTC)

┌───────────────────────┘
I am in no wise buying into this fight except insofar as observing you all appear to be behaving precisely as disgracefully as the worst of the school-boys described in (whatever version) of this very work. Especially if they are right then it behoves the senior boys to behave with a minimum of dignity and not to berate the new lad. Kindly grow up. Either learn to get along compatibly or have the sense not to make even bigger fools of yourselves than you have all ready done so. AuFCL (talk) 09:04, 4 December 2015 (UTC)

To be precise, the "new" lad has been here for eight years. --EncycloPetey (talk) 15:31, 4 December 2015 (UTC)

surely you can then come to a consensus, without edit warring, say expand to multiple versions, as uploaded (or with consensus) we should play nice with wikidata, even if we don’t fully embrace their dB POV. disappointing you both should revert to wikipedia behavior. slowking4 01:25, 6 December 2015 (UTC)

It's not as simple as that; it's not a question of two individuals coming to a consensus. The decision made regarding this point impacts how Wikidata will operate as a whole, and how every single Wikisource (in any language) is cross-linked via Wikidata. Even if we two make a decision, there is no guarantee that the whole issue won't erupt again in a month because of another editor. We need a project-wide decision, and the Wikidata community is divided on the issue of even discussing such changes. At its core, the Wikidata model for dealing with Wikisource works is fundamentally and logically flawed. Putting a bandage on it won't fix the problem; there needs to be a mass discussion of the issues involved. I don't hold out any hopes that the issue will be resolved soon, because the Wikidata community can't even agree on the correct way to link Commons categories—there are currently three different methods being employed, and which method (or methods) is in place for any given category varies wildly. --EncycloPetey (talk) 15:39, 6 December 2015 (UTC)

@EncycloPetey: Although I registered at Wikisource more than eight years ago, I am still a new editor for proofreading Index Pages. My whole experience on editing Index Pages before this discussion was just six times for only two pages. Many thanks for your patience and guidance. And following Hesperian's suggestion, I have stopped the shitty job of proofreading the 1868 edition. I will appreciate it very much if you could have a look at my proposed versions page at Talk:Tom Brown's School Days. Thank you! --Neo-Jay (talk) 19:38, 6 December 2015 (UTC)

I agree with AuFCL. This sort of rude bickering certainly discourages participation in Wikisource and other Wiki projects. I was going to post a request for help here, but this doesn't seem to be the place to go for help. I'll look elsewhere, though I shouldn't have to. Outlier59 (talk) 01:34, 6 December 2015 (UTC)

Tech News: 2015-50

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

• Revision scoring will help to automatically identify bad-faith and good-faith edits. The point is to make it easier to block vandals and welcome newcomers. It currently supports Wikidata and 14 Wikipedias. [1]

Problems

• Meta was not given access to information from Wikidata last week. This will happen later. [2]

Changes this week

• You will be able to use wikilinks in Flow topic titles. [3]
• IP users will have a toolbar with links to the user talk page and user contributions. Some Wikipedias already have this feature. [4]
• You will be able to edit the graph size in the visual editor. You can either specify the size in the graph dialog or drag it to be the size you want it to be. [5]
• It will be easier to write math in the visual editor if you don't know LaTeX. You can use symbol buttons instead. [6]
• You will be able to use syntax highlighting when you write math with LaTeX in the visual editor. [7]
• UploadWizard will look a bit different. [8]
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 8 December. It will be on non-Wikipedia wikis and some Wikipedias from 9 December. It will be on all Wikipedias from 10 December. (calendar).
• New MediaWiki versions will now be on Catalan and Hebrew Wikipedia on Wednesdays. Other Wikipedias get the new MediaWiki version on Thursdays. [9]

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 8 December at 19:00 (UTC). See how to join.
• You can join the next meeting with the Architecture committee. The topics this week are "Graph/Graphoid/Kartographer – data storage architecture" and "Parametric JSON builder". The meeting will be on 9 December at 22:00 (UTC). See how to join.

Future changes

• A new beta feature will show users links to related articles at the bottom of an article. It will not be enabled by default. [10]

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

17:52, 7 December 2015 (UTC)

Link tables (again)

Compendium of US Copyright Office Practices, II (1984)/800 , I've been updating the underlying pages, and so far I've had to use Hard Purge, every single time, merely reloading the page doesn't update the displayed content. I thought this annoyance had been solved? ShakespeareFan00 (talk) 10:48, 12 December 2015 (UTC)

This report is insufficient to explain to me the issue that you are having. Please add detail and steps. — billinghurst sDrewth 00:10, 14 December 2015 (UTC)

Hmm, it seems to be intermittent, as I am not seeing the issue right now to confirm what was doing. :( ShakespeareFan00 (talk) 00:32, 14 December 2015 (UTC)

If you are seeing image or text layer issues out of sync with the Index:/File:/Page: then use the purge function from the Index: page as it is set to kick at Commons. If you are having thumbnail generation issues, it can be a local/browser issue or it can be a problem at Commons, so try a different browser to see if it can be reproduced, and if it can be reproduced as a problem then utilise the process described at mw:How to report a bug. If you are seeing something else, then use the instructions to see if you can better restate the issue to being specific. — billinghurst sDrewth 00:11, 15 December 2015 (UTC)

Not sure why we bother with Commons

The Commons administrators and their processes continue to be unhelpful to English Wikisource. They delete pages without notice to this sister site, and they apply dubious deletion criteria, eg. Google lead pages removes a whole work, or that insufficient labelling on a historical document. I have pretty much had enough, and feel that we should basically put Commons on notice, and take works here. — billinghurst sDrewth 00:09, 14 December 2015 (UTC)

well, IA uploader would need to be modified. you could get a super-user right to evaluate deleted files there and move them to wikisource as they are deleted. maybe a bot to automatically make a copy of all files in use at wikisource when nominated. Slowking4♡Richard Arthur Norton's revenge 00:58, 14 December 2015 (UTC)

I agree with this sentiment. I might start uploading to WS instead of Commons regardless. —Beleg Tâl (talk) 02:52, 14 December 2015 (UTC)

We need to be clear whether we are talking about all files, including page illustrations, or only book scans. Personally I strongly support page illustrations being uploaded to Commons, because we want to make these illustrations available for other uses such as the wikipedias. I suspect however that I'm preaching to the choir on that point — it is only book scans that are contentious. Hesperian 03:40, 14 December 2015 (UTC)

Protest is protest, we do what suits ourselves. If Commons administrators are doing things to suit themselves and with a very narrow interpretation of reality and making things difficult for us, it becomes contingent upon us to protect our works, and take the challenge of a different view on copyright interpretation. — billinghurst sDrewth 00:00, 15 December 2015 (UTC)

I haven't had to face the issue of a scan being deleted that I was working with, so I haven't experienced this issue. I would caution everyone, however, that if we have a locally stored file, there is nothing to stop someone else coming along and uploading a file to Commons with that same filename. That could lead to some new problems. --EncycloPetey (talk) 05:11, 14 December 2015 (UTC)

Nor have I had it happen to my scans, however, I have had to much remedial, AND it only is evident that it has happened when there is an image specifically included through {{missing image}}, otherwise it is hard to detect. [That is a task that I need to work out how to identify, and we should be able to do something through the Index: ns, though we may need to update the Mediawiki template that we use]. With regard to local vs Commons uploads, the local version of upload will always override the Commons image of the same name. — billinghurst sDrewth 00:00, 15 December 2015 (UTC)

OR we start stirring among the Wikisources for a Commons Wikisource and see where the politics take us. — billinghurst sDrewth 00:02, 15 December 2015 (UTC)

well, wikimedia hebrew did some push back against the aggressive URAA deletions. i’m not sure they care, i.e. people will delete per their ideology, until thwarted and then stomp off. but trying an RfC for some consensus would be a start for some consciousness raising. Slowking4♡Richard Arthur Norton's revenge 02:17, 15 December 2015 (UTC)

 Comment Commons has created c:User:SteinsplitterBot/DR/wikisource which will reputedly monitor and report English Wikisource files nominated for deletion. — billinghurst sDrewth 09:52, 16 December 2015 (UTC)

Tech News: 2015-51

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

• Meta will be able to use information from Wikidata. [11]
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 15 December. It will be on non-Wikipedia wikis and some Wikipedias from 16 December. It will be on all Wikipedias from 17 December. (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 15 December at 19:00 (UTC). See how to join.
• You can join the next meeting with the Architecture committee. The topic this week is talking about the agenda for the Wikimedia Developer Summit. The meeting will be on 16 December at 22:00 (UTC). See how to join. [12]

Future changes

• A new gadget manager will come next year. The new gadget system is called Gadgets 2.0. [13]

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

17:42, 14 December 2015 (UTC)

Comments over Gadget 2.0 news

We do need to note the information about the new Gadget manager and namespace [14] and have a plan for review and transition. — billinghurst sDrewth 00:04, 15 December 2015 (UTC)

Agreed. In a nutshell, one day there will be a far more seamless way to develop gadgets locally and share them project or foundation wide [hopefully] without all the loading/resource/dependency concerns we have with the current approach to gadgets.

Having "followed" the premise and development to some degree already, here are some opening concerns/points on what we might need to look into on the local, project and developmental levels ahead of the unavoidable replacement date. Note: Each section is not meant to be definitive at this point in time; merely informative; please feel free to add your own thoughts/concerns. -- George Orwell III (talk) 05:08, 15 December 2015 (UTC)

Local level

• Better utilization of the MediaWiki: message namespace in general.— Whether under the current approach to Gadgets or under the coming Gadgets 2.0 [15] scheme, -- and putting the reasons &or causes aside for now -- we are woefully ignorant (if not outright incompetent) when it comes to the identification, designation and utilization of MediaWiki "messages" in our Template design. I mention Templates here first primarily because they are frequently called upon from our library of Gadgets (as well as from User: scripts) to accomplish or automate one task or the other in endeavors.

  If the new Gadget system is believed to be as 'language flexible' as advertised, a huge component of its success will depend on how much of the existing Template: makeup and Gadget content point to specific "terms" predefined in the MediaWiki namespace. Using such predefined MediaWiki: (mw) "terms" in place of any highly repetitive &/or narrowly project specific ones makes for easier (on-the-fly) translations into other languages or projects while promoting uniformity throughout in the process much akin to the usage of MAGICWORDS do now.

  Briefly; we frequently see parameters like | author = in a template right now. That's great for English users of a gadget that calls upon that particular template, but what about the other language domains under this coming system of a 'shared repository of gadgets for all'?

  Currently, we have asinine 'translation' lists peppered across various locations from site to site doing local (or self) messaging like this self.ws_messages = {'author':'auteur',... to help "handle" any cross compatibility issues. What we should have had in place by now is

  | {{lc:{{int:wm-license-information-author}}}} = which produces the same | author = in use now but with some additional 'benefits'.

  First, the desired ease of translation is better facilitated thanks to a central language conversion list inherent to the MW namespace.

  {{int:wm-license-information-author}} is found

  here MediaWiki:wm-license-information-author in English,

  here MediaWiki:wm-license-information-author in French.

  Applying the MagicWord forcing all lower case lettering ({{lc:foo}}) promotes uniformity in spite of any 'accidental' deviations made at one partner site from the rest.

  Second, by cleverly including license-information in the naming of the designated mw message it can be inferred that the copyright status of associated works "factors in" the death-date-to-nation-of-origin-to-nation-of-hosting found with the [parameter] author. I don't know what good such nuances can be in the overall picture -- other than for organization/categorization purposes -- nevertheless its something to be mindful of.

  The task at hand is to first identify Template: parameters inferring the same entity, description, action, location and similar in high use today that already have a suitable MediaWiki message defined and replace the parameter label for the mw-message. The "harder" task will be identifying the same as before, do not have existing counter-parts defined on MediaWiki at the moment, come up with an agreeable labeling scheme and then establishing them as part of the MediaWiki code moving forward. If the community doesn't want to get [further] left behind, the community needs to chime in here; one or two admins cannot possibly be familiar with all the common parameters & their usage levels out there. Further discussion is needed at this juncture; please participate.

• ...

WS project level

Tracked in PhabricatorTask T64717Open

• Completely [re]align 'oldwikisource' to the times as mul.wikisource.org once and for all.— Practically everyone should be familiar with this one by now. Maybe a fresh wave of interest against the Phabricator task might get things moving again.
• ...

Core &or extension development level

Tracked in PhabricatorTask T74525Open

• Harmonize the Wikisource namespace numbering used by the ProofreadPage extension.— This is about the standardization of the current numbered designations for the Page: and Index: namespaces from their current pairings per WS language domain to 250 and 252 respectively across all the exiting and any future WS domains.

  The timely completion of this task and any subsequent "needed adjustments" locally are both rooted in the same rationale and logic being argued above in the Local Level discussion(s). If we want to enjoy all the benefits that the new Gadget manager and namespace [16] are to provide, everybody must be "working off the same page" uniformly. While this may involve a few days of "pain" after making the change to re-fresh and re-align existing Module:s, Template:s and the like that "point" to the erroneous namespaces designation, its still worth doing sooner rather than later.

• ...

Text wrapping script or gadget?

Is there a well working script/gadget available that does text wrapping? I am looking for such a tool to be able to edit in any Operating System, and not be tied to Windows because of AutoHotkey which is great but there is no equivalent in Linux.— Ineuw talk 05:35, 15 December 2015 (UTC)

I am afraid I do not understand your question. Are you looking for some utility which closes up useless new-lines on a Page: a.l.a. Pathoschild's TemplateScript? Or something quite different? AuFCL (talk) 06:03, 15 December 2015 (UTC)

The cleanup script removes single linebreaks at the end of text lines in the OCR, which has the effect of wrapping paragraphs. I've been using the script since plagiarising it from Hesperian for about 5 years now, so I can assure you it's "well working". Pathoschild has done some of his magic on it and the latest version is accessible from WS:TS. It can be invoked via a key combination—see my common.js to see how Pathoschild has set it up for me. Beeswaxcandle (talk) 05:45, 15 December 2015 (UTC)

Thanks for your replies. It is Hesperian+Pathoschild's script is what I am looking for and will check the common.js on how to activate it. Will return here to post the results. — Ineuw talk 21:00, 15 December 2015 (UTC)

Installed the script but don't know how to activate it and this is the only tool I need.

$.ajax('//tools-static.wmflabs.org/meta/scripts/pathoschild.templatescript.js', { dataType:'script', cache:true }).then(function() {
	// customise proofreading tools
	pathoschild.TemplateScript.library.override('wikisource.proofreading', 'cleanup-ocr', { accessKey: 'x' });

});

The regex editor, which now I assume is part of the templatescript.js suite has been previously selected in the Gadgets. — Ineuw talk 21:38, 15 December 2015 (UTC)

You were missing the bit that actually gives you the scripts. The code chunk above is what makes them available in your side-bar (and gives a shortcut key). I've added the script chunk to your common.js. Beeswaxcandle (talk) 06:11, 16 December 2015 (UTC)

@Pathoschild: has also been adapting TemplateScript this to a method that will allow a pseudo-Special page. He has left notes on my talk page, and I have been too busy with other things to nut it out. Maybe now that I have given myself some time back I will get that chance. Maybe Pathoschild could explain it better than I if he perchance sees this request. — billinghurst sDrewth 10:35, 16 December 2015 (UTC)

@Beeswaxcandle: My sincere gratitude. Now I can work in Linux. I compared the results of the script with my AutoHotkey macro and they are identical! with one minor stylistic difference. Amazing.— Ineuw talk 03:12, 17 December 2015 (UTC)

One last question please, how do I connect it to the keyboard (what I assume to be Alt-x?)— Ineuw talk 04:30, 17 December 2015 (UTC)

According to Wikipedia:Keyboard_shortcuts#Modifier_keys most likely it is Alt-Shift-x in your case. AuFCL (talk) 05:08, 17 December 2015 (UTC)

What IdeaLab campaigns do you want to see?

Hey folks. I’m seeking your help to decide on topics for new IdeaLab campaigns that could be run starting next year. These campaigns are designed to attract proposals from Wikimedia project contributors that address a broad gap or area of need in Wikimedia projects.

Here’s how to participate:

• Learn more about this consultation and review submitted campaign topics.
• Vote on and submit new campaign topics in the AllOurIdeas Survey (in English)
• Discuss campaign topics and ask questions on the IdeaLab talk page.

With thanks,

I JethroBT (WMF), Community Resources, Wikimedia Foundation. 23:02, 17 December 2015 (UTC)

Recognising recorded biographical detail in author template?

For a while we have been using the author talk page as a means to capture biographical detail about authors, especially when there is no Wikipedia article, or the article is sparse for primary data. As this addition of the talk page information is less than evident, I am wondering whether there is value in adding a flag to the author template pointing to the data, similarly to what we do with the edition = flag within {{header}}. — billinghurst sDrewth 01:34, 18 December 2015 (UTC)

Get involved in Wikipedia 15!

This is a message from the Wikimedia Foundation. Translations are available.

As many of you know, January 15 is Wikipedia’s 15th Birthday!

People around the world are getting involved in the celebration and have started adding their events on Meta Page. While we are celebrating Wikipedia's birthday, we hope that all projects and affiliates will be able to utilize this celebration to raise awareness of our community's efforts.

Haven’t started planning? Don’t worry, there’s lots of ways to get involved. Here are some ideas:

• Join/host an event. We already have more than 80, and hope to have many more.
• Talk to local press. In the past 15 years, Wikipedia has accomplished extraordinary things. We’ve made a handy summary of milestones and encourage you to add your own. More resources, including a press release template and resources on working with the media, are also available.
• Design a Wikipedia 15 logo. In place of a single icon for Wikipedia 15, we’re making dozens. Add your own with something fun and representative of your community. Just use the visual guide so they share a common sensibility.
• Share a message on social media. Tell the world what Wikipedia means to you, and add #wikipedia15 to the post. We might re-tweet or share your message!

Everything is linked on the Wikipedia 15 Meta page. You’ll find a set of ten data visualization works that you can show at your events, and a list of all the Wikipedia 15 logos that community members have already designed.

If you have any questions, please contact Zachary McCune or Joe Sutherland.

Thanks and Happy nearly Wikipedia 15!
-The Wikimedia Foundation Communications team

Posted by the MediaWiki message delivery, 20:58, 18 December 2015 (UTC) • Please help translate to your language • Help

Beta tool : Completion suggester

“	In the continued quest to make the search bar a better tool, the Wikimedia Foundation's mw:Discovery Department has put a completion suggester into Beta Features. The tool functions with search-as-you-type, with a small tolerance for typos and spacing in finding results. Possible matches are then displayed as you type in a drop down menu, hopefully eliminating the need to perform a fulltext search with landing page and all. You can read more details at mediawiki.org and use the talk page for now for feedback. The tool is now available and will only be enabled for the article namespace for now, and will progress into full production at some point hopefully in early 2016, depending on feedback. It's going to be important to get feedback from regular contributors who use search to make sure that any of the basic feature requests for searching the main space can at least be addressed while in Beta Features.	”
—[Dan Garry (WMF), Discovery-L mailing list

— billinghurst sDrewth 15:09, 19 December 2015 (UTC)

Index:Compendium of US Copyright Office Practices (1973).pdf

I'd really like some help on getting this transcribed, I've been working away it for ages, and would appreciate someone doing a chapter to assist.ShakespeareFan00 (talk) 23:29, 19 December 2015 (UTC)

Password Strength RFC

Hello

We have started an RFC on meta to increase password requirements for users that have accounts which can edit MediaWiki:Common.js, have access to checkuser or have access to Oversight.

These types of accounts have sensitive access to our sites, and can cause real harm if they fall into malicious hands. Currently the only requirement is the password is at least 1 letter long. We would like to make the minimum be 8 letters (bytes) long and also ban certain really common passwords.

By increasing requirements on passwords for accounts with high levels of access, we hope to make Wikimedia wikis more secure for everyone. Please read the full text of the proposal here, and make your voice heard at the RFC.

Thank you

(On behalf of the WMF security team) BWolff (WMF) (talk) 07:24, 21 December 2015 (UTC)

Delivered using the distribution list

m:Requests for comment/Password policy for users with certain advanced permissions. Slowking4♡RAN's revenge 16:16, 22 December 2015 (UTC)

Tech News: 2015-52

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

Tech News

• Because of the holidays, the next issue of Tech News will be sent out on 11 January 2016.
• The writers of the technical newsletter are asking for your opinion. Did you get the information you wanted this year? Did we miss important technical news in 2015? What kind of information was too late? Please tell us! You can write in your language. Thank you!

Recent changes

• CompletionSuggester is a new suggestions algorithm for Search. It is available as a Beta feature since 17 December. (more information)
• The Multimedia team is running an A/B test for the cross-wiki upload tool. They are testing four different interfaces. The test is running from 16-23 December. (more information)

Changes this week

• There is no deployment of MediaWiki scheduled until 12 January 2016 (calendar).

Meetings

• Should administrators and other users with advanced tools need stronger passwords? You can discuss about it in a Request for Comments.
• No meeting with the VisualEditor team on 22 and 29 December, and 5 January.

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

18:29, 21 December 2015 (UTC)

Community Wishlist Survey results

Hi everyone,

The 2015 Community Wishlist Survey is over, and now the Community Tech team's work begins on the top 10 features and fixes.

In November and December 2015, we invited contributors from all Wikimedia projects to submit proposals for what they would like the Community Tech team to work on, for the purpose of improving or producing curation and moderation tools for active contributors.

634 people participated in the survey, where they proposed, discussed and voted on 107 ideas. There was a two-week period in November to submit and endorse proposals, followed by two weeks of voting. The top 10 proposals with the most support votes now become the Community Tech team's backlog of projects to evaluate and address.

You can see the whole list with links to all the proposals and Phabricator tickets on this page: 2015 Community Wishlist Survey.

For everybody who proposed, endorsed, discussed, debated and voted in the survey, as well as everyone who said nice things to us recently: thank you very much for coming out and supporting live feature development. We're excited about the work ahead of us. -- DannyH (WMF) (talk) 21:15, 21 December 2015 (UTC)

Above is the message I'm posting on lots of wikis, but I want to talk about Wikisource specifically. Wikisource is an important project that doesn't happen to be as big as Wikipedia or Commons. We've been hearing a lot from Wikisource contributors who feel like the WMF doesn't pay attention to this project. There were some very good Wikisource-specific proposals in the Wishlist Survey. Unfortunately, they didn't get enough support votes to make it to the top 10, but they did very well considering the relative size of this project. The top Wikisource proposal made it almost to the top 20 -- you can see the full results page.

So we're thinking about what we can do to support Wikisource. We'll be talking about it at the Wikimedia Developer Summit in January, and we're also talking to the WMF Developer Relations team to see if we can encourage volunteer developers to work on a Wikisource proposal. I can't make any promises right now, but we've got good intentions and we'll see what we can do. As George Orwell III and AuFCL said above, being the "squeaky wheel" will definitely help. Our team has heard your squeaks, and I encourage you to keep squeaking. -- DannyH (WMF) (talk) 21:32, 21 December 2015 (UTC)

It isn't so much about squeaks, as hearing the "wagon wheel flats" over the noise of passengers moaning that the ride quality is poor. ;) ShakespeareFan00 (talk) 21:55, 21 December 2015 (UTC)

Of interest to me, as a participant in the Vienna Wikisource conference. I don't think anyone there was aware that a prioritisation was to be done, based solely on voting. In fact discussion with members of the Community Tech team who were there rather suggested otherwise. (I have to admit that I left before the conference was over. But we did have an extensive day-long meeting on the Saturday, covering the ground.) The wish list was not where our attention was directed.

In terms of process, therefore, I have some concerns. Charles Matthews (talk) 10:52, 22 December 2015 (UTC)

thanks for the effort. the VE and Indic OCR both got elevated in the wishlist, but the right to left support seems forgotten. (and just because they have a ticket doesn’t get it punched.) wagon wheels. Slowking4♡RAN's revenge 14:46, 22 December 2015 (UTC)

Thank you Mr. H. for taking the effort to post this. However as I can without extending myself name at least six "think tank" efforts going on at present (not a few of which are mentioned in Scriptorium discussions—at least until archived/presumed "pending lost"—above) I am wondering which is the best strategy: should all requests be mass duplicated into all possible forums (leading to accusations of "thou doest protest too much"); or are they all just a diversion and potential waste of time?

My internal cynic leans toward the latter conclusion: perhaps these repeated "surveys" are only awaiting some poor sap asking the question that they really want to address and any other ideas whatsoever are really destined to be (no doubt politely) be filed in the famous "round filling bin"? AuFCL (talk) 00:20, 23 December 2015 (UTC)

I've mentioned this before and I'll say it again, I think all wikisource needs is better "advertising", and the best advertising can be provided by wikipedia itself. Looking at an example w:A Christmas Carol if someone by chance were to read this article on wikipedia, what chances are there at all of that person reading all the way to the bottom, and then going to the external links section and then looking to the right at that little box which mentions something about wikisource having original text relating to the article. And what are the chances this user would actually click to see what this little box is all about? I say maybe one in a million, and I think that's a shame, since some very hard work has gone into providing transcriptions here at wikisource, e.g A Christmas Carol (Dickens). I think a in your face link from a wikipedia article about a certain book or author to wikisource is very important, and all wikisource needs to become more popular, since someone reading the article would probably like to read some transcriptions about the author or the work, and who better to provide that transcription than wikisource, being a sister project.

Taking myself as an example, I had been reading wikipedia articles for years before finding wikisource, and I think it's a shame that I didn't find wikisource through wikipedia but from some chance google search.

Jpez (talk) 06:15, 23 December 2015 (UTC)

The book infobox on enWP has a field for wikisource = xxx. I thought I had already added it on A Christmas Carol, but couldn't see it, so have now done so. Beeswaxcandle (talk) 07:51, 23 December 2015 (UTC)

@Beeswaxcandle: It's there but what I'm trying to say is it's hard for an average user to actually find the box and come over here. I bet most average users don't even know about wikisource. The little box is hard to find I think. Jpez (talk) 15:46, 23 December 2015 (UTC)

@Jpez:, I'm not sure that you're looking at the same box. The infobox on a WP article is the box on the top right hand side of the article that summarises data about the subject. The last data item in the box is a link to the WS text. We should be adding this field for all works that we have at least proofread, where there is an article. Beeswaxcandle (talk) 17:18, 23 December 2015 (UTC)

@Beeswaxcandle: Yes sorry I thought you meant the little data box at the bottom, but I think even the link you added in the infobox isn't very easy to spot. It would be nice if we could add something more obvious to the top right corner of the wikipedia article for example or somewhere else, something that would say "Look at me!". I don't think this is too much to ask, since if a wikipedia article is about a given work, the source text of that work is of paramount importance if it can be provided. Jpez (talk) 17:53, 23 December 2015 (UTC)

Wikisource needs more tech support, no question. Thinking globally, the known issues are not going to be addressed otherwise.

The Indic languages, for example, struggle under conditions which are hardly imaginable here on enWS. Some other initiative is clearly going to be needed for the languages of the country which is projected to be the world's largest, by population, come 2050. Scrooge would be proud of what they are currently being offered. Charles Matthews (talk) 09:04, 23 December 2015 (UTC)

Ruffhead Transcription

As long-term progress on this has been effectively stalled by some technical issues, I've filed a bug here https://phabricator.wikimedia.org/T122340 to track them.

I appreciate that other things have a higher priority, but the stalling of a what could have been a fairly major effort by technical problems is a big discouragment. ShakespeareFan00 (talk) 21:08, 23 December 2015 (UTC)

Time for a long break, some of what appeared to be an issue wasn'tShakespeareFan00 (talk)

Entries in pagelists

I recently found that under certain conditions the entries in a pagelist tag on Index pages which contain charcters like a . mean that the page numbers are not correctly displayed when pages from that Indexed worked are transcluded. A simple (alll though time consuming solution) would be to examine which pages have 'illegal' characters in pagelist entries and 'clean' them. I am carefully doing this with Index's I added pagelist information to.

On a related note, whilst uncovering the above, I also found that in related circumstances a simmilar issue of page numbers becoming undefined arises when something other than the pagelist tag appears or proceeds the pagelist tag, I've been solving this by moving any remarks to another field (typically the top of the ToC field.)

The fixes above seem to be resolving the issues concerned so far , but it would be helpful if anyone here was able to provide a list of Index: pages where the following applies :

• . : or other charcters (other than letters, numerals, quotes, brackets or spacing appears in pagelist entries.
• Where additional explanations or remarks are present in the Pages field.

I can and am performing a cleanup on my own efforts, but would appreciate the assistance of other contributors so I don't have to check every single Index page I contributed to. (Most seem not to have the issues related.)

Thanks in advance. ShakespeareFan00 (talk) 12:21, 24 December 2015 (UTC)

You would not have issues if you undertook the basic concept of page numbering. Books have numbers be they roman or arabic, or sometimes alphabetic. What you are doing is outside the scope of page numbers, and as I am seeing it of no demonstrated use. You repeatedly, in the history of your involvement of this project, look to make things more complex than is necessary, for some idealised notion of a facsimile of a book in the web environment. How is it that you are the only one who has these issues, and the vast bulk of the rest of us are able to manage within the framework. — billinghurst sDrewth 14:17, 24 December 2015 (UTC)

Addendum. If you can identify the basic troubles that you have got yourself into, then please specifically list them, preferably with links to examples. We can run bots through to fix issues. — billinghurst sDrewth 14:19, 24 December 2015 (UTC)

As I said I'm more than capable of reviewing my own efforts. but the issues seem to be,

1. Pagelist entry contains an "illegal" charcter , I.e "Adv." vs "Advert" Adv. vs Adv , Stripping out . from entries is reasonably straightforward, However I've asked GOIII if there's a KNOWN list of problematic,illegal characters.
2. {{red|!!}} used as pagelist entry - Example https://en.wikisource.org/w/index.php?title=Index:Medical_Inquiries_and_Observations_Upon_the_Diseases_of_the_Mind_-_Benjamin_Rush.djvu&diff=prev&oldid=6026514 I've been simplifying entries down to a simple "!!" instead. (the remainder I can do mannually.)
3. {{front-sheet}}{{water-marking}} or other 'additional texts' proceeding main pagelist - https://en.wikisource.org/w/index.php?title=Index:Medical_Inquiries_and_Observations_Upon_the_Diseases_of_the_Mind_-_Benjamin_Rush.djvu&diff=prev&oldid=6026514 (I've been moving these to after the pagelist)
4. Multiple-pagelists - https://en.wikisource.org/w/index.php?title=Index%3ARuffhead_-_The_Statutes_at_Large%2C_1763.djvu&type=revision&diff=6025640&oldid=6004250 which I simplified down to a single pagelist.

I appreciate I seem to be the one encountering these issues, but it would sometimes be nice if you wrote down what the agreed official framework was, so there aren't "mis-understandings". I've raised this with you before on a related issue about how to number images, but no visible progress was seemingly made on updating the relevant advice as far as I could tell. If page numbers can't use certain characters or indeed template sequences then the advice in Help: should perhaps explicitly say so? ShakespeareFan00 (talk) 15:38, 24 December 2015 (UTC)

Did you mean undertook or understood?, If you meant understood then I apologise for a mis-understanding of what the (unoffficial) guidance says. ShakespeareFan00 (talk) 15:38, 24 December 2015 (UTC)

I've had this issue on a couple of occasions; I once proofread a book that had a colophon and something else on the same page (I forget what it was but let's pretend it was a preface), with no page number as it was front matter. I tried labelling it in the pagelist as "colophon/preface" and this caused the Index page to go all wonky, so I ended up just labelling it "colohpon" and leaving it at that. —Beleg Tâl (talk) 14:50, 24 December 2015 (UTC)

My current efforts in "cleaning" have reached the start of October 2014, however given certain views being expressed I am unwilling to continue (and thus potentially have to re-clean some items when at some future date a different contributor decides there's been another "mis-understanding"), until some SPECIFIC questions are answered as follows:

Limit pagelist numbering to solely roman/arabic numerals (and combinations thereof and —.-,–	Yes/No?
Label images as "—" or as Img/Plate/Map/Illus/Fig on Context	Yes/No?
Number pages uniquely where possible	Yes/No?
Combine multiple page-lists into one set per Index page	Yes/No?
Do not number works without pages/ use Djvu numbering	Yes/No?
Re-examine already validated works	Yes/No?
Re number existing Index pages not meeting the "standard detailed here"	Yes/No?
Remove additional texts, or explanatory materials outright:	Yes/No?
Move additional texts. or explanatory materials to a different field?	Yes/No?
Characters not to be used in page list entries:
Do not attempt to format pagelist entries with bold/italic or other markup	Yes/No?
Number Cover pages as Cvr/Cover or as a dash	Yes/No?
Number Title pages as Title/Half-title?	Yes/No?
Number title page as part of a numeric run in context?	Yes/No?
number Subheadings not forming part of numeric run as "–" or as a specifc worded example?	Yes/No?
Avoid use of ... or .. for continuations?	Yes/No.
How to number Frontspeice Images?
How to number non-blank pages which do not form part of the work such as library tamps, cover sheets &c.?

In sorry it had to come to this approach, asking for all of these points (and possibly others) to be explicitly stated but owing to certain views stated here, in order to avoid continued "mis-understandings", I am of the opinion it's time we set down the rules of what goes in pagelist entries formally. ShakespeareFan00 (talk) 18:09, 24 December 2015 (UTC)

Here are some "rules of thumb" (which currently are true but may "drift" over time and software updates):

1. As a gross rule please do not consider the MediaWiki:PageNumbers.js algorithm to be UNICODE-stable (its not bad; but neither is it that good). Lesson is don't use &mdash;, &ndash; or even &nbsp; for any purpose within Index: <pagelist/>s.
2. All (current) Display Options attempt to reserve about 3em to present the page number in the left margin (when selected) at a slightly reduced font. Lesson here: don't use long descriptive names like "Frontispiece" (there is simply no way it will fit without possibility of overlapping into the text region. And note it will overlap. This is not one of those cutesy floating regions where stuff will neatly skip out of one another's way!
3. Although I am not currently aware of such a bug beware that full-stop/period "." can be a significant character to JavaScript and as such should probably never be used "just in case."
4. "Safe" values for page number values are: ASCII alphanumerics ([0-9A-Za-z])
5. And one final warning from the "truly bizarre file": Try to avoid using any sequences which may be misinterpreted as global CSS class names. Londonjackbooks was bitten recently when she turned up an index with a series of pages named "toc". This is a hard one to forecast but if it gets you prepare to be surprised. Details upon request. AuFCL (talk) 22:06, 24 December 2015 (UTC)

Thanks. Next problem a script to scan index pages to list potential problems like the ones you've mentioned, (Ill get the strait jacket and rubber room ready right now? Ed.) XD ShakespeareFan00 (talk) 22:50, 24 December 2015 (UTC)

Oops. I forgot to mention above, my personal preference for marking blank pages in <pagelist/> is to use a simple hyphen "-". (However I know some people think the result is too tiny to select links, so alternate suggestions invited.)

Careful with that search: some of the issues raised are unfortunately quite hard to search for using normal means. AuFCL (talk) 23:04, 24 December 2015 (UTC)

Thanks, however I am waiting for other contributors to respond so that everyone is working to the SAME standard and that all Index: are being revised to an agreed specification which won't get contributors lept on for 'disruptive' editing.ShakespeareFan00 (talk) 23:12, 24 December 2015 (UTC)

I use roman numerals where they are used in the book and I avoid using descriptive, terms like title, contents etc. unless they aren't numbered. I prefer not to use abbreviations if I do but the full terms. I use a simple - for empty pages. For me this the best way to label pages and I agree with ShakespearFan00 that we should have one way for doing this. Jpez (talk) 23:40, 24 December 2015 (UTC)

Guidelines are helpful (perhaps helpful add'l notes on the help page?), but "one way" seems too restrictive to me. Some texts have multiple TOC's throughout the work, such as this one, and it is helpful to label/make note of where each TOC begins/ends while proofreading. Each work has its own personality—as does each proofreader. We can utilize some level of creativity if it helps the proofreader/proofreading process—as long as it works... Where it doesn't, it becomes a learning/teaching experience. Part of the game, in my opinion. Londonjackbooks (talk) 00:52, 25 December 2015 (UTC)

Good point; I heartily agree. My "suggested list" is only that: a suggestion, and incorporating as many "gotcha's" as I am currently aware of. Never intended as prescriptive. AuFCL (talk) 01:33, 25 December 2015 (UTC)

AuFCL Says there's also a length issue, this means some full terms can't be as easily included.ShakespeareFan00 (talk)

Definitely not a length issue. In fact it is quite opposite. If you choose labels that are too long you will get overlap effects. Even things like links on top of links are possible with all the inherent chaos that represents. As the old cartographic joke goes: "There (May) Be Dragons Here!" That is all. AuFCL (talk) 01:33, 25 December 2015 (UTC)

For the benefit of anyone that wants to risk getting lept on for doing cleanup work:-

http://quarry.wmflabs.org/query/6528 is the 3503 index pages I've edited :) - Of course not all of these have pagelist issues, and some may have already been updated.

http://quarry.wmflabs.org/query/6529 is the 85 or so under my alternate account (and as far as I could tell there aren't that many in the list that have the issues mentioned previously. ShakespeareFan00 (talk) 23:47, 24 December 2015 (UTC)

Take many many steps back. The whole purpose of page numbers is that they are page numbers as displayed of the book they are not meant to be our creations. The purpose of the anchor function is to be able to wikilink to specific pages, and often we are attempting to do this ahead of time. [All of this was discussed and set out this way years ago.] Use publisher's numbering wherever possible, where specific and where implied. [We have discussed exceptions in the archives, eg. duplicated numbers, etc.]

Now to the rest, this should all be covered by the term "Typically ..." as it is the general rule, and there will always be good reasons to deviate on occasions, and we have always allowed for deviation for good reason, and would expect it to be documented if it wasn't bleeding obvious.

Re illustrations, we should utilise the publisher's methodology and usually they are inline with page numbers, or where plates they are outside of page numbers and referred to as facing ... they don't need labels beyond what they have. Feel free to add an inline anchor if you so choose. [Follow what the publisher has done unless there is a good reason not to do so, look to document on the talk page if you have deviated.]

There is next to no reason to label title, half title, … pages in a work. Like page numbers they are all constructs of the publisher though they are not titled and they don't need linking. Why do you believe that they need to positively exist in that form? When they are transcluded they are obvious what they are, they don't need a little label (and IMO look ugly), they don't need linking. It was a later convenience by some to have Adv so people could see where they exist and when a book is complete (not part of the work proper), but it was never a necessity and it wasn't for the purpose of the transclusion and the label.

Re the use of hyphens vs en dashes (as &ndash; or "–") vs em dashes (as &mdash; or "—") in <Pagelist />. I see that each of those works fine in index pages, and in linking through to Page: ns. if someone can demonstrate to me an issue, then please provide a link. My issue with hyphens is that they are smaller and harder to align to click, so I use en dashes and have for years and I am unaware of issues, and have not encountered any since ThomasV updated the early version of pagenumber.js at my request. My preference to use ndash rather than mdash on works that I set up. So here my advice differs from AuFCL though that may be through different experiences.

Covers: Typically we haven't transcluded them traditionally, and when they come from libraries they are regularly not original. As such we can ignore them, and if there is a cover it is usually first and last scan page, or second if we have a google image. Why do they need a label? There has been a few examples of artistic covers and they would normally follow the exemption for good reason process.

Notes would typically belong on the Index talk: page, though where there has been considered the necessity they have always been terminating in the table of contents field.

Template:Front-sheet and Template:Watermarking are your creations, and I am unaware of others using them. I see no value in either template. Maybe the former has some value at Commons at some point when someone wants to swap out the front pages. At this time, here, I see zero requirement for either. — billinghurst sDrewth 04:43, 25 December 2015 (UTC)

And I truly do have issues with even that recent example from above. You gave the example of this supposed simplification(!?!)

https://en.wikisource.org/w/index.php?title=Index:Medical_Inquiries_and_Observations_Upon_the_Diseases_of_the_Mind_-_Benjamin_Rush.djvu&diff=prev&oldid=6026514

<pagelist 
1="!!"
2=Cvr
3to5=-
6=-
7=-
8to13=roman
8=Title
10=3
14=7
372=365
373=Adert
374to376=-
377=Cvr
/>

Below is a simplification and it covers all the essentials. You can tell which are part of the book and which are not. No iteration; nothing superfluous. https://en.wikisource.org/w/index.php?title=Index:Medical_Inquiries_and_Observations_Upon_the_Diseases_of_the_Mind_-_Benjamin_Rush.djvu&diff=6027310&oldid=6026514

<pagelist 
1to7="–"
8=1
8to13=roman
373to377="–"
/>

— billinghurst sDrewth 04:58, 25 December 2015 (UTC)

Fair enough, but I was previously told to NOT to mark pages with content using dashes (per the guidance notes). If that's changed the guidance note should also be updated so everyone is working to the SAME standard. ShakespeareFan00 (talk) 10:17, 25 December 2015 (UTC)

AAAGH! You miss the entire debate about simplification and it is nothing to do with hyphens/en dash/em dash. Ignore those, it is irrelevant, and makes no fdifference. — billinghurst sDrewth 14:30, 25 December 2015 (UTC)

Table termination

Billingshurst has been kind enough to point out off-wiki that terminating tables in a page with a |- is currently incompatible with the page numbering script, I.E the {{nop}} should be at the end of a page and not the start of the table on the next page.

I had been following what the notes on splitting tables currently said, which was that the nop went at the top of a continuing table rather than at the end of the previous one. From personal experience (and I will have to look for a specific example), there are some circumstances where a {{nop}} DID have to be inserted at the start so the table rendered correctly when the start of the table was in the header of a page. This needs some further investigations, and the advice updating so that everyone is working to the SAME consistent approach which doesn't break stuff elsewhere. ShakespeareFan00 (talk) 10:30, 25 December 2015 (UTC)

I'm also very frustrated that by following what I thought was the semi-official gudiance I'm effectively going to have re-do nearly 10 years worth of efforts because the guidance turned out not to be 'consistent' with actual behaviour in the rendering etc. This is a very big disincentive to my continued contributions. ShakespeareFan00 (talk) 10:35, 25 December 2015 (UTC)

I again told you that row markers terminating a page were the cause of your problems, and I did not mention {{nop}}. NOP should remain at the top of the page so that the row marker is seen as such, not as text. All the examples that I have done have been exactly that way. — billinghurst sDrewth 14:22, 25 December 2015 (UTC)

Plus you don't need to redo anything, that is just pointless editing. We can bot things, and we only need to fix things where they are broken. Just sit back and relax. You are running around like a headless chook with your editing, commentary, and actions. Slow down, proofread well, and enjoy the experience. — billinghurst sDrewth 14:33, 25 December 2015 (UTC)

I will attempt to take a chill pill, but I still have some long standing concerns abut how certain things should ideally be handled, and I don't won't to break things on future proofreading...

ShakespeareFan00 (talk) 15:41, 25 December 2015 (UTC)

For reference this what the help page actually said - Help:Page_breaks#Tables_across_page_breaks, it would appear to need updating. ShakespeareFan00 (talk) 19:25, 25 December 2015 (UTC)

Could you please point out what and where you think needs to be updated on the above mentioned page? — Ineuw talk 22:05, 25 December 2015 (UTC)

Currently the advice concerning tables (in the section I linked) appears to state you should put a a row break |- at the end of a table which is split over a page break as the last item in the main text of the page. As Billingshurst pointed out to me this confuses the pagenumber script which adds the page numbers on transclusion. The "row-break" |- should therefore be added after the {{nop}} on the continuing page, as opposed to the end of a page. I will wait for Billingshurst to comment more fully, as he discovered this issue. ShakespeareFan00 (talk) 00:08, 26 December 2015 (UTC)

It is the Method sections which I felt should ideally be updated.ShakespeareFan00 (talk) 00:10, 26 December 2015 (UTC)

I find the instructions are perfect and used them in hundreds of tables spanning pages. It can be seen on this and the following pages, and then check out the transclusion. I believe that there may be a misunderstanding regarding the place of the row indicator |-. I place it as the last table element in the body of the page, but not in the footer, unless there are special circumstances with regard to page numbers in the footer!!

Can you point to, or create temporarily a real world example of the problem in the page namespace?. You can transclude a pages into your sandbox, just as if it were in the main namespace? Otherwise the instructions should not be touched!!! — Ineuw talk 01:00, 26 December 2015 (UTC)

ineuw, come on, really? we have pointed to numerous examples here over the weeks and I have obviously fixed issues in the past day. We cannot point to the issues now as we fixed them. The issue is not the Page: ns, it is when the tables are transcluded. With your example page when it is transcluded, I don't even see the page number links (from phone), so it has some sort of issue for you to explore. — billinghurst sDrewth 05:33, 26 December 2015 (UTC)

Be nice!

In point of detail Page:Popular_Science_Monthly_Volume_42.djvu/887 and following do not precisely follow the instructions given in Help:Page_breaks#Tables_across_page_breaks. When viewed on a desktop platform only the first page number is rendered at Popular Science Monthly/Volume 42/Index.

As mobile is still in eternal flux mode I place no value on using such as a reference device at this point in time.

So the choice remains: shall we update the PSM pages to precisely follow the Help pages and presumably react to whatever breaks; or will Billinghurst actually review the Help pages and make (or at least advise on any) necessary corrections?

May I suggest everybody else holds off making changes until the various pundits settle their differences? AuFCL (talk) 06:07, 26 December 2015 (UTC)

Thought I was being nice, but perhaps we are referring to two different things!!!!. If you are referring to the page numbers along the left side of the transcluded pages (main namespace), that's no secret to me! It's because in the DjVu Index page number layout I named all the Volume Index pages as "Idx".

P.S: The layout system only lists unique designations, when 10 pages are coded as "Idx", there is only the first one shows up. — Ineuw talk 06:48, 26 December 2015 (UTC)

Just checked the mobile, and in Desktop mode the PSM pages numbers and a single "Idx" of the first page do show up — Ineuw talk 07:07, 26 December 2015 (UTC)

No Ineuw, I was not taking a pot-shot at you.

No, Ineuw, it is not true that making multiple index pages the same name results in PageNumbers.js producing only the first unique one. In fact the javascript contains code to explicitly attempt to side-step this very issue:

	function init_elem ( i, page_span ) {
		var name = page_span.getAttribute("data-page-number") || page_span.id;

		// what if two pages have the same number? increment the id
		var pagenumber_id = "pagenumber_" + page_span.id;
		var count;
		if ( pagenumbers_collection.is( "#" + pagenumber_id ) ) {
			count = ( pagenumbers_collection.filter( "[id ^= '" + pagenumber_id + "']" ).length + 1 );
			page_span.id += ( "_" + count );
			pagenumber_id += ( "_" + count );
		}

Even acknowledging all of this, I believe my earlier remarks still stand unaffected. I see no evidence that any of the involved parties are arguing this issue from an entirely common stand-point and until this changes this exercise will be a waste effort. AuFCL (talk) 07:39, 26 December 2015 (UTC)

It is poetic justice that just as I saved the above the example I was looking for popped up: Please have a look at The_Works_of_Robert_Louis_Stevenson_(Vailima_ed.)/Volume_8/A_Child's_Garden_of_Verses#TOC. Multiple matching index-page names; each of which appear in transclusion. The result clearly works but the Help page instructions do not match (Is this "Billinghurst" style perhaps?) AuFCL (talk) 07:49, 26 December 2015 (UTC)

@AuFCL: Thanks for your comments and the example. Also, my apologies to billinghurst. I will try that tomorrow because something is wrong at my end. Now, it's sheep counting time. Goodnight all. — Ineuw talk 08:51, 26 December 2015 (UTC)

It is not my pages that were broken, it was SF00's with the terminating row markers. These were fixed by making them starting row markers; so I related this experiences in their fixing. If others have solutions for having terminating row markers work with page numbers then bring them forth.

Keep me out of the battle of the help pages, I didn't write them, and I have done leading row markers for many years. — billinghurst sDrewth 13:33, 26 December 2015 (UTC)

┌─────────────────────────────────┘
@Billinghurst:, @AuFCL:, @ShakespeareFan00:, Think I solved the issue of the page numbers not-appearing in the transcluded page and where the {{nop}}' should be placed. These 10 pages of one continuous table, I realized the difference when I saw AuFCL's TOC example above, since I was also mystified.

the last 4 lines at bottom of page:namespace main text area

|-{{ts|vbm}}
|[[Popular Science Monthly/Volume 42/February 1893/Birds of the Grass Lands#D471-1|Birds of the Grass Lands.* S. Trotter]]
|align="right"|[[Page:Popular Science Monthly Volume 42.djvu/471#D471-1|453]]
{{nop}}
--------------------- beginning of footer
|} 

============ end of page

============ new page
{{RunningHeader|866|''INDEX.''|}}
{|width=450px align=center {{ts|bgt|al|bc}}
|-{{ts|vbm}}
|
|align="right" width="35px" {{ts|sm80}}|PAGE
|-
------------------------  end of header
{{nop}}
|-{{ts|vbm}}
|[[Popular Science Monthly/Volume 42/November 1892/Literary Notices#D137-0|Books noticed]]
|align="right"|[[Page:Popular Science Monthly Volume 42.djvu/137#D137-0|127]]

the first 4 lines at top of page:namespace main text area

The trick is not to terminate the table with a row marker |- at the bottom of the main text area and add the {{nop}} immediately after the last line (cell) for the page numbers to show up, and the use another {{nop}} at the beginning of the next page. You can check the indexes of previous volumes of PSM. — Ineuw talk 07:51, 28 December 2015 (UTC)

So there are two methods that can be used, though your solution requires particular text modifications in two different pages, whereas mine has it all at the top of one page. The help pages should provide the two alternate means, or a one preferred means, whilst neither is wrong. — billinghurst sDrewth 10:43, 28 December 2015 (UTC)

: Actually, I was wrong. Just tried with Popular Science Monthly/Volume 4/Index. It works without the {nop} at the bottom as long as the table is not terminated with |-. That is all we need to add to the Help page. — Ineuw talk 11:12, 28 December 2015 (UTC)

Regarding Popular Science Monthly/Volume 4/Index: the transclusion may well work but individual Page: displays do not (unless you consider this unimportant at this point in the proofreading cycle?) You still need some mechanism to force mediawiki to recognise the |} as structural rather than textual in the footer. There are several ways of doing this (blank line—regrettably not very visible—or {{nop}}—which might be regarded as excessive) without affecting the transcluded result.

The Help: instructions finally settled upon should be couched both in terms of being workable at all stages in the proofread cycle and catering for frequent situations which do not arise in this particular example, e.g. page numbers in footer? AuFCL (talk) 21:22, 28 December 2015 (UTC)

I was wrong again (sort of) . . . . without the row code |- and {nop] the page numbers will appear alongside a transcluded pagein the main: ns when there are tables spanning pages, but will also reveal the table closing |} code in the page: ns normally hidden in the footer. So, my first post is the correct one.— Ineuw talk 21:15, 28 December 2015 (UTC)

An example of Table Row and {{nop}}

I've inserted here the {nop} months ago (March 2015) when this issue came up in a discussion somewhere, but then it was spaced correctly and each link was in it's proper place. Since that time there had to be a change in the mediawiki code in one of the updates which caused this to bunch up. — Ineuw talk 21:56, 28 December 2015 (UTC)

Pummelled to death? AuFCL (talk) 04:31, 29 December 2015 (UTC)

Embedded page links and tables

You're all chasing your tails when it comes to this. The display of embedded page links on transclusion of a table across multiple pages might have "looked right" all this time but the truth is it never really worked the way it was supposed to.

1. Go to any main-space transclusion of a table broken across more than one page that you think is rendering correctly.
2. locate Display options in your sidebar menus and change page links beside text to page links within text.
3. now look at the embedded links again.

You'll see that from at least the 2nd embedded link on, <pagenum spans> are really being inserted at the end of whatever the last table cell's content is rather than at the exact point between one Page: to the next you'd think it would be a true indicator of (i.e. between closing and opening TRs). The only reason this particular scenario ever appeared correct to the "eye" is when the embedded page links are forced (floated?) to render in the left gutter (and the actual reason ... beside text is the default option and not ... within text); the <pagenum spans> still reside at the end of the content of the last cell of the last row on a Page: in relation to the Page: that follows regardless.

The only way to "fix" this (as well side-notes and similar) is to stop using the "span" design and use HTML5's <aside> element instead. Unfortunately, it is STILL not recognized by the everyday MediaWiki parser / Wiki mark-up so we're stuck with using hacks like NOP to continue to "trick" the eye into seeing something useful until that day arrives. -- George Orwell III (talk) 04:34, 29 December 2015 (UTC)

I grant you all this but if we are not all going to figuratively "live within Planet Hack" there really isn't a lot of point in waiting for a response to those plaintive mouse-like calls for it to be renovated into the dream paradise we all wish mediawiki was already? Assuming <aside> magically becomes available tomorrow what is the course we should be taking today to minimise the potential rework? AuFCL (talk) 04:47, 29 December 2015 (UTC)

Short answer: Re-work the entire Dynamic layout concept to something more HTML5-ish or more flex-box like; prune PageNumbers.js down into the 3 or 4 separate functions it's handling now as a single script in the process (or as need be).

Can't do anything like that here because things will "break" and stay that way until alternative avenues are vetted out with the best solutions possible & that takes time and effort. You're more than welcome to come help break things on test2.wikipedia.org with me but in all honesty I can't even manage to get things to match our current state close enough to consider it to be a valid and viable "testbed" just yet. So mostly I'm thinking the place to "restart" development is best done over there on Test2 no? -- George Orwell III (talk) 07:40, 29 December 2015 (UTC)

The display options is not available on the PSM main namespace pages because the pages are framed by {{PSMLayoutTop}}, which eliminates this issue of the display and all pages will look the same, for any reader. Which is what I wanted. — Ineuw talk 08:07, 29 December 2015 (UTC)

??? I can't recall any main-space PSM page transcluded in from the Page: namespace where I don't have a Display Options sidebar menu nor embedded page links back to the originating Page: holding the actual content being transcluded.

Please link a specific page where I'm not suppose to be able see either the Display options side-bar menu, the embedded page links or both. -- George Orwell III (talk) 08:14, 29 December 2015 (UTC)

Sorry, when I posted the above, it was missing. Now it's there. — Ineuw talk 09:26, 29 December 2015 (UTC)

I filed a Phabricator request concerning asides a a few months ago when I had the view that sidenotes as Asides would be a cleaner approach than some of the current approaches to sidenotes. ShakespeareFan00 (talk) 10:40, 29 December 2015 (UTC)

Missing pages in scans

Hello, I've recently come across a new problem for me, which is that I've come across scans that have pages missing. One book has two pages missing and the other has six. Since the books are 400+ pages I thought it would be a shame to not add them for a couple of missing images, so I added some empty pages where the missing pages were meant to be as placeholders with the hope that in the future a scan with these missing pages might be added. Do we have a category or a way for dealing with scans with missing, ripped half pages etc? If not I think we should create one so that hopefully scans with the omitted pages can be added in the future. Maybe a template in the style of the {{incomplete}} template that will automatically categorize the work and also state which pages are missing? Jpez (talk) 18:03, 25 December 2015 (UTC)

There was at one time a template you could put on "missing or damaged pages" ? ShakespeareFan00 (talk) 10:24, 26 December 2015 (UTC)

What about {{Bad page scan}} and related categories? Hrishikes (talk) 12:56, 26 December 2015 (UTC)

Yep that is exactly what I was looking for Hrishikes. Thanks! Jpez (talk) 14:49, 26 December 2015 (UTC)

Sidenotes namely ({{sn-paragraph}})

• Index:An Answer to the Declaration of the American Congress.djvu
• Index:Historical Works of Venerable Bede vol. 2.djvu

Currently portions of these use a highly experimental template for doing sidenotes, which produces a slightly cleaner layout (in my opinion).

However, certain comments have been expressed both recently and previously that it's incompatible with other Wikisource features.

There is STILL (despite previous discussions) NO clear means of implementing sidenotes and sidetitles, elegantly, neither of the current approaches being {{Sidenotes begin}}{{Sidenotes end}} or {{sn-paragraph}} respectively being ideal for all cirumstances. The former under some conditions leads to overlapping sidenotes (such as here - Page:Historical Works of Venerable Bede vol. 2.djvu/79}}, the latter avoids this, but in effect has to override a lot of Mediawiki formatting to do ii, and owing to certain parser handling raises other problems, such as the inability to make 'clean' start and end versions of the relevant template.

Because of the lack of resolution on the above in this work, Index:The pilgrims progress as originally published by John Bunyan ; being a facsimile of the first edition (1878).djvu I was using a third again less than ideal approach of inserting what would be the sidenotes as references.

It would be nice to have ONE approach, which had no issues, so where to go from here? ShakespeareFan00 (talk) 02:15, 27 December 2015 (UTC)

Northwestern University engineering students error correcting

• Engineering students fix common glitch in digitization of books published before 1700 wonder if worth a followup; is it opensource? can it be incorporated in WS? Slowking4♡RAN's revenge 02:35, 29 December 2015 (UTC)

Compendium I

Index:Compendium of US Copyright Office Practices (1973).pdf This is now complete.ShakespeareFan00 (talk) 16:43, 29 December 2015 (UTC)

well done, i will mention to the LOC folks, they may have other typed documents, that i will try to scan in the new year. Slowking4♡RAN's revenge 03:40, 30 December 2015 (UTC)

Wikisource also has Compendium II , which I also had a hand in typing up. My understanding is that the most recent edition (Compendium III), was already in digital format. ShakespeareFan00 (talk) 09:55, 30 December 2015 (UTC)