Wikisource:Scriptorium/Archives/2017-02

Announcements

Project by New Law College Pune

Hi,

There is a discussion under progress at w:en:New Law College (Pune) to take up proof reading, validation, compilation etc. of Indian Laws and to begin with Copyright laws and Intellectual property laws at Portal:Copyright law/Copyright law of India as a (internship) project, most likely in consultation with CIS A2K and local wikipedian community. Activity likely to begin by middle of next week.

Undersigned requests your initial support in making other Intellectual property laws available, and initial support to new users. Please do note that most of the faculty and student's first exposure of editing is begining with wikisource and may not necessarily have previous exposure to wikipedia editing.

Besides would like to create a Project come Dashboard kind of page.

Besides would like to know if wikisource is already having any thing simillar tow:en:Wikipedia:Education_program separately for wikisource.

Suggessions are welcome.

Thanks for all support of all en wikisource community in this initiative.

Mahitgar (talk) 13:57, 10 February 2017 (UTC)

This sounds like a worthwhile project, Will this be solely in English or were translations (to official languages) on the appropriate Wikisource also being considered?

Although it may not yet exist in an open format, something else I'd also strongly suggest transcribing if licensing permits is a list of former British measures repealed in the Republic of India after 1947 to present day. As I understood it Indian legal practice followed English practice closely, and so a "Table of Statutes" for the Republic of India would almost certainly exist?

Did you plan to note in the headers of the transcribed items, information concerning subsequent repeals or amendments, or were you only transcribing the "as enacted" versions of the legislation concerned? Having an accurate Table of Statutes would assist in providing this metadata.

ShakespeareFan00 (talk) 15:50, 10 February 2017 (UTC)

I will also note that there was a series of {{cl-act-paragraph}} templates to assist with formatting legislation with side-titles, BUT having been involved with their development, was of the view that they need to be drastic overhaul before being used further. Other contributors here may be able to advise on formatting and cross-referencing issues.

It was however my understanding that in general, Wikisource used the "Short title" of a measure for linking purposes, Disambugating where needed. ShakespeareFan00 (talk) 15:54, 10 February 2017 (UTC)

Thanks User:ShakespeareFan00 for your valuable feed back. The focus of this college is mainly english specific; (Translations of entire laws will be too big a project for now, For example at Marathi wikipedia copyright case articles I am translating relevant sections only, at a latter stage they may be clubbed together at mr-wikisource and remainin translation can be done; For rest of Indic language translators looking for participation of different audience some thing like journalism students would be more effective.) Your discussion also reminded me need to take account pre-indipendance copyright acts applicable in Portugese and French published in Goa and Pondicherry.

Transcribing if licensing permits is a list of former British measures repealed in the Republic of India after 1947 to present day is a good suggession; this and other suggessions I will inform about this discussion to project co-ordinating faculty.

About wikisource style guide a seperate group of students can be made to study style guide and inform their peers.

Thanks for your valuable feed back once again and regards

Mahitgar (talk) 04:24, 11 February 2017 (UTC)

Some of the repealed acts are listed in Index:British Statutes (Application to India) Repeal Act 1960.djvu. Another list is at w:List of Acts of the Parliament of India. Hrishikes (talk) 04:55, 11 February 2017 (UTC)

We would not usually have a long discussion in an announcement.

We have always been supportive of Wikisource:WikiProjects. I would invite you to set up a project then announce it and invite people to discuss it there. There is a range of expertise and knowledge that can be provided or requested. Style and templates is definitely an issue to discuss, and these projects will have examples of what they have done. — billinghurst sDrewth 10:44, 11 February 2017 (UTC)

Proposals

Font-style and font-size of layout 2 of display options

Would it be a possible to change the display options of layout 2 in the main namespace to the same font style and size as the other layouts? The current style now is Garamond which is not a very palatable font style and it's also smaller. I believe that the other layouts use Arial, and guessing a 1em font-size. I hope that the community would not object to uniformity. — Ineuw talk 04:19, 9 February 2017 (UTC)

No. Part of the reason for having this font is to preserve the serifs. In works on classical texts, it can be difficult or even impossible to tell what you are reading without serifs, because of the abundance of various styles of Roman numerals, abbreviations, and uses of lower-case "L". And changing the font size would retroactively affect the margins and line wrapping of hundreds of pages. So, not a good idea either. --EncycloPetey (talk) 04:24, 9 February 2017 (UTC)

First, I find that applying the words "classical texts" to displays is really meaningless. Second, I would like to take a poll as to how many users use the Layout 2. — Ineuw talk 04:58, 9 February 2017 (UTC)

You didn't read carefully: I said works on classical texts. That is, works about the literature of ancient Greece and Rome, the period we call "classical". Works where the various abbreviations II. Il. and ll. may all appear on the same page, each being entirely different, yet indistinguishable without serifs. --EncycloPetey (talk) 05:28, 9 February 2017 (UTC)

Umm, I would think that the means to that resolution would be to create Layout 4, use the config for 2 and amend the font. Additional layouts are easy. Noting that we also have the gadgetised trial layout where we can play with an additional layout in front space, though without inconveniencing anyone. — billinghurst sDrewth 06:00, 9 February 2017 (UTC)

@EncycloPetey: I didn't mean that what you said was meaningless. I said it because no matter how hard we try it will never be like the originals. This Layout issue also falls in the same category. Aside from being unable to read my work in full width mode, I was having problems at the beginning with centered image sizes, floating image sizes, and table layouts. Narrowing the layout, close to the original, resolved these problems. The PSM original is 540px, and Display layout 2 is 560px. If Layout 4 is set to 540px, would make me very happy. — Ineuw talk 06:31, 9 February 2017 (UTC)

Fixed width is a problem for mobile phones, and we should be avoiding fixing widths unless absolutely necessary. At least with the use of layouts, we allow people to have choice, if the default does not suit. — billinghurst sDrewth 06:35, 9 February 2017 (UTC)

I thought that Layout 2 is controlled by a width value. In any case, whatever you think is best — Ineuw talk 08:04, 9 February 2017 (UTC)

Yes, it is, the difference is that they can toggle out of it to something useful to them. If you set a fixed width in the template, then toggling layouts is non-functional as you have set the width. Layouts utilises the code in MediaWiki:PageNumbers.js which is more editable and a better way to code (is my understanding). — billinghurst sDrewth 10:20, 9 February 2017 (UTC)

@Billinghurst: Placed a copy of PageNumbers.js in my namespace to test Layout 4 and it works well. May I add the Layout 4 snippet to MediaWiki:PageNumbers.js? — Ineuw talk 00:29, 10 February 2017 (UTC)

┌─────────────────────────────────┘

For what it's worth, I read everything in Layout 2 because I prefer the serif font. As the layouts are really a matter of preference more than anything, I would suggest (and support) the addition of a new layout to address a desire for such a thing, rather than an adjustment to a long-existing layout that others prefer for certain (or all) works. --Mukkakukaku (talk) 01:35, 10 February 2017 (UTC)

Thanks @Mukkakukaku:. A majority of one is good enough for me to proceed. — Ineuw talk 06:37, 10 February 2017 (UTC)

Proposal to upgrade User:Dr. Sapna Deo user rights to account creator

Dr. Sapna Deo (talk • contribs) • activity • Global

This is a proposal cum request to give additional rights to User:Dr. Sapna Deo as an account creator. As anounced here earlier CISA2K is conducting a internship program for New law college,Pune students to proofread India law related pages. I suppose this may be first or very few of this kind of collborative activity on en wikisource.

One of the majior problem they are facing is account creation for their students. Their technical person informed me that sharing IP with mediawiki developers is not technically sound enough proposal for them. So they emailed me a list of students with email addressess where in I created user IDs on marathi language wikiource- being sysop on that project- that sent passwords dirctly to their respective email IDs. But that step rather than easing their problem it increased since message sent by mediawiki software is in Marathi language and none of these students understand Marathi language, and if some one tries to login directly to enwikisource without first log-in on Marathi wikisource also not supported well by the software. Today informed me telephonically that they created the new accounts again as much (6) allowed by the software but again rest of the students and activity got stuck.

User:Dr. Sapna Deo -while not having much experince in editing wikis she is avid reader of wikipedia and wikisource- is a reliable program co-ordinating and senior faculty their. And hence I propose and reuest to approve/give her additional account creator rights. To identify student accounts of their college for this activity separately those user names are being suffixed with BVPNLC will be additional step which helps maintain a sense of desciplene and co-ordination for wikisource project.

While earlier the better, frank community views in this regards are requested.

Thanks and regards

Mahitgar (talk) 08:47, 1 March 2017 (UTC)

@Mahitgar: For zero edits on any wiki, I don't believe that it is a reasonable request for the community to be able to assess. So ...

How many people are we talking about? Are talking about all using the same IP address or are we talking multiple IP addresses? If limited IP addresses can we identify the IP range? Do we know the period over which the accounts are being made? There are alternate solutions, we just need extra information prior to providing that advice. — billinghurst sDrewth 10:03, 1 March 2017 (UTC)

I understand your point, I worked with alternate solutions in few other universities and colleges. But everywhere we are dependant on co-operation and confidance from technical people. Few plces they dont have separate technical people. Like this college many places people donot know what wikisource is all about. The way you feel doubt they too may feel doubt from their side. Again what I am facing is language barrier, the college is in Marathi language area so we are supporting but students are not from Marathi language background.

Thanks for your inputs

Mahitgar (talk) 10:15, 1 March 2017 (UTC)

@Mahitgar: I also don't need to be lectured about technical issues, I didn't lecture you about our accountability and responsibilities for the rights that we allocate both to this wiki, nor to the broader WMF community. There are alternates and we should explore those first.

You also avoided answering my questions, which of course is your right, however, when someone is trying to assist you, it is not encouraging. I also believe that I have already offered support to your project, and will continue to do so, however, it will not be by choice to do it in a means of giving rights to a wiki newbie with zero edits. Call me a cautious former-steward. — billinghurst sDrewth 10:45, 1 March 2017 (UTC)

See I reuested in writing and in person both for IP addressess to their technical person. I did not get it officially what do I do ? I am an outsider for the institution. When I aproached them till recently Institution did not know me nor they were very conversant with wikipedia fuctioning let alone wikisource, CISA2K and all, It will take its own time from both side for confidance building and that will happen in due course of time.

Where I dont have answers I cant answer you.

They had given me list of 60 students who registered for internship-they (faculty) devided them in broad subject wise teams . I created accounts from mr-wikisource after consulting on phabricator. First team I was personally there for the workshop so problems could be handled. Now they tried on their own and seems to got stuck. On account creation aspect, Even mediawiki allows to send password info for new accounts in english lanuage even if it is created on mr-wikisource and they can log in directly on wikisource it will be easier to address problem.

It is not that I am insisting that this request be apprroved in any case. Becauase I amware of likely community aprehensions. At the most pace will remain bit slower till things get placed in their places and that every one need to bear with.

Thanks for your frank assessment, and all the support

Warm regards

Mahitgar (talk) 11:07, 1 March 2017 (UTC)

@Mahitgar: 1) If you were there, and creating accounts, we can have a steward run a CU request on the account creations and get the IP address(es), and have a phabricator request to remove the throttle if we can identify a time period. As it is you, you could request it at m:SRCU 2) We can have a list of account names provided to stewards requesting it be passed to me, and I can sit and create the accounts. 3) We can share it through a number of (English speaking) wikis (looks like 6 accounts a day per wiki), I could send a note to the CU mailing list or to stewards to share the message so the accounts are not blocked as sockpuppets ahead of time. All less than perfect I understand. All functioning. — billinghurst sDrewth 11:31, 1 March 2017 (UTC)

Other discussions

PhD theses from Edinburgh University

Hi, the digital curator at the University of Edinburgh has asked if it would be appropriate for out-of-copyright digitised PhD theses to be included on Wikisource? The university has been digitising its collection of PhD theses for the last few months and is now at a stage where it can consider uploading a test case to Wikisource: a medical thesis by British physician & geologist Thomas James Jehu. Just looking to establish if this project is something we can go ahead with in terms of Wikisource's project scope. NB: We also have a number of Open Books we could look to import. Many thanks, Stinglehammer (talk) 12:19, 12 January 2017 (UTC)

Are these thesis published in other journals? ShakespeareFan00 (talk) 18:49, 12 January 2017 (UTC)

Aside, I would encourage you to lobby for "open access" publication to be an option for recent thesis authors, once University formalities have been completed obviously.ShakespeareFan00 (talk) 18:49, 12 January 2017 (UTC)

The relevant issues are discussed at Wikisource:What Wikisource includes. Since PhD theses will have been reviewed and approved by a committee at the University, I would consider them suitable for inclusion, provided that there are no copyright concerns. The open books, I am unsure of, as they would normally need to have undergone some sort of peer review and publication. --EncycloPetey (talk) 21:52, 12 January 2017 (UTC)

The open books are a collection of works the library has scanned. Many of them are clearly in scope, and the rest of the English language works are old stuff that should be in scope.--Prosfilaes (talk) 23:59, 12 January 2017 (UTC)

•  Support @Stinglehammer: Peer-reviewed works that are in the public domain or are freely-licensed are within scope. There are of course some mechanics to discuss.
   Comment Re open books, are they static to a point of time? Are they approved by experts in a way analogous to peer-review? If they are not static, or they are not peer-reviewed then here may not be the most appropriate place. I am wondering whether we should be including our colleagues at English Wikibooks to see where they fit best. — billinghurst sDrewth 01:16, 13 January 2017 (UTC)

  Addendum Looking at the Open Books, some of those seem to be analogous to us as historic documents of notable people, so not needing the peer-review component as they have a notability aspect. Where that is the case, then they get my  Support too. We may have to pick some out, or expand this conversation a little. — billinghurst sDrewth 01:21, 13 January 2017 (UTC)

