Wikisource:Scriptorium/Archives/2014-10

= Announcements =

User global javascript and css configuration
I am excited to announce that on Tuesday, August 26, we will be deploying the GlobalCssJs extension, which enables per-user JavaScript and CSS across public Wikimedia wikis. Users will be able to create global.js and global.css subpages on Meta-Wiki and these pages will automatically be loaded across all public Wikimedia wikis.

There is documentation available if you want to load JavaScript on a subset of all wikis (e.g., all Wikisources, all French language projects, etc.).

Some users currently have manually set up global JavaScript/CSS by creating local user subpages (e.g., monobook.js/css subpages) to load their global scripts. For these users, the deployment of the extension will mean that modules will be loaded twice, and they will no longer be included in global scope. A script has been prepared to delete these page if they were created in the standard format. Users can signup at a Meta-Wiki page to have this done on their behalf once the extension is deployed.

Thanks,

For your information. As Wikisource users tend to be crosswiki contributors (both within interlanguage sites and across sister sites), and occasionally editors of js and css files, this information is possibly of interest to you. — billinghurst  sDrewth  01:03, 20 August 2014 (UTC)

Global preferences

 * As I was editing my Preferences (replicating from the English) in the French Wikipedia, a silly question occurred to me. Why not provide a replication gadget of the user Preferences of global users on other Wikis. Access to this gadget on another Wiki where I plan to post/edit occasionally would be helpful and at the same time limit spawning the info to sites where there is little likelihood that I will be posting to, like Esperanto, but then who knows? — Ineuw talk 02:53, 2 September 2014 (UTC)
 * Having just looked at the installation instructions, I was disappointed to find that it's not just a gadget or preferences switch. Understanding how to create and modify these files makes them inaccessible to the average user (I am barely able to follow the instructions myself).  I guess that's for the future.  Laura1822 (talk) 12:27, 2 September 2014 (UTC)
 * @Laura1822: where are these installation instructions? Helder 18:16, 2 September 2014 (UTC)
 * I was referring to the page target of the first link above in the quoted announcement. Laura1822 (talk) 19:59, 2 September 2014 (UTC)


 * @Ineuw: what gadget are you referring to? Helder 18:16, 2 September 2014 (UTC)


 * BTW: I started a gadget for this task a few days ago (but it is still undocumented, sorry). Helder 18:25, 2 September 2014 (UTC)


 * I think you got my drift, the gadget doesn't exist yet, and there is no rush. It was an idea for a gadget which copies preferences from my Home account to the one where I activate the gadget. Since my home account is on English Wikipedia. I also understand that not every setting here corresponds, which is fine, setting those manually anyone can easily live with that. — Ineuw talk 19:00, 2 September 2014 (UTC)

Phabricator to replace bugzilla end of September
According to our plans, we are just a few weeks away from Wikimedia Phabricator Day 1. On that day, Bugzilla will be accessible in read-only mode, and all the bug reports will have been migrated to Phabricator. From that point, all bug reporting will be done in Phabricator.

We are very excited about this move. Phabricator provides a friendlier environment to new/casual users while offering a powerful collaboration platform for software development and project management in general -- all at once! For instance, users can edit task descriptions, one task can be assigned to more than one project (or none), and tasks can be organized in project workboards (i.e. http://fab.wmflabs.org/project/board/31/ ).

Learn about the launch at http://fab.wmflabs.org/T282. You can subscribe to this task to receive any updates.

This Day 1 is also relevant for other migrations (RT, Trello, Mingle, even Gerrit at some point) but first of all we want to make sure that the Bugzilla migration is well communicated and understood across all Wikimedia projects. For that, we need your help.

We are planning the communication activities at http://fab.wmflabs.org/T317 -- feedback and volunteers are welcome.

Learn more about Wikimedia Phabricator, and how we got to the point we are now after nine months of discussion and work: https://www.mediawiki.org/wiki/Phabricator

If you need help using Phabricator or you see other users with problems, check/improve https://www.mediawiki.org/wiki/Phabricator/Help. Support is provided at the related Talk page.

We will continue sending major updates to this list between now and Day 1. As always, we welcome your questions and feedback.


 * As a quick note. At a later point of time, once the migrations have occurred, there will be scope for the project management tools to be used for the non-technical aspects. Having used Trello, that type of tool will be interesting to see how functional we can make it; definitely something that we can use for managing maintenance. So the suite of tools has possibilities. — billinghurst  sDrewth  10:51, 7 September 2014 (UTC)


 * Query: Is Phabricator intended to always "stand apart" from the rest of the wiki-cluster (ala existing Bugzilla); or are logins intended to be eventually merged and/or OAUTH/login-by-credential access enabled? In other words, ought interested parties be applying for logins now, or would that be jumping the gun? (Or have I just missed something obvious?) AuFCL (talk) 11:07, 7 September 2014 (UTC)
 * Don't create any account, as once it comes out of labs space then it will use your existing wmf credentials, as per Phabricator/Help. (Labs environment tools purposefully don't utilise wmf credentials for security reasons.)

Please be kind to the cleaning crew
I've been going through the list of Queued to be validated and in case anyone knows of a book/work/project that's been proofread and waiting to be validated Please add it to the bottom of the list with the link preceded by the year and month as in YYYY-MM, (2014-09). P.S: I don't do windows - just in case it comes up. — Ineuw talk 21:33, 12 September 2014 (UTC)
 * I may (probably) have missed the point, but are you perhaps really looking for Category:Index Proofread? AuFCL (talk) 22:21, 12 September 2014 (UTC)
 * Or try something along the lines of (for a semi-automated list):

 category=Index Proofread ordermethod=lastedit addfirstcategorydate=ISO 8601 order=ascending 
 * Sample output (limited to random 10 entries):

 count=10 category=Index Proofread ordermethod=lastedit addfirstcategorydate=ISO 8601 order=ascending 
 * ? AuFCL (talk) 22:51, 12 September 2014 (UTC)
 * I was referring only to the list of the 50 titles at the above link. Only BWC can answer why they were listed there. All I wanted to do is add the year & month to the list to prioritize them by date.


 * Of course your list is the correct one for all works waiting to be validated, if we were planning to do validations based on the oldest proofread date. — Ineuw talk 03:23, 13 September 2014 (UTC)


 * Oops. More fool me. I should have read your request more carefully before deciding what you really wanted. Pardons, please? AuFCL (talk) 03:38, 13 September 2014 (UTC)


 * It's not an issue. Unwittingly, I butted into User:Beeswaxcandle's territory. I acted on the wrong assumption and will clear it up with BWC. — Ineuw talk 19:27, 13 September 2014 (UTC)

Scroll-wheel in ProofreadPage
I'm not too sure if this counts as a proper announcement; and in any case not being a complaint it might result in culture-shock around these parts resulting in summary censorship. Considerably to the contrary: I have just noticed that (presumably since the last version upgrade) the scan image may once more be resized using the mouse/scroll-wheel in Firefox during edit sessions. This feature has only been broken for me continuously for the last twelve months (or maybe more) so a big thank-you from me to whomsoever wishes to claim credit for the fix. AuFCL (talk) 10:56, 21 September 2014 (UTC)
 * More like 2 or 3 versions ago. See https://gerrit.wikimedia.org/r/153304 Prior to that (& if I recall correctly), it was intentionally crippled for some reason or another and refinements since have allowed for its "recent" return. -- George Orwell III (talk) 11:31, 21 September 2014 (UTC)
 * I must have just become used to not expecting it to work, so simply never retried. I did notice on my very rare and occasional forays into μSoft/I.E. land that it has been working for several months there. AuFCL (talk) 11:47, 21 September 2014 (UTC)
 * I used it for the first time in ages just the other day, and it was useful. But I must admit, I never realised it’d been broken! I normally am on a big wide monitor, and with the left sidebar completely removed, and so the scans appear rather big anyway. &mdash; Sam Wilson ( Talk &bull; Contribs ) &hellip; 03:59, 22 September 2014 (UTC)

mul: interwiki now exists
It quietly happened in the mediawiki release last week git #f0d86f92 - Add additional interwiki links as requested in various bugs (bug 16962, bug 21915) that the mul: interwiki has appeared for the wikisources to be able to point to wikisource.org. So we can now do mul: and it appears in interwiki links as "More languages". We will have a number of places, especially in the project namespace where we need to do some additions. I am in the process of spreading this marvellous news to the broader community. I would like to thank for their coding and review to get this through and to  for listening to thoughts about Wikisources' place in the WMF-sphere. Now to see how we can get mul: working for Wikidata. — billinghurst  sDrewth  03:39, 29 September 2014 (UTC)
 * See The Lord's Prayer for an example of the language link in action. It would be easy to apply custom styling (e.g. bold, italic) to the "More languages" link in the sidebar on a global basis, if the community decided to do that. This, that and the other (talk) 07:55, 29 September 2014 (UTC)
 * billinghurst, do you know whether this was announced in m:Tech/News? I don't remember seeing it.  If not, we should add it, as a subtle advertisement for Wikisource.  ;-)  WhatamIdoing (talk) 15:09, 1 October 2014 (UTC)
 * I don't believe so, is this something that should be added? I haven't had the time to look at the resolution across all wikispace, I just spoke about it in the wikisource and wikiversity universes. — billinghurst  sDrewth  23:34, 1 October 2014 (UTC)

= Proposals =

A template that causes links to Wikipedia to appear in dark blue
There is a lovely template here at Wikisource that causes links to terms defined at Wiktionary to show up as a subtle dark color. Why don't we create a similar that causes links to to appear  dark blue  or some similarly subtle shade? It would make heavily linked technical work easier on the eyes and help prevent unintended emphasis of linked terms less significant to the text. Abyssal (talk) 15:18, 4 September 2014 (UTC)

Asking for input on category name for images of technical and instructional support of WS
Based on the principle of 1 picture is worth. . . . I have been uploading various images of


 * problematic editing practices like this File:Wordwrap in header caused by double vertical bars.jpg
 * images of browser differences
 * technical issues
 * instructional support
 * etc.

and looking to group them under a single category. I came up with Category:Instructional images about Wikisource but would prefer community input. — Ineuw talk 13:11, 18 September 2014 (UTC)

= BOT approval requests =

=Help=

=Repairs (and moves)=

