Please do not post any new comments on this page. This is a discussion archive first created in , although the comments contained were likely posted before and after this date. See current discussion or the archives index.
Copyright and deletion discussions needing community input in September 2019
The following copyright discussions and proposed deletions discussions have been open for more than 14 days, and with more than 14 days since the last comments, without a clear consensus having emerged. This is typically (but not always) because the issue is not clear cut or revolves around either interpretation of policy, personal preference within the scope afforded by policy, or other judgement calls (possibly in the face of imperfect information). In order to resolve these discussions it would be valuable with wider input from the community.
Copyright discussions require some understanding of copyright and our copyright policy, but often the sticking points are not intricate questions of law so one need not be an intellectual property lawyer to provide valuable input (most actual copyright questions are clear cut, so it's usually not these that linger). For other discussions it is simply the low number of participants that makes determining a consensus challenging, and so any further input on the matter would be helpful. In some cases, even "I have no opinion on this matter" would be helpful in that it tells us that this is a question the community is comfortable letting the generally low number of participants in such discussions decide.
Note that while these are discussions that have lingered the longest without resolution, all discussions on these pages would benefit from wider input. Even if you just agree with everyone else on an obvious case, noting your agreement documents and makes obvious that fact in a way the absence of comments does not. The same reasoning applies for noting your dissent even if everyone else has voted otherwise: it is good to document that a decision was not unanimous.
Some suggestions about web visibility and page quality
After rebuilding THIS LIST to include the corresponding main namespace pages to see if they exist and what is visible to the (first time) visitor.
In addition to our current visibility, we should consider adding separate webpages titled something like "Wikisource for proofreaders" and "Wikisource for readers" with their respective information and linked to the Wikisource main web page, while keeping the Wikisource main webpage as uncluttered as possible.
Regarding the main page of any work, the first thing noticed is that the quality indicators only display the current page status. Would it be possible to add a bar display on a work's title page aka {{ROOTPAGENAME}} a summary of the overall status of the subpages related to the title. — Ineuw (talk) 23:57, 3 September 2019 (UTC)
I am not understanding your issue, what exactly are you expecting where? (noting that all the classifications has always been a mystery to me) The links seem fine to me at face value. FWIW this seems controlled from Template:Portal Class and that is unprotected, and could do with a sandbox and testcases. — billinghurstsDrewth12:06, 3 September 2019 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
You can use the new termbox interface if you edit Wikidata on a mobile device. This is to edit labels, descriptions and aliases easier on the mobile pages. [1]
The new version of MediaWiki has been deployed during the last week.
The previously announced change of positions of the "Wikidata item" link on all wikis has been rollbacked due to unexpected cache issues. [2]
The limit for rollbacks has been increased from 10 to 100 rollbacks per minute. [3]
The advanced version of the edit review pages (Recent Changes, Watchlist, and Related Changes) now include two new filters. These filters are for "All contents" and "All discussions". They will filter the view to just those namespaces. However the "All discussions" filter does not include pseudo talk pages, like discussions that are in the Project: or Wikipedia: namespaces. But it will include changes happening on Project talk: or the Wikipedia talk:. [4]
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 3 September. It will be on non-Wikipedia wikis and some Wikipedias from 4 September. It will be on all wikis from 5 September (calendar).
When you log in, the software checks your password to see if it follows the Password policy. From this week, it will also complain if your password is one of the most common passwords in the world. If your password is not strong enough, please consider to change your password for a stronger password. [5]
Meetings
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 4 September at 15:00 (UTC). See how to join.
It seems that the author header has problems with choosing a picture from Wikidata if there are two of the same rank (see Wenceslaus II of Bohemia). It could probably be easily solved by distinguishing their ranks there, but this would solve only this particular case. I think the header should be corrected so that it could handle a similar situation, should it appear in the future again. --Jan Kameníček (talk) 21:36, 3 September 2019 (UTC)
So this particular issue was solve by removing the other picture, but the fact that Wikisource cannot handle such situation imo needs to be solved too. Wikidata allows to have there multiple pictures on purpose and so such situations may occur again. (Maybe there already are some more author pages with this problem, it could be worth if a bot made a search for them). --Jan Kameníček (talk) 08:14, 4 September 2019 (UTC)
It happens infrequently enough that fixing the priority in Wikidata has worked so far (and to be honest, I think the priority should be fixed when this happens on Wikidata). However, you are right, we should update the Header module to identify when this happens and adjust accordingly. —Beleg Tâl (talk) 12:41, 4 September 2019 (UTC)
I did it this way purposefully as we were getting the first image and that was often the rubbish image. Where the image is problematic, ie. there are two, page is flagged as broken at Category:Pages with missing files, and you fix it at Wikidata by setting a priority per the instruction on the category page. How is that problematic? — billinghurstsDrewth12:54, 10 September 2019 (UTC)
And to note, that it was resolved by my preferring one image, not the removal of the image, and it was done on the same day that you created the page, and without knowledge of this post. So, normal maintenance processes work. — billinghurstsDrewth13:02, 10 September 2019 (UTC)
Should the disambiguation pages for "Song" and "A Song" be combined?
Hi. I just noticed that along with the nice, well-organized disambiguation page for Song, there's a page for A Song too, which is just the same kind of generic "song" poems which can only be told apart by their first lines. Would it make sense to put the "A Song" poems in the list with the "Song" poems and change the smaller page into a redirect? ~~ Teller XIV (talk) 20:40, 10 September 2019 (UTC) ~~
Can someone who has the patience and the time look to fix the series of this series templates to convert the template series to have a lead |- rather than a trailing |-. They break page numbering formatting on all table of contents so typically only the lead page number of the ToC shows and it is long time that it we get it resolved. They will need to go through the sandbox. — billinghurstsDrewth02:18, 8 September 2019 (UTC)
@ShakespeareFan00:. I see this was just done directly on the templates. However, as I said, in detail, last time this was brought up (to which there was no reply), care must be taken here, because whitespace in the wikitext between TOC row templates will be sucked into the rows, whereas before, it was not. For example, Page:1965 FBI monograph on Nation of Islam.djvu/4 is now double-spaced. Specifically, whereas the following was fine before:
I think this might be fixed by removing the newline before the "|-" at the start:
<includeonly>|-
|align=right valign=top|{{{1|}}}
Even then, you must still be careful about having two or more line spaces between rows (and newlines at the end of the last parameter count as well), so you'll need to ensure nothing gets broken. Thanks for making the effort to fix this long-standing issue. Inductiveload—talk/contribs10:11, 10 September 2019 (UTC)
The line feed at the start is needed so that Mediawiki recognises the Table row marker. Placing it as you suggests visibly breaks rows in a manner that is more obvious than the dual whitespace you mention. Whitespace handling interactions between templates, tables and transclusions is a long-standing issue, and so far no long-term soloution has emerged. I'm quite prepared to revert ALL my changes, on the basis that it's long overdue for someone else to thoroughly rethink how these templates are done, and redesign them to be white-space neutral.ShakespeareFan00 (talk) 10:47, 10 September 2019 (UTC)
Following further concerns, I've now reverted ALL the changes made to this family. Perhaps someone else can sit down and fully redesign it so that it is completely independent and neutral of the minutiae of Mediawiki's (still under documented) whitespace handling behaviour. ShakespeareFan00 (talk) 11:21, 10 September 2019 (UTC)
Getting the page numbers right is tricky, but it isn't due to some mysterious non-specific "minutiae" in whitespace, it's just simple concatenation of the page content. It's due to this: on a Page page that starts with a TOC row, you essentially have this:
It's documented in the second sentence at mw:Help:Extension:Linter/fostered: "Specifically, content in tables can only be present in table cells, table headings, and captions.". Because the ProofreadPage span (with class "pagenum") is inserted between tr's, it's therefore "fostered" and pops out of the table. This isn't noticed by the linter, I assume because ProofreadPage inserts its spans after the linter and parser do their things.
Your change to the template starts the page off as appending to the previous page's last row, like this it to this:
While this is now a valid place for the pagenum span, its 1) on the wrong row and 2) this tends to suck in any inter-template whitespace just before the first </td> and make it part of the cell content, even when it's not part of the template parameter, which is slightly "surprising" behaviour.
I'm unsure as the the best approach. I think an ideal solution would be for the ProofreadPage extension to know when it's trying to stuff a span in-between table rows and instead push it into the first cell, but I have no earthly idea if that is possible. I have raised phabricator:T232477 to ask people who might know the answer.
If this is deemed to be "user error" (i.e. it's not MediaWiki/ProofreadPage's problem and these templates are objectively "wrong"), then the only recourse here is to change all the templates (as you did) and carefully check that the spacing is not broken. There are roughly 2000 pages using these templates, and many are OK, so it'll be a PITA, but tractable. Then, going forward, it will be disallowed to have blank lines between TOC rows. IMO it would be preferable to allow whitespace between templates, as it's more readable and it's surprising for users that single blank lines would cause such issues. But it wouldn't be the end of the world.
@Inductiveload: This is so much not a solution — merely a suggestion towards… Get rid of the mediawiki mark-up in the templates and replace with explicit <table>, <tr>, <tb> etc. This does not solve the whitespace problem but at the very least eliminates the counter-productive requirement for blank lines required to be present for proper recognition of mediawiki keywords…
Also, doubling down on the linter issue (i.e. why not introduce a structure which works in more cases even though it will drive lint slightly crazy in the general case…), is it worth considering modifying MediaWiki:Proofreadpage pagenum template to something like:
— yes the above is pretty nuts in normal situations (but workable after the parser strips the useless tags… and works perfectly in the rare case where inserted between </tr>…<tr> tags…? 114.78.171.14410:52, 11 September 2019 (UTC)
I have, in fact, already attempted using raw HTML tags (e.g. here), and while it does solve the line-break issue, the issue with page numbers persists (logically, as the <span> is still between a </tr> and <tr>).
Your idea about putting the pagenum in a <tr> has another drawback (other than upsetting the linter, though I actually think the linter would miss it due to when the PP extension injects the code) in that it will force a dummy row in the table, which would probably cause disruption across page-breaks. Inductiveload—talk/contribs11:22, 11 September 2019 (UTC)
Proposition to change the Wikispecies label in Module:Plain sister.
Comment The intent of plain sister labels was to target the result, not wiki name specifically, view the other labels in the series. If the existing label is not suitable, I would just prefer "species" though I am a dinosaur. The words species and taxonomy come from the scope for that site. — billinghurstsDrewth12:27, 3 September 2019 (UTC)
“
Wikispecies is an open, wiki-based species directory and central database of taxonomy. It is aimed at the needs of scientific users rather than general users.
Although they still claim to be a "species directory and database of taxonomy", they became also a database of authorities. Ferdinand Stoliczka is not a species and so our link to this entry should be labelled appropriately. --Jan Kameníček (talk) 16:54, 3 September 2019 (UTC)
Oppose it is not meant to be identifying the wiki, it is meant to be identifying the type of article, which is the design of the whole plain sister. — billinghurstsDrewth13:05, 10 September 2019 (UTC)
Support per Jan's second post above; authors are not species so labelling it as a link to a taxonomy makes little sense. —Nizolan(talk)17:58, 12 September 2019 (UTC)
@Jan.Kamenicek: Not sure how that ever worked. This is using <div>…</div>-based (block) templates inside <span>…</span>-based (inline) templates, which is always going to be pure luck if it seems to work. Of the ones in use there, {{overfloat left}} and {{smaller}} work together; the rest don't. All of them except {{lh2/s}} can probably be replaced by new inline versions of the current templates if the need is great enough. {{lh2/s}} will probably simply not work as an inline template (line height, I think, can only be applied to block elements). --Xover (talk) 18:02, 11 September 2019 (UTC)
@Xover:Now I see. I guess the {{lh2/s}} could be replaced by {{lh}} which is based on span, so it would be perfect if the other templates were adapted for inline use. I cannot say how great the need is generally, but it would help me when proofreading this particular book of almost 800 pages :-) After several attempts this solution of sidenotes seemed best to me (before I discovered the paragraph problem) as I tried to avoid various distracting frames and also get the sidenote text as dense as possible so that two succeeding notes did not interfere with each other. --Jan Kameníček (talk) 18:28, 11 September 2019 (UTC)
This will increase the backlog of lint errors that I periodically try to decrease [10]. I fail to see the benefit of hammering templates that produce broken HTML only for the sake of trying to reproduce format as faithfully as possible.Mpaa (talk) 19:57, 11 September 2019 (UTC)
I thought that adapting the templates for inline use would help decreasing the lint errors. I am not seeking a solution causing any errors.
It does not have to be completely the same as original, although I would like to keep especially their position on the side of the text (i.e. not the text flowing around). It is also true that some other deviations from the original caused by our templates make the result ugly; for this reason it would be good if the text of the notes was aligned to the left, without distracting frames, and densely written (so that two succeeding notes do not interfere with each other). --Jan Kameníček (talk) 20:47, 11 September 2019 (UTC)
@Jan.Kamenicek: I would very much assume Slowking4 means that they will convert side notes to end notes in the works they proofread themselves in the future, and not that they intend to do it in works that others (like you) have already proofread using side notes. Granted there are many issues we as a community disagree on, but doing that would be downright uncollegial! :) --Xover (talk) 18:46, 12 September 2019 (UTC)
yeah, sorry, i’m sure we can work out sidenote preference on work talk page. but you understand while i might applaud your attempts to fix sidenotes, i have given up for those works i will be doing. the backlog is so immense, that we could both go along without seeing each others edits for years. not enough value added for me. yrmv. Slowking4 ⚔ Rama's revenge23:29, 12 September 2019 (UTC)
Why not use {{left sidenote}} for this sort of thing? I'd vastly prefer semantic templates over formatting ones any day (that is, templates that tell you what things are, rather than what they look like, like {{ch}} over {{c}}, etc). I've tried it out on your page (didn't save, of course), and the preview at least looked good to me.... Dcsohl (talk) 19:54, 12 September 2019 (UTC)
Before I started using the overfloat template, I had been trying the left sidenote template too, but 1) I really do not like the distracting frame and 2) the note in the left margin instead of the text flowing around imo also looks much better. --Jan Kameníček (talk) 20:12, 12 September 2019 (UTC)
Very strange. When I tried it out on your page, there was no frame and the content did not float around it; it looked much as yours does now, with a wider gap between the notes on the content. That was the only difference I saw. Dcsohl (talk) 20:54, 12 September 2019 (UTC)
…And at the moment {{left sidenote}} is (still) somewhat broken on two of the dynamic layouts because of errors in the CSS ("Proposed Layout", where the sidenotes get pushed to overlap the edge of the screen, and Layout 4, where they overlap the text). They work best in Layout 2. —Nizolan(talk)23:17, 12 September 2019 (UTC)
@Nizolan: Ok, still new here, never noticed the different layout options before. What are they, what is the "Proposed Layout", and why does that one look so bad? But, to my original point, @Jan.Kamenicek:, this is why I like semantic templates better--the actual formatting is ultimately up to the device rendering the text. Showing that it is a sidenote in a clear fashion, I think, enhances the likelihood that it can be formatted in a meaningful way 20 years from now, even if the "Proposed Layout" doesn't look so great right now (and should be improved, rather than hacking around it). Dcsohl (talk) 01:12, 13 September 2019 (UTC)
Hmmm, that is something new to me as well, in layout 2 it looks OK, so I started thinking about changing it for left sidenote in combination with {{default layout|Layout 2}}. Good point, thanks. --Jan Kameníček (talk) 06:24, 13 September 2019 (UTC)
I have a complicated table page that needs formatting to completion, but I have been unable to find similar examples that I could follow to finish it off.
I would appreciate if someone could format this for me? or maybe provide a link to something close enough to its style so that I can try and understand and replicate the layout?
I recently deleted a political speech by Carrie Lam, Chief Executive of Hong Kong, as copyright work. A user has pointed me to Portal:Speeches/Copyright which references
which states that political speeches are able to be hosted.
I would argue that the current approach has been to delete scripted political speeches, than to follow the first guidance. That said, I don't get to reframe community's earlier consensus, nor to unilaterally impose my PoV, so I am putting this before the community.
If it is thought appropriate, this can be moved to WS:CV though I thought that I would start here initially due to the reference conversation being here and archived in the subpages. — billinghurstsDrewth13:30, 9 September 2019 (UTC)
That guidance is terribly confused, and it's from 2005/6 (i.e. before any Wikimedia project had figured out the basics of copyright, much less had coherent copyright policies). As best I can tell it has not reflected actual community consensus for about a decade ({{PD-Manifesto}} was deprecated around 2010, and deleted in 2013; see this page and its further links), it's just never been updated.Extemporaneous speech—aka. "off the cuff remarks"—is generally not considered to be protected by copyright. Mainly because extemporaneous speech has not been fixated in a tangible form, which most copyright frameworks (Common law, in particular) demand in order for a work to be eligible for copyright. However, it is extremely unlikely that any public speech of any sufficient notability to be hosted here was not prepared in advance and fixated prior to being memorised and recited, or read from the teleprompter. Even seemingly ad hoc statements made in response to audience or journalist questions is likely to have been previously fixed in the form of a list headed "Talking points". These are all copyrightable works subject to essentially the same copyright rules as any other kind of work.In addition, even if the speech in question is truly extempore, we need to source the speech from somewhere; and that somewhere (like a news broadcast) is very likely to have its own copyright in the recording (think of it as the translator's copyright in a translated work).There will of course be exceptions, that are truly extemporaneous speech, but these will rarely be speeches as such (and will often be out of scope for Wikisource). The guidance for speeches should be the same as for any other work: “Has its copyright expired?”, “Was it exempt from copyright under PD-USGov?”, etc.In other words, the copyright guidance link on Portal:Speeches should be removed and the sub-page excised with fire. --Xover (talk) 15:58, 9 September 2019 (UTC)
Note that the WMF has posted their opinion on a related subject at m:Copyright of Political Speeches, and their opinion agrees with Xover's above: speeches that are written down by the speaker before hand are copyrighted, and off-the-cuff remarks are not copyrighted. Speeches written by an officer or employee of the United States Government as part of that person's official duties are exempt from copyright, but of course that does not apply to Lam's speeches. —Beleg Tâl (talk) 16:25, 9 September 2019 (UTC)
this is the copyright maximalst position - whenever you might try to reference a speech to a PD VOA video, then there is the mass nomination with "i saw the speech notes in their hands". but if they did not publish the speech text elsewhere, isn’t that intent to make public domain? i.e. precautionary becomes an enabler of the RIAA and MPAA. a better way would be keep as "no known copyright" until affirmative evidence of publication is found anywhere. Slowking4 ⚔ Rama's revenge16:30, 9 September 2019 (UTC)
That is not how American copyright works. As soon as the text of the speech hits the paper, it is protected by copyright, regardless of the intent of the speaker, regardless of subsequent publication, regardless of whether anyone saw speech notes in anyone's hands. However, your point about keeping the speech anyway as "copyright status unknown" is a good one. —Beleg Tâl (talk) 16:38, 9 September 2019 (UTC)
american copyright law mostly does not work; and bad cases make bad law - i don’t see a wave of DMCA takedowns for speeches - and so "A work must be “fixed in a tangible means of expression” to be protected by copyright, but a work is “fixed” when [it] is sufficiently permanent or stable to permit it to be perceived, reproduced, or otherwise communicated for a period of more than transitory duration.”" means when i read from notes it is copyrighted, but when i throw away those notes it is not? (since they were not sufficiently permanent) do not nominate my wikimania talks. it is the imposition of Berne culture upon CC culture, i guess we can advise and extend our remarks to include a CC declaration. Slowking4 ⚔ Rama's revenge12:25, 10 September 2019 (UTC)
Here is an important counterpoint: Help:Licensing compatibility#Presumed licensing: "Works whose licenses are unknown but are likely to be a compatible license or criteria […] are generally prohibited. However, some very limited conditions have been permitted by the community, most notably regarding public speeches." This is similar to what Slowking4 said above, that it would be better to keep the works until evidence of tangible medium is demonstrated. Note that there is a list of relevant discussions on the linked page. —Beleg Tâl (talk) 16:43, 9 September 2019 (UTC)
I'll note further that I don't really agree with this personally, because it seems to me that speeches are very unlikely to have a compatible license or criteria. —Beleg Tâl (talk) 16:46, 9 September 2019 (UTC)
That should also be fixed; it stems from the same time period as the Portal:Speeches guidance. Note that all the links predate the discussions that started in 2009(ish) and ended up with deleting PD-manifesto in 2013. The overall intent is fine—there's certainly a case to be made for keeping individual works of an unknown copyright status when special circumstances makes it likely-but-undocumented that free licensing obtains (*cough* Guerilla Open Access Manifesto *cough*)—but speeches as the example is actively misleading. --Xover (talk) 16:53, 9 September 2019 (UTC)
here are some videos with compatible license [12]; if video weren't so hard, we could have more; and as we move to video rather than text, the text based rules look more ridiculous; there is a push to get more uploaded with machine voice overs. so we need a consensus on the standard of practice, other than "this is professional video therefore delete"
It's clear that modern speeches are inherently copyrighted, and that anyone who wants their work freely used needs to say so explicitly.--Prosfilaes (talk) 02:04, 13 September 2019 (UTC)
@Levana Taylor: It didn't work because {{p}} didn't actually have mt0 and mb0 options. I've added them now. But note that I also agree with Billinghurst here: don't go to extremes to reproduce formatting; good enough is good enough. Especially when the complex formatting starts to create problems on its own. --Xover (talk) 07:37, 15 September 2019 (UTC)
Thanks for adding those. I actually hardly ever use paragraph margins (I used to but "simplify, simplify, simplify" - I’ve gone through my old work and removed all fancy formatting). But zero margins are useful for a variety of purposes. For one thing, they help with avoiding the use of <poem>. Speaking of things that create problems, <poem> is the great offender & I am trying to never use it. Levana Taylor (talk) 08:01, 15 September 2019 (UTC)
For many years we allowed the words of the author to be king, and let the typography and typesetting of the printer to guide us, not force us. We wanted to simplify as someone else has to validate the work, and there should not be the expectation for people to dance through unnecessary complexity. So when I do my proofreading I try to keep those key components in my mind.
<poem> is acceptable usage here, though we allow first transcriber to make the choice for their work. So we don't condemn its usage, that is about your choice.
Simplicity also is key where someone wish to copy and paste our work, to get something useful. It is the philosophy of not forcing a font face unless truly needed, and why we do relative sizing so that the reader is able to not have us force their browser display. So I implore you to not knock simplicity in our replicating works, and to focus on the whole, not the part of a publisher as the priority. — billinghurstsDrewth08:14, 15 September 2019 (UTC)
True, "does the text come out right if cut & pasted" is a bare minimum rule of thumb for good formatting. That’s not taking into account tables in the text, to be sure. Levana Taylor (talk) 08:26, 15 September 2019 (UTC)
Can some please write a style guide for this so I am not constantly having to do minor edits to get a consistent style for things like the formatting on the first letter, first word of paragaphs please? Thanks.
ShakespeareFan00 (talk) 09:48, 17 September 2019 (UTC)
Hi. I'm proofreading a book in Spanish and tumbled upon some symbol i've never seen before. See this page. On the footnotes, after the numbers, there is this symbol that in that context I understand it means "thousands", but I can't find it elsewhere. Have any of you found something similar? In the meantime I wil proofread it as 000. Regards, --Ninovolador (talk) 21:27, 17 September 2019 (UTC)
@Ninovolador: it appears to be called a calderón, millaron, or millar. There is a history of the symbol here. In this thread on the Unicode mailing list they note that some publications have represented the symbol using ↄ or ¶, and also make the suggestion that Ɔ⃦ is a good representation provided that the reader's browser renders it correctly (it's supposed to position the two vertical lines directly centered over the Ɔ)—Beleg Tâl (talk) 00:15, 18 September 2019 (UTC)
Yes, this is a real extreme. Imo, wikilinks should be made in two cases:
To other texts to which the author clearly wanted to refer to (e. g. to a book, journal article, encyclopaedia entry) and which are also present at Wikisource.
To more general pages that contain links to various other texts relevant to the topic and present at Wikisource, like to author pages or portals.
@Mpaa: I agree that this example is clear overkill, but perhaps not by quite as much as you and Jan.Kamenicek think.This one is an extreme example, but if we say this is the outer edge of a scale that has "zero links" as the other terminus, I think this one is quite possibly closer to the ideal compromise than the "zero links" extremity. We obviously shouldn't be linking common words like "salmon" in a biographical encyclopedia entry, and for links other than author/portal or work titles the use of redlinks is questionable, but providing links that enhance the reader's understanding is in general a good thing. The sheer density of links is clearly a problem in that text, but if you take out the obviously excessive ones ("salmon", "July", "published", etc.), the result is actually within the area where "reasonable men may disagree". Providing a link from "Lake Champlain" (which I've never heard of and have no idea where it is or even what it is, above guessing that it's most likely a lake somewhere that they primarily speak English) is a good thing! In this specific case, since the work is an encyclopedia, these would most naturally be to internal entries in the same work; but for things like scholarly monographs, I think even links to Wikipedia would be a good thing. There are also some necessary distinctions related to the type of work (scholarly monographs vs. fiction vs. poetry) or context in the work (inside a quotation vs. in the author's own voice) that quite strongly affect whether linking is appropriate at all, what to link, and how much.WS:Links does not provide particularly clear guidance, and I am not at all convinced it still reflects community consensus (or, at least, that the interpretation of its practical consequences does), so I have a todo item for starting a community wide discussion about that (I'm, among other things, waiting for the currently open proposals to conclude to avoid overwhelming people). If nothing else, I am hoping to make the guideline clearer and to more directly address a few of the most obvious and common cases. If anybody has thoughts about this I would welcome them, both in advance to help inform my proposal and when such a proposal is eventually posted. --Xover (talk) 08:51, 23 September 2019 (UTC)
What you describe is exactly what annotated versions are for and outside annotated versions links should be used scarcely. Links to our author pages and portals make sense because they are not that many and because they introduce a variety of our works connected with the person/topic. The aim of the links as I understand them is not to provide explanation (why should we choose a source of explanation for the readers? – they can surely do it much better themselves and definitely not in an encyclopaedia which is 100+ years old.) but simply to show that we have other works on the topic. To avoid overlinking, this should be done only if we have multiple works of that kind (gathered at author pages and portals) and not if we have only one old encyclopaedia entry. If explanation is really needed, Wikipedia can definitely be a better choice for such a purpose than Britannica, but it should be treated really cautiously. In fact the argument can be repeated: why should we choose Wikipedia for the readers, who would otherwise look for explanation by themselves and maybe find even better sources? Besides that I personally get always quite irritated if the links always go in different directions (once to an author page and another time to Wikipedia) so I am not able to predict where I am going to end up and if I find there what I am looking for. Links should also be predictable. When there is a link from a name of another work, it should always go to our text of the work (like The Bartered Bride) and never to Wikipedia (like The Bartered Bride), even if we did not have such text at Wikisource, because readers expect that such links go to works and not to articles about works. --Jan Kameníček (talk) 15:09, 23 September 2019 (UTC)
Thanks. All good points. But let me just be clear that my point is that the place where we draw the line to an Annotation (and subject to the WS:Annotations policy), where wikilinks are concerned, is currently not sufficiently clear, and not necessarily in the right place (depending on the interpretation). There is a world of difference between wikilinks, on the one hand, and added illustrations and explanatory notes, on the other. Depending on how one interprets the linking policy, it is currently extremely conservative, and I assert it should be loosened at least a little bit. --Xover (talk) 16:47, 23 September 2019 (UTC)
Something I have struggled with is old transcription schemes in works like SBE3, where you might have proper nouns like "Sze-mâ Khien", which, in modern pinyin is Sima Qian. It's normally fairly obvious when to link when there's an Author, Portal or Wikipedia page available, but sometimes there isn't.
An example is "ℨû-lâi" (Culai, 徂徕), which is a mountain in Shandong. My occasional approach here has been to use a tooltip with the modern transliteration and characters. However this is sub-optimal, as it's impossible to select/copy the tooltip text (useful if you want the characters and don't have a Chinese input method), they can't be hovered on mobile devices, and they don't appear in the exported formats. Would annotated references be acceptable here, and if so, how to indicate that they are not original references (when the work has references)?
The reason I'm particularly interested is because older texts on China universally use old transcription schemes (the current system dates from the 1950s; the one here is Legge romanization), and it's unfriendly to make readers decipher these themselves. In particular for Chinese, even if you understand the transcription mapping to pinyin, the Chinese character is not known without further research. This research if done by the proofreader seems a shame to throw away, even if it's not part of the original.
My opinion is that we should focus on enabling people to access old publications, not to try to modernize them. If the publication uses outdated transliteration, we should copy it and that is all. Whatever else you add, like tooltips with modern transliteration, falls under WS:Annotations policy. --Jan Kameníček (talk) 18:10, 24 September 2019 (UTC)
If it was possible to write an abuse filter to stop someone for being a spammer, a vandal or a general PITA, then it would have been achieved years ago. You have seen this person morph their behaviour, and that is the thing about humans, they are adaptable. We do what is possible that still allows editing from IP addresses. — billinghurstsDrewth20:56, 26 September 2019 (UTC)
Proofreading line by line
Tool for typo correction on mobile
I tried to do some proofreading and I experienced two difficulties:
1 I need to jump back and forth between the text version and the scan. Usually needs to jump up and down since the lines aren't aligned.
2 I need to proofread a whole page in order to submit, which means if I don't have 10+ minutes to carefully check the whole page, I better not start.
My proposed solution is to have the scans broken down to lines, and then one will be able to proofread one line at a time. It will also allow for mobile users to contribute easily.
This approach was implemented by Haifa University in Tikkoun Sofrim project.
Would like to know if there is any reason this wasn't done and if no such reason, I would like to start developing this tool, and as MVP simply upload a PDF with one line per page.Uziel302 (talk) 20:22, 19 September 2019 (UTC)
1) When proofreading, you should be able to drag the image to a position where the lines are aligned.
2) When I am only able to proofread part of a page, I will usually place a comment like <!-- PROOFREAD UP TO THIS LOCATION --> at the place where I proofread up to. Or you can just proofread part of it and make life easier for the next person who finishes the page.
3) If your tool requires that users chop up book scans line-by-line, I don't imagine it will gain much traction, but I'm certainly intrigued. —Beleg Tâl (talk) 20:33, 19 September 2019 (UTC)
I would be enthusiastic about a well-written proofreading gadget of the sort you describe; it would take quite a bit of programming though! I don’t think hand-uploading a line-by-line PDF is the solution. Too much work by far. Instead, image recognition has now advanced to the point that software should be able to pull apart an image into one-line image strips (and it could deal with multiple columns too -- not too hard to recognize them, or it could ask you how many columns). This would be far less of a challenge than OCR! Levana Taylor (talk) 20:39, 19 September 2019 (UTC)
At the very least, the DjVu and PDF files must have the OCR'd text locations available. Furthermore, if the scan is from the IA, this information is directly available in the djvu.xml file in terms of page, column, line and word co-ordinates, so you don't even need to pick apart the file ot get at it. For example: a random book's XML. Inductiveload—talk/contribs21:29, 19 September 2019 (UTC)
I can imagine that proofreading line by line works well if the contributors focus on pure text. However, Wikisource tries to focus also on text formatting, and so it is much better to work with the whole page. Formatting each line separately would be too much work and I suppose that putting the formatted lines together would also be very difficult. --Jan Kameníček (talk) 21:33, 19 September 2019 (UTC)
What Jan said ^^^ and most importantly is where hyphenation, formatting and wikilinks FWIW Trove has its newspapers in line by line, and it works for that where it replicates a work, and focused on text search, not so much for reproduction of books and works. — billinghurstsDrewth03:38, 20 September 2019 (UTC)
i kinda agree. final formatting is important, but it would be good to get something mobile friendly or small screen friendly, for a preliminary pass. just a gamified find and replace for typical scan errors would be nice. and we could AI it, for suggested replaces for a work. (and possibility of feedback to OCR) Slowking4 ⚔ Rama's revenge20:38, 20 September 2019 (UTC)
Slowking4, it's kinda funny, I already run a gamified find and replace small-mobile-friendly tool, and it helped us correct over 14000 typos on Hebrew Wikipedia. I ran the scan for English Wikisource and imported the tool, attached screenshot. But it seems to be irrelevant to correct typos, since many typos are sic, thus written. The only right way to correct such typos would be by attaching relevant screenshot of the source, but that would be much more work on my side. You are more than welcome to help me with the tool on English Wikipedia: Wikipedia:Correct typos in one click. Uziel302 (talk) 13:25, 28 September 2019 (UTC)
We either note original production errors with the invisible {{sic}} or the visible {{SIC}}. If we are talking about OCR errors, there are some weird and wonderfuls, and I repeatedly build endless versions for my automated regex replaceents, though find that many are internal to a work. — billinghurstsDrewth11:26, 29 September 2019 (UTC)
Per the discussion above, I would like to propose that the following change be made to Wikisource:Style guide: Replace... Use typewriter quotation marks ("straight," not “curly”). ...with... Curly quotation marks are permitted only if they are used in the original work and are used consistently throughout the transcription. Otherwise straight quotation marks are recommended.
Please express whether you support or oppose this change. Kaldari (talk) 15:39, 14 August 2019 (UTC)
Support. Two suggested tweaks to the language:
Instead of the word "ensure" (which occurs twice), I suggest "unless one or more Wikisource users are committed to ensuring." It's impossible to ensure anything on a public wiki; and I can foresee unresolveable arguments about what it means to "ensure" this in any given case. But, the stated intention of a single wiki user can be a powerful thing, and is possible to define more clearly.
I find the parenthetical section slightly confusing. I think it means that a large number of contributors would make it harder to ensure consistency; but that isn't entirely clear, and that's not necessarily true. So instead, perhaps, "(e.g., because many contributors, without a clear or enforceable agreement on style conventions, are likely to contribute to this particular work.)" -Pete (talk) 17:09, 14 August 2019 (UTC)
Oppose. 1) Curly quotes should be allowed regardless of the style of quotes in the source scan, just like straight quotes. 2) I cannot tell if your wording intends to cover other systems of punctuation such as „lower quotation marks“ or «guillemets», which should never be replaced with upper quotation marks of either style. —Beleg Tâl (talk) 17:27, 14 August 2019 (UTC)
I agree with what I think Beleg Tâl is saying...if we're going to alter the policy, it should permit using other kinds of quotes (at least, if they are what the original uses). In fact, I think if several contributors agree that guillemets are the appropriate choice in a specific work, even if they weren't used in the original, there might be good reason for it, and it shouldn't be expressly disallowed. -Pete (talk) 01:04, 15 August 2019 (UTC)
Oppose. I do want curly quotes allowed but don't favor the proposed version of the proposal. I agree with both Beleg Tâl’s comments. I think that the only restriction should be something like, if a work already wholly or partially proofread uses straight quotes throughout, a user should not introduce curly quotes unless they're committed to changing the whole thing to curly. Levana Taylor (talk) 18:26, 14 August 2019 (UTC)
I don’t think "all contributors to the transcription agree to use them consistently" is a practically workable condition to impose. What if (as is extremely likely) some early contributors can no longer be contacted? Someone who comes in later ought to be able to make a global change as long as they change the whole thing. Levana Taylor (talk) 02:22, 15 August 2019 (UTC)
Yes! This is more like it. I can support this simplified version, which leaves it open whether consistency is to be achieved by consensus (e.g. on projects that have a discussion page), or (in smaller works) one person going through the whole thing. And I don't mind restricting use of curly quotes to works that use them in the original. Use of straight quotes is something of a special case -- might be found in modern documents (e.g. government work being added here), and it makes sense to keep that style, I guess. We still have to mention. guillemets and German „goose feet“ … maybe the wording should be re-organized, more or less thus: straight quotes, guillemets, etc. should be kept as in the original. If the original has curly quotes, these may have straight quotes substituted for them, or curly quotes may be used; the latter should only be done if they are used consistently throughout the transcription. Levana Taylor (talk) 03:51, 15 August 2019 (UTC)
Comment. The previous voting discussion has shown that there are supporters of the change in favour of other than only straight quotes, but they prefer various solutions. For this reason it is probably not a good idea to pick one of them and vote simply for or against, it would be better to vote about all of them and choose the one with the biggest support. (BTW, the chaos accompanying this process, when somebody considered the discussion to be voting, while others were waiting for the voting to start, is a result of missing instructions similar to Wiktionary:Voting policy and Template:vote on hold.) --Jan Kameníček (talk) 18:57, 14 August 2019 (UTC)
Support. I have made two changes to the style guide in favour of this; the first, a more general approach favouring standardisation, and the second, a more specific approach similar to the desires of Jan Kameníček and Levana Taylor. TE(æ)A,ea. (talk) 11:51, 15 August 2019 (UTC).
Sorry to contribute to the nit-picking but though I'd like to support this I'm not sure on the current wording because there's a disproportion between the two parts: if curly quotes are only permitted under certain conditions then why are straight quotes merely recommended otherwise? What's the alternative? Also agree with BT above that exceptions for guillemets and other forms should be specified. —Nizolan(talk)12:49, 15 August 2019 (UTC)
Oppose. We're having a vote where the text is being tweaked throughout the vote after some people have voted. We need to vote on a set text, not be adjusting it throughout the vote. You don't change the candidates or platforms once the vote has begun. --EncycloPetey (talk) 15:18, 15 August 2019 (UTC)
If the tweaking doesn't go on for too long, it's not very hard to check in with the early voters and find out whether/how it impacts their votes. I stated above that the tweaks were to my liking, other early voters could always comment/clarify as well. But I think we're in agreement that it's best to at least limit/minimize changes in order to have a coherent vote. -Pete (talk) 16:49, 15 August 2019 (UTC)
Weak Support, as it is better than forcing everybody to use only straight quotes, but I am not very happy with the specific expression “curly quotes” instead of "the same kind of quotation marks as the work presents". There are several kinds of "curly" quotes and I believe they should not be used interchangeably. If a work uses “” the contributors should not use ’ ’ or „“, although they are all curly. --Jan Kameníček (talk) 22:18, 15 August 2019 (UTC)
The current MOS guideline to use straight quotes only does not imply that users can use ' ' in place of "; neither would this updated guideline imply that users can use ’ ’ in place of “”. Curly quotes in this context means specifically “this” as opposed to "this", and ‘this’ as opposed to 'this'. It would still be wrong to use “this” in place of ‘this’, or in place of «this», or in place of literally anything except "this". —Beleg Tâl (talk) 23:50, 15 August 2019 (UTC)
Alt proposal: Allow curly quotes under any conditions
I propose that, rather than the above change to WS:MOS, we instead change
Use typewriter quotation marks ("straight," not “curly”).
to the following:
Use a consistent style of quotation marks ("straight" or “curly”) within a given work. It is recommended to use "straight" quotes in works where there are a large number of contributing editors, since consistent use of “curly” quotes may be difficult to achieve.
And yet you agree with allowing to use straight quotes even in cases when the original works use curly quotes. I think that if we allow straight quotes in place of curly, but do not allow curly in place of straight, then we may as well continue to disallow curly altogether. —Beleg Tâl (talk) 23:37, 15 August 2019 (UTC)
In my opinion, disallowing the use of curly quotes when a scan uses straight quotes is similar to: disallowing the use of 'a' when a scan uses 'ɑ'; disallowing the use of 'g' when a scan uses 'g'; disallowing the use of '$' when a scan uses ''; &c. —Beleg Tâl (talk) 00:03, 16 August 2019 (UTC)
What if a scan uses German-style lower-level quotation marks, but those quotation marks are straight? There is no straight lower-level quotation mark to replace it with, and you would not allow the replacement of the straight quotation marks with „curly ones“. —Beleg Tâl (talk) 00:04, 16 August 2019 (UTC)
Hmm, I have a hard time imagining a case where this hypothetical problem becomes an actual problem. In most cases, there is no practical problem with one kind of quote...if it's an academic essay, for instance, I really don't see how a reader is done a disservice by encountering “curly quotes” where they expect "straight ones." In a few cases, like poetry, it might actually be significant. In those cases, I have more trust in the good judgment of my fellow Wikisourcers to find the proper solution, than I have in any policy. If a poem had straight quotes, and its appearance would be substantially altered by using curly quotes, it's hard for me to imagine a Wikisource editor who appreciates the poem using the policy to justify changing them to curly quotes. Your objection, Jan, seems to me rooted in worry about something that's very unlikely to happen. -Pete (talk) 00:52, 16 August 2019 (UTC)
Support. Nice, this is very similar to the original proposal, but slightly clearer, and uses more straightforward language. -Pete (talk) 00:52, 16 August 2019 (UTC)
Support I really like this. Cuts the Gordian knot, allows contributors to use their judgment; and if it doesn't address all the ins and outs and special cases, well, what wording could? Levana Taylor (talk) 23:13, 16 August 2019 (UTC)
Neutral While this codifies what we already have in place by de facto, I have seen nothing that addresses the basic issue that some of us are unable to type these so-called curly quotes. So, how will consistency in works be ensured? If this goes ahead it is essential that on each work (on the Index Talk: page), a formatting note is provided indicating which mode of textual quote marks are being used AND that all contributors to the work actually read the note prior to contributing. Beeswaxcandle (talk) 23:32, 24 August 2019 (UTC)
I expect it will be the same as any other issue. We have consistency problems in PotM, and even cases where a second editor makes spot changes to format. We cannot control these things except to note that they have happened and chastise a person who has done so. The point of this vote, however, is to provide a standard against which such calls may be made. --EncycloPetey (talk) 02:41, 25 August 2019 (UTC)
As for typing them: they can be found among the special characters just above the editing window, although it may slow down the work.
Both points raised above are among the reasons why I proposed there should be specifically written that the curly quote rule does not apply to works where cooperation of more people can be supposed. If three people out of four prefer curly quotes, it is no good if the fourth person is forced to use them too for "consistency reasons" even if s/he feels limited by them. There should be written that curly quotes are allowed only if it can be assured that no contributor to the work opposes them or may oppose them (typically when one single person transcribes the whole work). --Jan Kameníček (talk) 07:48, 25 August 2019 (UTC)
I don't like the idea of it being entirely impossible to use curly quotes in large, extensive works. It should be a matter of judgement by people who are working on it at the early stages, at the time style is being established. They should discuss as much as possible and decide whether curly quotes are practical under the circumstances where the work is being done.
As for entry, there are several plugins for Firefox, and I think for Chrome too, to assist with quotes. Personaly I use a combination of two method: convert chunks of text, highlighting quotes, with MS Word; while typing, use the superb macro plugin ABCTajpu which has made my life easier In so many ways. Levana Taylor (talk) 16:35, 25 August 2019 (UTC)
Exactly, you need various plugins, highlight the quotes in Word..., which some people may dislike or be unable to do. I personally prefer working directly in the editing window using OCR buttons. Google button usually transcribes all quotes as straight, so if somebody wants to use curly ones, they have to be changed manually, which is time consuming.
I do not believe that all contributors transcribing entries of large encyclopedias will bother with discussing which kind of quotes to use (I have seen results of collective projects like profread of the month, and unfortunately contributors here usually do not take care about consistency with much more important issues at all). However, let's suppose they will and imagine the following situation: 7 people start transcribing work, 4 prefer curly q., 3 straight. After quite lengthy discussion taking their time the three of them retreat (or some retreat and some leave the work) and they start using the curly q. After some time, other contributors come. Some of them do not use the curly quotes, but since quite a lot of work has been finished, they are notified that for consistency reasons they have to, and so they are forced to surrender to something they do not feel comfortable with (or they do not join). Imo this is not good. --Jan Kameníček (talk) 17:22, 25 August 2019 (UTC)
This is already how it goes for pretty much everything though. I don't like using the <poem> extension for example, and will push for explicit line breaks in transcribing poetry. If a project's original contributors have settled on using <poem>, I will have to either go along with that, or move on to some other project. —Beleg Tâl (talk) 18:18, 25 August 2019 (UTC)
As there is majority support and a sufficient length of time has passed, I will implement the measure in one day (24 hours), if there is no objection. TE(æ)A,ea. (talk) 21:19, 23 August 2019 (UTC).
I have undone this change. Do not give us arbitrary deadlines that have no requirement for a deadline. Typically our issues are discussed and open for extended periods. — billinghurstsDrewth23:58, 24 August 2019 (UTC)
Yes, 24 hour notice is not remotely sufficient for closing a discussion. There are still editors commenting here. Be patient. I think if this discussion remains completely untouched for two full weeks we could consider it closed, though I would give it the full thirty days allotted by SpBot. —Beleg Tâl (talk) 22:22, 25 August 2019 (UTC)
I proposed the 24 hours not as a time period for the discussion, but a time period to notify in the place of further discussion, as the outcome is already obvious. I believed that one weeks’ time, as had already passed, was sufficient. TE(æ)A,ea. (talk) 23:31, 25 August 2019 (UTC).
There's no hurry. English Wikisource has existed for 15 years without curly quotes. Another few weeks won't hurt. Kaldari (talk) 15:04, 27 August 2019 (UTC)
Support the alt proposal. I've just been alerted to this page, and not sure whether to add the comment here or in the lower discussion. The 1911 Encyclopædia Britannica Wikiproject is one that has long had a standard of curly quotes and apostrophes in its style guide, has a few current editors, and they are familiar with the style. Undoing the guide would be a needless waste of effort that could more usefully be put into proofreading (though I admit I'm guilty of not having done much of that lately). Raw scans will need fixing in any case. While I'm agnostic on what should be the default WS-wide, I'm strongly opposed to a new mandate for a long-established project. DavidBrooks (talk) 16:13, 28 August 2019 (UTC)
Support I had actually decided to abstain on this, since it wasn't sufficiently detailedly specified for my peace of mind (I do like exhaustive detail on such matters). But after far more agonising than the issue strictly merits, I've come around: I just simply want the pretty curly quotes too much! And since we're taking the "let's just open the gates and deal with problems as and when they show up"-approach already, I think it makes the most sense to pick the variant that gives maximum flexibility to our contributors. I do urge everyone to be extra on guard for diverging practices going forward: the benefit of an ultra-conservative approach is it's easy to guarantee consistency, but cleaning up if chaos has been let run unchecked can be near impossible. Keeping an eye out for variations we don't want now can save us a whole mess of trouble later on. (also: shout-out to Jan and BWC, whose concerns I share but land on support anyway) --Xover (talk) 15:50, 30 August 2019 (UTC)
It is indeed a valid concern to worry about introducing a typographic feature which is not entirely straightforward to use correctly, lest it create mess. We should be thinking about software methods to help with proofreading, both checking at the time of adding text and going over existing pages. I have some ideas, but this isn't the place to detail them. Levana Taylor (talk) 16:08, 30 August 2019 (UTC)
Further concern Having just advised someone on creating a link, I've realised a further concern with this proposal. When linking to works, to subpages, or to sections within a page we must have a single standard orthography. This particularly so for apostrophes, but from time to time quote marks are also affected. Links within a work will be fine, but links from another work will require the editor to decide everytime if normal marks or bent marks were used. A hypothetical example: a book I'm working on refers to Odysseus's Return in Joe Blogg's seminal work Greek Myths and Legends Reinterpreted for the Victorian Age. Do I link to Greek Myths … Age/Odysseus's Return or to Greek Myths … Age/Odysseus’s Return ? The best way around this is to insist that all Titles and Subtitles only use straight quote marks and apostrophes. The next problem comes at sections within a (sub)page where the section heading is a text item within the book. If Odysseus's Return is a section on Greek Myths … Age/Chapter 7 and has not yet been proofread, how will I know which type of mark to use in creating the deeplink? Beeswaxcandle (talk) 19:03, 31 August 2019 (UTC)
Agree with straight quotes in page titles. However, for the ones that exist, I would advise moving them and leaving redirects. It seems to me there is a tendency on this wiki to not leave redirects. That seems counterproductive to me, especially when a page has been up for a while; there's no way of knowing the various places, online and offline, where there might be incoming links. What's the harm in a redirect? -Pete (talk) 17:01, 3 September 2019 (UTC)
Support I think the question of whether to allow curly quotes is the wrong question entirely. Of course we should—we should be preferring them like PG does nowadays. Straight quotes are a hack introduced with early typewriters as a way to save room on the keyboard, and I would really prefer that we use the original, traditional typesetting instead. So I suggest, instead, that the right question to be asking here is how to make it easiest and most convenient to type smartquotes, since I see that looms largely in people's minds, and rightly so. There are many options we could be discussing, including keyboard shortcuts (easy to add javascript so that ctrl-\" adds a pair of quotes), or a bot to do automatic substitution (which would need to be validated), or other possibilities I haven't even thought of. Dcsohl (talk) 20:01, 8 September 2019 (UTC)
As there has been little discussion for some time, and there is large support in favour of this proposal, I shall change the relevant guideline, if there are no objections in the next twenty-four (24) hours. TE(æ)A,ea. (talk) 23:55, 25 September 2019 (UTC).
Okay, I will change the relevant guideline. I was about to post here asking that opposers join the discussion, because the few opposers are not discussing things. The discussion has finished as to whether or not we do this.--Prosfilaes (talk) 04:31, 26 September 2019 (UTC)
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
Last week's Tech News had delivery problems. Some did not get the newsletter. Some got it more than one time. The problem where some pages got it three times should now be fixed. [15]
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 1 October. It will be on non-Wikipedia wikis and some Wikipedias from 2 October. It will be on all wikis from 3 October (calendar).
Meetings
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 2 October at 15:00 (UTC). See how to join.
Special:Contributions will get the standard OOUI look. This makes it easier to use on mobile and makes it look like other Special: pages. There is a script you can use to make the form smaller if you want to. [16]
The consultation on partial and temporary Foundation bans just started
Hello,
In a recent statement, the Wikimedia Foundation Board of Trustees requested that staff hold a consultation to "re-evaluat[e] or add community input to the two new office action policy tools (temporary and partial Foundation bans)".
For the longest time, Wikisource's inclusion policy imposed additional criteria for including texts published on or after January 1 1923. This happened to coincide with what was then the public domain cutoff date for published works in the United States, although the policy makes clear that these are to be considered separate concerns. With the public domain rolling forward in the US at last, a user changed the references to 1923 to a dynamic CURRENTYEAR-95 expression. I have reverted this change pending discussion. Do we want to roll forward our unconditional inclusion threshold along with the copyright law or do we want it to stay put? Phillipedison1891 (talk) 06:54, 25 September 2019 (UTC)
@Phillipedison1891: The change was purposeful, and reflects the point that the 1923+95 has been reached, and each year that now passes increments the year we can have. The community had been awaiting that anniversary, and the consensus was determined at the creation of the template all those years ago Please undo your change. — billinghurstsDrewth13:47, 25 September 2019 (UTC)
the lack of discussion is more a function of a small wiki more interested in doing work, than memorializing consensus. it is not more restrictive than PD, but rather using whatever works commons will allow. the use of simplistic date hurdles is for them, using PD not renewed works are at the hazard of summary deletions there, for example c:Commons:Deletion requests/American seashells (1954). however, fair use of jeppeson charts in PD documents are not ok. but if you want to build a consensus for "what is in scope" go for it. Slowking4 ⚔ Rama's revenge21:26, 28 September 2019 (UTC)
@Slowking4: Belated thanks to the people that retrieved those... I missed that discussion on Commons about the images, but had actually looked up the original registration and checked for a renewal by number before uploading the book, and it was also cleared by the Copyright Review Management System at HathiTrust (i.e. actual paid copyright experts). Disturbing that people would delete items specifically uploaded as 'not renewed' without actually checking, particularly works with a renewal date that would be in the online USCO database. (FWIW, that publisher was bought out by a big conglomerate in 1968, and most of their publications were probably never renewed.) Jarnsax (talk) 05:52, 8 October 2019 (UTC)
there is no consensus for URAA interpretation either here or on commons, see also c:Commons:Village_pump/Copyright#URAA_revisited_in_2019 and "The WMF does not plan to remove any content unless it has actual knowledge of infringement or receives a valid DMCA takedown notice. To date, no such notice has been received under the URAA. We are not recommending that community members undertake mass deletion of existing content on URAA grounds, without such actual knowledge of infringement or takedown notices." [17] -- Slowking4 ⚔ Rama's revenge10:58, 18 October 2019 (UTC)
Last time we had this discussion, it was pretty clear there was consensus for not supporting texts that aren't in the public domain in the US on Wikisource.
Ignoring the URAA doesn't mean that the rule of the shorter term would come into play. Huge number of works as late as the 1980s would be PD. It also doesn't matter for many British and Canadian works, which were routinely published and even renewed in the US. E.g. the last works of H. Rider Haggard are still in copyright in the US, despite his death in 1925, with or without the URAA, because they were renewed. Many more may be out of copyright, no matter when their authors died, because they were registered with the US copyright office and not renewed.--Prosfilaes (talk) 15:50, 18 October 2019 (UTC)
Yes. Chinese Wikisource applies how the WMF does, without ignoring the URAA. It is why I ask here about how strict we enforce the URAA, active or passive.--Jusjih (talk) 03:01, 21 October 2019 (UTC)
The new version of MediaWiki has been deployed during the last week.
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 4 September at 15:00 (UTC). See how to join.
Support Seems the most accurate and sensible label to me. --Xover (talk) 11:22, 3 September 2019 (UTC)
Comment The intent of plain sister labels was to target the result, not wiki name specifically, view the other labels in the series. If the existing label is not suitable, I would just prefer "species" though I am a dinosaur. The words species and taxonomy come from the scope for that site. — billinghurst sDrewth 12:27, 3 September 2019 (UTC)
Oppose it is not meant to be identifying the wiki, it is meant to be identifying the type of article, which is the design of the whole plain sister. — billinghurst sDrewth 13:05, 10 September 2019 (UTC)
'; &c. —Beleg Tâl (talk) 00:03, 16 August 2019 (UTC)
![[13]](https://commons.wikimedia.org/wiki/File:20140806_openaccessmanifesto-01.png){kind=link}