•  Support Certainly the theses seem in scope for Wikisource, and the few Open Books I've looked at (at random) would, as Billinghurst says above, be fine. Perhaps, if there are materials that are not a good fit for Wikisource, they could be added to Wikiversity? They'd be good candidates for raw research material there. —Sam Wilson 01:30, 13 January 2017 (UTC)
• That's the first thesis added. Thomas John Jehu's Some problems in variation and heredity from 1902. It's been proofread. Just needs validated. Is there a specific place we should place a link to it so that it is more likely to get validated? e.g. Proofread of the Month? Also, Gweduni who did the proofreading was wondering about how to represent the scoring out of certain words and the words inserted above the scoring out? Plus is there a shortcut for adding underlining other than just typing it as markup code as bold & italic seems represented on the menu bar but no underline? Many thanks, Stinglehammer (talk) 18:35, 28 February 2017 (UTC)
  • {{dual line}} works well for showing manual corrections, as you have used; {{u}} (a.k.a. {{underline}}) can be used for underlining. —Beleg Tâl (talk) 19:53, 28 February 2017 (UTC)

Refactoring dates in the author template

(This is related to a discussion above, but I thought I'd raise it here too, as this is more general.)

I'd like to propose replacing the date-handling bits of {{author}} with a new Lua module, Module:Author. This would be the date-display code and the categorisation code that's currently done in {{author/year}} (which could then be deprecated). At the same time, we can start pulling in data from Wikidata when possible and when it's not supplied locally with the birthyear and deathyear parameters.

I've started writing the code and documenting it at Module:Author/doc. The date-display stuff is pretty straight forward, but the categories are more complicated. At the moment the module is categorizing into the following categories:

1. In all cases (where applicable):
   • Category:yyyy births and Category:yyyy deaths
   • Category:<era> authors with era defined by Module:Date.era()
   • Category:Authors with unknown birth dates‎ and Category:Authors with unknown death dates‎
   • Category:Authors with approximate birth dates and Category:Authors with approximate death dates
   • Category:Authors with missing birth dates‎ and Category:Authors with missing death dates‎
   • Category:Living authors
2. Where manual birthdates are supplied
   • Category:Authors with non-numeric birth dates and Category:Authors with non-numeric death dates
   • Category:Authors with unrecognised birth dates and Category:Authors with unrecognised death dates
   • Category:Authors with birth dates differing from Wikidata and Category:Authors with death dates differing from Wikidata

I've started writing tests; see Module talk:Author/testcases. Not all are passing at the moment, and not all required code paths are present yet. There's also the dates in the microformat to be done. (I'm working on all these.)

I'd love anyone's feedback about this idea! :-) Thanks. Sam Wilson 06:54, 17 January 2017 (UTC)

 Comment How will we deal with disambiguated author pages where the page title includes birth and death dates? That is, there is a possibility that we will have set up a pagename including dates which then change based on Wikidata. How would we track and account for this? --EncycloPetey (talk) 13:07, 17 January 2017 (UTC)

@EncycloPetey: Good point. We can parse the dates out of the page title and check them against the Wikidata values. If they don't match, we can add the page to a maintenance category, for manual follow-up. Do you think that'd work? If they're in the format like Author:John Newton (1725-1807) then it'll be fine. Sam Wilson 21:05, 17 January 2017 (UTC)

yes, that’s good. include a manual input override. include a "edit on wikidata" button, to lead people to fix there. need to think about non-standard date formats and OS vs. NS. Slowking4 ‽ RAN's revenge 21:41, 17 January 2017 (UTC)

Tracked in PhabricatorTask T132790

There is a whole project within WD to look at "in-wiki/local" editing. Maybe we can add some pertinent commentary there, especially about pushing data from our templates. To also note that there is javascript tool available with which I have been playing, and can set up for others if they so wish. Not perfect, but adds something. — billinghurst sDrewth 06:30, 18 January 2017 (UTC)

That will be super brilliant when it happens! And people at the Dev Summit last week were talking about also being able to show Wikidata changes in the local history of a page, which'd help too. Sam Wilson 07:18, 18 January 2017 (UTC)

agreed - the ticket seems to be about infoboxes, maybe some input about author / creator templates would be good there. Slowking4 ‽ RAN's revenge 17:54, 18 January 2017 (UTC)

I've added a function to categorise disambig'd authors into Category:Authors with title-date mismatches where the title dates don't match Wikidata. Sam Wilson 08:24, 18 January 2017 (UTC)

I've been doing a bit more on this. If anyone's got a chance could you have a look at Module talk:Author/testcases and see what tests are missing? Both for dates as supplied in the {{author}} template and those retrieved from Wikidata. Thanks! Sam Wilson 02:22, 19 January 2017 (UTC)

The Module:Author dates method is ready to deploy to the author template. Is it okay if I go ahead with this? Does anyone have any other testcases that should be investigated? Sam Wilson 03:19, 26 January 2017 (UTC)

I'm going to go ahead with this. I'll be on hand to fix anything up that goes awry! Ping me if you notice anything. :) Sam Wilson 00:42, 30 January 2017 (UTC)

@Samwilson: Do you realize that this is adding hundreds of articles to Category:Pages_with_script_errors in instances where the author name has some disambiguation--e.g. Author:John_Newton_(1725-1807) or Author:Eusebius (Pope)? —Justin (koavf)❤T☮C☺M☯ 06:17, 30 January 2017 (UTC)

@Samwilson: And evidently no last name, e.g. Author:Hippocrates. —Justin (koavf)❤T☮C☺M☯ 06:20, 30 January 2017 (UTC)

Sorry! Yes, I'm fixing this right now. I thought I had tested all permutations of that, but in fact I failed. Sam Wilson 06:20, 30 January 2017 (UTC)