= Other discussions =

What do you want from search?
I had the opportunity to discuss local search with WMF's search guru here at Wikimania. Some of my questions were about some of the improvements that I would like to see occur, and what, if anything, could we do to improve our data structure for search (of which I now have some homework, and thinking).

The challenge back to us, was what more did we want from search? What can't it do, that we want it to? So the question to the community ... What searches have you tried that have failed? What searches have you tried that only partially met your needs? What more would you like to be able to do with local search? — billinghurst  sDrewth  15:23, 7 August 2014 (UTC)


 * When you search for, Author:Jules Verne is the 22nd result (you do not see it unless you click on "next 20" or choose to show more than 20 results at a time).--Erasmo Barresi (talk) 16:29, 7 August 2014 (UTC)
 * Discussed at WM2014, and for us the Author: field can be given a higher weighting. Just needs to have bugzilla done, which I will do when I am at home and have access to my passwords and a little more free time. — billinghurst  sDrewth  19:28, 13 August 2014 (UTC)
 * not sure what has changed, however, when I do the search the author page is the top link for me. So unless you can replicate something else, this is a WORKSFORME (WONTFIX) — billinghurst  sDrewth  11:30, 17 August 2014 (UTC)
 * I totally agree with Erasmo in the context that I prefer more than 20 results at a time. In fact, I prefer all 500 search results shown. It is easier to look down a full list and a search from my browser will help spot the result I want but 20 at a time is far too short. Also, I would like to be able to search for a book's name that is under construction without having to try placing "Index" in the search. What is the url for WM2014? (looks like my initials and this year) —Maury (talk) 07:10, 15 August 2014 (UTC)


 * https://wikimania2014.wikimedia.org/wiki/Wikimania --Erasmo Barresi (talk) 08:37, 16 August 2014 (UTC)


 * There is a range of page display links from 20 to 500 on a search, so you can display them as you like ...


 * I know. I somewhat stated it above but not as well as  "default 500" above. —Maury (talk) 06:21, 20 August 2014 (UTC)


 * ...If you are wanting this to be a remembered default, then I would encourage you to put in a new bugzilla request against the Mediawiki product line. Where the request would be that there be a means to remember a personal search preference, that is residual either for a session or as a permanent preference. — billinghurst  sDrewth  05:48, 20 August 2014 (UTC)


 * billinghurst, preference default 500 is what I was trying to explain in my archaic way. But it is not any sort of a necessity -- just a preference -- which perhaps may be good for everyone here to have under setting our "preferences" if it is not too difficult. If it is difficult then abort the idea.["ping" must be for mobile devices but I have none.] Thank you for your reply and better wording than mine. Respectfully, —Maury (talk) 06:21, 20 August 2014 (UTC)


 * When I search for a word or phrase, I do not want a gajillion Catholic Encyclopedia returns swamping out the few items that were not in the CE. I'm not sure what approach would work best, but possibly some sort of subgroupings of search results whose "directory" is the same, or a means of filtering out selected directory groups once I've gotten search results. --EncycloPetey (talk) 11:39, 16 August 2014 (UTC)


 * I have entered a bugzilla for WMII about his preference for the ability to set a results display preference. — billinghurst  sDrewth  07:27, 20 August 2014 (UTC)

Something has changed... Author:Jules Verne is now the 23rd result rather than the 22nd! Okay, seriously, I can no longer find the "search options" section in my preferences, so I can't tell you why we get different results.--Erasmo Barresi (talk) 12:19, 18 August 2014 (UTC)

Also, I just repeated the search while temporarily logged out, and the author page was still the 23rd.--Erasmo Barresi (talk) 12:37, 18 August 2014 (UTC)
 * May I confirm precisely the same results: position 23 here: both logged -in and -out. AuFCL (talk) 12:48, 18 August 2014 (UTC)
 * Weird, today I am back to getting a result on the second page. I will complete a bugzilla for this component. — billinghurst  sDrewth  05:48, 20 August 2014 (UTC)
 * 69771 that asks for author: ns to be given same weighting in search results as main ns. — billinghurst  sDrewth  06:10, 20 August 2014 (UTC)


 * On a similar vein of thought, I have asked whether there is more that we can do to align our main and author ns header templates to better function/interact with CirrusSearch. As we utilise parameters with microformat data there may be good opportunity to align aspects, or get some advice about how we can configure for better alignment. — billinghurst  sDrewth  07:07, 20 August 2014 (UTC)

News on 69771, author ns: rating
Nik reports in the bugzilla that he has made some code changes that should go live in a couple of weeks. We should watch the CirrusSearch sections in the roadmaps for rollout and do our testing. We should also ping wikisource-l on the completion of our request and the results of testing. It is pertinent to their efforts. — billinghurst  sDrewth  23:51, 17 September 2014 (UTC)