Okay, sorted those bugs out. What other problems are there? (I'm going through a random sampling of Author pages now.) Note that Category:Authors with birth dates differing from Wikidata and Category:Authors with death dates differing from Wikidata are getting rather a lot in them too! Sam Wilson 06:29, 30 January 2017 (UTC)

 Comment Don't rush too fast Samwilson, let us bring the community along at a reasonable rate, supported and informed. We are better to hasten slowly with implementation than forcing changes. There is no absolute requirement to change templates to not show these fields as I presume that empty parameters will populate from WD. At this point, I feel that we are better to label them to be left empty, and to notify that we are using WD, rather than obliterate from our preloaded templates. We have numbers of authors not in WD where we have dates of life, and to not have that data available today to then create or match later at WD is not helpful. — billinghurst sDrewth 03:18, 31 January 2017 (UTC)

Yes, sorry!! I realise I was rather getting carried away. Thanks for reverting. I think it's okay to remove dates from individual authors though, where the data's already in WD though. I've been trying to investigate ones where there are differences especially. I shall try to be more communicative and slower! :) Sam Wilson 04:33, 31 January 2017 (UTC)

While I don't personally have an issue removing date parameters, I do know that we haven't discussed that with the broad community as a specific proposal. My experience with removing other parameters from author and authority control templates is that the community wants reassurance and clarity that problems are resolved prior to such actions. Let us see how the module works and its resilience, prior to the next step. — billinghurst sDrewth 06:32, 31 January 2017 (UTC)

Out of curiosity, is this work why Category:Living authors isn't auto-populating anymore? For example, Author:Andrew Beniuk should be in there, but he's not. --Mukkakukaku (talk) 04:15, 31 January 2017 (UTC)

Yes, good point. This is a tricky one. We were assuming that anyone with a birthyear but no deathyear was therefore living, but now with Wikidata we have the ability to explicitly mark 'date of death' as 'no value', which means someone is still alive (as opposed to 'unknown', which means they're known to be dead but not when they died). So I'm not sure what to do: we already have Category:Authors with missing death dates, which used to only apply if both dates were missing, but now can apply where we have an unknown death date. The ultimate solution is to update the data in Wikidata, but apart from that, what is the best option here? Sam Wilson 04:33, 31 January 2017 (UTC)

I can see now that I've got it backwards. We should assume that people without death dates are living, unless their birth dates are >130 years ago, and for the false positives we can give them "date of death = unknown" at Wikidata. That makes more sense doesn't it? Sorry I got it wrong; I'll fix it up now. Sam Wilson 04:42, 31 January 2017 (UTC)

Another thought on this: for authors with unknown dates, I have sometimes added dates = fl. YYYY for when they were active. I just noticed that Wikidata has a property floruit (P1317) ; is this also used or usable in the new module? —Beleg Tâl (talk) 20:56, 31 January 2017 (UTC)

@Beleg Tâl: yes definitely, good idea. Can you point me to a Wikidata item using this? One that's unlikely to be given more solid birth and death dates, that I can add to the testcases. I'd say that floruit should be displayed on its own when there are unknown birth and death dates, or as e.g. (1800 – aft. 1850) when there's a birth date and f. 1850 (and similar if there's only a floruit and death date). Does that sound okay? Sam Wilson 00:03, 1 February 2017 (UTC)

I recently created Author:Mrs. Dunbo (d:Q28585286) with no dates except for the floruit field. I think your ideas for how to display when there is a floruit date and only one birth or death date will work very well. —Beleg Tâl (talk) 17:50, 2 February 2017 (UTC)

Possible bot

Might there be any interest in maybe setting up some sort of bot which could, perhaps, on the talk page of a given portal, indicate which works mentioned in that portal have been scanned for proofreading, and maybe how far along in proofreading they have gotten? John Carter (talk) 19:39, 18 January 2017 (UTC)

It might be able to give some idea, but there are many Portals where authors are listed instead of duplicating the list of relevant works, even if not all of that author's works are relevant to the given Portal. And for some works, like the EB1911, that will be difficult to judge, since only a portion of the work might relate to the particular portal. --EncycloPetey (talk) 19:56, 18 January 2017 (UTC)

You mean like adding a link along the lines of this one? Not much of a justification for a bot. —unsigned comment by 121.216.33.233 (talk) .

I wasn't thinking of anything along the lines the first-time IP editor indicated, and find the conclusion rather remarkable, but, rather, more along the lines of a bot which might generate something which looks in some way, allowing for all the variations, something along the lines of wikipedia:Wikipedia:WikiProject Christianity/Popular pages, possibly with some sort of accomodating changes like my recent verifying of The Complete Works of Lyof N. Tolstoï/How to Read the Gospels. The relevant criteria for us might be number of page views, number of pages involved, and current development stage, maybe for the latter ranking them based on the existing index proofreading scheme. John Carter (talk) 20:12, 18 January 2017 (UTC)

Interesting idea @John Carter:. Beyond author pages, we are pretty horrid about presenting works to our public, completed or pending. We sort of have portals, though they are curatorial in nature, and based on what we think is the subject. [Truth be told, we mostly enjoy transcribing and are not fantastic on administrivia. Personally I am a shocker about working out the subject matter.] As has been mentioned for Special:IndexPages we can add keywords/phrases/title and display related books based on that, example at Wikisource:WikiProject DNB/Progress. That would take the addition of keywords/phrases to the Index: files, and then adding something like {{Special:IndexPages|key=(phrase)}} to a section on the pages or the talk page (IF PEOPLE LOOK THERE). I take your conversation as telling us that we should be doing better, and in that you are correct, and most look up, then go back to their comfort zone of transcribing. — billinghurst sDrewth 06:00, 19 January 2017 (UTC)

Believe me, I understand. I could myself try to do a lot more in this regard myself, and may well do so when I get a bit better grasp of how to do things here. Unfortunately, I still don't have any ability at making index pages, which I kind of hate, because some recent reviews of other encyclopedias have said wikipedia:Louis de La Vallée-Poussin's articles on Buddhism in the old Hastings Encyclopaedia of Religion and Ethics have been said in reviews of more recent reference works to be the best works on their topics ever written, and, fumbingly try as I might, I've still not really had any success in trying to add those volumes here. John Carter (talk) 20:53, 21 January 2017 (UTC)

that’s very good - i would support an agenda / action plan to refresh Main Page, Portals, Projects to make more useful. a bot could be a part of maintaining that. or wikidata maintenance list updated by bot. (i.e. [1]) using [2] minimizing impact on old transcription work flows would be critical for community acceptance. Slowking4 ‽ RAN's revenge 16:39, 19 January 2017 (UTC)

Perhaps a "portal expansion drive" could be a weekly or monthly collaboration project. We could rotate through some of the portals that have not seen much attention for a while, or even initiate portals for subjects we are still missing? --EncycloPetey (talk) 17:41, 19 January 2017 (UTC)

Another good use for a bot along these lines: there are a lot of portals which have an equivalent category; a lot of the items in such categories could easily be automatically added to the relevant portals. —Beleg Tâl (talk) 04:22, 20 January 2017 (UTC)

Given the recent success over at wikipedia in "drives" headed by w:User:Rosiestep and w:User talk:Dr. Blofeld, both of whom I am more or less in awe of for the success they've had in their collaborative efforts, I think there may well be merit in maybe including in such a bot or a similar bot a search for recent hits at portals and author pages to determine the number of views of each for the purpose of seeing what is likely to get the most input for such "portal/author improvement" drives as suggested above. The reference work bot might then be used to see which reference works have articles on the topics which may not have yet been addressed, which might then be included in the portal improvement. Particularly for wikipedia editors, maybe finding which portal/author pages have shorter "entries" in collective works which could be listed by bot for expansion might help bring in some more wikipedia editors more used to working on shorter "projects" than proofreadings of full books, although maybe the "portal improvement" effort might be maybe optimally chosen to relate to the following months "Proofread of the Month" to maybe get a few more such newer editors involved in that effort as well. John Carter (talk) 20:44, 21 January 2017 (UTC)

One idea is to use Wikidata: I guess all portals have a Wikidata item, and so we can find out their main topic, and then find all editions that have that as their main subject (non-fiction) or genre (fiction), and list them all on the portal? But would this leave us with weird things? For example, we don't have a Portal:Novels in which Pride and Prejudice would go (let alone Portal:Satire). And anyway lots of things don't have subjects or genres at Wikidata. :-( I've played around with a script to make Portal:Penguin Classics, which seems to work okay, but that's a different sort of portal (and should probably be renamed Portal:Penguin Classics works or something). Sam Wilson 06:50, 20 January 2017 (UTC)

that’s very good. another step would be a wikidata list query that updates by bot. don;t know how community feels about semi-automatic versus automatic. we can use the lists to provide input for content drives such as women in red. lots of metadata to deconflict / get linked. Slowking4 ‽ RAN's revenge 14:28, 22 January 2017 (UTC)

If we were to request a bot be created roughly along the lines of the Popular Pages bot linked to above, what sort of specific details would we want? I might include name of portal or category item linked to, number of hits (per month?) to same, individual pages included in those portals or categories which number of hits, number of pages per pagescan in the individual works, number of problematic pages in the transcluded text, and, maybe, level of development past the current proofread level of the pages transcluded into an individual work and/or of the broader work whose index is linked to. If the last isn't really clear, indicating the number of pages at non-proofread, proofread or verified level, not differentiating in the bot results between the two higher levels, for a work still at not-proofread level and that sort of thing. John Carter (talk) 15:34, 25 January 2017 (UTC)

I've left a request at wikipedia:Wikipedia:Bot requests regarding the above proposed bot. I hope to here something in response shortly. John Carter (talk) 14:47, 6 February 2017 (UTC)

Index:The_pilgrims_progress_as_originally_published_by_John_Bunyan_;_being_a_facsimile_of_the_first_edition_(1878).djvu

A simple consultation. Should I continue converting this to use the sidenotes, which on a number of pages are currently not quite fully working, or revert back to the approach of using footnotes?

I'd also like a decision on whether to use the long s as I have been (faithful to text), or substitute a modern s for reader ease. ShakespeareFan00 (talk) 11:54, 22 January 2017 (UTC)

Wikisource:Style guide allows the use of {{long s}} in the Page: ns, though noting that it displays normal s when transcluded. Not sure that it is a work that would be any more special than that. — billinghurst sDrewth 13:45, 22 January 2017 (UTC)

EncycloPetey used hard-coded, visible-in-mainspace, Unicode long-s in next month's FT, The Clandestine Marriage. You appear to have done this so far. Considering it is a facsimile of the first edition from the 1600s, I would favour continuing with this approach. Interestingly, however, {{blackletter}} does not appear to support long s, meaning the page headers are incorrectly displayed. Not sure what you could do about that... BethNaught (talk) 14:35, 22 January 2017 (UTC)

{{long s}} also doesn't work nicely with {{hws}}{{hwe}} pairs, which is why I was considering hardcoding.ShakespeareFan00 (talk) 15:06, 22 January 2017 (UTC)

your style solution seem ok to me. i’ve kinda given up on easy to use sidenotes. i would note a lot of other transcription projects don’t even try. unclear benefit to reader, of sidenote, when content is there in a different place. it is vestigial marginalia Slowking4 ‽ RAN's revenge 14:37, 22 January 2017 (UTC)

@BethNaught: {{blackletter}} does some glyph-replacement by default; you can override this with mode=1 as follows: s = s and ſ = ſ.

OK let's make this simple.

Hardcode {{ls}} as the Unicode Character? (Yes/No)

Hardcode {{rr}} as the Unicode Character? (Yes/No)

Use footnotes as opposed to sidenotes? (Yes/No)

I'm not going to reformat anymore pages until there is a clear consensus and someone else puts a style guide on the Index talk, I don't want to be changing back and forth.

Let's give it 7 days for someone (other than me) to write the style notes? ShakespeareFan00 (talk) 15:01, 22 January 2017 (UTC)

The preface to the work in question shows that "no pains have been spared. In all those matters of orthography, grammar, rough or quaint expression, typographical peculiarity, &c., above referred to, absolute reproduction has been the one aim." Because of this, I would encourage this attitude in the WS transcription as well, and would therefore suggest hard-coding the characters. That being said, if the sidenotes don't work, it's okay for them to be footnotes. —Beleg Tâl (talk) 19:43, 22 January 2017 (UTC)

Further to this, I'm pretty sure that ꝛ is only used once in the Preface, and subsequently only in the non-transcluded page headers, so it may not be worth changing. And finally, if you hard-code it we can use autowikibrowser to change it afterwards if desired. —Beleg Tâl (talk) 19:47, 22 January 2017 (UTC)

1. While {{long s}} and {{ls}} both render as s in the edit screen and as ſ in the mainspace, {{s}} is always rendered as as ſ regardless of where it is rendered.
   We also have {{s|2}} (ʃ), {{ss}} (ſſ), {{ss|2}} (ʃʃ), {{ss|3}} (ß), and {{ss|4}} (ʃß).  These five always render as stated, regardless of where they are rendered.
2. I definitely think it wise to use the exact typography found in the text being transcribed, meaning always using the long-s (etc.) when the text being transcribed uses the long-s (etc.) and using the short-s (etc.) when the text being transcribed uses the short-s (etc.).
   Take, for example, old Bibles and new Bibles.  We have some Bibles here on Wikisource from the 1600s.  We have other Bibles here from modern times.  When a person goes to look at one of the Bibles from the 1600s, that person wants to see all of the original typography; otherwise, she or he would have directed her- or himself to a more-modern printing.  If we incorporate modern typography into transcriptions of old printings, we do a grave disservice to those who are specifically seeking out those old printings.
   allixpeeke (talk) 00:20, 2 February 2017 (UTC)

Possibly, although I have trouble seeing how our having material in one format in our transclusions makes it harder for parties interested in the original forms of the typography to get them from the .pdf or .djvu we are basing the transclusion on. And, speaking personally, as someone who is highly involved in religious content here and elsewhere, personally, I want stuff I can read easily, and sometimes older typography isn't easy to read. I imagine the same might be true for students looking for a good source to use in papers, most of which are in current typography too. On that basis, and given that I don't know what proportion of readers meet the criteria you discuss, I'm not sure exactly how much of a disservice we would be doing, although, I guess, if rules here permit it, maybe having some older books in ye olde type for those interested in such might be possible, maybe? John Carter (talk) 01:26, 2 February 2017 (UTC)

Yes, people could take a look at the .pdfs/.djvus in order to see the original text, but then again, transcribing texts from .pdfs/.djvus into .html/wikitext is what wikisource is all about; otherwise, we'd simply upload .pdfs/.djvus here and do nothing more with them.

It's not unusual for someone to look for "stuff [she or he] can read easily," but I must ask you this:  When you, John Carter, go looking for easy-to-read Biblical content, do you tend to look for older sources or newer?

Personally, when I have occasion to look up stuff in the Bible, I go to the New American Bible (Revised Edition) (2011).  Sometimes I may opt for a side-by-side comparison with the New King James Version (1982).  But when I go to the Douay–Rheims Bible (1582–1610), I'm definitely not looking for easy readability; I'm looking for the actual 1582–1610 text.

Even back when I was a student, I always preferred the actual text as opposed to modernisations in spelling and typography.  It doesn't take much effort for students to take "The Booke of Genesis" and "the Spirite of God moued ouer the waters" (e.g.) and rewrite them as "The Book of Genesis" and "the Spirit of God moved over the waters" if they for some reason really need to.  (Doing so doesn't even require the student to look at the .pdf/.djvu; the student is able to make this revision, if necessary, by merely remembering how things are spelled nowadays.)  Conversely, however, taking a modernisation and diligently rendering it back to the original can be painstaking, especially insofar as the text that needs to be unmodernised is lengthy.  (The student has to keep looking at the .pdf/.djuv and then back at the document she/he is writing, back to the .pdf/.djuv, back to the document, back and back again.)

I am not averse to the idea of having texts rendered in dual formats.  That said, I regard the original print formats to be the more-valuable renderings, and any modernisations we do of secondary value.

Yours respectfully,
allixpeeke (talk) 02:50, 2 February 2017 (UTC)

This is why I like {{ls}} so much: it renders as 's' for the majority of people who want to have something easy to read, but individual users can configure their profile such that it renders as 'ſ' instead. It essentially removes the debate completely. Hard-coded ſ or {{s}}, on the other hand, should only be used sparingly, and with a good reason. In this version of Pilgrim's Progress, the original editor's insistence on preserving the typography provides that good reason. —Beleg Tâl (talk) 13:25, 2 February 2017 (UTC)

@Beleg Tâl:

You write, "This is why I like {{ls}} so much: it renders as 's' for the majority of people who want to have something easy to read, but individual users can configure their profile such that it renders as 'ſ' instead."

I have searched through the Preferences options, and I don't see how to turn it on so that I do see the long-s.  How do I do that?  Please help.

Thanks in advance,
allixpeeke (talk) 21:50, 5 February 2017 (UTC)

The documentation at Template:ls describes how to do this. You will need to modify your personal CSS file (Special:MyPage/common.css) or your personal JS file (Special:MyPage/common.js). —Beleg Tâl (talk) 01:49, 6 February 2017 (UTC)

I disagree; if I'm looking at the Wycliffe Bible, it's because I want to know what the Wycliffe Bible says, not because I care about the particular details of orthography. You talk about typography and use examples from orthography when we dispose of the first and keep the second, and the questions all lie on the line. We do keep the original text; the question is whether these features are text or typography.

I think it's also a peculiar choice to pick a book in translation. There are a lot of works that have no "modern edition"; American Cookery is one, and I think it entirely likely to want to read the details of early US cooking without digging through weird typography that might well stop someone unfamiliar with it. "the Spirite of God moued ouer the waters" forces me to stop and figure out what it says, a great deterrent if I'm trying to read more than a couple sentences.--Prosfilaes (talk) 22:14, 2 February 2017 (UTC)

It's funny you should mention the Wycliffe Bible, since I just went searching around the Internet specifically looking for transcriptions that included the original typography earlier today!  I even found a few that looked pretty good, having the thorn and whatnot correctly displayed.  But, to my utter chagrin, I couldn't find a single one that had all of the books' titles in their original typography!  Every book was either titled in modern English or semi-modernised English.  It was completely useless to my needs!

In any event, the Wycliffe Bible is a perfect example of a text that is best presented with side-by-side versions, showcasing both the original Middle English typography and a translation into modern English.  How better to show the evolution of the English language from the Middle Ages to today?  If only the modern English translation is presented, then all that rich history is tossed away.

Yours,
allixpeeke (talk) 21:50, 5 February 2017 (UTC)

Nobody is talking about a translation into modern English! We're not even talking about modernizing spelling of the words. We're talking about changing a few letterforms to modern letterforms. Transcription is quite far from the original manuscript, but is also quite far from translation into modern English.--Prosfilaes (talk) 04:01, 6 February 2017 (UTC)

Digha Nikaya ... to a portal?

Anyone got ideas on where this sits? There does not seem to be a complete published work by the name so sitting it in the main ns seems inappropriate, and it seems to have components in numbers of places. Do we think that it should be a portal? (happy for anyone to make a solution) — billinghurst sDrewth 22:59, 29 January 2017 (UTC)

By itself, it is not a single work. It is a collection of 34 separate works, arranged in 3 divisions, originally in Pali language. 1987 tr. by Maurice Walshe is available at https://archive.org/details/DighaNikaya. 1899 tr. by Rhys Davids, in 3 vols, is at 1, 2, 3. Therefore yes, complete published work in English translation is available; but not in Wikisource right now. Hrishikes (talk) 01:28, 30 January 2017 (UTC)

In that sense it looks like it would be comparable to the Bible, also a collection of 24 to 51 books (depending who you ask) in up to 3 divisions. In that case, a mainspace page would be appropriate, especially as the collection is generally published as a unit, but individual mainspace pages for each component work would also be approporiate. —Beleg Tâl (talk) 03:41, 30 January 2017 (UTC)

But we don't have it as a single published work, which is our focus for main namespace. So either it becomes a disambiguation page if we have more than one copy of the work, or in its current form it becomes a portal. — billinghurst sDrewth 09:31, 30 January 2017 (UTC)

This collection does not behave like a portal. In a portal, the order of the listed works is not fixed. If fiction is before poetry, you can change it. You can also add new items. In Digha Nikaya, the number of components is fixed. Their order is also fixed. A portal where you cannot change the order of the items, cannot add extra items, I don't think the concept of such an un-amendable portal exists in this site. From this angle, the components behave more like chapters of a book. Hrishikes (talk) 14:26, 30 January 2017 (UTC)

The order and number of elements in the Bible is also fixed (albeit they differ slightly among religious groups), so a Portal is probably the best approach, just as we have done for the Judeo-Christian Bible. --EncycloPetey (talk) 23:20, 30 January 2017 (UTC)

In a portal the order of works is what we make it, many are not ordered, but that is just those. An portal can be what we make it IMNSHO. If a portal page is ordered and should remain ordered, then it is stated to be so. I also understand that it can be considered a book, that is not my argument, that page is a construct, not a published work. The main ns is for published works, so those components published appear as per the work. — billinghurst sDrewth 04:56, 31 January 2017 (UTC)

@Billinghurst, @EncycloPetey: The text here is indeed published work. It is the Rhys Davids translation; IA has it, in 3 vols., link given above. Although the current root page is a TOC only. Hrishikes (talk) 02:59, 2 February 2017 (UTC)

I think you misunderstood. The Portal is a construct, and not itself a published work, so it has flexibility. --EncycloPetey (talk) 03:04, 2 February 2017 (UTC)

I do not understand what you mean by misunderstanding. The root page here is a TOC; linked items are the items in the Rhys Davids translation. That 3-vol-set is Part 2 of the series, Sacred Books of the Buddhists, edited by Max Müller. This series is analogous to another series Sacred Books of the East, also edited by Max Müller. Hrishikes (talk) 03:34, 2 February 2017 (UTC)

@Hrishikes: What exactly was published and when. The versions of the bible that we have are specific editions, I do not see that Digha Nikaya is an edition of an English translation. To me it looks like a construct. If that work has been published like that, then let us get it into the shape expected of an edition. — billinghurst sDrewth 04:46, 2 February 2017 (UTC)

@Billinghurst: I have added the concerned index files and also the migrate to djvu template on the root page. Currently the root page shows the TOC of all 3 volumes, which is not appropriate, I think. The name should also be changed to English (Dialogues of the Buddha) from the current Pali form. To reconcile the Pali and English forms, I have moved the root page to Portal:Tipitaka/Digha Nikaya, and now, the linked component works can be kept in the main space under English title used by Rhys Davids. Hrishikes (talk) 06:25, 2 February 2017 (UTC)

Thanks. Always good to get knowledge and sense applied to a solution. — billinghurst sDrewth 09:52, 2 February 2017 (UTC)

Tyronian et

I started working on Index:The Jolly Pinder of Wakefield with Robin Hood Scarlet and John.jpg, which is a poem written in blackletter font. For simplicity's sake, I'm dropping the blackletter typeface and updating the long-s and rotund-r to regular s and r and so forth. However, the text also makes significant use of the Tyronian et, '⁊', which is also a defunct character. Based on w:Tyronian et and w:Ampersand, this symbol is not just an old version of & or + or similar 'and' symbols, so I can't just replace it with the modern version. Should I preserve the et symbol in the text, or replace it with something? If I replace it, with what? —Beleg Tâl (talk) 19:54, 30 January 2017 (UTC)

Do you mean w:Tironian notes? It is an abbreviation for "and", so there's no reason not to replace it with & unless the text actually uses it for basically word-play.--Prosfilaes (talk) 22:21, 30 January 2017 (UTC)

As a side note -- whatever you decide can you note it on the Index's talk page for the reference of whoever comes by to validate? --Mukkakukaku (talk) 03:44, 31 January 2017 (UTC)

I've replaced it with & in the text and made a note of it in the Index talk page. I have also created {{et}} (similar to {{ls}} and {{rr}}) for future use as desired. —Beleg Tâl (talk) 13:30, 31 January 2017 (UTC)

Oof, this is going to be one of those things ... the {{et}} renders like a little rectangle for me. :( --Mukkakukaku (talk) 05:01, 14 February 2017 (UTC)

Pretty sure that rendering was one of the matters that we covered all those years ago. That said, we now have {{ULS}} capability added since those years ago, so maybe see what may be renderable through that implementation. — billinghurst sDrewth 06:09, 14 February 2017 (UTC)

OK, based on the info at the enWP article and that cool {{ULS}} template, I've hacked together this, which shows for me: ⁊. Which I think is the letter we're all talking about? Except it just renders like a square for me even in the text input area which makes it really hard to work with.... --Mukkakukaku (talk) 02:39, 15 February 2017 (UTC)

Please don't use ULS in the template. Most of the places I've seen this character are within the context of {{blackletter}} or {{insular}} and this will override those. Sometimes you just need to display a raw Unicode character. If necessary, you can use Special:MyPage/common.css to set a font-family on the class "typographic-et". —Beleg Tâl (talk) 12:53, 17 February 2017 (UTC)

Well yeah, but overwriting my common.css will just help me and let everyone else with the same problem see little rectangles. Given the choice between seeing a little rectangle or seeing a letter in a different font in the middle of a blackletter, I think the second is preferred. --Mukkakukaku (talk) 04:44, 18 February 2017 (UTC)

Missing sections

There is a block of several discussions on this page that cannot be edited by my, for whatever reason. They do not have [edit] displaying, and when I try to circumvent this by editing a different section, and changing the section number, the system balks. Is anyone else having this issue? --EncycloPetey (talk) 03:01, 2 February 2017 (UTC)

Yes.  I've resorted to hitting the main edit button for the section missing section-edit links.  allixpeeke (talk) 04:13, 2 February 2017 (UTC)

It looks as though billinghurst has sorted the problem now. :) --EncycloPetey (talk) 05:19, 2 February 2017 (UTC)

What would you like done about "found" dates of death or birth?

In fixing up author pages I have come across a situation where we have had authors having died since we created the author page, predominantly people with the licence of {{PD-USGov}}, though not exclusively. The data in the situation that I was looking at is in Wikidata.

If the data is in wikidata, we can right a test within {{author}} to display the data for year of death where we have left it empty. Is that something that contributors like to see done? Plus if we do that, are we wanting this to be the only solution? Or are we then wishing to manually enter that data locally to the template, ie. create another maintenance task (either manual or possibly bot'able)

To note that I ran a test query with petscan that looked at pages within Category:Authors with missing death dates and then said show me pages where wikidata has a "date of death" property. There are numbers of "no value" or "unknown value" fields which would require some qualification, though that is fairly simple.

Then it poses the situation that we can do the same for missing birth dates. What would the community like done. — billinghurst sDrewth 10:30, 9 January 2017 (UTC)

There are also situations where we have the data (manually entered by someone) and Wikidata, even VIAF does not. So we should keep both options open. The Wikidata option should be default, it should be displayed as long as someone manually does not enter something. If some manual entry is made, that should override the input from Wikidata. I have seen many times that editors here make entry of birth and death years after considerable research. This practice often yields valuable information, and should not be discontinued. However, editors should be encouraged to update the concerned fields in Wikidata simultaneous with local entry. Hrishikes (talk) 12:08, 9 January 2017 (UTC)

might want to think about author template pulling items from wikidata and edit data there. if you find a source, update it and include url reference. Slowking4 ‽ RAN's revenge 02:33, 17 January 2017 (UTC)

Wikidata sometimes lists more than one date of birth or death, especially for ancient and classical authors, where sources disagree about the date. There is also the issue that Wikidata sometimes records dates using the Julian calendar or other systems, according to whatever source was cited for the date. --EncycloPetey (talk) 02:36, 17 January 2017 (UTC)

@Slowking4: That is why I am asking, it is a technical vs. social question. What does the community want?

@EncycloPetey: That is all able to be identified and managed if we choose to take the WD-populated approach. 1) if multiple dates of birth we can always take the preferred. 2) If it is a Julian date, we can call back that qualifier, too. If we can identify what we want to do, then we can identify how we do, and a plan to avoid the pitfalls. — billinghurst sDrewth 06:14, 17 January 2017 (UTC)

Actually as I asked the question, I didn't express an opinion, though that I asked at all flags my general thoughts. Some thoughts, philosophically I would like to be able to use a set of authoritative or best known data for our {{author}} and {{header}} templates. I would much rather have data stored in WD, and be widely available, searchable and retrievable, rather than bottled-up here, and I would much rather have data entered correctly once, than in multiple places. [Call me lazy] That said we don't want dodgy data, and we do want the ability to readily manage data, so we want to have the ability to set up alerts and warnings.

If we do have our data well-populated at WD, I see that it offers us more, much more, enabling smart tools to do smart things. An example of the bigger sorts of things that we could do is use ListeriaBot to generate all our Wikisource:Authors-... pages and to update on a regular basis. For that we need 1) all authors in WD, and on author items 2) first and family names, 3) dates/years of birth and death, 4) a descriptor.

We can set up WD at a passive level, and do some mix and match with available tools, or by use of categories to identify where data differs between our data and WD data. In the end it is about what level of control, and whether we wish to manually enter data, and have it potentially out-of-date, or to let the system populate, and us to overview. — billinghurst sDrewth 06:14, 17 January 2017 (UTC)

@Billinghurst: I think that if data for blank parameters is in Wikidata then we should use it. Also, as @Slowking4 says, that if the {{author}} template uses Wikidata data, then any wrong dates can be fixed over there instead. I've been investigating converting the date-handling bits of {{author}} to Lua (in Module:Author:dates()). Doing that would mean the various confusions around multiple dates and different qualifiers etc. could be handled with more ease than is the case in pure wikitext (e.g. multiple possible years for Author:David (1039 BCE/1040 BCE – 969 BCE/970 BCE) rather than just 'circa' (c. 1040 BCE – c. 970 BCE), to be more accurate). We can add tracking categories for managing the cases where data is different. Do you think this is a worthwhile direction to explore?

I've started writing some test cases to make it easier to maintain too. Sam Wilson 06:20, 17 January 2017 (UTC)

Oops, I was actually replying to your earlier comment @Billinghurst (you posted as I was writing), but I'm just agreeing with you, so it sort of makes sense still. :-) I think the way forward is to use WD data where we can, and bit by bit migrate to only using it. Sam Wilson 06:26, 17 January 2017 (UTC)

@Billinghurst: What we call "first name" and "family name" here are very different from what Wikidata uses. Our values are a matter of convenience, splitting the name so that the "family name" sets the alphabetical positioning for sorting, regardless of whether it is actually the "family name" or not. Likewise, the "first name" value is the remainder of the name to complete display in the header, and not simply the "first name". Wikidata does not do it this way, so there will not be a match.

Additionally, Wikidata values will necessarily be dynamic. It is not uncommon for the primary value for a name or name element at Wikidata to be altered. This would play havoc with any kind of internal linking to Author pages if we took that information dynamically from Wikidata, or updated. --EncycloPetey (talk) 13:03, 17 January 2017 (UTC)

@EncycloPetey: I understand that there are issues to work through, datum to populate, however, our "lastname" ties to "family name" and their combinations for "first name" can align with our components of "firstname", eg. Author:Adam Storey Farrar and d:Q350994. We can and should also be demanding of the system to generate data aligned with our needs. I have started working with their team to look at utilising our template parameters to further populate their data, and one of their team is involved with frWS. We will hasten slowly and deliberately. Sitting on our hands and doing nothing, means we become static and isolated, and to me that is a danger. We need to have bots, tools, and data extraction to make us more visible, and more flexible and to do the drudge work. — billinghurst sDrewth 22:20, 17 January 2017 (UTC)

@Billinghurst: I'm thinking especially of names from Arabic and Chinese, of medieval and classical names, of names that are royal or clerical, and of pseudonyms and pen names, where the usual rules seldom apply. Whatever we choose to do will have to account for such situations and ones like them. --EncycloPetey (talk) 03:07, 18 January 2017 (UTC)

@EncycloPetey: These are definitely things to be careful of. I think a lot of it comes down to how names are represented in WD, because I think it's pretty possible to capture all the nuance that is required at Wikisource, but that sometimes people don't add all the required data (which is fine; we can just fix it up). For example, given name (P735) can contain multiple statements, and each should be given a series ordinal (P1545) qualifier to record what order the names go in. So we can recreate the Wikisource version of someone's name by joining the names together in the required order. And then we could add maintenance categories to help fix the pages where the page title doesn't match what is retrieved from Wikidata. Do you have some examples of authors to examine?

Anyway, I think the current discussion is just about dates isn't it? (Specifically the idea to use Wikidata where there's no local date given.) Should we defer the discussion of names until the dates are sorted out? Sam Wilson 03:41, 18 January 2017 (UTC)

@Billinghurst: what do you think of the idea of switching {{author}} to using Module:Author? It should leave everything pretty much as it is, but also give us Category:Authors with birth dates differing from Wikidata and Category:Authors with death dates differing from Wikidata as a means to find problems. Do you have example authors with particularly weird dates? —Sam Wilson 06:02, 23 January 2017 (UTC)

Some examples of authors with weird dates:

• Author:Sallustius (4th century – 4th century)
• Author:Gaius Oppius (100 BCE – 100 BCE) !!
• Author:Vitruvius (70s BCE – c. 15 BCE)
• Author:Zosimus (490s–510s)
• Author:Quintus Curtius Rufus (?–?)

All of these are from Category:Ancient Roman authors, and there are more besides—some with two birth dates separated by a slash and such. --EncycloPetey (talk) 17:45, 2 February 2017 (UTC)

Hm, yeah, there's some weird ones! :) Will try to fix...

• Author:Sallustius (4th century – 4th century) What's wrong with this? I guess he was born and died within the same century, but no one knows quite when?
• Author:Gaius Oppius Fixed and is now (1st century BCE – 1st century BCE).
• Author:Vitruvius (70s BCE – c. 15 BCE) This is what's specified in the author template.
• Author:Zosimus (490s–510s) Again, these dates are the local override ones.
• Author:Quintus Curtius Rufus (?–?) Ditto.

Sam Wilson 01:49, 3 February 2017 (UTC)

 Comment why are we trying to generate vague years of birth and death in such situations, we simply should be using floriut. It is something that we would do well to reflect upon with wikidata availability. — billinghurst sDrewth 05:00, 3 February 2017 (UTC)

I think that (4th century – 4th century) and (1st century BCE – 1st century BCE) should just be rendered as (4th century) and (1st century BCE) respectively; I think that's what most editors have done with the dates parameter in the past for such authors. However, if that's too much bother, I don't think it matters very much. —Beleg Tâl (talk) 12:40, 3 February 2017 (UTC)

Typo: floruit, and I think using that in any instance where the birth and death dates are identical would be a good approach. --EncycloPetey (talk) 12:43, 3 February 2017 (UTC)

Yes, nice. Y — billinghurst sDrewth 00:50, 4 February 2017 (UTC)

•  Comment I edited Author:Quintus Curtius Rufus and found out that the qualifier for a date of death was "presumably" at wikidata, which is pretty weird . As we didn't plan for such use we didn't give a "c." marker, we may wish to monitor for it. (Personally I think that they should be corrected, which is what I did for this at WD.)

Wikidata date guidance

• d:Help:Dates#Inexact dates is worth a review to look at the scenarios we need to capture. — billinghurst sDrewth 22:48, 12 February 2017 (UTC)

Cleanups required ...

Looking at the some of the pages that are throwing up errors, I see that there are some practices that have taken place that are not ideal, especially if we can automate data. Some of these are also unnecessary as the author template had also means to handle some uncertainty. So without discussing the value of the parameters are sourced here or at WD, there is cleanup. We should maybe classify what needs to be done to what is clearly needed doing, and stuff that should be discussed in some depth. (Please feel free to add to the list)

Uncontroversial tasks

• remove birthyear = ?
• remove deathyear = ?
• remove dates = ?-? and variations

Other tasks

Shall we proceed with these?— Mpaa (talk) 20:28, 13 February 2017 (UTC)

Good idea. I'm confused about the categories though. Is the current idea is that authors with empty birth or death dates (i.e. empty here and on Wikidata) are categorised in Category:Authors with missing birth dates, but if we "know that we don't know" then they're in Category:Authors with unknown birth dates? What's the difference between Category:Authors with unknown birth dates and Category:? births (and their 'death' counterparts)? On the face of it I think we only need:

1. Category:Authors with missing birth dates
2. Category:Authors with missing death dates
3. Category:Living authors

There's no difference between a 'missing' and an 'unknown' birth date, because every author was born. The only difference comes with death dates, because living authors don't have death dates but that's not because they're missing.

With regard to displaying the dates and question marks, I think a missing birth or death date should be displayed as a '?', because for living people we already leave a blank death date after the dash (e.g. "?–1890" or "1840–?" for dead authors, or "1940–" for a living author). Alternatively, we could go the Wikipedia MoS route and do "b. 1940" for living authors, so that any dates with a dash would end with a date or a question mark. Or maybe just write "(living)" or something after instead?

Sam Wilson 02:08, 14 February 2017 (UTC)

How are you going to tell the difference between a living person, and a person with no death data? If they were born a loooong time ago (>120 years), then we can assume that they are dead, and apply "?", if they are marked as death date unknown/not recorded at WD, then we can apply a "?". If there is nothing shown, and < 120 years I will presume that we will regard as (presumed) living. I am happy with no terminator, it is understood and is easier to do automagically. To complicate matters, we are starting to get modern works that are freely licensed papers, and typically we don't have dates of life for these authors. So to me it seems wrong to manage that as ?–? for an author of a 2017 paper is not pertinent. Plus we are going to need to manage two different scenarios of "no birth date/no death date". I would always recommend play it safe, and we wait until there is some data like floruit or like showing which we can hang off and apply ?–? to it. — billinghurst sDrewth 06:29, 14 February 2017 (UTC)

I think we just have to assume that if no death date is given then they're alive, because it's easy to add 'unknown value' as the death date if they're known to be dead. At least, this seems to be the way it's working on Wikidata. The Author module here also takes "death date = no value" to mean living. We could additionally not mark people born more than 120 years ago as living (seems sensible to me) but we should really just do this as a way of tracking who needs to be updated at wikidata.

For the 2017 author example, I guess the current answer would be (20th century –); does this sound okay?

Birth dates are different in all this, because every author either has one or it is "unknown", so I think we only need Category:Authors with missing birth dates. Death dates have three states: known, unknown, and "living" (or no value). What do we need the other categories for?

Sam Wilson 02:49, 15 February 2017 (UTC)

Index:Majjhima Nikāya.djvu

Non english work? Uploaded for translation? ShakespeareFan00 (talk) 21:25, 2 February 2017 (UTC)

Creation of an index page is within scope. — billinghurst sDrewth 23:04, 2 February 2017 (UTC)

Disambiguation in Translation: namespace

We need to update {{disambiguation}} to work in the Translation: namespace. Parked here in case someone gets the time to do it before I do. We need to fix Translation:Penal Code of Thailand.

In fact there is a bit of work to do around those works as there is a portal-type construction going on there around dynamic laws, contrary to WS:WWI. Though one thing at a time. — billinghurst sDrewth 22:55, 2 February 2017 (UTC)

Why not limit {{disambiguation}} to the Main namespace. If there is a page in the Translation namespace that needs to function as a disambiguator (as we have here), then redirect it to the Main namespace for disambiguation, and link to entities there. Otherwise, we could end up with situations where we duplicate disambiguation lists in two different namespaces (e.g. when there are one or more copies in the Main namespace and one or more in the Translations namespace). --EncycloPetey (talk) 23:57, 2 February 2017 (UTC)

There was some similar commentary in Wikisource:Scriptorium/Archives/2016-10#Disambiguation and Wikidata items — a conundrum with no perfect solution by Hesperian. So are you thinking that no disambiguation in Translation: namespace, and that we utilise main namespace with templates disambiguation/versions/translations. — billinghurst sDrewth 05:27, 3 February 2017 (UTC)

I think that would be the simplest solution. The alternative would be to follow what the Italian Wikisource has started doing, and create an entirely new "Work:" namespace where information about any work is stored, including all versions/translations listings. However, I'm not decided in my own mind that their approach is a good or necessary change. --EncycloPetey (talk) 12:41, 3 February 2017 (UTC)

I agree that translations should be disambiguated in mainspace (Odes is an okay example). This is especially true since occasionally works in mainspace and works in Translation space need to be disambiguated from each other. —Beleg Tâl (talk) 12:46, 3 February 2017 (UTC)

Attempting a summary

We are therefore saying

1. disambiguate only once per title variation (all namespaces);
2. {{disambiguation}} can be used in one of three namespaces of Main, Author, Portal; and not in Translation, shouldn't be required elsewhere, think that there is one in Wikisource:
3. that where {{disambiguation}} is used it will initially occur in the namespace of the conflict; and if there is a title conflict in the main namespace with other namespaces (portal, author, translation), then the disambiguation will only take place in main namespace, and not be duplicated in other namespaces.

OR; I could more aggressively read the above comment to replace the last dot point as

1. (as above)
2. (as above)
3. All disambiguation shall take place for all namespaces in the main namespaces, irrespective of where the conflict takes place.

   Noting that the consequence of this variation would be that we would need to consider the status of all existing disambiguation pages outside of the main namespace (currently 250+ in Author, 5 in Portal

Questions:

• Any further comment?
• Should we prod the broader community for their opinion prior to next steps? Done
• What about guidance {{versions}} and {{translations}} which both could be used in Translation: namespace — noting that they are not currently.

Required outputs:

• Update Help:Disambiguation
• Possibly update existing disambiguation pages
• Possible tracking of use of templates (either Petscan or tracking categories)

— billinghurst sDrewth 06:06, 5 February 2017 (UTC)

 Comment Watchlist announcement put in place for all logged-in users. Suggested close of RFC: 14 February 2017

Comment about disambiguation change

I think that your summary #2 is the best option. I think it is worth noting that pages in mainspace and pages in Translation space are closely related, in that they are both works. Thus, a work called (say) Tim Jones could exist in mainspace, and another different work called Tim Jones could exist in Translation space. In such a case, Wikisource would have two hosted works entitled Tim Jones, and it would be useful to disambiguate between them; the appropriate place for such a disambiguation would be mainspace.

I am not sure about {{translations}} and {{versions}} without specific use cases. It seems to me that {{versions}} would be utterly inappropriate in Translations space, since {{translations}} is essentially the same thing as {{versions}} but for translations, and every single work in Translations space is a translation. I could see {{translations}} being used in Translation space if there were multiple Wikisource translations of the same work, but even then I would put the disambig page in mainspace. An example would be İstiklâl Marşı. Sometimes of course there will be a mix of translations in mainspace and in Translation space, such as The Internationale. —Beleg Tâl (talk) 17:37, 5 February 2017 (UTC)

You've misunderstood. The items given above constitute a summary, not a list of options. We're not choosing one of them; we're choosing all of them, or modifying them as needed. --EncycloPetey (talk) 17:42, 5 February 2017 (UTC)

Yes, it appears I did misunderstand. I think that mainspace works and Translation space works are both works, and therefore should be disambiguated with each other, and such disambiguation page should be in mainspace only. I think that Author space pages and Portal space pages are not works and should not require disambiguation with works in either mainspace or Translation space, even if the names are the same (e.g. St. Francis of Assisi and Author:Francis of Assisi) although in such case a link from one space to the other could be appropriate as in the example. I don't think this view aligns with either summary above, so do with my two cents as you will. —Beleg Tâl (talk) 01:57, 6 February 2017 (UTC)

The one comment to add here, and it was what provoked the previous thread (linked above) is that a disambiguation page we can only have one link to English Wikisource from Wikidata (like all interwiki links). So if Wikidata has the disambiguation page "John Smith" that can only be linked to once so would take main ns Whilst there could also be a disambiguation page "Author:John Smith" it would sit separate from the other disambig page, it would presumably never have a pairing page. And at the moment our linking to Wikidata from our content namespaces ignores the namespace nomenclature, so it would add complexity. That may not matter, and should not be the determinator, it is something to note, and consider. — billinghurst sDrewth 05:51, 6 February 2017 (UTC)

I personally do not think that that is a major problem, at least not for us. Commons has an issue where a given person might have a gallery in mainspace, a category in Category space, and a Creator space page as well, but only one page can be listed for Commons as an interwiki link. I understand that Wikidata is doing its best to accomodate Commons, rather than Commons accomodating Wikidata. In our case, I do not think that the benefit of having automatic interwiki links on our disambig pages is sufficient to justify the great undertaking of merging all disambiguation pages to mainspace. —Beleg Tâl (talk) 13:07, 6 February 2017 (UTC)

And to elaborate further: we do have instances where a work exists in multiple namespaces at once, e.g. Matthew (Bible) (the work) and Portal:Gospel of Matthew (works about the work), which has the same problem as having a disambiguation exist in multiple namespaces at once. —Beleg Tâl (talk) 13:13, 6 February 2017 (UTC)

Well, yes and no. There is no reason that Portal:Gospel of Matthew will be limited to copies of Matthew's gospel, or to works title "Matthew", but the page for Matthew (Bible) and Matthew are necessarily so limited. And it is always possible to have a more broadly defined portal that simply points to a disambiguation page for that portion of its content, but more likely it will contain a richer source of information. Consider Portal:Ancient Greek drama as an example of a Portal presentation that does list the translations of various Greek tragedies, but do so in a completely different sort of way from the associated disambiguation pages. So, I don't think the situation of having some duplication between Main namespace disambiguation and Portal namespace is especially relevant. --EncycloPetey (talk) 04:46, 8 February 2017 (UTC)

I think perhaps you have misunderstood me. What I mean is this, with a better example:

• The item that is the Gospel of John, represented on Wikidata as d:Q36766, has two pages on Wikisource: John (gospel) listing translations of this item, and Portal:Gospel of John listing works related to this item.
• The item that is disambiguation on "John", represented on Wikidata as d:Q397210, has two pages on Wikisource: John listing works labelled as this item, and Author:John listing people labelled as this item.

To me these scenarios are functionally equivalent and therefore quite relevant to the discussion. It is common practice to split a logical item into pages in separate namespaces with separate functions, and this is true of both disambig pages and work pages. —Beleg Tâl (talk) 13:49, 8 February 2017 (UTC)

Further to the above: if people really want to consolidate disambig pages from works, authors, and portals all on one page, I would not oppose a move in that direction, and in that case would prefer all such disambig pages to be in mainspace. —Beleg Tâl (talk) 04:09, 6 February 2017 (UTC)

I vote for mainspace-only. In my view:

1. Disambiguation pages (and also versions pages and translations pages) are in essence curated search results: a user types something into the search box, and, rather than let it be handled by the search tool, we intercept it and present a list of the things they were likely looking for. Or, a user follows an incorrect (because ambiguous) link, and we present a list of the things they were likely looking for.
2. With respect to the search box case: Only our experienced users (i.e. mainly our editors) know to type "Author:George Bush" into the search box, and we don't really need to worry about them—they will find what they are looking for. Our inexperienced users will type "George Bush" every time, and we must respond to this by taking them to our curated content, else there's no point having it. At present, these users get presented with search results, because George Bush doesn't exist. This suggests mainspace-only disambiguation pages are the way to go.

   aside @Hesperian: did you see #SEARCH: Subphrase matching. I am of a mind to ask whether the default for the community (anon and new) could be set to subphrase. That partially addresses the cases that you mention. — billinghurst sDrewth 05:16, 8 February 2017 (UTC)

3. With respect to the incorrect link case, this is best handled by us editors not creating such links in the first place. I know if I add a link that points to Author:George Bush and it comes up blue in preview, then I'll probably save without looking at the target. Thus we build up a heap of incorrect links to Author:George Bush, and these links then serve to justify the existence of the page. But if the page didn't exist, the link would have come up red, and I would have checked and disambiguated.

Hesperian 04:27, 8 February 2017 (UTC)

Matthew Henry's earlier edition

PeterR2 found a 1721 edition edition of Matthew Henry's An Exposition of the Old and New Testament (1828). It is not the whole thing, just the last folio in a four-volume set. I had started working on the later edition because I thought that the whole Bible version was not published until the nineteenth century. Matthew Henry died before finishing the final volume and other people completed it from his notes. Originally I thought that it was not published until about a century later, but I was definitely wrong. It has wonderful old-timey typography. In any case, the pdf is originally at Princeton, where I do not have a library account. Are there any legal concerns with moving the volume to Commons? Does anybody have access to download the pdf? Heyzeuss (talk) 18:46, 3 February 2017 (UTC)

I'm not sure I follow entirely, but if your only problem is downloading the work from HathiTrust, I've compiled instructions for how to do so without a login here. --Mukkakukaku (talk) 22:28, 5 February 2017 (UTC)

How, Mukkakukaku? I can download image or .PDF as single files and put them all together as one .PDF file but all single .PDFs have extra information added to both sides of the scan. It is as though each scan is placed on a larger sheet of white paper that has watermarks and information. —Maury (talk) 22:40, 5 February 2017 (UTC)

Another point, I have never had to log in here to download anything from HathiTrust and I have downloaded several works from HathiTrust but usually one page at a time. —Maury (talk) 00:10, 6 February 2017 (UTC)

Oh, okay, on your user page - I thought you meant you placed that on Wikisource or had it in a file on your computer. I am in the USA and I do use Firefox. —Maury (talk) 00:15, 6 February 2017 (UTC)

DownThemAll of Firefox is good for those sites (like DLI) where pages are individually numbered. In HathiTrust, all pages are named "image", without numbering. During batch download, smaller files get downloaded earlier. So they get renamed as per chronology of download, not original order in the book. Moreover, text pages are in png format and image pages in jpg format; so they get renamed separately. To overcome this problem, I am using Hathi Download Helper for downloading from HathiTrust. It is a free software, you only need to enter the id of the work. You can save the work in pdf, images etc, ocr option is also there. Hrishikes (talk) 01:26, 6 February 2017 (UTC)

Thank you, Hrishikes. Typically I have been working with Adobe Acrobat 11.0.08 and learned several ways to work with files from there, pdf, png, or jpg. But I have downloaded DownThemAll and I will download what you have suggested to see what those programs will do. I don’t know why Mukkakukaku would make such an excellent statement and then not answer a question about it. Again, thank you, —Maury (talk) 13:06, 6 February 2017 (UTC)

Oh, another tip for whomever, those files named "image" can easily be renamed and an extension placed on it. For example, if I want 3 image files and it shows "image" I will give them a number page 344.jpg, 345.jpg, 346.jpg By numbering them in sequence they remain that way, in (alpha/numerical) order after downloading.—Maury (talk) 13:20, 6 February 2017 (UTC)

Sorry, Maury, I didn't see your question. I hope Hrishikes was able to clarify things for you. (I personally have never had the problem them mentioned about downloaded pages being out of order, but I'm definitely going to check out the download helper tool recommended above.) For naming the files I usually apply a mask to get them numbered, something like *name**inum*.*ext*, but I think you figured this out already. :) --Mukkakukaku (talk) 04:02, 7 February 2017 (UTC)