Steps
What are the steps to create or submit a 100 year old document in wikisource, i'm new here? (Monkelese (talk) 09:20, 29 August 2014 (UTC)
 * What is the source document? ShakespeareFan00 (talk) 12:10, 29 August 2014 (UTC)
 * What stage is the work that you are considering? Is it just in book form and need scanning +++? Is it scanned and in either a DjVu or pdf file? Or maybe individual jpgs, and if the latter, how many pages? Typed or written? Depending on its stage is going to very the length of the advice. So a little extra information is going to be helpful. — billinghurst  sDrewth  12:12, 29 August 2014 (UTC)
 * Thought you could copy and paste an article that is more than a hundred years old, its a memoir located at pbs website and it was published in the 1800s. (Monkelese (talk) 16:43, 29 August 2014 (UTC)


 * You could just copy and paste an article, but the best practice here is to have the transcription and the scan side by side. What's the title of the document you have in mind? Who's the author? Maybe there's a scan available somewhere on the Internet.--Erasmo Barresi (talk) 07:59, 1 September 2014 (UTC)

Internet Archive releases 2.4 million images scanned from pre-1923 books
The Internet Archive has just released 2.4 million images to Flickr, extracted from scanned pre-1923 books (with perhaps five times that more to come, in the next few weeks)

I have started a project on Commons to explore and understand the set, and start uploading relevant batches, at
 * c:Commons:Internet Archive/Book Images collection

with the initial thought of proceeding along the lines of the existing
 * c:Commons:British Library/Mechanical Curator collection

But it could use some advice at this, the blank page stage, from people who know about book resources as they exist already across the Wikis.

For example, how much is there already from the IA that's been uploaded to Commons or Wikisource or Wikidata ? And how is it being held / described ? Are there already quite good automated approaches for extracting metadata from the IA and/or Open Library ?

Initially, I've been thinking to use quite a simple link-back template on book-image category pages, along the lines of eg c:Template:BL1million bookcat as used at the top of this category; but I'd welcome advice on this.

The advantage of such a simple template is that it is easy for users to apply by hand, with very little input being required, until such a time as templates can be created that can automatically draw all relevant information from Wikidata (which probably requires Phase 3 on Commons). But if people think the project should be being more ambitious, and especially if there are already any easy ways to draw the relevant data automatically from IA to fill out more advanced templates with minimum effort, that would be very valuable to know.

Please do join in and sign up on the Commons page now if you would be interested in mapping and understanding this collection. Jheald (talk) 18:27, 30 August 2014 (UTC)


 * Good news for Internet Archive, Flckr and the Commons, bad news for me. — Ineuw talk 18:51, 30 August 2014 (UTC)


 * Why??? Is there something I'm not understanding? Jheald (talk) 19:36, 30 August 2014 (UTC)


 * Sorry, it's my humor. I've done almost all of the images for the commons:Category:Popular Science Monthly illustrations project and numerous other books, and am attracted to working on 19th century images. An additional 2.4 million images conflicts with my other - previously made commitments on WS. Can the Commons wait until I catch up? On a more serious note - I foresee numerous duplicates between this and earlier contributions. — Ineuw talk 20:19, 30 August 2014 (UTC)


 * Well, if we can identify which books have previously been most heavily uploaded, that would help with not re-uploading them. Is there a category tree on Commons for material sourced from the Internet Archive?  I couldn't find one; but often with commonscats, first you need to know where to look...
 * One thing I should note about these Flickr uploads is that there is often very little metadata, very little machine-readable description, very little machine-readable basis for categorisation, not even a meaningful file name -- so all the work you've done remains invaluable, and any suggestions as to how we can get even a little of this data more automatically would be brilliant. Jheald (talk) 21:05, 30 August 2014 (UTC)
 * the metadata is pretty bad, so lots to cleanup manually. it should be familiar to WS’ers since it’s all OCR’d unclear what the value of an engraving of a painting already uploaded is, or if anyone scanned a book page at higher resolution; but there will be lots of images to illustrate an article without an image. Slowking4 ♡Farmbrough's revenge 14:27, 31 August 2014 (UTC)
 * the metadata is pretty bad, so lots to cleanup manually. it should be familiar to WS’ers since it’s all OCR’d unclear what the value of an engraving of a painting already uploaded is, or if anyone scanned a book page at higher resolution; but there will be lots of images to illustrate an article without an image. Slowking4 ♡Farmbrough's revenge 14:27, 31 August 2014 (UTC)

Tech News: 2014-36
 Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.

Recent software changes
 * You can now test a new Beta Feature to see links to other wikis in the sidebar. The links come from Wikidata.
 * You can now search pages that link to a page. Use the  keyword in your search.
 * A redirect to a section now changes the URL in the address bar of your browser. If "Dog" redirects to "Animals#Dog", you now see "Animals#Dog" instead of "Dog#Dog".
 * If you are testing Flow, you now have a Flow tab in your Notifications. It is called "Messages". [//www.mediawiki.org/wiki/Echo_(Notifications)/status#2014-08-monthly]

VisualEditor news
 * You can no longer delete required fields in templates.
 * We fixed many Internet Explorer bugs. If you use Internet Explorer 11, you will get VisualEditor next week. Support for earlier versions is coming next.
 * VisualEditor now looks better in Monobook.
 * We fixed a bug where some of your typing could be undone when you used "cut" (Ctrl+X).
 * You will no longer see empty or deleted categories among the suggestions when you add a category.

Future software changes
 * The latest version of MediaWiki (1.24wmf19) is on test wikis and MediaWiki.org since August 28. It will be on non-Wikipedia wikis on September 2, and on all Wikipedias on September 4 (calendar).
 * There is a proposal to build a database on Commons for file data. It will make it easier to see the author, license and topics. You can give feedback on this idea. You can also come to the IRC chat on September 3 at 18:00 (UTC) in  at freenode.
 * You can give feedback on Media Viewer until September 7. You can say what needs to be improved and ask other people to give feedback too.
 * You can test a new version of the tool to show math. It uses MathML. Report bugs in bugzilla.
 * You will no longer be able to upload images from the mobile site.

Tech news prepared by tech ambassadors and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.  07:49, 1 September 2014 (UTC)

Highlighting points worthy of further discussion
From the above post it is worth highlighting and starting discussions on some of these aspects as they have some bearing on our approach, or they could. There are a number of significant changes there.

In the past few years we have utilised the adaptive template plain sister to display our xwiki sister links, and these have displayed within the respective namespace headers (top right, generally in the notes section equivalents). With Tpt's script in beta, there is now the ability to have sister links displayed, for an example turn on the beta and look at Author:William Shakespeare. So the community should be discussing whether we a) want just the existing header links, b) want just sidebar links, or c) allow both to exist as people will get used to sidebar links, however, more overt linking is useful, especially in the eyeline — billinghurst  sDrewth  15:36, 1 September 2014 (UTC)
 * Sister links in sidebar in beta


 * With all due respect, what a cleverly designed, useless feature. For example, when enabled gap reveals that it is apparently equivalent to wikipedias (because some clever-clogs has determined it to be so in wikidata&hellip;) Whether you check or just trust my call, they are not remotely the same template or coding, so:  Choice 1: How do we go about fixing this sort of linkage error?  Choice 2: How do we prevent some well-meaning (you know you want me to say one of the other words for this) nincompoop from trying to merge incompatible objects?  My 2¢. AuFCL (talk) 22:24, 1 September 2014 (UTC)
 * I'm sort of in agreement with AuFCL here but if some Users: enjoy being the dog chasing it's own tail by hunting down inconsistencies between sister-sites or being led down the wrong roads altogether, I don't see why this could not be a User enabled preference or gadget if need be. But try add something like this WOT as a forced site-wide default extension or something and I'd be 1000% against it. Plus, I'd sort of like to see what possibilities in the personal-bar/side-bar areas present themselves from the expected pruning of "skins" from the core code first - positioning stuff like that might become obsolete in an instant. -- George Orwell III (talk) 01:04, 2 September 2014 (UTC)


 * Template:Gap & Template:Spaces fixed; however, I'd like to see a more positive attitude to sister-project volunteers.--Erasmo Barresi (talk) 08:22, 4 September 2014 (UTC)

This new search query allows us to undertake a new series of criteria for search based on the target, and also allows us to use  which may be a useful maintenance tool. Also useful for research searching, eg. which would return pages that mention Banjo Paterson but do not link to the author page. As a community, I think that there is definitely work for us to do to explore the options in mw:Help:CirrusSearch and put some local spin on how to exploit the new power, and also with some of the Extension:DynamicPageList uses. — billinghurst  sDrewth  15:36, 1 September 2014 (UTC)
 * search filter
 * This looks worthy of further exploration; count me in. -- George Orwell III (talk) 01:04, 2 September 2014 (UTC)

Index:Compendium of US Copyright Office Practices, II (1984).pdf
One more chapter of the original and the Index.

Anyone want to help get this finished? ShakespeareFan00 (talk) 19:39, 1 September 2014 (UTC)

Grants to improve your project
Greetings! The Individual Engagement Grants program is accepting proposals for funding new experiments from September 1st to 30th. Your idea could improve Wikimedia projects with a new tool or gadget, a better process to support community-building on your wiki, research on an important issue, or something else we haven't thought of yet. Whether you need $200 or $30,000 USD, Individual Engagement Grants can cover your own project development time in addition to hiring others to help you.
 * Submit your proposal
 * Get help: In IdeaLab or an upcoming Hangout session PEarley (WMF) (talk) 15:21, 3 September 2014 (UTC)

Status check. Index:The Great Secret.djvu
Do they adverts count for validation ready? ShakespeareFan00 (talk) 19:33, 4 September 2014 (UTC)
 * No, adverts are outside the scope of the text that we use to indicate an index is validated. — billinghurst  sDrewth  13:31, 6 September 2014 (UTC)

Index:A History of Hindu Chemistry Vol 1.djvu
I have just added this work. It's an acclaimed masterpiece in 'history of science' genre, by India's foremost chemist of the modern era. I am now working on other items that I have started here, so all of you are welcome to try your hands at this work. I'll add the pictures to Commons which can be accessed from this work's category. If no one else gets interested, then of course I'll start work on it after finishing my current projects. Hrishikes (talk) 17:33, 6 September 2014 (UTC)

Where is everyone?
I see no new messages, edits, &c being posted. The place looks abandoned. Is everyone watching football? That is over here in the US. —Maury (talk) 04:02, 7 September 2014 (UTC)


 * I'm here, most days. Just don't have anything to say. Wikisource doesn't seem quieter than usual, to me. :) &mdash; Sam Wilson ( Talk &bull; Contribs ) &hellip; 03:13, 9 September 2014 (UTC)


 * I check my watchlist daily. Hi Maury. :) Abyssal (talk) 03:30, 9 September 2014 (UTC)

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

VisualEditor news
 * From Thursday, Internet Explorer 11 users will get VisualEditor. Support for earlier versions is coming next.

Future software changes
 * The latest version of MediaWiki (1.24wmf20) is on test wikis and MediaWiki.org since September 4. It will be on non-Wikipedia wikis on September 9, and on all Wikipedias on September 11 (calendar).
 * You will soon confirm a "Thanks" inline instead of in a dialog.
 * You can read more about the plan to move to Phabricator, a tool that will help people develop the MediaWiki software and report bugs.

Problems
 * There were problems with JavaScript and CSS on Friday, September 5 because of a code error.

Tech news prepared by tech ambassadors and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.  09:33, 8 September 2014 (UTC)

Licensing of a re-edition of Flora of Northumberland and Durham
I was informed that Flora of Northumberland and Durham is about to be re-published in a re-edited version based on the Wikisource version, and the question arose what the licensing should be. The original book is obviously in the public domain, but publisher and editor plan to go for CC BY, since the re-editing is a significant effort. Yet because the book went through Wikisource, would CC BY-SA play any role here? -- Daniel Mietchen (talk) 09:38, 8 September 2014 (UTC)
 * Wouldn't clause 7h. (Modifications or additions to material that you re-use) under [//wikimediafoundation.org/wiki/Terms_of_Use#7._Licensing_of_Content the Terms of Use] apply in this case? AuFCL (talk) 09:54, 8 September 2014 (UTC)
 * I may be wrong, but I have been under the impression that transcribing a work verbatim from the original is not enough to create a copyright claim. Hence, the edits can't be relicensed under Wikimedia's umbrella CC-BY-SA because converting the image to text isn't adding any new creativity to the work.  All the edits are public domain in that regard.  I don't think it matters what the editor uses (so long as it's a legitimate claim) because they're really just using a public domain endeavor already.—Zhaladshar (Talk) 13:21, 8 September 2014 (UTC)
 * Wot Zhaladshar said! Sweat of brow doesn't invoke a change of licence, so the only components that are new are the header templates, and the data contained; so the existing licensing is what to use. That said, they can give credit for our efforts. — billinghurst  sDrewth  14:58, 8 September 2014 (UTC)


 * oh, go put "all rights reserved" on it, everybody else does. if they’re going to use the images in the linked articles, they are CC-BY-SA. are they publishing in US or UK? sweat of brow is dead in US given Bridgeman, but there is no case law yet in UK. we also don’t have any case law about the CC-BY-SA transcription of PD works (that i know of, & ianal). i see someone needs to transcribe pages 147-435 quick to complete. ;-p  Slowking4 ♡ 15:28, 8 September 2014 (UTC)
 * Just to be clear, the images were made by the Biodiversity Heritage Library and although I would have liked help on Wikisource, I did all the proofreading myself. Wikisource will be credited as the place where the proofreading was done. So I'm not trying to take anything from Wikisource. The project had to be copied out of Wikisource, because there doesn't seem to be a way to georeference locations effectively and there were many other annotations I wanted to add that would have been difficult or impossible in Wikisource. The only reason we want to make the licence more open is because additional licence restrictions hinder scientific use of the document. Please feel free to help me out with my next flora project https://en.wikisource.org/wiki/Index:The_Botanist%27s_Guide_Through_the_Counties_of_Northumberland_and_Durham_(Vol_1).djvu.Qgroom (talk) 18:46, 8 September 2014 (UTC)
 * love your work; i’ll help you anytime. i note you have linked to the wikipedia articles and wikispecies, for only the first three pages of plants. (are you planning on using those in the publication?) i would suggest more use of the template:smallcaps and template:center. i’ll make some notes on the work talk page, about the usual WS transcription norms. <font face="Vijaya"> Slowking4 ♡ 00:17, 9 September 2014 (UTC)
 * Thanks Slowking4 for helping with those pages. You are a lot faster than I am, so you may have to change your name. I'd like to finish adding links to wikipedia articles and wikispecies, I think this adds a lot to the document. Please do comment on transcription norms, I have a lot to learn!Qgroom (talk) 08:17, 9 September 2014 (UTC)
 * To sum up, it seems to me that Qgroom can go ahead with publishing the re-edition under CC BY. Of course, would be nice to see this new version here on Wikisource at some point, but this seems difficult technically at the moment. --<font style="font-family:Monotype Corsiva; font-size:15px;"> Daniel Mietchen (talk) 02:08, 9 September 2014 (UTC)
 * The re-edition is now live at 10.3897/ab.e4002. --<font style="font-family:Monotype Corsiva; font-size:15px;"> Daniel Mietchen (talk) 09:35, 11 September 2014 (UTC)

Echo and watchlist
Special:Notifications & Special:Watchlist substantially overlap in functionality, except the former also contains extra (some non-public) events and doesn't provide with passive usage options (means to turn off web-nagging or email-nagging and to just keep visiting the page whenever I'm free), while the latter doesn't provide with options of active web-nagging notifications (but already provides email interface). Partly, in my personal view, the Echo/Notifications project was driven by low usability of watchlist; comes to mind. It's also perhaps worth noting that Echo users aren't exposed to Special:Notifications unless thy have JavaScript disabled — in which case it's their only means of reading the notifications.

I'd like to get this done: Thoughts on both, please? --Gryllida (talk) 02:27, 9 September 2014 (UTC)
 * 1) Merge these two pages into one.
 * 2) To remedy large inflow of information, introduce multiple levels of importance of the web-nagging notifications (red for mentions, orange for thanks, blue for new watchlist items, etc and configurable in your settings).


 * i thought they were migrating features to notifications; from echo to flow. i.e. it’s threaded conversations, not workflow. watchlists and recent changes are a failed work task model. maintenance categories are slightly better. it’s a replacement for talk pages. this is a project of the WMF, are you in touch with them?  <font face="Vijaya"> Slowking4 ♡ 03:00, 9 September 2014 (UTC)
 * Slowking4, "from echo to flow" makes no sense to me (not even after reading the link provided). Flow items are currently in both the watchlist and notifications.


 * well, my analysis, opinion is that notifications incorporated features of echo, but could be / will be migrated into flow. put a reply button there, or ping user other than thanks, and it looks like threaded conversations. (parallel; independent of talk pages) it sounds like you want to change the notifications interface; that sounds like a WMF project, and i’m sure they would love your feedback; interactive prototype. i’m not sure WS should have a custom one; i’m afraid WS’ers will have a big meh. maybe an essay about your wants, needs, philosophy, and then an action plan, would clarify how to move forward.  <font face="Vijaya"> Slowking4 ♡ 00:18, 10 September 2014 (UTC)


 * This is a "would we like this done?" discussion; means to do it (through WMF Engineering or a Chapter) are a different beast... --Gryllida (talk) 22:13, 9 September 2014 (UTC)
 * For me there is absolutely no functional overlap between the two. Notifications tell me when someone has thanked me, left a message on my talk page, or reverted an edit I've made. The Watchlist tells me about edits that anyone has made to the pages that I'm interested in monitoring. I'm quite happy with it this way and cannot see the point of merging the two. I don't want to have the little red box appear immediately upon anyone editing one of the pages on my watchlist. When I'm logged in, I check RC relatively often and when I first log in I check my watchlist immediately. In respect of the "large inflow of information", we are a small wiki and there isn't a large enough volume to warrant a series of little coloured boxes spread across the top of each page. Beeswaxcandle (talk) 06:52, 9 September 2014 (UTC)
 * This would be configurable. I can see a need in different terms for the two notification modes ('watchlist' mode is passive, 'notifications' mode is web nagging or email). To me, the lack of ability to set up watchlist to be active, or notifications items to be passive (I can't get them to appear on Special:Notifications without the web nagging in the corner), makes no sense. -Gryllida (talk) 22:13, 9 September 2014 (UTC)


 * I'm with Beeswaxcandle on this for basically the same reasons & I just don't see the point or even possible a need for merging the two. Plus there are several combinations of User preference settings that can refine the interaction (or separation) of the two functions even further. Sorry -- George Orwell III (talk) 22:48, 9 September 2014 (UTC)
 * I am even more simplistic. These are global functionalities, and are meant to be consistent across wikis (no surprises). Any discussion about functionality belongs at the respective pages, and in more global discussions, even if there was discussion about local customisation, it would and should belong in the bigger picture, and about how a user configures it, not something designated at a local level. — billinghurst  sDrewth  01:08, 10 September 2014 (UTC)

Change in renaming process
''Part or all of this message may be in English. Please help translate if possible.'' Single-user login (SUL) finalisation's goal is so that every Wikimedia editor has a single, recognized global account with one username across all projects. As you may know, after a long delay, it's now underway as an effort between bureaucrats, stewards, and Wikimedia Foundation engineers. This will also allow for development of cross-wiki tools like global notifications and watchlists. There is no set date for the completion of single-user login finalization at this time.

The process involves changing all rename processes into one global renaming process. The ability for local bureaucrats to rename users on this wiki will be turned off on Monday, 15 September 2014, as one of the first steps. Global renamers are in the process of being created to make sure projects and languages are represented by the time this occurs. I sent a note to every bureaucrat about this process three weeks ago with an invitation to participate and many have begun requesting to be a part of the group. Together with the stewards, the global renamers will be empowered to help editors work through the often difficult process of getting a global name.

In parting, visit Special:MergeAccount to unify your account if you have never done so. If your local pages about renaming still need to be updated, please do so and consider pointing people to m:SRUC for future rename requests, especially if this project does not have bureaucrats that hold global renamer permissions. If you have any questions, you can read more on the help page on Meta. You can also follow the technical progress on mediawiki.org. Contact me on Meta any time with questions as well. Thank you for your time. -- User:Keegan (WMF) (talk) 9 September 2014 16.22 (UTC)


 * If necessary, I can answer questions, and assist any lost souls. — billinghurst  sDrewth  00:06, 10 September 2014 (UTC)

Link templates that change default colours — seeking opinions
Philosophical question. I am wondering what the community thinks of templates like Template:WiktGray and Template:WikiDark that change the colour of links, and forces them to a determined colour. It is my understanding that the community has put forward a position that we prescribe less, rather than more, and that if there is particular looks that users want, they are free to define them in their personal common.css setting. The rationale for such templates is to remove the visual impact of the applications of the templates. Which might be a solution masking a problem of overlinking.

So do we have an issue that forcing link colours is an issue? Is masking of links an issue of overlinking? Is it time to review our guidance on linking? My personal opinion probably comes through a little in the means that I am addressing this matter, however, my opinion is just one among many, and probably good to start a thread where opinions are sought on these matters. — billinghurst  sDrewth  22:51, 9 September 2014 (UTC)
 * Wikilinks our (long-proposed) proposed policy
 * Philosophical answer: One should never attempt to remove useful functionality. (Begging of course the question of what is "useful." Topic for entirely another day.) The capability of link colour changing after visitation is well-established and should not be lightly stomped upon. As pointed out, individual users are entirely at liberty to suppress this kind of behaviour without adverse effect upon those who like or rely upon it occurring. This is one of those "Damned if you do; damned if you don't" situations, and the best anyone can do is to try and determine if the majority of users in any given situation can stumble along without disruption. The remainder will be "hurt" (for, one hopes only a minor buffetingly amount of "hurt") in any case; and it is merely human nature that the thus inconvenienced will howl the loudest. Kind of makes judging a non-trivial task.  Here endeth the lesson. AuFCL (talk) 00:40, 10 September 2014 (UTC)
 * Which says somewhat, if it is a needed functionality &hellip; widespread, then we should gadgetise such a behaviour &hellip; some individuals, then we give instructions and code on how to make that change in Special:MyPage/common.css. — billinghurst  sDrewth  01:13, 10 September 2014 (UTC)
 * Agreed. And this brings us to the other side of the overarching issue: over-linking. This is also another DiydDiyd situation, however one in which I personally lean the other way. Too many links for one audience is not enough for another and vv. I vote we send a message of appreciation to those who put in the effort of researching and making linkages; and hold our tongues in criticism of those who don't even bother. Harsh words? Well you posed the question, so don't blame me if you don't like the response&hellip; AuFCL (talk) 01:39, 10 September 2014 (UTC)
 * And if the link-er is a complete boob? Then what? Play periodical policeman for each link on top of the existing proofreading scheme? And at what price? The body of work-integrity we are all suppose to be striving for? No thanks. I'll take my content with the least amount of 3rd party influences as possible - especially when it comes to those that take you completely off project. -- George Orwell III (talk) 02:00, 10 September 2014 (UTC)
 * And the cycle is complete. See "Begging the question&hellip; above. Wash, rinse, repeat. You could add something along the lines of "complete idiocy aside" but why bother? See difficulty of judging above. Well that went off the rails even faster than this little cynic expected. AuFCL (talk) 02:30, 10 September 2014 (UTC)


 * George's "off-project" comment captures my main concern. We editors all grok the Wikimedia sister project structure, and we're accustomed to it, so we aren't impacted by suddenly finding ourselves at Wikipedia or Wiktionary. But for a visitor unfamiliar with Wikimedia, they click on a link and suddenly find themselves at a different site that kinda sorta looks the same but kinda sorta doesn't. They may not be aware that they have changed sites, yet their searches pull up completely different content. Bewildering. For this reason, I don't like to see cross-wiki links embedded in work texts at all — link to key sister project information in the header notes, and redlink conservatively to local portals within the text. Hesperian 02:43, 10 September 2014 (UTC)


 * I agree with what Hesperian says here. We go to such lengths to replicate the originally-published look of books, but then throw in completely non-fidelitous hyperlinks. Confusing. &mdash; Sam Wilson ( Talk &bull; Contribs ) &hellip; 03:10, 10 September 2014 (UTC)


 * "Laws, like sausages, cease to inspire respect in proportion as we know how they are made." I quite agree rubbish links should be removed. I just don't necessarily agree that we possess enough facts to categorically rule out certain cases. We should be wary of conflating contexts. We (editors, sysops and bureaucrats) all happen to be effectively curators of the works on WikiSource, and are thus subject to the "familiarity breeds contempt" syndrome. As such none of us may be taken as a trustworthy/impartial audience in this kind of matter. Because we happen to see too many links does not imply the end-consumer will, in a properly constructed system flow. After all why use mediawiki (whose raison d'être happens to be easy creation of linkages) if the aim of the exercise is not to use that very feature? Are we (or more accurately the system designers) insane? If the EPUB generation process were indeed sane (nobody will quite agree that in its current form it is) then virtually all links will be stripped out on the basis that they do not actually make a lot of sense for that class of consumer. As for lacking "periodical policemen," how can anybody exist in the wiki-world without agreeing there are a surfeit of self-appointed volunteers for the rôle? The problem has always rather been to usefully occupy all that enthusiasm more productively. And links to other wiki-family members are a similar conversational non-starter: most outsiders do not even know there is a difference between the various WMF sister projects. They think we are just WikiPedia, so we all might as well swallow our pride and just get used to it.  However, EPUB is not the only end-consumer. A web-based reader might expect links to be present for terms we consider quite unimportant. WikiData cross-references stuff you would not believe; and perhaps one day links may be automatically/mechanically inserted in places we cannot currently imagine. (Ever heard of something I believe is called a "dictionary?")  Who are we to stipulate works we have been involved in may never be used in such a fashion? I am not saying stripping links is necessarily bad policy; I am merely emphasising this is not a simple arm-chair critic issue, and that absolutely no matter what choice is eventually settled upon somebody will be disappointed so just get yourselves prepared to be  no matter how this matter is resolved. AuFCL (talk) 08:35, 10 September 2014 (UTC)
 * And in a related note to AuFCL's query "why use mediawiki (whose raison d'être happens to be easy creation of linkages) if the aim of the exercise is not to use that very feature?", I have to ask what good does it do to archive some kinds of texts here if we're not integrating them with other Wikimedia content through links? My own archiving here is focused on public domain scientific papers. Since they're public domain they're freely available, but their technical nature implies the inclusion of contents like tables, leader boxes, footnotes, diagrams, etc requiring complex and tedious formatting during the proofreading stage of archival. If the final Wikisource archive offers no more functionality than the original and already freely available PDF, then what benefit to the world will my efforts produced?


 * Archiving a scientific paper dense with the aforementioned complexities can take enough time for me to write multiple articles for, each getting 2,000-5,000 views while on the main page, and more traffic afterward than a Wikisource archive would get. I see integration with other Wikimedia content to be the extra layer of functionality and value that justifies the effort involved in archiving the text and distinguishes it from the original source PDF. Abyssal (talk) 09:46, 10 September 2014 (UTC)


 * I think links should be standard colours. It's easy enough to override things in one's own stylesheet. The other factor that comes up with these for me is that lots of ereaders (eink ones anyway) don't support changing font colours or even text-decoration. This means that links appear as underlined and so appear to have greater emphasis than the writer intended. @AuFCL, I am very grateful that people go to the effort of researching and adding links, but I do sometimes find them distracting, that's all. (Hmm... maybe all I need to do is add an option to the epub export tool to strip all links! That'd solve the problem for me. I never use the links.) &mdash; Sam Wilson ( Talk &bull; Contribs ) &hellip; 02:26, 10 September 2014 (UTC)
 * There is a mediawiki PRINT option (of which I need to read more, and will find the link later) that removes certain components of a work. It sounds like that could be of use for any non-screen version at a bare minimum. Otherwise, it may be something that we ask of Tpt that the epub versions strip non-WS links. Epub forms output is something that we also need to readdress as numbers of us are now more familiar. — billinghurst  sDrewth  03:49, 10 September 2014 (UTC)
 * These pages may address some of the print issues ... w:Help:Printable, mw:Manual:Skinning, and mw:Manual:FAQ — billinghurst  sDrewth  13:59, 10 September 2014 (UTC)


 * I don't think the epub export uses much that's common with the built-in print view stuff. It basically concatenates the HTML output of the Page NS pages of a work and wraps it up with some metadata. But you're right, epub output should become much more of a priority now that many more people are using it. I reckon the option to remove links would be great. &mdash; Sam Wilson ( Talk &bull; Contribs ) &hellip; 04:56, 10 September 2014 (UTC)
 * are you able to offer some authoritative guidance on this? — billinghurst  sDrewth  13:59, 10 September 2014 (UTC)

Index:The London Gazette 28314.pdf
The scan quality on these leaves a lot to be desired, so I am considering leaving this for someone else who can get access to better scans. ShakespeareFan00 (talk) 12:18, 10 September 2014 (UTC)
 * No real point putting it here. Mark the index file in some way that indicates that the File is going to need an update. It is such a specialised work of which you want the scan, it is unlikely anyone is going to see it here in passing and just go hunting for it for you. — billinghurst  sDrewth  14:10, 10 September 2014 (UTC)

Index:Q Horati Flacci Carminum librum quintum.djvu
Should really by at la.wikisource.org also, but doesn't currently seem to be present there. ShakespeareFan00 (talk) 13:01, 10 September 2014 (UTC)
 * It may be, however, the English pages have been set to be here, which is correct for a twin language work. — billinghurst  sDrewth  14:06, 10 September 2014 (UTC)

Index:John Wycliff, last of the schoolmen and first of the English reformers.djvu
Anyone want to take on the tables at the end of this work? Other than the tables and the images this ones ready for validation. ShakespeareFan00 (talk) 18:21, 11 September 2014 (UTC)
 * Tables complete.ShakespeareFan00 (talk) 09:36, 12 September 2014 (UTC)

Statutes of Wales.
 OK For wikisource? 1908 Work, seemingly published in the UK. Author died in the mid 1930's. ShakespeareFan00 (talk) 14:14, 12 September 2014 (UTC)
 * It seems OK here with .--Jusjih (talk) 05:28, 30 September 2014 (UTC)

EbyDict project
user:Ijon talked about his hebrew dictionary project at wikimania beginning at 40:00. he has some interesting pdf partioning for non-wikicode editors. is it possible to incorporate this in a wikisource wizard more generally? <font face="Vijaya"> Slowking4 ♡ 14:13, 13 September 2014 (UTC)

Index:The statutes of Wales (1908).djvu
Uploaded this and in the course of constructing the page list found 2 missing pages.

Not too much of a problem, given that IA has 2 different versions, namely: Both of which have the 'missing' pages.
 * 
 * 

I know that the file can be patched (and I could "patch" these myself, but wanted someone else to do this to confirm that they are in fact all the same edition, and so that the relevant underlying text layer was also patched, which I wasn't sure how to do yet.ShakespeareFan00 (talk) 21:18, 13 September 2014 (UTC)
 * File here(and Commons) patched with 'placeholders'. ShakespeareFan00 (talk) 23:19, 13 September 2014 (UTC)

Tech News: 2014-38
<section begin="technews-2014-W38"/> 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 software changes
 * You can now change the style of links to disambiguation pages. This is done with the  CSS class.
 * There was a problem on right-to-left wikis with Wikidata log entries. The text was messy in watchlists and recent changes. The problem is now fixed. The same problem will be fixed soon for user names.
 * New users are randomly chosen for a test on 12 Wikipedias. They get messages with ideas of articles to edit. The ideas come from what they have already edited.

Problems
 * There was a problem with loading images on September 10.

VisualEditor news
 * If you don't select text when you add a link, the link now shows a number.
 * The citation tool no longer offers to reuse a citation if there are none on the page yet.
 * You can now use help buttons in the "" menu to see what the options are for.

Future software changes
 * The latest version of MediaWiki ( 1.24wmf21 ) is on test wikis and MediaWiki.org since September 11. It will be on non-Wikipedia wikis on September 16, and on all Wikipedias on September 18 (calendar).
 * These changes are coming with the new version:
 * If you use Internet Explorer 7, JavaScript will no longer work. JavaScript tools and scripts will no longer work in that browser. You should update to a newer browser. [//www.mediawiki.org/wiki/Compatibility#Grade_C]

Tech news prepared by tech ambassadors and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe. <section end="technews-2014-W38"/> 08:34, 15 September 2014 (UTC)


 * To note that next week (Thursday is the plan at the moment) that there will be a new beta feature. This feature will allow you to use the new php servers (HHVM) to call up your pages, and this new setup is meant to be quicker than the current call (Varnish). So if you plan to turn it on, find a big page and call it up, and time its appearance, then turn on the beta and rerun the test. Record your data somewhere if you can be bothered, and we can provide back back to WMF about how we see it work with out multi-transclusion pages. — billinghurst  sDrewth  14:49, 15 September 2014 (UTC)
 * THe HHVM beta preference actually rolled out within the last 24 hours, and is now available. — billinghurst  sDrewth  05:20, 19 September 2014 (UTC)
 * Apologies if this has been noted elsewhere but in case anyone else is interested the following link selects all Page: namespace edits performed recently using HHVM ( I appear to have embarrassed the system daemons; or perhaps they are out to embarrass me. This very item was tagged as processed by the VM, and just about every single edit I have made since as well. AuFCL (talk) 05:55, 20 September 2014 (UTC) Does anybody know if only certain types of user—or perhaps only a certain proportion of edits—are eligible for processing by the new method?): [//en.wikisource.org/w/index.php?namespace=104&tagfilter=HHVM&title=Special:RecentChanges Recently changed Pages on enWS processed via HHVM] AuFCL (talk) 04:05, 20 September 2014 (UTC)
 * All edits using the HHVM are being tagged by WMF as a means to identify issues. — billinghurst  sDrewth  07:35, 20 September 2014 (UTC)

Post-Reformation Digital Library
I've just added support for d:Property:P1463 on Module:Authority control. This property is particularly very interesting because their website lists book digitizations for a given writer in many languages. See for example Author:Hugo Grotius (http://prdl.org/author_view.php?a_id=952), or even pt:Autor:Jerónimo Osório (http://prdl.org/author_view.php?a_id=4642). Lugusto 14:17, 16 September 2014 (UTC)

Change to the enhanced toolbar, again?
Who is changing the layout of the enhanced toolbar. . . again? and why? and why is it called "enhanced"? GO3 and BWC won't be happy when they return from their camping trip.— Ineuw talk 20:38, 16 September 2014 (UTC)
 * Thanks for noting this. I thought I'd gone loopy&hellip;again. AuFCL (talk) 20:59, 16 September 2014 (UTC)
 * It got changed as part of 1.24wmf21. I've given up and reverted to the "normal" toolbar and will reinstate my buttons shortly. When that gets deliberately broken again, I'll probably find something else to do in my spare time. There is patently no interest in enabling editors to actually work. All "they" seem to be doing is experimenting with code and creating new toys that aren't wanted, don't work as advertised and replace things that did work. Why? Because they can. Beeswaxcandle (talk) 21:09, 16 September 2014 (UTC)
 * Thank you both for confirming that I am not crazy either. — Ineuw talk 02:09, 17 September 2014 (UTC)
 * Can't speak for BWC, but surely you meant "as well"? AuFCL (talk) 02:21, 17 September 2014 (UTC)
 * The only thing that I can see relating to WikiEditor in the last update is this and it only seem to relate to on/off in the Page: ns. If there is a specific problem, then we need to lodge a bugzilla. — billinghurst  sDrewth  03:06, 17 September 2014 (UTC) who doesn't use it, so doesn't know the issue
 * Speaking strictly selfishly I have no ongoing problem with this change short of it adding momentarily to my background level of confusion. I have a couple of private scripts which depend upon certain DOM constructs which it turns out have not fundamentally changed this time anyway. AuFCL (talk) 08:19, 17 September 2014 (UTC)

Here I go again - a day late and a dollar short... What exactly is the problem? Maybe my cache needs to catch up but afaict, all that has changed is the move to WikiEditor-like icons for button images in the page namespace and the quirk about one or both User prefs being selected now produces the same WikiEditor toolbar above the noinclude header field regardless of the selection(s). What specifically did I miss here? -- George Orwell III (talk) 23:34, 17 September 2014 (UTC)


 * When I first wrote the post the mdash was missing, but it showed up mysteriously and miraculously. Now my only comment is that the magnifier set of icons is so pale that I need a magnifier to see them, and the icon to switch between side by side and over/under editing looks like a gallows. Otherwise, everything is OK. — Ineuw talk 00:44, 18 September 2014 (UTC)


 * The icon change took place in https://gerrit.wikimedia.org/r/157115 While I don't think he/they got the end rendering size quite right for the toggle-header/footer & layout buttons either, I'm not seeing any issue with the three magnification buttons like you seem to have.  I'd bring it to Tpt's attention first and see if a bugzilla is necessary from there. -- George Orwell III (talk) 01:00, 18 September 2014 (UTC)


 * I am not complaining - my comments were to entertain you. Let's see if others share my observations. — Ineuw talk 01:24, 18 September 2014 (UTC)


 * the only thing that stays the same is the constant change. it’s unclear if it’s improvement. it’s small beer. are we not trying to model best practices of communicating with the community? where is the outreach and inquiry?  <font face="Vijaya"> Slowking4 ♡ 03:09, 18 September 2014 (UTC)


 * (e/c) For me it has nothing to do with the look of buttons, but where they live on the screen. Up until the change was released, the beta toolbar sat comfortably between the header and the body fields and the CharInsert was where it should be "under the edit window" (to quote the gadget text in Preferences). Afterwards, the first thing on the page was the CharInsert, followed by the toolbar, then the usual fields. However, press TAB twice to move into the Body and *poof*, CharInsert and toolbar both off the top of the screen and into pointless existence. In addition, the leading in the body field seemed have increased further, which in turn extended that field further down the screen. Beeswaxcandle (talk) 03:33, 18 September 2014 (UTC)


 * Isn't the Charinsert in your setup is on the bottom? In my implementation - The code added by User:helder.wiki  window.charinsertMoveHigh = true;  is only effective, (if at all,) if I have BOTH editors selected in Preferences. Otherwise it stays in the bottom. Although, I haven't neutalized this code to test - but will now do so and report to you. Just in case, pls check your Preferences. — Ineuw talk 13:38, 18 September 2014 (UTC)


 * Here are the results:  window.charinsertMoveHigh  does nothing! Left it at true, then neutralized it, and then set it to false, it had no effect on Charinsert's placement with the all the toolbar selections. Mind you, I am using the Modern skin to gain some additional space. These were the final results:


 * Charinsert below the edit window exists only with the legacy toolbar. Just switching toolbars in Preferences, changes nothing.
 * To force Charinsert to be below the edit window, disable both toolbars and save Preferences. Enable legacy toolbar, save, and Charinsert stays at the bottom.
 * If the enhanced toolbar is enabled, Charinsert moves above the edit window, regardless if the Legacy toolbar is also selected or not.
 * Note, I cleared the caches between each test. But then, who knows? Now I have the enhanced toolbar selected, the code line  window.charinsertMoveHigh  is set to False, and Charinsert is above the edit window. — Ineuw talk 14:47, 18 September 2014 (UTC)
 * I see the same now that I've focused just in the Page: namespace. Everywhere else, my attempt to legitimatize "load high" in the CharaInsert core .js seems to behave as desired (when set) just as it works when not setting it (loads above edit summary instead of completely after the edit section [or Old EditTools]). I said it when I announced it - somebody needs to double check my work. -- George Orwell III (talk) 18:25, 18 September 2014 (UTC)


 * Woe is me, I never bothered checking any other namespace, like here. I changed the common.js code reference to true it still shows on the bottom here, (Not that I care). 18:51, 18 September 2014 (UTC)


 * About the icon change, I agree with you. The new icon are not very nice (but I think better than the old toolbar icons that looked wired in the WikEditor). Feel free to open bugs on bugzilla about it. Tpt (talk) 16:48, 18 September 2014 (UTC)
 * Nah. What we need is somebody really into graphics/images to take a stab creating/improving the WikiEditor style buttons (rarely is an author also the illustrator to put it another way). -- George Orwell III (talk) 18:25, 18 September 2014 (UTC)
 * Perhaps we can advertise on the Commons Village Pump - sort of a contest? — Ineuw talk 18:51, 18 September 2014 (UTC)
 * I think getting some options, and a swell of opinion/support for one (something approaching a consensus) would be a good way to progress, then lodge the bugzilla. — billinghurst  sDrewth  00:07, 19 September 2014 (UTC)
 * +1. Could you organize a such thing? Tpt (talk) 09:43, 19 September 2014 (UTC)
 * Hold up a sec. While I agree discussion and consensus is worth doing on this point, I don't think the point actually focuses on where "we" would like to arrive someday in the future. Deciding which images to use for toolbar buttons is rather minor in the larger scheme of things the way I see it.

The main sticking point is, of course, the "old" toolbar (Classic) versus the "enhanced" toolbar (WikiEditor). Recent events have made it rather clear that the primary hang up between the two camps is the amount of screen area each one takes up and how that screen space is utilized and/or rendered. The "Classic" toolbar, with its smaller buttons and tighter layout (only 8? buttons by default), obviously lets you load up on buttons, cuts down on the amount of back & forth scrolling needed when editing and, being in place for so long now, is well understood by many tweakers. WikiEditor, in its current out-of-the-box form, is generally thought of as having the opposite characteristics of those traits. It seems to me that if experienced Users could do away with the drop-down sub-menus and extra dialogs of WikiEditor altogether into a single "row" of buttons then filter which buttons are generated in which namespaces instead, it would go a long way in resolving the current 'back & forth' between the two camps while also staying mindful of the implementations yet to come. Let's get some "manually added" buttons to execute some of the more common functions first and then worry about what that button "looks like" afterwards. -- George Orwell III (talk) 11:26, 20 September 2014 (UTC)

Javascript changes coming soon ("All your scripts are going to break" edition)
This information has been sent out for weeks, if not months, but I'm not sure if it's reached this project in a way that makes sense to the people who need to know about it. This message is for you if you could be described (even a little bit) by one of these categories:


 * Volunteers developing gadgets (such as Twinkle, HotCat, etc.).
 * Users that maintain their wiki's MediaWiki:Common.js scripts.
 * Users that have their own personal scripts.
 * Users who get questions when other people's scripts break (like you).

Several deprecated methods in MediaWiki's JavaScript modules will be removed soon (early October). Please check your code to ensure it won't break with these changes, and update it if needed. Please also check and fix any gadgets or scripts you or your wikis rely upon, to prevent breakage.

What's going to break
Deprecated methods to be removed in MediaWiki 1.25:


 * Remove mw.user.name method. 1 Use mw.user.getName instead.
 * Remove mw.user.anon method. 1 Use mw.user.isAnon instead.
 * Remove mediawiki.api methods' "ok" and "err" callback parameters. 2 Use the returned Promise interface instead.
 * Remove mediawiki.api.category "async" parameter. 2 The ability to override $.ajax to not be asynchronous has been removed. The default (asynchronous) behaviour remains. Use the Promise interface to retreive the fetched data from the API.
 * Remove jquery.json module. 3 Use standardised JSON.stringify and JSON.parse methods. And depend on the "json" module to ensure a polyfill is lazy-loaded for cross-browser support.

If your script contains these functions, then they're going to break. If you use a script, and the author isn't active any more, and you don't know whether it's going to break, then I believe that all you need to do for the first couple is read (or search) the script and see whether the bold-faced words appear in them. If not, then it should be okay. I saw some of the cleanup over at the English Wikipedia a few weeks ago, and it didn't look too difficult.

When it's going to break
These removals will land in MediaWiki 1.25alpha in early October 2014, being deployed to Wikimedia wikis in October 2014 (probably 1.25wmf2 or 1.25wmf3).

How to stop things from breaking
If nobody here can figure out what needs to be done, then you can ask for assistance on the the wikitech-ambassadors mailing list.

If you know more, if you've already updated certain scripts, or if you're able to help people, then please feel free to post that information here. WhatamIdoing (talk) 05:21, 18 September 2014 (UTC)


 * With such news, we usually shoot the messenger.— Ineuw talk 12:58, 18 September 2014 (UTC)


 * We have nothing to do with the UK-Scotch referendum - why are we being treated this way? -- George Orwell III (talk) 18:32, 18 September 2014 (UTC)
 * Over the weekend, I will see if I can search through all local mediawiki: and user: ns .js files for the identified components. I will also see if I can generate a list of all called external files within the same files, and see if I have the skills to identify how big an issue that we have. I will probably have to beg for help in the pywikibot irc channel, however, that is within my skill set. — billinghurst  sDrewth  23:29, 18 September 2014 (UTC)
 * Ineuw, I had a very similar feeling when I saw the e-mail message about this. The only difference is, if I shot that dev, they might have to delay this set of changes by a couple of weeks.  Shooting me wouldn't be very productive.  (The people I feel particularly sorry for are people running private wikis.  For some of them, it's going to be like upgrading your computer's operating system and discovering that your favorite software application no longer works.)
 * User:Billinghurst, were you able to find out what you needed to know? WhatamIdoing (talk) 01:48, 21 September 2014 (UTC)
 * I haven't get to it, sleeping at the keyboard last night was ineffective for my nascent pywiki-coding (and gave my forehead an interesting pattern). — billinghurst  sDrewth  08:46, 21 September 2014 (UTC)

Observed Breakages
1.25wmf1 (ab89c52) is now deployed on enWS. As of this morning I am observing javascript errors from a couple of gadgets; notably: The following items may be indicative of failure to load/changes in CSS: This is all I have been able to analyse so far... AuFCL (talk) 23:12, 1 October 2014 (UTC) Please ignore the above. I am a victim of my own idiocy. I happen to be forced to use a banking application that refuses to work without a faked browser user agent. Guess what breaks when I forget to set it back to the default value? Yep: mediawiki&hellip; AuFCL (talk) 02:55, 2 October 2014 (UTC)
 * "Strike out links to blocked users" gadget: "ReferenceError: mw is not defined"
 * "UserMessages" gadget: "ReferenceError: $ is not defined" (triggered by "$(template_onload);" statement)
 * Some of the ProofreadPage icons have reverted to text-only forms (e.g. "Previous page", "Next page", "Index" tabs)
 * The "thanks" and "add-to-watchlist" functions now break (e.g.) browse history flows (they used to be rather more discrete and return to the ongoing activity.)
 * The Preferences function now presents as a monolithic list, without breakage into tab-groups as before.

Malaya papers

 * File:British hansard (1963) Malaysia bill.djvu
 * File:Ukpga 19570060 en.djvu
 * File:Hansard_(1963)_Malaysia_bill_Clause_1.djvu
 * File:Hansard_(1963)_Malaysia_bill_Clause_2.djvu
 * File:Hansard (1963) Malaysia bill Clause 4.djvu
 * File:MALAYSIA BILL (Hansard, 22 Juli 1963).djvu
 * File:MALAYSIA BILL (Hansard, 26 Juli 1963).djvu
 * File:MALAYSIA BILL ADJOURNMENT (SUMMER) (Hansard, 30 Juli 1963).djvu
 * File:MALAYSIA BILL BUSINESS OF THE HOUSE (Hansard, 11 Juli 1963).djvu
 * File:MALAYSIA BILL RHODESIA AND NYASALAND BILL (1) (Hansard, 11 Juli 1963).djvu
 * File:MALAYSIA BILL RHODESIA AND NYASALAND BILL (2) (Hansard, 11 Juli 1963).djvu
 * Index:Report of the Commission of Enquiry North Borneo & Sarawak.pdf

In respect of some of the above files now deleted at Commons I'd like a FORMAL apology in respect of my time having been wasted, given that my efforts have seemingly been wasted because of the whims of certain individuals.

The undeletion request at Commons was closed as being stale. Nobody seemingly reads Undeletion requests at Commons it seems. ShakespeareFan00 (talk) 23:11, 18 September 2014 (UTC)
 * Settle petal &hellip; patience. You know that this is political, contentious, and where I have been causing a ruckus, and I have more political capital than you. Sometimes people will need to quietly change their minds when the focus is removed. If you want an apology, go to the user talk page of the person involved and make your case. Excuse us if we don't wish to join in, and wish to explore other avenues. The blunderbuss is a one-shot piece of equipment. — billinghurst  sDrewth  00:03, 19 September 2014 (UTC)
 * well, i’m sorry, but commons will never be, since it’s a morally broken place. "stale" gamesmanship is nothing compared to socking in order to vote stack. or templating peoples talk pages. get in line, (see also wikimania talk about wikimedia israel & URAA). i have my own fights; i bet i’ll get blocked before you. i have been known to upload under a new name using commonist, so it’s not blocked by wizard, teehee. <font face="Vijaya"> Slowking4 ♡ 00:13, 20 September 2014 (UTC)


 * That aside, the deletion of those files (plus several others in this case) causes [//en.wikisource.org/w/index.php?title=Special:LonelyPages&limit=500&offset=1200 orphans for us] in the Page: namespace. This happens every so often with a file here and a file there; no problem. But when its like this - multiple files deleted around the same time - the list becomes unmanageable with orphans running into the hundreds. Add to that the unwillingness of our ever mysterious Page: namespace caching to properly recognize all the newly orphaned files in the latest list refresh, sometimes files can appear weeks after the fact causing unnecessary investigation, etc. more often than not. If commons is going to delete one of the source files that has Page:s created under an Index: here on en.WS, they should delete any existing pages created in the Page: namespace first, followed by deleting the Index and finally the File: itself in that order not just the File:, while quietly absolving themselves of the problem(s) that creates. -- George Orwell III (talk) 01:18, 20 September 2014 (UTC)
 * I completely disagree GOIII. These files should not have been deleted. There has been sloppy process, and poor decision-making at Commons. Simple fact is that the files should not have been deleted. And, it is my contention where Commons feels the need to delete djvu/pdf file that are in use at enWS, they should be contacting us about this, though this is an obligation that they deny having. — billinghurst  sDrewth  07:06, 20 September 2014 (UTC)
 * Its exactly that denial that leads me to hold the above position - otherwise I'd probably be in the same camp as you on this (especially after following your efforts to date on this point). Plus I don't have any conflicting interests to tip-toe through either; I'm only concerned with fulfilling my duties here (I'm always trying to operate with a mindset of Wikisource rules while other projects drool in short). That said, the logical path to pursue now in light of their lack of acceptance of some sort of modified notification or timetable to date is to attempt to force these additional deletion tasks upon "them" here when a source file is deleted there. They already do something like this when an image file (.jpg, .png, etc.) is renamed/deleted on Commons; a bot comes through and diligently amends or removes the File: statement as the new file-status dictates. How can they argue any different when it comes to .Pdf or .DjVu files? Any argument that the current routine merely edits existing pages for File: usage while the additional tasks require full-on deletion are mere mechanics - the ultimate point/cause behind both scenarios is exactly the same....
 * Something you shmucks on Commons did there stopped the display of an image here. Its up to the same offender to either formalize that stoppage with the needed housekeeping (i.e. delete all existing Page: and/or Index: pages created under that source file just like when your Bot removes any "calls" to render image files when those are deleted) or implement some new set of guidelines between Commons and WS on how to handle this issue once and for all; enforce said guidelines across the board.
 * To reiterate - the obligation cannot be disputed since it is already in practice. Its up to them to completely follow through on that obligation. We propose they handle/automate the additional deletions needed for proper housekeeping; the fact page deletion rather article editing would then be involved is par for the course. At the same time, we are open to discussing alternatives IF (in the end) they will be enforced/practiced without the need to go 12 rounds every other week over every single file in question (like it seems to be now). Heck, even if they agree to automatically move the file to local Wikisources instead of simply deleting it there - leaving it up to us to follow up on copyright, etc. - would be an improvement over what we have now. -- George Orwell III (talk) 10:37, 20 September 2014 (UTC)

I have undeleted these files at Commons, and relicensed them. — billinghurst  sDrewth  07:57, 21 September 2014 (UTC)


 * good work, perhaps we need a clearing house for like minded admins at commons, and then only as a backup, a migration to a local copy. <font face="Vijaya"> Slowking4 ♡ 00:41, 23 September 2014 (UTC)

Future Alternative Work-flow?
I do not want to distract unduly from the above discussion, but may I float the idea of reordering the sequence and location of workflow for future projects? Maybe instead of initially uploading the composite image/scan file, be it .PDF or .DJVU directly to Commons, might it make more sense to upload it instead to the relevant primary language WikiSource and perhaps transfer it only later in the transcription process when more "eyes" have reviewed it and its consequences, be they copyright or whatever? I am not pushing this approach so much as pointing out there are perhaps other ways of approaching the issue. If Commons regards the WikiSources as "too hard" to support, perhaps some other form of push back along the lines of their diminished relevance might find a better balance point? (This last line can surely be less confrontationally worded—suggestions welcome; anyone?) Even (worst case) if this is an already known bad-idea&trade; perhaps the very fact the community is entertaining such thoughts may be of itself useful leverage? "Too hard" can cut both ways. AuFCL (talk) 11:17, 20 September 2014 (UTC)


 * i doubt that commons would care. keep in mind there are people who upload images to english, with a no transfer tag, image gets transferred anyway, and file gets deleted. but the local wikisource version should be in preparation. the WMF is well aware of the common "problem", but it will take a lot more to motivate change. some culture change is desperately needed; it will be a long time. in the meantime, we will need to route around problem. <font face="Vijaya"> Slowking4 ♡ 03:08, 21 September 2014 (UTC)
 * Depressing but true. And there is the entire problem in a nutshell: how to go about idiot-proofing the process, bearing in mind just how perversely clever the average idiot can be. AuFCL (talk) 04:26, 21 September 2014 (UTC)

Localisation needed File:Survival of the Fittest, JC Squire, 1916.djvu
This file is hosted on Commons, but the author seems to be by an author who died in 1958, meaning the file is not necessarily compatible with the licensing zealots at Commons.ShakespeareFan00 (talk) 17:37, 21 September 2014 (UTC)
 * I will do it later today. — billinghurst  sDrewth  23:21, 21 September 2014 (UTC)
 * ✅ Sitting locally with From Commons awaiting conversion to local version wtih do not move to Commons. — billinghurst  sDrewth  00:33, 23 September 2014 (UTC)

File metadata cleanup drive
The File metadata cleanup drive is an effort started in September 2014 by the Wikimedia Foundation. Its goal is to fix file description pages and tweak templates to ensure that multimedia files consistently contain machine-readable metadata across Wikimedia wikis.

This is relevant to us as we still own numbers of files in this space, and need to tidy to get them to commons, or properly retained here, or discarded. So it would be worthwhile those who have maintenance wishes to review the page. 01:51, 22 September 2014 (UTC)

Tech News: 2014-39
<section begin="technews-2014-W39"/> 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 software changes
 * You can test a new Beta Feature called HHVM. It should make editing faster. Please report bugs if you see them.

Problems
 * There was a problem on the English Wikipedia on September 19. It was due to edits on a template used on many pages.
 * Sites were down for users in the Pacific area around 7:00 UTC on September 20. It was due to a problem in the San Francisco data center.
 * There were two bad bugs messing up articles in some browsers in VisualEditor. We fixed the bugs and updated the sites.

Software changes this week
 * The new version of MediaWiki ( 1.24wmf22 ) is on test wikis and MediaWiki.org since September 18. It will be on non-Wikipedia wikis on September 23, and on all Wikipedias on September 25 (calendar).
 * If you have more than 2000 notifications, the oldest ones will be removed.
 * In the "Vector" skin, the icon used for users will show a neutral gender.
 * The VisualEditor template tool now tells you if a required field is missing.
 * The "Cancel" button of the VisualEditor save window is now called "Resume editing". This shows that you can still edit and you won't lose your changes.
 * There are new keyboard shortcuts in VisualEditor. Use Ctrl+Shift+6 for  and Ctrl+Shift+5 for strikethrough.
 * In VisualEditor, you can now see that you are switching to the source editing mode. Before, it was not clear it was happening.

Future site changes
 * You can see a plan for the move to Phabricator. It's the new tool to track bugs. A guided tour will be done via video on September 24.  

Tech news prepared by tech ambassadors and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe. <section end="technews-2014-W39"/> 09:05, 22 September 2014 (UTC)

Illustrated London News
Hello, a german user has collected some links to digital copies of The Illustrated London News. Would it be possible to transfer them to english wikisource? I don't know if it is common to collect such links here, it looks like you are only collecting source texts, because you have no templates for linking to Google Books or Internet Archive.--Sinuhe20 (talk) 11:47, 22 September 2014 (UTC)


 * . A page of links, and information like that, for us would belong at Portal:The Illustrated London News which is curatorial, rather than in our main namespace, which we reserve for reproduced material. We have such information like that for other newspapers, and it is one of those tricky items where there is a grey area between curated, and links, and one that we have yet to perfect. You can see Portal:Notes and Queries as an example of a similar work. With regards to the deWS page and transfer here, we can host an English language version at the suggested portal link. For links to external source material we use ext scan link, though we do have IA, and have no real need for Google Books outside of the former template to this point of time. — billinghurst  sDrewth  00:28, 23 September 2014 (UTC)


 * Thank you for your answer. So there seems to exist some differences between english and german wikisource. As a service to the reader we try in addition for newspapers to collect all electronic files which can be found in the internet (and which can spread out in many different sources). For that we have what we call theme pages, which are maybe equivalent to your portal pages and which will then be linked in our corresponding wikipedia articles.--Sinuhe20 (talk) 07:14, 23 September 2014 (UTC)

Index:The Monkey's Paw.djvu
Drama copyright? 1910 work so PD-US. If published in UK dramtist died in 1944 and it won't be out of copyright until January. (Which isn't that long to wait).ShakespeareFan00 (talk) 14:26, 24 September 2014 (UTC)


 * For Commons purposes, it's derivative of a British work by an author who died in 1943, and co-published US/UK by a dramatist who died in 1944. It's free for WS purposes, and I would suggest just not bothering it for Commons purposes.--Prosfilaes (talk) 23:33, 24 September 2014 (UTC)

Index:The Pilgrim's Progress.djvu
The underlying work is PD, (text clearly is), the illustrator around in 1943. Only remaining issue is when the edition was published, so it's correctly indicated in the metadata, IA source doesn't give an edition date :( ShakespeareFan00 (talk) 21:01, 24 September 2014 (UTC)


 * The text is not self-evidently PD; I know that Shakespeare editions tend to be glued together from several originals, and I don't know the textual history of the Pilgrim's Progress, but sufficient editorial changes can be copyrightable. When did the illustrator publish the illustrations is a necessary question for copyright, too. I'm guessing the library got their copy in 1967--page 2 has 67-73312 typed into it, which is not in fact a LCCN, but follows the format, so I think it's a local library number of the same format. Thus I would assume this edition was published after 1950, which would leave the biography, for one piece, under copyright for sometime, even given only the anonymous 70 years and not the US 95. I think a well-dated edition should be found and this one deleted.--Prosfilaes (talk) 23:45, 24 September 2014 (UTC)

Identfying authors
Was considering a transcribe on the work listed here to be done by October 31st. User:ShakespeareFan00/Halloween but having run into concerns about anthologies before, I felt it best to compile a list of stated authors (based on titles in the work.)

The assistance of other contirbutors used to doing authorship confirmation would be appreciated.

The reason I am checking before uploading is because although the work is a US Pre 1923, I couldn't be certain some extracts and poems had a subsisting non-us copyright.

ShakespeareFan00 (talk) 22:30, 25 September 2014 (UTC)


 * Globally speaking, might be the case: "non US-copyright" covers many jurisdictions. Is this a Wikisource concern, however? PD in the USA is certainly the criterion used for the DNB and other big collective works here. Charles Matthews (talk) 04:51, 26 September 2014 (UTC)
 * Well it is a concern because it determines if the djvu has to be uploaded locally (instead of at Commons), and if there are parts of the work I can't (being UK based) transcribe owing to authors works still being copyright here, even though the book is around 1910. ShakespeareFan00 (talk) 10:00, 26 September 2014 (UTC)


 * I'm all for being scrupulous on IP matters where necessary. On the former point, the Commons page on licensing reads "Wikimedia Commons only accepts media [...] that are in the public domain in at least the United States and in the source country of the work." That is therefore a necessary condition. Here the US is the country of publication. So that necessary condition about public domain is fulfilled. My understanding, which of course may be deficient (this being a treacherous area) is that US public domain would be taken as sufficient by Commons. I'm citing the page that is not for lawyers, knowingly.


 * On the other point, I would take that to be a personal choice, rather than a policy matter. Charles Matthews (talk) 10:34, 26 September 2014 (UTC)
 * Just upload the thing at Commons. If it becomes problematic we will transfer it over here as we know that it is hostable. As attributions are made to author pages, you will work out whether you want it pushed here. Dropping all that I am currently doing to assist with lower priority author pages isn't going to happen. — billinghurst  sDrewth  11:58, 26 September 2014 (UTC)
 * OK. I really doubt that a pre 1923 US work is going to have major issues. ShakespeareFan00 (talk) 12:11, 26 September 2014 (UTC)

Index:The young Moslem looks at life (1937).djvu
Query, is this license on this correct? The author according to Wikisource died in 1964, so I don't see how it can be PD-70 which is what Commons claims.? ShakespeareFan00 (talk) 00:33, 27 September 2014 (UTC)
 * No, if you look at the work here you will see how we have tagged it. I have retagged the File: with c:Template:PD-US-not renewed. — billinghurst  sDrewth  06:30, 28 September 2014 (UTC)
 * Thanks, should really have done that check myself :( ShakespeareFan00 (talk) 17:23, 28 September 2014 (UTC)

— Ineuw talk 21:52, 29 September 2014 (UTC)
 * A reply that says nothing, and is somewhere between "three wise monkeys" and an ostrich or Sergeant Schultz in Hogan's Heroes. — billinghurst  sDrewth 
 * Exactly, and when looking at the "Rights statement" only the films are PD. and I quote:

https://archive.org/details/prelinger

<div >Descriptions, synopses, shotlists and other metadata provided by Prelinger Archives to this site are copyrighted jointly by Prelinger Archives and Getty Images. They may be quoted, excerpted or reproduced for educational, scholarly, nonprofit or archival purposes, but may not be reproduced for commercial purposes of any kind without permission.

Tech News: 2014-40
<section begin="technews-2014-W40"/> 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 software changes
 * On Commons, you can now see what files are most used across all wikis. You can also see the same list for deleted or uncreated files.
 * There are now many more translations for language names.

Software changes this week
 * The new version of MediaWiki ( 1.25wmf1 ) is on test wikis and MediaWiki.org since September 25. It will be on non-Wikipedia wikis on September 30, and on all Wikipedias on October 2 (calendar).
 * Errors from Scribunto (Lua) are now shown on the page. Before, you had to click on "Script error" to see them.
 * You can add an "autovalue" for a field in TemplateData. When users add the template to a page, the value will be added automatically. An example is when a clean-up template shows the date it was added.
 * If you change a user preference but don't save it, it now asks if you want to save it.
 * The PDF export tool has changed. The new one has better language support but it doesn't offer ZIM and EPUB formats.

Future changes
 * You can watch a video showing Phabricator, the new tool to track bugs. You can also read more about the move from Bugzilla.
 * JavaScript authors: Many old methods will be removed soon. Please check your scripts and gadgets and replace the old methods by the new ones if needed.

Tech news prepared by tech ambassadors and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe. <section end="technews-2014-W40"/> 09:44, 29 September 2014 (UTC)

Talmud seems a need to be tidied
When I have a look at "Talmud"'s subpages (Special:PrefixIndex/Talmud/) we seem to have a bit of a hotchpotch. Some looks like it belongs in Talmud (Wikisource) but wasn't moved (and which should be moved to Translation:Talmud) and some maybe deleted, or moved to heWS. Anyone have any knowledge of the work to be able to advise the community? — billinghurst  sDrewth  02:00, 30 September 2014 (UTC)


 * It seems OK to me, but it's missing tractates. I believe there are 64 of them. What do you see wrong? Can you elaborate?— Ineuw talk 02:26, 30 September 2014 (UTC)


 * Ineuw, if you look at the base page Talmud, you'll see that it's a VERSIONS page, so it shouldn't have these subpages. I think that's what billinghurst is getting at. The pages listed in the link all have Talmud as their base page, so they do not seem to be associated with any main page or any particular source. --EncycloPetey (talk) 02:32, 30 September 2014 (UTC)


 * OK. Thanks for the explain. However, I also know that the Talmud's organization is idiosyncratic (not my words) and I also have to track down the source. In other words, I'll look into what's missing.


 * Apologies for being implicit, not explicit. It seems that we have disambiguated the root page of the work, and not the subsidiary pages. We probably need to move the disambig page of the way, move in the ..(WS) page, then move that branch to the Translation: ns, then put the disambig page back in place, and update. — billinghurst  sDrewth  14:44, 30 September 2014 (UTC)


 * Hi, I just finished looking at the very pages you mentioned, (the head is clearer this morning, so the typos are less). Besides the disambiguation page, I also know that the whole layout needs updating. I want to study and think about it a bit longer. — Ineuw talk 14:54, 30 September 2014 (UTC)


 * What a mess! — Ineuw talk 16:15, 1 October 2014 (UTC)


 * This being my first "complex" page moves, can you check somehow if it is OK?— Ineuw talk 22:36, 1 October 2014 (UTC)
 * Seems okay. I did make some dated soft redirects as IMO longer existing pages are better suited to pointers, and MPAA's bot cleans up later. — billinghurst  sDrewth  02:10, 2 October 2014 (UTC)