No problem, Mukkakukaku. I thought perhaps you were still in this area but I found your user page. The program is one I had not used and I was curious about it. Hrishikes posted a very good explanation for the both of us. My thanks to the both of you for mentioning and clarifying the programs. Respects, —Maury (talk) 04:10, 7 February 2017 (UTC)

Just wondering whether anything further happened about this, Heyzeuss? PeterR2 (talk) 08:53, 18 February 2017 (UTC)

Index:The International Code of Marketing of Breast-milk Substitutes.pdf

Was raised at CV a long time ago, Scans now deleted at Commons, which means it needs cleanup, anyone?

ShakespeareFan00 (talk) 11:48, 6 February 2017 (UTC)

See - https://en.wikisource.org/wiki/File:The_International_Code_of_Marketing_of_Breast-milk_Substitutes.pdf for page links.

Thanks.ShakespeareFan00 (talk) 11:51, 6 February 2017 (UTC)

And the Page: s ? ShakespeareFan00 (talk) 12:39, 7 February 2017 (UTC)

Done.— Mpaa (talk) 21:59, 7 February 2017 (UTC)

Tech News: 2017-06

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

Problems

• The block log sometimes showed blocks as being much longer than they were. This has now been fixed. [3]

Changes this week

• Wikimedia pages will now be better at showing pictures when you share them on social media. The descriptions will be different too. You can see an example of before and after. [4]
• There are some changes to the OOjs UI. Some old functions will not work anymore or not work as they used to. This could be a breaking change. [5]
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 7 February. It will be on non-Wikipedia wikis and some Wikipedias from 8 February. It will be on all wikis from 9 February (calendar).

Meetings

• You can join the next meeting with the VisualEditor team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 7 February at 20:00 (UTC). See how to join.

Future changes

• Tidy will be replaced later this year. Instead, the HTML 5 parsing algorithm will be used to clean up bad HTML in wikitext. This will cause problems on a number of wikis. They need to be fixed first. You can see if your wiki still has something to fix here for one of the HTML problems. This list does not cover all problems. You can read about more problems. [6][7]

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

19:45, 6 February 2017 (UTC)

Fix coming this week

Tracked in PhabricatorTask T157204Resolved

At the advanced Special:Search the use of MediaWiki:Powersearch-ns was broken for the use of wikilkinks. I reported it this week, and a fix is is in the code and expected to be rolled out this week. Once this is rolled out then we can mark this as resolved. The fix expected is that wikilink code will become a wikilink. — billinghurst sDrewth 11:03, 7 February 2017 (UTC)

Proofread progress bar

Hi all, any chance we can get the proofread progress bar mw:Proofreadhelp#Proofreading_status_indicator next to listed works, or wherever we want it for each individual work. For example in portals or our user pages, where works are listed, to help with seeing where each individual work is at in the proofreading process. Is it possible?Jpez (talk) 10:37, 9 February 2017 (UTC)

@Jpez: It has been previously talked about and there is a phabricator ticket somewhere, so no. BUT! Please see recent discussions here (probably archived) about use of Special:IndexPages and it can be utilised to display a cut down list, and that list transcluded. Definitely not as perfect as what you desire, however <shrug>. — billinghurst sDrewth 21:47, 9 February 2017 (UTC)

@Jpez, @Billinghurst: It's a good idea, and wouldn't be too hard to implement I reckon. I can't find an existing phab task for it though; do you remember what it might be called? Or we can just create a new one. Sam Wilson 00:28, 10 February 2017 (UTC)

I could be dreaming that it became a phabricator ticket, and it would have been bugzilla time anyway. I cannot find it listed at mul:Wikisource:Wishlist, so it maybe was just an item discussed with Tpt or ThomasV before that. <shrug> Create a new one. — billinghurst sDrewth 01:23, 10 February 2017 (UTC)

Anyone willing to create the task? I wouldn't know where to begin myself. Jpez (talk) 12:34, 14 February 2017 (UTC)

CIA UFO reports

Hi, The CIA released last year some UFO reports [8]. I imported a few. May be some of you are interested: Index:Flying Saucers in East Germany, CIA Report.pdf. Regards, Yann (talk) 13:49, 9 February 2017 (UTC)

Errata - because life is never simple

I've run into an issue on Page:Odes of Pindar (Myers).djvu/91 with the use of {{errata}} because the error to be annotated appears within a footnote.

Does anyone technically-minded enough have the means to edit the template, or to suggest a way this might be handled? --EncycloPetey (talk) 02:58, 11 February 2017 (UTC)

Done Nevermind. Found a workable solution documented at Help:Footnotes and endnotes that did the trick. --EncycloPetey (talk) 04:49, 11 February 2017 (UTC)

New problem with {{errata}}: I'm getting text overlap at Page:Odes of Pindar (Myers).djvu/98, and this appears in the transcluded version as well.

Any suggestions? --EncycloPetey (talk) 21:39, 13 February 2017 (UTC)

Should be okay now. The style you applied to the containing <div> "text-indent:-1em" also applies to any block child elements, and {{errata}} displays as inline-block. —Beleg Tâl (talk) 02:07, 14 February 2017 (UTC)

Index:Mrs Beeton's Book of Household Management.djvu

All the recipe text is now present. Much appreciated if someone could work on the 16 pages of Menus, and the Index which remain, as I'd like to focus on some other projects.

ShakespeareFan00 (talk) 12:01, 13 February 2017 (UTC)

Orphaned pages of deleted index.

Bulk speedy anyone?

List

• • Page:The Pilgrim's Progress.djvu/1
  • Page:The Pilgrim's Progress.djvu/10
  • Page:The Pilgrim's Progress.djvu/11
  • Page:The Pilgrim's Progress.djvu/117
  • Page:The Pilgrim's Progress.djvu/118
  • Page:The Pilgrim's Progress.djvu/13
  • Page:The Pilgrim's Progress.djvu/142
  • Page:The Pilgrim's Progress.djvu/151
  • Page:The Pilgrim's Progress.djvu/152
  • Page:The Pilgrim's Progress.djvu/167
  • Page:The Pilgrim's Progress.djvu/168
  • Page:The Pilgrim's Progress.djvu/193
  • Page:The Pilgrim's Progress.djvu/194
  • Page:The Pilgrim's Progress.djvu/2
  • Page:The Pilgrim's Progress.djvu/202
  • Page:The Pilgrim's Progress.djvu/203
  • Page:The Pilgrim's Progress.djvu/21
  • Page:The Pilgrim's Progress.djvu/214
  • Page:The Pilgrim's Progress.djvu/22
  • Page:The Pilgrim's Progress.djvu/223
  • Page:The Pilgrim's Progress.djvu/224
  • Page:The Pilgrim's Progress.djvu/23
  • Page:The Pilgrim's Progress.djvu/239
  • Page:The Pilgrim's Progress.djvu/24
  • Page:The Pilgrim's Progress.djvu/240
  • Page:The Pilgrim's Progress.djvu/25
  • Page:The Pilgrim's Progress.djvu/26
  • Page:The Pilgrim's Progress.djvu/269
  • Page:The Pilgrim's Progress.djvu/27
  • Page:The Pilgrim's Progress.djvu/270
  • Page:The Pilgrim's Progress.djvu/28
  • Page:The Pilgrim's Progress.djvu/299
  • Page:The Pilgrim's Progress.djvu/3
  • Page:The Pilgrim's Progress.djvu/300
  • Page:The Pilgrim's Progress.djvu/329
  • Page:The Pilgrim's Progress.djvu/330
  • Page:The Pilgrim's Progress.djvu/347
  • Page:The Pilgrim's Progress.djvu/348
  • Page:The Pilgrim's Progress.djvu/374
  • Page:The Pilgrim's Progress.djvu/375
  • Page:The Pilgrim's Progress.djvu/376
  • Page:The Pilgrim's Progress.djvu/389
  • Page:The Pilgrim's Progress.djvu/390
  • Page:The Pilgrim's Progress.djvu/391
  • Page:The Pilgrim's Progress.djvu/392
  • Page:The Pilgrim's Progress.djvu/4
  • Page:The Pilgrim's Progress.djvu/5
  • Page:The Pilgrim's Progress.djvu/59
  • Page:The Pilgrim's Progress.djvu/60
  • Page:The Pilgrim's Progress.djvu/7
  • Page:The Pilgrim's Progress.djvu/79
  • Page:The Pilgrim's Progress.djvu/8
  • Page:The Pilgrim's Progress.djvu/80
  • Page:The Pilgrim's Progress.djvu/89
  • Page:The Pilgrim's Progress.djvu/9

ShakespeareFan00 (talk) 16:10, 13 February 2017 (UTC)

Done —Beleg Tâl (talk) 18:56, 13 February 2017 (UTC)

De-Recognition of Wikimedia Hong Kong

This is an update from the Wikimedia Affiliations Committee. Translations are available.

Recognition as a Wikimedia movement affiliate — a chapter, thematic organization, or user group — is a privilege that allows an independent group to officially use the Wikimedia trademarks to further the Wikimedia mission.

The principal Wikimedia movement affiliate in the Hong Kong region is Wikimedia Hong Kong, a Wikimedia chapter recognized in 2008. As a result of Wikimedia Hong Kong’s long-standing non-compliance with reporting requirements, the Wikimedia Foundation and the Affiliations Committee have determined that Wikimedia Hong Kong’s status as a Wikimedia chapter will not be renewed after February 1, 2017.

If you have questions about what this means for the community members in your region or language areas, we have put together a basic FAQ. We also invite you to visit the main Wikimedia movement affiliates page for more information on currently active movement affiliates and more information on the Wikimedia movement affiliates system.

Posted by MediaWiki message delivery on behalf of the Affiliations Committee, 16:25, 13 February 2017 (UTC) • Please help translate to your language • Get help

Tech News: 2017-07

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

Recent changes

• EventStreams is a new way to show activity on Wikimedia wikis. For now it works with the recent changes feed. It will do more things later. It will replace RCStream. Tools that use RCStream should move to EventStreams before 7 July. [9]

Problems

• The Firefox add-on Firefogg can cause problems with the Upload Wizard. This will not be fixed, because Firefox will not support Firefogg in the future. The Upload Wizard will no longer work with Firefogg. [10]
• Tool Labs and Wikimedia Labs databases will be under maintenance on 15 February. This will start at 17:00 (UTC) and last for about six hours. Some tools could have problems during or after this. [11]

Changes this week

• The TwoColConflict extension is a new way to solve edit conflicts. It makes it easier to copy and paste the relevant text to the text field. It will come to Meta and German Wikipedia this week. It is already available on MediaWiki.org. It will come to more wikis later. [12]
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 14 February. It will be on non-Wikipedia wikis and some Wikipedias from 15 February. It will be on all wikis from 16 February (calendar).

Meetings

• You can join the next meeting with the VisualEditor team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 14 February at 20:00 (UTC). See how to join.

Future changes

• Page Previews will be turned on for logged-out users on the Catalan, Greek, Russian, and Italian Wikipedias in the middle of February. Page Previews shows readers a short part of a linked article when they rest their mouse pointer on the link. This is to help them understand what it is about without leaving the article they are reading. Page Previews used to be called Hovercards. It will come to more wikis later this spring. [13]
• The Developer Wishlist is a list where developers prioritize tools they need. The voting closes at 14 February 23:59 (UTC). This process is only for developers.

Review

• You can read the 2016 product summary from the Wikimedia Foundation Product group to see what they did with things they said they would work on in the annual plan.

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

18:06, 13 February 2017 (UTC)

Collaboration products newsletter: 2017-02

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

What's new?

Flow satisfaction survey’s results are available. The survey provides useful data on what users like and don't like about Flow. This information will be helpful in discussions recently begun as part of the editing team's Annual Plan process. As the editing team investigates its priorities for next fiscal year (which begins in July), many ideas for improvements have been suggested, including projects to research the future of wiki discussions and to fix Flow's shortcomings.

Edit Review Improvements [More information • Help pages]

• Huggle users are asked to share their feedback concerning proposed improvements for Huggle.

Notifications [More information • Help pages]

• Flow notifications category in the Notification Preferences page will be changed from (in English) "Flow" to "Flow Discussion". Messages that have to be updated on TranslateWiki are echo-category-title-flow-discussion and echo-pref-tooltip-flow-discussion. [14]
• Mentions were not recognized when more than one section is added during the same edit or when an new section was added and a change (new message or deletion) was done in another section. This is now solved. [15]

Flow [More information • Help pages]

• Rich text mode is now the default in Flow replies. Some inconsistencies used to exist. Now the preference between visual mode and wikitext mode is updated when a content change is made in the selected editor, literally when it is typed in, not when it is saved or when the editor is switched. [16]
• We plan to change Flow's URLs to make them more human readable. Your feedback is still welcome, the conversation will be closed on February 28th.

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

09:40, 14 February 2017 (UTC)

Script created for assisting Fourier/FFT/descreening/half-tone removal workflows

I've assembled a bash script for assisting with workflows for removing half-toning and the resulting moire effects in scanned images. It automates a few of the tedious steps of FFT processing, automatically reprocessing an image each time an intermediary file is edited. It's primarily ripped from an ImageMagick guide, and requires ImageMagick and inotifywait.

I'm thinking of linking to this from the Commons guides to descreening: Help:Scanning and Commons:Cleaning up interference with Fourier analysis.

Any input would be appreciated. djr13 (talk) 01:00, 15 February 2017 (UTC)

Oh, that's cool. Will it run on Windows under Cygwin if I can convince ImageMagick to cooperate, do you think? --Mukkakukaku (talk) 02:43, 15 February 2017 (UTC)

It would almost certainly require significant adaptation. I'm not sure if there's a Windows compatible equivalent of inotifywait...the script could be changed to make it an optional feature though. And of course that assumes you can run bash scripts without a problem. Feel free to modify it. I put it together rather crudely. djr13 (talk) 03:36, 15 February 2017 (UTC)

Author template

Sorry everyone, I just stuffed up the author template for a moment. It's fixed now. I hiding the dates on author disambiguation pages (or rather their categories). Sam Wilson 04:36, 15 February 2017 (UTC)

@Samwilson: Thanks. —Justin (koavf)❤T☮C☺M☯ 04:39, 15 February 2017 (UTC)

Review of initial updates on Wikimedia movement strategy process

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

The Wikimedia movement is beginning a movement-wide strategy discussion, a process which will run throughout 2017. For 15 years, Wikimedians have worked together to build the largest free knowledge resource in human history. During this time, we've grown from a small group of editors to a diverse network of editors, developers, affiliates, readers, donors, and partners. Today, we are more than a group of websites. We are a movement rooted in values and a powerful vision: all knowledge for all people. As a movement, we have an opportunity to decide where we go from here.

This movement strategy discussion will focus on the future of our movement: where we want to go together, and what we want to achieve. We hope to design an inclusive process that makes space for everyone: editors, community leaders, affiliates, developers, readers, donors, technology platforms, institutional partners, and people we have yet to reach. There will be multiple ways to participate including on-wiki, in private spaces, and in-person meetings. You are warmly invited to join and make your voice heard.

The immediate goal is to have a strategic direction by Wikimania 2017 to help frame a discussion on how we work together toward that strategic direction.

Regular updates are being sent to the Wikimedia-l mailing list, and posted on Meta-Wiki. Beginning with this message, monthly reviews of these updates will be sent to this page as well. Sign up to receive future announcements and monthly highlights of strategy updates on your user talk page.

Here is a review of the updates that have been sent so far:

• Update 1 on Wikimedia movement strategy process (15 December 2016)
  • Introduction to process and information about budget spending resolution to support it
• Update 2 on Wikimedia movement strategy process (23 December 2016)
  • Start of search for Lead Architect for movement strategy process
• Update 3 on Wikimedia movement strategy process (8 January 2017)
  • Plans for strategy sessions at upcoming Wikimedia Conference 2017
• Update 4 on Wikimedia movement strategy process (11 January 2017)
  • Introduction of williamsworks
• Update 5 on Wikimedia movement strategy process (2 February 2017)
  • The core movement strategy team, team tracks being developed, introduction of the Community Process Steering Committee, discussions at WikiIndaba conference 2017 and the Wikimedia movement affiliates executive directors gathering in Switzerland
• Update 6 on Wikimedia movement strategy process (10 February 2017)
  • Tracks A & B process prototypes and providing feedback, updates on development of all four Tracks

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

Posted by MediaWiki message delivery on behalf of the Wikimedia Foundation, 20:31, 15 February 2017 (UTC) • Please help translate to your language • Get help

How to edit a typo?

Here in the last sentence a scanning error: "We'11 have" instead of "We'll have". I am an experienced Wikipedia editor, but here after 10 mins of searching a way to edit this I decided to ask. --Neolexx (talk) 10:13, 18 February 2017 (UTC) Whatever you've done with the interface — it is way overdone.

@Neolexx: The page numbers on the left hand side of the page link through to the underlying publication with the image (from Commons). From there you can edit the text with the image. — billinghurst sDrewth 11:21, 18 February 2017 (UTC)

Thank you, done. --Neolexx (talk) 11:27, 18 February 2017 (UTC)

Short titles

Following a disscussion here:

User_talk:Hrishikes#Indian_Legislation

I, felt this needed a wider disscusion.

Various items of legislation in the UK (and other Commonwealth Realms) use short titles.

English Wikisource has a Lua module accessed via a series of {{short-title}} templates.

However, those templates (which were used quite extensively by me), don't necessarily included any form of automatic disambiguation or ability to consider that different Jurisdictions may have identically titled legislation.

{{short-title/y1}} for example links to Copyright Act 1956 which is a redirect to the actual item at Copyright Act, 1956 (United Kingdom)

There hasn't to date necessarily been any consistency of titling, and I'm not aware of any semi-formalised Wikisource policy on this, so I am opening this thread with a view to establishing what the actual guidelines should be so that the relevant Lua module and dependent templates only need to broken ONCE, and that there only needs to be one set of re-titlings (or redirects) to ensure consistency across English Wikisource.

In the linked user talk disscussion, concern was also raised about the use of an "Act # of YYYY (India)" form for Indian primary legislation , on the basis that although able to link uniquely, a title of that form wasn't necessarily what potential searchers would be familiar with. I'd also note that many earlier items of UK legislation also have A regnal, Chapter form, which although identifying stuff uniquely, might not be how researches find relevant items.

My view currently was that United Kingdom acts should be suffixed (United Kingdom) to disambig them from Indian ones suffixed "(India)" and so on..

Hence you'd have:-

• Copyright Act, 1956 (United Kingdom) (4 & 5 Eliz. 2 Ch. 74)
• Indian Copyright Act 1957 (India) (Act 14 of 1957)

(Note: In the latter the Suffix might be considered redundant but is included for completeness.)

It would also be nice to have a consistent rule about when to use a Comma before the Year, for Acts passed in various Jurisdictions

So I'm opening this disscussion in the hope that someone can sort out :-

• Consistent titling/linking guidelines.
• Document such guidelines.
• Update the {{short-title}} series of templates accordingly.
• Check for existing linked items, and update links accordingly.

The eventual goal being ONE consistent and logical approach. ShakespeareFan00 (talk) 12:20, 18 February 2017 (UTC)

Read later

is there any way i can add pages to some place to read them later on other devices if there is pleas tell me and if not then tell me so that i can make one it would be nice to save pages you like to read them later on all the devices your account is logged in —unsigned comment by Zia-ur-Rehman Rehmanii (talk) .

@Zia-ur-Rehman Rehmanii: You can make a book at Special:Book and choose whichever text you want to save and read later or print out as a PDF. —Justin (koavf)❤T☮C☺M☯ 18:07, 18 February 2017 (UTC)

yes but that would be not as efficient as a link to that page saved in your account like a bookmark

eg. you can save it on your computer and read it in your tablet or mobile just mark the page and it is synced into all your devices @Zia-ur-Rehman Rehmanii:

@Zia-ur-Rehman Rehmanii: You can save it at User:Zia-ur-Rehman Rehmanii/Book. —Justin (koavf)❤T☮C☺M☯ 18:41, 18 February 2017 (UTC)

do you mean save for offline reading if you do then it would not be synced into all your devices and if you mean a bookmark into the browser then some browsers do sync bookmark but there are these other browser which do not sync them and that's the problem

oh sorry i dint see the last part but any how that would save it like a book and that's not what you would want like massing up Wikisource just for your own benefit so that you can read the page later i just want to save the link for it so that later when i click the link i am directed to the page just like that no making useless books and massing up the Wikisource —unsigned comment by Zia-ur-Rehman Rehmanii (talk) .

@Zia-ur-Rehman Rehmanii: You can save for offline reading as a PDF or you can make it on the Web and bookmark it. You can do both. It's not a problem to make user books--it's a feature. Sorry, I'm not sure about what you mean by syncing links. Firefox has a feature like this so you may want to use that browser. —Justin (koavf)❤T☮C☺M☯ 19:03, 18 February 2017 (UTC)

Sir i don't think that your are getting my point lets say for example that you want to save a page to read it later in your mobile or tablet so if you save it like a book you would generally loss the link to that page itself so i just want to make it a bookmark so when i open Wikisource in my mobile or tablet there is a notification saying hay you have just bookmarked a page want to read it and when i click that link it redirects my browser to that page itself by its link not to a saved PDF file or something like that because that way i will not b able to see the categorys below the page and the tools available for simple page not for pdf files or books

Does your browser have bookmarks? If so, you can save that bookmark, and add a hashtag for the page number when you save, such as "#45" to the end of the page location to take you back to page 45. To make this portable, save the link on your user page. For example: Cape Cod (1865) Thoreau/The Plains of Nauset#45. --EncycloPetey (talk) 19:23, 18 February 2017 (UTC)

Well thank you all but i think i have founded my solution somewhere else i just gonna ma a suggestion on phabricator for something like this or i will make an extension for it thanks again

•  Comment @Zia-ur-Rehman Rehmanii: the download/print options (left sidebar) available for every work allow you to save the work in a format for you to read offline (epub/mobi/pdf/...) We prefer those over the default Special:Book, though we left the default in place. — billinghurst sDrewth 10:15, 19 February 2017 (UTC)

  And if you are on mobile technology then you should be getting those icons which you should be able to bookmark. — billinghurst sDrewth 10:17, 19 February 2017 (UTC)

Tech News: 2017-08

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

Recent changes

• The edit summary box is now a little bit bigger. This is to make it follow the Wikimedia design guide. [17]

Changes this week

• Page Previews will be updated on 23 February. This fixes many bugs. Page Previews can be turned on as the Beta Feature called Hovercards. [18]
• There has been a problem where the CSS of gadgets has been loading twice. The Gadgets extension has two new options: type and peers. The type option solves this problem. You can use peers to create gadgets with more than one style module. Read more about type and peers. [19]
• OAuth will handle blocked users in a more consistent way. [20]
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 21 February. It will be on non-Wikipedia wikis and some Wikipedias from 22 February. It will be on all wikis from 23 February (calendar).

Meetings

• You can join the next meeting with the VisualEditor team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 21 February at 20:00 (UTC). See how to join.

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

19:25, 20 February 2017 (UTC)

Footnote groups?

On w:Help:Cite link labels, there's a description of predefined ref group names (lower-alpha, upper-roman, etc.) that can be used to make the footnote markers for non-default groups be ^[a], ^[b], or ^[I], ^[II], and so forth; rather than something like ^{[groupname 1]}, ^{[groupname 2]}. I've used that approach in various places on enwiki with reasonable success, however, on WS, with a <ref group=lower-alpha> tag, I'm instead getting ^{[lower-alpha 1]}, ^{[lower-alpha 2]}.

Is this a known issue? Deliberate? Can it be fixed? Worked around?

I ran into this with a work that has ordinary running footnotes throughout (that I am putting in the default group and will be collecting at the end), but for one page has inline notes in the middle of that one page (annotating a piece of Middle English poetry). --Xover (talk) 09:07, 21 February 2017 (UTC)

Wikisource does not attempt to replicate the specific footnote symbol notation of the original. Instead, we use sequential numbering, regardless of the style of footnote markings in the original. It is possible to create a separate grouping, but the process is not pretty. See Help:Footnotes and endnotes. --EncycloPetey (talk) 09:10, 21 February 2017 (UTC)

@Xover: In many cases we would transclude the work to its own page, rather than a series of works on a page. If it is on its own page then the references become a tidy set of endnotes without any need to differentiate with anything else on other pages. — billinghurst sDrewth 09:57, 21 February 2017 (UTC)

Hmm. I don't think I'm following you (sorry). The work in question is a sixty-odd page book (pamphlet?) that originally appeared as a newspaper article, with very little internal division (chapters and so forth). The only way I could see it transcluded to mainspace would be as a single unit. But perhaps I'm missing something?

Note that this is not a collection of poetry (if your meaning was that each poem would be its own page?), but a critical commentary on a literary controversy (Malone's takedown of Chatterton's fake Middle English "Rowley" poems) that happens to quote some poetry in order to illustrate its points.

The notes in question (explanations for individual words in a Middle English poem) really do belong, not only on the same page, but really just under the poem they are attached to. In the work they are distinct from all the other, normal, notes (which I am treating as EncycloPetey suggests), and really should be treated as such. Intermingling them with regular notes would, in my opinion, be very suboptimal and lose a small, but significant, amount of fidelity.

I could certainly just use a ref group name like "n", to get ^{[n 1]}, but even that is pretty gross for where it'll be used. The optimal solution would be to use the lower-alpha predefined group, which, I believe, is a default part of Cite.php (which is these days a core part of MediaWiki and should be updated whenever it is). As best I can tell, that this does not work is either an error somewhere, a lack of the requisite configuration for it on WS (the note markers for each group need to be defined, as outlined on the enwiki Help: page I linked above), or functionality that has been deliberately disabled on WS for some reason (which I would be interested to know, incidentally). --Xover (talk) 10:26, 21 February 2017 (UTC)

What (non-stylistic) reason is there to use footnote groups for this particular work? Admittedly I only spot checked a few pages, but I don't see any real reason why standard footnotes won't suffice.

If you're concerned about the length of the work, you can navigate back from the footnote to where you were originally in the text by clicking the little arrow next to the on the footnote number. It's less convenient than when you're looking at a paged work, but it's the functionality that we have implemented here at this time. --Mukkakukaku (talk) 03:03, 22 February 2017 (UTC)

If there are some logical spaces to break or interrupt the work, then we can even do (on the one page) sets of transclusions, and put {{smallrefs}} in between the transclusions. There are numbers of ways to address the issue without thinking that we are having to do an exact replica. [We have already changed the presentation by doing endnotes rather than footnotes.] — billinghurst sDrewth 06:34, 22 February 2017 (UTC)

Second attempt

Ok, I seem to have been unclear, so let me make a second attempt…

My request here is primarily regarding a technical capability.

The Cite.php extension has for quite some time now been a part of MediaWiki core and included in updates of MediaWiki, and is what provides the <ref> functionality… This module has support for reference groups (using <ref group="someGroupName">), and these work also on English Wikisource. In addition to this, the module has support for some "special" group names which, when used, affect how the note marker that's displayed for the note is generated. In the default group, this is ^[1], ^[2]. In these special groups, as typically implemented (it's configurable to at least some extent), these can be ^[a], ^[b] (with the special group lower-alpha) or ^[I], ^[II] (using upper-roman), and so forth.

So… I am asking for this technical capability to be made available here, completely independently of the policy and practical questions of where it is appropriate to use it. The feature is mature, included in MediaWIki core, in use on other high-volume Wikimedia wikis, is (as best I can tell) not very costly to implement, should cause very little added maintenance (effectively none that I can see), and has no obvious drawbacks or downsides.

Now, the reason I thought to ask for this is a specific problem I ran into where having this capability would have solved the problem in a much nicer way than the workaround I eventually landed on.

The specific case, for which I wanted to use this technical capability, is in the work Cursory Observations on the Poems Attributed to Thomas Rowley (1782). This sixty-odd page book discusses Thomas Chatterton's forged Middle English poems—published in the 18th century, but passed off as being by a priest named "Thomas Rowley" in the 15th century—and tries to demonstrate why the poems in questions are modern (18th century) fakes. The work has running notes throughout (and Edmond Malone is a right bastard about footnotes, so there are a lot and they are long!) that I have implemented using the bog standard <ref> tags in the default group, and which are transcluded, using {{smallrefs}}, in a separate section after the pages of the work itself are transcluded. So far so good…

However, in the course of his takedown of the poems, Malone at one point (on one page) quotes one of the poems in its original Middle English in order to, among other things, show that Chatterton's use of Middle English words is inconsistent (and he invents words, etc.). In this poem he has annotated the text with little footnote-ish markers, that point to explanations that are then given inline in the text (in the middle of the page; not down at the bottom with the other footnotes). These are distinct from the running notes, both conceptually and concretely as implemented in the original work. That is, they are a perfect case for using reference groups. Except that absent support for the "special" group names, the note labels generated are of the form ^{[groupname 1]}, ^{[groupname 2]}, which, in this specific case, is really ugly and disturbing (big blue markers inside the text of a poem, even multiple ones in a single line).

To work around this lack I've used {{ref}}/{{note}} templates, but that's a really tedious and suboptimal approach, that I would really rather have tried to solve using the pre-defined group name feature of Cite.php.

The page in question is this one: Page:Cursory Observations on the Poems Attributed to Thomas Rowley (1782).pdf/52

So… There are two distinct issues here. The first is the availability of the technical capability, and the second is when, where, and how to actually use it. And on the latter issue it seems obvious that it should be used sparingly, but if we don't have that technical capability it can't be used at all; in no cases, even in ones we have as yet not thought of. --Xover (talk) 10:46, 22 February 2017 (UTC)

Another work which would benefit from this feature: Bible (Webster's)/Obadiah —Beleg Tâl (talk) 13:28, 22 February 2017 (UTC)

WMF Wikis all have the same version of mw:Extension:Cite so I would presume that is simply a style issue.

Our reluctance has been addressed previously in this forum, and comes down to 1) footnotes to endnotes changes the dynamics of a work, 2) ye olde use of * † ‡ § ... is extremely limiting and becomes problematic, 3) fussing on (archaic) footnotes through a work was problematic in a shared environment, 4) pushing that approach is out of step with our guidance (use KISS). — billinghurst sDrewth 21:52, 22 February 2017 (UTC)

If it is the labelling for the grouping that you wish, you can create it manually, it is just a representation at that point. — billinghurst sDrewth 22:17, 22 February 2017 (UTC)

 Comment for Page:Cursory Observations on the Poems Attributed to Thomas Rowley (1782).pdf/52 within our current setup, I would have done a reference group "∞" (pick your symbol of choice that works with Cite) and then had an inline and within-page{{smallrefs|group="∞"}}. You are wanting to keep it in situ and not as a endnote. I can see that utilising a horizontal list can have benefits, and we may wish to adapt the template to be able to force a horizontal list. — billinghurst sDrewth 22:25, 22 February 2017 (UTC)

Our reluctance to add alternate styles to reference presentation is related to once we make something available there are some who wish to slavishly replicate a work, despite the difficulties in presenting, and in further proofreading. We have experience in those (ugly) difficulties and those difficult conversations. Reproduction of works covers a spectrum, and being hard up against the "100% look" of a book doesn't work on the web in our experience, so we look to be close, though retain modern features, and be web (desk and mobile) and wiki compliant. — billinghurst sDrewth 22:45, 22 February 2017 (UTC)

all explained at w:Help:Cite link labels — billinghurst sDrewth 05:55, 23 February 2017 (UTC)

Display of floruit dates from Wikidata

I know there was recently some work done on importing floruit dates from Wikidata and I’ve just noticed there might be a small error in the import. I’ve created author page A. M. Sanchez and corresponding Wikdata item d: Q28811762 and since there was very little to find regarding date of birth or death, I added a floruit date for the 1900s (meaning 1900-1910), which was about as accurate as I could make it.

It was imported to the author page as (fl. 1895s), so there seems to be some mistranslation going on there. I’m not sure where the import is defined or happening or I’d gladly have a look. Anyone with some more knowledge able to help here? Ping @Samwilson:, I believe you did a lot of work here? Marjoleinkl (talk) 12:25, 21 February 2017 (UTC)

@Marjoleinkl: Thanks for finding this bug! :-) I've tweaked Module:Author to hopefully better account for decade precision in all dates. Let me know if there's anything still amiss. Sam Wilson 12:41, 21 February 2017 (UTC)

See also Category:Authors with approximate floruit dates. Sam Wilson 12:43, 21 February 2017 (UTC)

Great thank you very much :) I’ll let you know if I run into other things Marjoleinkl (talk) 13:52, 21 February 2017 (UTC)

Error: Author:Corinna is categorized in Category:Living authors, despite "fl. c. 509 BCE". I assume this has happened because the Wikidata item uses floruit and there is no definitive date of death. --EncycloPetey (talk) 00:46, 26 February 2017 (UTC)

Fixed. It will now remove 'living authors' from anyone with a date more than 110 years ago. Sam Wilson 23:43, 26 February 2017 (UTC)

Trinity's Access to Research Archives — plenty of downloads available

Hi. I have found that Trinity College has both some open access and old works available as scans. See http://www.tara.tcd.ie/

I have started to probe "JSSISI: Journal of The Statistical and Social Inquiry Society of Ireland, 1847- " and ther eis quite an eclectic mix of stuff there. — billinghurst sDrewth 06:29, 25 February 2017 (UTC)

Tech News: 2017-09

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

Problems

• On 22 February the wikipedia.org portal did not work for an hour. This was because of a problem with a JavaScript file. [21]

Changes this week

• You will be able to use <chem> to write chemical formulas in the visual editor. Previously this only worked in the wikitext editor. [22]
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 28 February. It will be on non-Wikipedia wikis and some Wikipedias from 1 March. It will be on all wikis from 2 March (calendar).

Meetings

• You can join the next meeting with the VisualEditor team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 28 February at 20:00 (UTC). See how to join.

Future changes

• You can soon upload 3D files to Commons. The file formats are AMF and STL. The plan is for this to work later this week but it could be later. [23]
• The name "Wikipedia" will be more obvious at the top of the page when you read Wikipedia in the mobile view. This is because many readers don't realize they are on Wikipedia. [24][25]

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

19:55, 27 February 2017 (UTC)

Index:Mrs Beeton's Book of Household Management.djvu

I finally managed to complete the Index.

Does anyone want to validate and transclude? ShakespeareFan00 (talk) 22:09, 27 February 2017 (UTC)

I need some feedback about Index:History of Greece Vol I.djvu

Since I’m not really acustomed with en.wikisource I would like some feedback and opinions about the following matters:

1. Am I handling well the refs that span 2 pages? I copy the rest of the reference to the previus page (e.g. Page:History of Greece Vol I.djvu/59)
2. When a new paragraph is need within a ref, I insert a newline followed by a {{nop}}. Is this the manner I should handle it? (e.g. Page:History of Greece Vol I.djvu/60)
3. Am I supposed to link every instance of an Author that has a page in en.wikisource, and every instance of a work cited or once per page, or just once (only the first time)?
4. Since this work cites greek classical texts in their original language, should I link the ref to el.wikisource, when the original is available? (E.g. [[Author:Plutarch|Plutarch]], [[Lives (Dryden translation)/Solon|Solon]], [[:el:Βίοι Παράλληλοι/Σόλων|c. 12]] i.e. Plutarch, Solon, c. 12)
5. should I use the <poem> tag in cases like in the second ref of Page:History of Greece Vol I.djvu/59, or is the <br /> tag preferable?

Thank you in advance! —Ah3kal (talk) 08:10, 26 February 2017 (UTC)

@Ah3kal: some comment in reply

1. Help:References ... we look to leave them in situ as there is a means to identify and join continuing refs. Weird or bug-eyed formatting solutions would drive us to amalgamate, ie. when there is a table split across two pages (my bane yesterday)
2. I would usually put in a <p> or a <br/> to make up for the collapsing component. Whatever works, it isn't critical.
3. I normally link once per chapter, and again for a link going into an endnote. We are more likely to underlink than overlink.
4. Bit of a toughie, if you know that the work exists at the wiki, and is the author's direct work, then sure. Often with those ancient works we end up with a disambig page, and that can contain a link to the works. That is usually what I do, but that is personal. As it is rarer for a work to exist in native language it is not something that we have discussed from memory.
5. We don't prescribe between <poem> and <br/>, personal choice to get the desired result, community did not reach a consensus and in the end it makes little difference. — billinghurst sDrewth 10:35, 26 February 2017 (UTC)

Thank you very much billinghurst. I feel a bit dumb that I didn’t notice Help:References. As for greek texts, given that el.wikisource is my homewiki, I can resolve the links to the actual texts (when no exact edition is mentioned). —Ah3kal (talk) 14:21, 26 February 2017 (UTC)

2. A {{dhr}} {double hard return) between paragraphs works too. Zoeannl (talk) 23:50, 15 March 2017 (UTC)

An Exposition of the Old and New Testament (1828) (Matthew Henry)

Work has been in progress for some time on this, initiated by User:Heyzeuss, though it has not got all that far. Having done some proofreading in Genesis, I decided to check and if possible validate some of the earliest pages done before I arrived so that there were not too many "yellow" pages awaiting "green" validation. I discovered that the end of the Memoir of Matthew Henry was missing from Wikisource and from the source scan at Archive.org . However I find at Hathi Trust that only two pages are missing and would like to add these from Hathi. Could someone put them in for me so I can proofread them? I'm fairly new to Wikisource so have no idea what is involved.

I did message Princeton about scans if the pages were present in the copy from which the Archive.org work was taken, before I discovered the California scan of an apparently identical printing at Hathi. If Princeton send theirs to me, they will still be relevant for getting inserted into the Archive.org edition. PeterR2 (talk) 22:28, 27 February 2017 (UTC)

Of course if it's going to cause lots of problems with references I could just type the missing material onto the bottom of Page:An Exposition of the Old and New Testament (1828) vol 1.djvu/35 with a hidden note as to what I've done and my source. It's hardly a major part of the book. PeterR2 (talk) 23:13, 27 February 2017 (UTC)

Princeton emailed me a monochrome scan of the two missing pages. They are having the two pages scanned and inserted into the record on Internet Archive. PeterR2 (talk) 00:23, 3 March 2017 (UTC)

The two missing pages have now been inserted in the Internet Archive document. How do we get the corresponding pages into Wikisource?PeterR2 (talk) 08:31, 8 April 2017 (UTC)

@PeterR2: I am trying to work out exactly what you are after. Let me see if I can tease it out c:File:An Exposition of the Old and New Testament (1828) vol 1.djvu has missing pages, and you have managed to get a new version upload to IA and it is exactly the same edition. Now you are asking how we repair the file at Commons, then update pages here. If that is correct, can you tell us which pages are missing, and where they are inserted Index:An Exposition of the Old and New Testament (1828) vol 1.djvu.

If it is exactly the same edition, then from the file at Commons you an overwrite the existing version; then we can ask @Mpaa: to get his bot to move the pages that need moving. — billinghurst sDrewth 09:17, 14 April 2017 (UTC)

@Billinghurst: Yes, there are two pages missing after Page:An Exposition of the Old and New Testament (1828) vol 1.djvu/35. Currently proofreading has been done all the way to Page:An_Exposition_of_the_Old_and_New_Testament_(1828)_vol_1.djvu/106 (I started at Page:An Exposition of the Old and New Testament (1828) vol 1.djvu/85 ) so as a newbie I'm a bit concerned as to what will happen if two pages get added in the middle of work that has already been done and linked, for instance at An Exposition of the Old and New Testament (1828)/Genesis, but it really needs to be done somehow for completeness. Princeton Theological Seminary (the source library for this item) arranged for the two missing pages to be inserted in the Internet Archive file which is linked from An Exposition of the Old and New Testament (1828) - see [26] - as you can see they have used a different scanning method for these two pages.PeterR2 (talk) 08:55, 15 April 2017 (UTC)

Done. I preferred to keep the djvu fmt, so the two pages have no text layer right now. It should be copied manually. I have not taken care of realigning Main ns.— Mpaa (talk) 18:37, 15 April 2017 (UTC)

@Billinghurst:@Mpaa: Thank you! That's great. I notice the Index:An Exposition of the Old and New Testament (1828) vol 1.djvu has lost its status colours. How do I get them back, please?PeterR2 (talk) 06:48, 19 April 2017 (UTC)

I see 1-77 and other odds and sods reflecting various states. What are you expecting to be different? — billinghurst sDrewth 07:19, 19 April 2017 (UTC)

Actually I Googled and found the answer in the Scriptorium archive in 2013 or 2003 or something and fixed it by refreshing the page by making a null edit.PeterR2 (talk) 07:23, 19 April 2017 (UTC)

This section was archived on a request by: — Mpaa (talk) 19:42, 28 April 2017 (UTC)