Wikisource:Scriptorium/Archives/2019-04

Please do not post any new comments on this page. This is a discussion archive first created in April 2019, although the comments contained were likely posted before and after this date. See current discussion or the archives index.

Talk to us about talking

The Wikimedia Foundation is planning a global consultation about communication. The goal is to bring Wikimedians and wiki-minded people together to improve tools for communication.

We want all contributors to be able to talk to each other on the wikis, whatever their experience, their skills or their devices.

We are looking for input from as many different parts of the Wikimedia community as possible. It will come from multiple projects, in multiple languages, and with multiple perspectives.

We are currently planning the consultation. We need your help.

We need volunteers to help talk to their communities or user groups.

You can help by hosting a discussion at your wiki. Here's what to do:

1. First, sign up your group here.
2. Next, create a page (or a section on a Village pump, or an e-mail thread – whatever is natural for your group) to collect information from other people in your group. This is not a vote or decision-making discussion: we are just collecting feedback.
3. Then ask people what they think about communication processes. We want to hear stories and other information about how people communicate with each other on and off wiki. Please consider asking these five questions:
   1. When you want to discuss a topic with your community, what tools work for you, and what problems block you?
   2. What about talk pages works for newcomers, and what blocks them?
   3. What do others struggle with in your community about talk pages?
   4. What do you wish you could do on talk pages, but can't due to the technical limitations?
   5. What are the important aspects of a "wiki discussion"?
4. Finally, please go to Talk pages consultation 2019 on Mediawiki.org and report what you learned from your group. Please include links if the discussion is available to the public.

You can also help build the list of the many different ways people talk to each other.

Not all groups active on wikis or around wikis use the same way to discuss things: it can happen on wiki, on social networks, through external tools... Tell us how your group communicates.

You can read more about the overall process on mediawiki.org. If you have questions or ideas, you can leave feedback about the consultation process in the language you prefer.

Thank you! We're looking forward to talking with you.

Trizek (WMF) 15:01, 21 February 2019 (UTC)

Discussion

I've signed us up. Please proceed to discuss discussions. —Beleg Tâl (talk) 16:13, 21 February 2019 (UTC)

Some thoughts on the subject:

• Due to the small number of regular editors, and the large number of content pages, discussions on most talk pages will not get any response. More experienced editors will know to post on the Scriptorium directly, but this is not obvious to new users. I continue to find old unanswered questions asked by new users on talk pages throughout the site.
• Sometimes the flow of a discussion is confusing, especially when editors don't consistently indent their comments. I've heard that the Flow extension resolves some of this, but I haven't tried it. I assume we've discussed using this extension, and had good reason for rejecting it.
• The biggest pipe dream for me regarding discussion is to more easily include other projects (particularly other wikisources) in discussions. Maintaining parallel discussions on two separate wikis is possible (and we've done it many times) but too clunky for general use. And I think there is a lot the wikisources can learn from each other.

I'm curious to hear what others have to contribute. —Beleg Tâl (talk) 17:01, 21 February 2019 (UTC)

I agree about the indenting issue. The biggest thing I see, however, that's specific to Wikisources is that it'd be great to have a single place for discussion for each proofreading work — i.e. a unification of all the talk pages from the Index, Page, and main namespaces (and for all of the 'discussion' tabs on all those places to go to one single place). Obviously there are exceptions (newspapers, encylopaedias, etc.), but most works don't have very much discussion and it'd be nice to make it easier to follow (e.g. a 'watch this work' button). It could even include the work's Wikidata item. Sam Wilson 05:43, 22 February 2019 (UTC)

Sam, this idea came up at the German Wikipedia as well (under the modest proposal that talk pages just be abolished, and everything redirected to Portal_talk:  ;-). Can't that be done now, though? It seems like a bot run to redirect all of the subpages would be sufficient. Whatamidoing (WMF) (talk) 19:21, 3 March 2019 (UTC)

yeah, veterans know to go to index talk about work format issues. but some threading together would be better. Slowking4 ‽ SvG's revenge 02:39, 8 March 2019 (UTC)

I've tried conversing with the Flow extension and find it to be non-intuitive and frustrating. --EncycloPetey (talk) 05:50, 22 February 2019 (UTC)

As I just signed myself up for closing the En:Wikipedia discussion, I will express my Wikisource only issues with communication here. There is no convenient way to be reached when I am not on the computer at home. (Text message alerts or SOMETHING would be really nice in this regard). If I can reply to a person on Twitter via text then getting direct messages on here (instead of email) should be equally as possible. I don't want everyone knowing my gosh dang email. We don't have an app that I am aware of. ―Matthew J. Long -Talk-^☖ 17:32, 23 February 2019 (UTC)

well, there is wikisurfer, but it seems to be broken. we need a good reader, and off line reader, but that would require some dev time. i have been communicating on FB, Telegram, twitter. the dysfunction of talk tends to impact the other projects more. if we had a more VE non-wikicode interface with more newbies, then talk might get used here more. to the extent people are helpful, then it is useful; when they are not, then not so much. -- Slowking4 ‽ SvG's revenge 12:31, 25 February 2019 (UTC)

• Most of wiki contain information that are partially complete and grammatically incorrect. As a suggestion, we can talk to content writers, editors to edit the pages. Being a Language Verifier myself, I can do editing for pages wherein I have knowledge with. —unsigned comment by Dhamayanthi Sivaram (talk) .

  Wikisource doesn't have "content writers". We're not creating original content on Wikisource. --EncycloPetey (talk) 01:28, 26 February 2019 (UTC)

Issue: Wikipedia does not allow edits from people - logged in or otherwise - via VPN proxies.

• I understand Wikipedia's desire to avoid bot-spam or malicious content from people who block their IP address.
• The other side of this issue is that there my be people - like me - who may not want to comment with an un-blinded connection. In my case, I spend a fair amount of time abroad, in Moscow Russia, and it is well known that the Russian government loves to spy on what people do. Right now I am using a VPN connection to an endpoint in NYC, and - according to Russian law - I can be heavily fined and face a significant prison term for using a VPN. However, I really hesitate to communicate, e-mail or otherwise, without a VPN connection to an endpoint outside of Russia.
• Maybe there is a person in China who wants to create and post an article that is not as flattering to the communist Chinese government as they would like? He can't do it without some way to get past the Great Firewall.
• I know that I can request an exemption, but I've already done that and had it turned down because "I don't contribute enough" And how am I supposed to do that when I can't contribute at all? Now that I've retired, I have more time to participate and would like to do so. In fact, this page - and my two talk pages I just created - seem to be the only pages I can post on.

May I respectfully request a reconsideration of a blanket ban on VPN connections? Perhaps a ban on people who haven't logged in, or have been members for a short time? Maybe edits/articles from that source can be subjected to heightened moderation before being posted?

Jharris1993 (talk) 14:47, 28 February 2019 (UTC)

Abuse

OP is globally blocked for cross-wiki harassment

Dont allow this user to edit any where.

https://en.wikibooks.org/wiki/User:Bonadea

https://en.wikibooks.org/wiki/User:Bonadeaz

(Grahmki (talk) 20:10, 28 April 2019 (UTC))

Additionally theser two user names are againest user name policy

‘Bonadea’ user name violence: with explanation

 https://en.wikipedia.org/w/index.php?title=Wikipedia:Administrator_intervention_against_vandalism&diff=894350413&oldid=894350412.

(Grahmki (talk) 20:50, 28 April 2019 (UTC))

What is "the LTA community"? As far as I know "LTA" stands for "Lawn Tennis Association", but they're unlikely to have banned editors. Also, there is no need to pre-emptively urge against editing by Users who have never edited on Wikisource. The admins will take care of that. --EncycloPetey (talk) 21:00, 28 April 2019 (UTC)

LTA Long term abuse , Community banned users their editing prohibited in all wikis of Wikimedia foundation including Wiki source.

Administrators note on Block : " A sock puppet of User:Bonadeaz . User:Bonadea is LTA and Community banned user of all wikis of Wikimedia Foundation "

(Grahmki (talk) 21:10, 28 April 2019 (UTC))

(Grahmki (talk) 21:13, 28 April 2019 (UTC))

This does not make much sense to me either. Why are you posting the message if the user "is banned in all wikies..." anyway? Besides that I found no explanation at the linked page. I just understood that the name Bonadea should be offensive for some reason, but searching for its meaning I found just Bona Dea, who was a goddess of chastity and fertility in ancient Roman religion. I have no clue why you bother scattering such a message across wikiprojects. Is it some sort of revenge against an opponent? --Jan Kameníček (talk) 21:16, 28 April 2019 (UTC)

Actually i have no idea about these users.But on observation i found some disruptive editing of these users.Reverting Bot comments,Reverting admin comments like that . Actually the religious related user names are block in all wikis of Wikimedia foundation Wikimedia foundation ..No i give reference and sources here.

Religious user names are prohibited in all Wikimedia projects

 https://en.wikiquote.org/wiki/Wikiquote:Username_policy

"Usernames which consist primarily of the name of a religious figure (such as "God", "Jehovah", "Buddha", or "Allah") are prohibited."

 https://en.wikibooks.org/wiki/Using_Wikibooks/Setting_Up_A_User_Account#Choosing_a_Username

"Usernames that invoke the name of a religious figure"

 https://en.wikiversity.org/wiki/Wikiversity:Username

"Inappropriate usernames : Names of religious figures such as "God", "Jehovah", "Buddha", or "Allah","

 https://en.wikipedia.org/wiki/Wikipedia:Username_policy#Usernames_violating_the_BLP_policy.

"User names related to race, religion or social groups should be immediately blocked by administrators"Religious user names are prohibited in all Wikimedia projects

 https://simple.wikipedia.org/wiki/Wikipedia:Username

"Offensive names policy : Do not use the name of a political, military or religious figure or event (including real people" .

At My knowledge the above 2 users were blocked.

(Grahmki (talk) 21:27, 28 April 2019 (UTC))

If they have been "banned in all wikis", then there is no need to tell us about it. If they have been banned only on Wikipedia, for activity on Wikipedia, there is also no need to tell us about it. You do not need to tell the community about its rules, particularly when your only edits here have been to raise a fuss about activity on other wikis, that does not apply here. There is nothing happening here on Wikisource that requires any response to this matter. --EncycloPetey (talk) 21:32, 28 April 2019 (UTC)

The user Grahmki looks like a puppet too as there are no contributions by this account to any wikiproject, so let's just ignore it. --Jan Kameníček (talk) 21:38, 28 April 2019 (UTC)

Wikipedia:Wikipedia:Long-term_abuse/Nsmutte is listed as impersonating other users. Do we have a local Checkuser?ShakespeareFan00 (talk) 21:45, 28 April 2019 (UTC)

My aim is to give information and to provide sources of disruption of these two users to prevent disruption again on wikis.I am a fresh user but i like wiki and its administrators.I will be here as a contributor for years,Thanq (Grahmki (talk) 21:52, 28 April 2019 (UTC))

Please read the comments of admin on their delete pages ,These two users are Long term abusers : "A sock puppet of User:Bonadea . User:Bonadea is LTA and Community banned user of all wikis of Wikimedia Foundation .", and the only contributor was "Bonadeaz" (talk)).These two are confirmed socks.Nsmutte may be other one.

https://en.wikibooks.org/wiki/User:Bonadea

https://en.wikibooks.org/wiki/User:Bonadeaz

Just i provided an usefull information....(Grahmki (talk) 22:02, 28 April 2019 (UTC))

Grahmki is a blatant sock of Nsmutte (mentioned above) who likes to harass w:en:User:Bonadea by impersonation, defamation, or a mixture of those two using good-hand, bad-hand accounts. I should know, I spent several months of 2016 on the front line of dealing with this on English Wikipedia. Blocking, and please don't encourage this troll any further. BethNaught (talk) 22:07, 28 April 2019 (UTC)

I just locked the account Grahmki globally, this is indeed Nsmutte. Regards --Schniggendiller (talk) 22:13, 28 April 2019 (UTC)

yeah, lesson for the wise: a lot of the talk of LTA and banning others is instigated by editors who are banned. we see drama exported to uninvolved projects. as this is a low drama project, it is particularly jarring; not so elsewhere. Slowking4 ‽ SvG's revenge 01:46, 30 April 2019 (UTC)

Zodiac Killer letters

All of the text at Zodiac Killer letters has been scan-backed and split to individual document pages. I will now proceed to move Zodiac Killer letters to Author:Zodiac Killer (to preserve edit history), then replace the contents of Zodiac Killer letters with the current contents of Author:Zodiac Killer. I intend to leave a {{soft redirect}} from Zodiac Killer letters to Author:Zodiac Killer due to incoming links from works external to Wikisource. None of this is controversial; it is standard procedure for pages like this. I merely post it here to inform the community due to the importance of this page. Please let me know if you have any comments. —Beleg Tâl (talk) 01:24, 1 April 2019 (UTC)

Wikisource:News: April 2019 Edition

English Wikisource's monthly newsletter; Wikisource:News, which seeks to inform all about Wikimedia's multilingual Wikisource.

• From the Editors: Volume 3 confirmed
• Xover nominated to be admin
• Administrator confirmations for April 2019
• Wikisource — A Wikipedia project
• WikiProject Spotlight: WikiProject Validate

Read this issue of Wikisource:News · Discussion · Unsubscribe · –MJL ‐Talk‐^☖ 12:53, 1 April 2019 (UTC)

Tech News: 2019-14

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

Changes later this week

• Notifications tell you about things that happen on the wiki. You can turn on notifications about new links to pages you created. For performance reasons you can no longer get e-mails about this. [1]
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 2 April. It will be on non-Wikipedia wikis and some Wikipedias from 3 April. It will be on all wikis from 4 April (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 3 April at 15: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.

16:29, 1 April 2019 (UTC)

Other discussions

Wikisource Community User Group representative vote

Dear all,

Sorry for writing in English and cross-posting this message.

Following the previous message, the vote for the representative of the Wikisource Community User Group to the Wikimedia Summit 2019 is now open.

There is two great candidates on page on meta to decide who will be the representative of the user group to the Wikimedia Summit. You can support a candidate now. All active Wikisource users can vote. The vote is ending on December 14, 2018.

Feel free to ask any question on the wikisource-I mailing list or on the talk page.

Thank you!

For the Wikisource Community User Group, Tpt (talk) December 8, 2018 at 18:53 (UTC)

Lawyers and law students' signatures needed for Supreme Court amicus brief in favor of publishing the law

Signatures needed to defend the public domain status of the law in the USA, so that we can publish such texts on Wikisource without problems if we want: https://boingboing.net/2019/04/25/happy-law-day.html Nemo 20:50, 25 April 2019 (UTC

Is CSS/JS cleanup worthwhile even if some stuff might break along the way

In the Site gadget (in your preferences, Gadgets tab, Interface section; the details can be seen on Special:Gadgets) there's a bunch of custom CSS and JS included that is, I believe, intended to be of general use for various bits of the interface and templates on enWS. Mostly these seem to have come about as a result of GOIII's efforts around 2013-2015, and they are not particularly well documented (that I can find, anyway). Looking over it I have a nagging suspicion that a lot of it is actually obsolete: it's custom stuff that either never was used, is no longer used, or has been superseded by newer versions of MediaWiki and its skins (Vector in particular). However, as these things tend to go, nothing ever gets removed because it's very hard to tell what's used and what isn't, and what might break if you do.

Since this kind of cruft-accumulation tends to offend me, I would like to try chipping away at it (slowly, intermittently), deleting what's unused, moving things to TemplateStyles where that makes more sense, etc. However, this kind of cleanup is almost guaranteed to break stuff, and so I'd like to have some backing from the community that some (presumably temporary) breakage and inconvenience is acceptable as a tradeoff for decluttering and easier future maintenance. Or if the community thinks this kind of cleanup is unnecessary and annoying for no good reason, then I would prefer to have that feedback before I start proposing such changes. I'd also like to hear to what degree the community is interested in getting changes individually proposed and discussed, and to what degree they would prefer I just plow ahead and not bother everyone with such arcana unless something breaks.

As an example, the issue that prompted me to start digging into this in the first place: in MediaWiki:Gadget-enwp-boxes.css there are some CSS rules to add disclosure triangles to collapsible elements like lists and boxes. You'll most commonly see these when previewing a page you're editing, usually at the bottom of the window, where it says "Parser profiling data" and "Pages/templates included in this preview" etc.; or in your Watchlist if you have the pref to group changes by page enabled. The custom CSS points to some image files that no longer exist (and haven't existed for years) making collapsible elements show up without any kind of visual indication that they can be expanded. I'd initially though to just fix the link (the rules point at a .svg but the files are actually .png), but as I dug into it it seems that this functionality is now actually included in MediaWiki.

My proposal is thus that the relevant bits of custom CSS is simply removed. Note that it shouldn't really affect the behaviour of collapsible elements, just the visual styling with a custom disclosure triangle.

The CSS in question is:

/* General-purpose icons via CSS. Classes here should be named "mw-icon-*". */
/* Adds arrows to toggle-blocks for collapsible elements */
/* For the collapsed and expanded arrows, we also provide selectors to make it
 * easy to use them with jquery.makeCollapsible. */
.mw-icon-arrow-collapsed, .mw-collapsible-arrow-toggle.mw-collapsible-toggle-collapsed {
	background-image: url(/w/skins/Vector/images/arrow-collapsed-ltr.png);
	background-image: -moz-linear-gradient(transparent, transparent), url(/w/skins/Vector/images/arrow-collapsed-ltr.svg);
	background-image: -webkit-linear-gradient(transparent, transparent), url(/w/skins/Vector/images/arrow-collapsed-ltr.svg);
	background-image: linear-gradient(transparent, transparent), url(/w/skins/Vector/images/arrow-collapsed-ltr.svg);
	background-position: 0% 50%;
	background-repeat: no-repeat;
	padding-left: 20px;
}
.mw-icon-arrow-expanded, .mw-collapsible-arrow-toggle.mw-collapsible-toggle-expanded {
	background-image: url(/w/skins/Vector/images/arrow-expanded.png);
	background-image: -moz-linear-gradient(transparent, transparent), url(/w/skins/Vector/images/arrow-expanded.svg);
	background-image: -webkit-linear-gradient(transparent, transparent), url(/w/skins/Vector/images/arrow-expanded.svg);
	background-image: linear-gradient(transparent, transparent), url(/w/skins/Vector/images/arrow-expanded.svg);
	background-position: 0% 50%;
	background-repeat: no-repeat;
	padding-left: 20px;
}

PS. The Vector skin didn't really exist until around 2014, and MediaWiki and Vector have gained a lot of functionality since then that used to require custom scripts and styling on the various Wikimedia projects. In particular, Gadgets and TemplateStyles are relatively recent developments that enable us to have a lot less global CSS and JS and push more of it either to only those users who need it, or into the templates that actually use it. I think it's likely that there's quite a lot of cleanup that's possible there, and which might both make future Mediawiki changes less fraught and make it easier to add custom stuff afterwards if we need it. But then again, nothing is currently horribly broken, so conservatism is an entirely valid stance to take on this: we don't have to clean any of this up urgently, I just think it's worthwhile to at least get started. --Xover (talk) 11:05, 1 April 2019 (UTC)

I'd say go for it. I don't think GO3 felt it necessary to pass these cleanup tasks by the community unless it was a functionality change. Keep us posted though, in case there are issues. —Beleg Tâl (talk) 15:06, 1 April 2019 (UTC)

Well, I know there were those who expressed frustration with the sweeping nature of the changes—and particularly with documentation and maintainability—so I figure it might be prudent to thread carefully in order to not aggravate such frustrations. Particularly as it is inevitable that such changes will cause at least minor breakage at some point: at least some such change will have to be of the "try it and see if anything breaks" variety. I'm hoping the community will be prepared to tolerate that, but I feel it's better to be upfront about the downsides. --Xover (talk) 16:21, 1 April 2019 (UTC)

Done I have left it in the css, though rem'd it within the page. Please report any problems so that it can be reverted. — billinghurst sDrewth 06:19, 6 April 2019 (UTC)

@Billinghurst: Thanks. Much appreciated! I can confirm that the built-in disclosure triangles are now displayed as intended. Could you also split the page layouts and page numbers script to separate functions and make each of them a gadget (so they can be disabled per-user in order to test out changes to them in a user script)? --Xover (talk) 08:57, 6 April 2019 (UTC)

A process and policy for Interface Admins

Somewhat related to the above proposed CSS changes… I had presumed I would be able to bug someone with the new interface admin bit to make the edits needed, but it seems there aren't any here. It is also, prudently enough, not one of the permissions administrators can assign themselves when needed. The description page at Wikisource:Interface administrators does not exist, and I've failed to find any documented policy or process related to this right.

The Wikimedia community consultation on this issue was last July, at which time there was a brief discussion here about it (raised by BethNaught, the only comment was by Billinghurst). That discussion does not appear to have had any conclusion.

The change took effect on August 27 as announced here: Editing of sitewide CSS/JS is only possible for interface administrators from now

The issue was raised again in October with comments from Mpaa, Beleg Tâl, Mukkakukaku, Beeswaxcandle, BD2412, and a logged out user. The discussion outlined several options: "Assign right on demand when needed" (A); "Assign right permanently to willing Admins, to be reviewed in the confirmation process" (B); "Assign right permanently to selected Admins, after approval process, to be reviewed in the confirmation process" (C); "assign the rights to all the admins, who have already been vetted for community approval, and then whoever has the ability and desire can make use of it as they will and as needed" (D). There was no firm conclusion reached, and some difference of opinion expressed, but the general sentiment seemed to be to assign this right to either all administrators or to willing administrators, only subject to assessment during the periodical admin confirmation process.

Subsequent to these discussions, the WMF Office has added a requirement for two-factor authentication (2FA) for holders of this permission. Since the Mediawiki 2FA feature is sufficiently… bumpy… that the enwp admins flat out refuse to make 2FA a requirement for the broom, even after several cases of compromised accounts with advanced permissions wreaking havoc, I conclude that this requirement in practice rules out giving all admins interface administrator privileges by default.

I take it there has so far not been any pressing need for handling this right, but I would assert that once such a need does materialise it is a bit late to start figuring out our policy for it. For that reason, and based on the above referenced discussions, I propose the following:

• Wikisource:Interface administrators is filled with something very similar to m:Interface administrators and w:Wikipedia:Interface administrators.
• All administrators may be added to the interface-admin group by self-request in a new section on the Administrators' noticeboard
  • Requests should include explicit affirmation of familiarity with the policy embodied in Wikisource:Interface administrators, in particular awareness of the privacy expectations of Wikimedia wikis and the 2FA and account security requirements, as well as sufficient technical proficiency
  • The intent of requiring explicit affirmation is to ensure the permission is not requested without full awareness of its requirements and effects
• Requests are processed by Wikisource bureaucrats (currently Hesperian, Mpaa, and Zhaladshar)
• During the regular confirmations for normal administrator rights, interface administrator rights are assessed as a separate matter
  • The intent being that interface administrator rights may be removed but normal administrator rights retained, for example in the case of a perfectly capable normal admin that happens to have a blind spot regarding their own technical (in)competence
• Interface administrator rights require administrator rights and losing the latter automatically means losing the former
• Interface administrator rights removed by the community (typically during the periodical confirmation process) are considered to be removed "under a cloud" and may not be restored without a nomination (as for admin rights) and community discussion
• Interface administrator rights should be removed 12 months after a user's last edit, or after 24 months of being substantially inactive even if there are intermittent edits
  • This is for security reasons: inactive accounts with advanced permissions are at high risk of hijacking and may cause significant harm in the hands of a bad faith actor
• Interface administrator rights may be voluntarily relinquished by request in the same manner they were requested
• Interface administrator rights removed due to inactivity or voluntarily relinquished are not considered to be "under a cloud" and may be regained through simple request
• There should always be a minimum of two interface administrators, much like checkusers, so that they can audit each other's edits
  • This is to have the ability to do so, not a requirement that all relevant edits are audited or patrolled
• If the number drops to one for whatever reason, the permission should be removed until at least one more interface admin can be added

I think that covers all eventualities, and should be mainly unobjectionable based on the above linked discussions. As this is in effect proposing project-wide policy on advanced permissions (and with security implications for all users) I ask that everyone chime in, even if your stance is "Don't care" or similar, but especially with support/oppose. I also stress that any policy can always be amended: the above proposal presents a single option in the hopes we can get a policy and process in place, even if it's not perfect. Nine months in and we are still without interface admins on the project, have no way to get them (because the stewards at meta require a policy before assigning it), and no way to install or remove gadgets, edit CSS/JS, etc. --Xover (talk) 17:25, 2 April 2019 (UTC)

I think this is still too complicated; I think that all admins (with MFA) should be granted interface adminship, either automatically or by request/as desired. The regular admin vetting procedure should assume that the admin being vetted may use interface admin features, and should only be removed by request or when adminship is revoked. My primary reason for this is: who is going to manage this additional procedure, and why should they have to manage it when they could be adding more works or dealing with backlogs instead?—See, for example, Wikisource:Administrators' noticeboard/Archives/2018#Billinghurst interface rights for how simple it can be —Beleg Tâl (talk) 17:33, 2 April 2019 (UTC)

My assumption is that the 2FA requirement in practice precludes automatically making all admins interface admins. I don't have personal experience with Mediawiki's implementation, but having skimmed some of the discussions at enwp I am convinced at least some admins will be adamantly opposed to such a requirement, and that there is at least partially cause for the opposition. The above is also designed to require the very minimum of additional management. The bureaucrats have to add and remove such groups anyway, and periodic confirmation for adminship can rubberstamp interface admin rights unless there is cause for concern. The "minimum of two" requirement is in practice self-managed: when we dropped to just one checkuser due to a resignation, the remaining checkuser resigned the bit themselves pending appointment of a second checkuser. The above also says all admins can have it by just saying they want it: the only added requirement in the above relative to what you describe is that the request has to say "I've read the policy and know what I'm doing". "Complicated" I'll grant you, but mainly due to the requirements of the role. Or at least I've tried to make anything more complicated than it has to be.

Your example is apt; the above is intended to be essentially that simple in practice. However, Hesperian strictly probably shouldn't have honored that request: in the absence of a local policy for interface admins the request should have been made to the stewards at meta, and they should have verified that Billinghurst had 2FA enabled (which is a WMF requirement not subject to modification by local policy). The loads of words in the above proposal is to deal with stuff like that, not to make the process any more complicated or labour-intensive in practice. --Xover (talk) 18:04, 2 April 2019 (UTC)

i don’t know that the admins here are as persnickety or cell-phobic as at english WP, 2FA might be worth a try. (i would much prefer the secure key fob i.e. [2] to 2FA, but they don’t listen to me.) Slowking4 ‽ SvG's revenge 01:58, 3 April 2019 (UTC)

Good point. enwp is… well, let's just say enwp is rarely entirely representative of other projects and leave it at that. --Xover (talk) 05:21, 3 April 2019 (UTC)

This sounds like a great idea. I'd like to put my hand up to become one. :-) As for the policy, it sounds pretty good I think. And as far as giving the right to all admins who have 2FA: that seems pretty good to me, the only possible drawback I can think of is that it might give some people without Javascript knowledge access to edit JS — and, I don't know, maybe open an avenue for someone else to socially engineer a non-technical admin into adding malicious JS. (After all, it's the JS security angle that resulted in this new right originally, isn't it?) But either way, we certainly need people here who can update gadgets! —Sam Wilson 03:46, 3 April 2019 (UTC)

Security is what drove this change, yes, so far as I know; both JS, CSS, and the various interface strings and markup in the Mediawiki: namespace can be appropriated by a bad actor to attack all users of a wiki, steal personal information, etc. I don't have the details, but I believe this was not a purely theoretical issue: the change was triggered by a specific incident. Hence the strong suggestion that the right should be considered to require even more trust than the regular admin privileges. It is also good security practice in general to restrict advanced permissions to only those who actually need them, so those who will not ever edit CSS/JS here should not have the permissions to do so either. But the flip side of that is also true: with more granular permissions it should also become easier to get the permissions you do need because it is clearer what the consequences are. --Xover (talk) 05:21, 3 April 2019 (UTC)

I'm generally supportive of this proposed policy. There may need to be some wording tweaks, but I would need to read it in a more final format on the policy page. At present it's not a right I would be seeking, but it is needed here with some urgency. I see no issues with 2FA being needed here for such a right. I already have to do so for some other areas of RL. Beeswaxcandle (talk) 19:25, 3 April 2019 (UTC)

I'm also generally supportive. However, we have a confirmation process for admins, and by longstanding convention we have confirmed other rights such as checkuser and bureaucrat as part of this process. People are able to, and indeed do, register !votes of the form "support as admin, oppose as checkuser". So I don't see why we wouldn't roll interface editor confirmation into the existing confirmation process in the same manner. Hesperian 01:54, 5 April 2019 (UTC)

I have no strong opinion on that. The above proposal suggests a separate section mostly due to my default preference for orderliness. There's no particularly good reason I can think of for why it's actually necessary to have a separate section, and given the general thrust of comments here favour being light on structure I think we can take it as read that it should be handled as you describe. And in any case, this kind of stuff is easy to adjust after the fact. --Xover (talk) 06:27, 5 April 2019 (UTC)

 Comment Three part answer.

1. If changes are required to elements that require interface administrators, they are probably best put to the community rather than to an individual. So make requests at WS:AN and the administrators can work the best means to implement such changes rather than an individual needing to do so.
2. The community has discussed our needs previously, and it was agreed that we can temporarily assign these rights locally and without much fuss, and the rights disappear reasonably quickly, and no requirement for 2FA. Pretty certain there is some discussion in archives at WS:AN, though forget all the places that I saw discussions from that time.
3. To note that if it is a simple change that we want, without the assignation of an ongoing right that we can ask global interface admins to make a change.

If we aren't making large amount of changes it isn't overly problematic to manage with temporary rights. — billinghurst sDrewth 06:14, 6 April 2019 (UTC)

And I probably should add that I do have global interface editor rights, and that gets reviewed annually at m:SRGP. — billinghurst sDrewth 06:28, 6 April 2019 (UTC)

@Billinghurst: The 2FA requirement comes from WMF Legal and has no exception for temporary assignment of the rights. For example, requests for temporary intadmin rights made to the Stewards on Meta are put on hold or denied if 2FA is not enabled. If the local 'crats are not checking and enforcing this requirement their practice is in conflict with the terms of service. And I have not been able to find any previous discussions of this issue that reached any conclusion; just the two discussions linked above that were inconclusive. Or put another way: absent an actual central policy documenting the enWS community's consensus on this, if our three local 'crats go on vacation at the same time, and we have to make such requests to the Stewards, what do we point them at so that they can verify whether to honour the request or not? --Xover (talk) 08:44, 6 April 2019 (UTC)

Our crats have the ability to remove and add interface rights, and the ability to set temporary interface rights, which was the light agreement. Let us not fuss the stewards doing such rights. I was meaning the ability to have stewards and global interface editors to make changes for us as required and requested. — billinghurst sDrewth 10:41, 6 April 2019 (UTC)

Seemingly identical links are not identical

Could somebody explain me please the difference between two revisions of [3] ? The link looks absolutely identical, yet in one of the versions it works and in the previous one it did not work. The same problem appeared also at [4] . Now I am going to continue founding the rest of the subpages of the book and I reckon I am going to face the problem again. I am really curious what the cause is and if there is any remedy, as it is really annonying.
I think it is related to the problem described at WS:Scriptorium/Help#The name of the main namespace page does not link to the Table of Contents entry. --Jan Kameníček (talk) 14:35, 7 April 2019 (UTC)

The text of the target page Anthology of Modern Slavonic Literature in Prose and Verse/In a Foreign Land had a U+2060 word-joiner character at the end of it, which displays no visible space. I have moved the page to the correct title and corrected the link. --EncycloPetey (talk) 14:47, 7 April 2019 (UTC)

Thanks very much. Is there any way how to avoid such problems in the future? I. e.:

• Is there any way how to notice that there is such a character before I create another page with non-functioning link?
• Is there any way how to avoid adding such undesired characters?
• Would it be possible that the software either ignored such an character or automatically removed it at the moment of saving the page? --Jan Kameníček (talk) 14:57, 7 April 2019 (UTC)

@EncycloPetey:. It seem I keep having the same problems with Anthology of Modern Slavonic Literature in Prose and Verse/The Tiny Man. I am trying to move the page to the handwritten title instead of a copied one, but the software tells me that the title is the same and so it cannot be moved. It is really annoying... Can you give me some advice, please? :-( --Jan Kameníček (talk) 15:19, 7 April 2019 (UTC)

I seldom come across this issue, so I do not know what has caused it. My best guess is that it is related to the original scan and the method by which the OCR layer was created. The best advice I can give for this volume is to retype by hand all the titles to be linked within the Table of Contents page(s) before creating any more pages: including a couple of characters before title as well as the curly braces afterwards. That is, highlight with your cursor the full title and a couple of characters before and after the title, then retype those characters by hand.

The only other suggestion I can make to to create a list of any weird characters that are known to be hidden as they are found, and seek someone with a bot to eliminate those characters from the text. I know that's not much help, but I'm not sure what else I could suggest. If there were a editing tool that could make those characters visible in some way, it would be helpful, but I know of no such tool. --EncycloPetey (talk) 15:37, 7 April 2019 (UTC)

Unwanted line return

Is there a simple way to correct the unwanted line return between pages 212 and 213 in The Osteology of the Reptiles/Chapter 7 without either introducing a new issue or requiring a massive re-coding? --EncycloPetey (talk) 22:39, 7 April 2019 (UTC)

Abuse of {{hyphenated word start}} and {{hyphenated word end}}? Hesperian 00:05, 8 April 2019 (UTC)

Or use <includeonly> and <noinclude> - I did similar for the page break in A Manual of Prayers for the Use of the Catholic Laity/Hymns and Sequences/Advent —Beleg Tâl (talk) 00:48, 8 April 2019 (UTC)

I tried being creative with just putting the ending parts of the code in the header and footer boxes, but yeah that gave less-than desirable results. –MJL ‐Talk‐^☖ 01:04, 8 April 2019 (UTC)

Yeah, it doesn't work when you transcribe only part of a template call on a single page. Mostly we get around it with separate templates for opening and closing (like {{center block/s}} and {{center block/e}}) but creating these for just a few words is a bit overkill here. —Beleg Tâl (talk) 01:07, 8 April 2019 (UTC)

Scan pages not appearing in Edit window, again

Is the Page extension broken again after the latest update? Today, I have started to have random pages from a DjVu file fail to display in the Page namespace, either in the Edit window or Page view. Is anyone else experiencing this same issue? --EncycloPetey (talk) 00:12, 8 April 2019 (UTC)

Yes three pages from Index: The Osteology of the Reptiles.pfd Index pages 243, 248 and 283. I've tried with Safari and Firefox (Mac). --kathleen wright5 (talk) 05:52, 8 April 2019 (UTC)

Any other editors currently having this problem on other files? --EncycloPetey (talk) 13:41, 8 April 2019 (UTC)

Colours in the edit window

When I try to edit a page, various templates or formatting stuff are coloured in blue or purple. I am not sure whether I switched something on by mistake or whether it is some new feature, but it distracts me quite a lot. However, I cannot find where to turn it off. May I ask for advice? Thanks! --Jan Kameníček (talk) 08:30, 8 April 2019 (UTC)

@Jan.Kamenicek: There's a button in the editor toolbar that's supposed to look like a magic marker, which turns on and off syntax coloring. --Xover (talk) 08:40, 8 April 2019 (UTC)

I see now thanks! I was exploring the preferences instead :-) --Jan Kameníček (talk) 08:42, 8 April 2019 (UTC)

Read-only mode for up to 30 minutes on 11 April

You will not be able to edit most Wikimedia wikis for up to 30 minutes on 11 April 05:00 UTC. This is because of a hardware problem. You can still read the wikis. You can see which wikis are affected. The time you can not edit might be shorter than 30 minutes. /Johan (WMF)

10:56, 8 April 2019 (UTC)

Tech News: 2019-15

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

• More wikis are now testing visual editor section editing for mobile users. You can read more.
• Admins on French and Polish Wikipedia can block someone from editing a page or a namespace. If your wiki wants to get these blocks before they are available to all wikis, you can tell the developers. [5][6]

Problems

• You will be able read but not edit most wikis for 30 minutes on 11 April at 05:00 (UTC). This is because of a hardware problem. You can see a list of the affected wikis. [7]
• A map update caused some problems on 29 March and 30 March. It was rolled back. [8]
• Pages on some Wikivoyages had problems with the top headline. This has been fixed. [9]

Changes later this week

• When you add an edit summary the VisualEditor will search your recent edit summaries in case you want to re-use one. This works in both the visual and wikitext modes on desktop. It also works on the mobile site. [10]
• The Wikimedia wikis will get a URL shortener. This will work from 11 April. You can read more. [11]
• The {{REVISIONID}} magic word will no longer work. This is for performance reasons. When you preview a page it will return "" (empty string). When you read a page it will return "-" (dash). For now this will only affect content namespaces. [12]
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 9 April. It will be on non-Wikipedia wikis and some Wikipedias from 10 April. It will be on all wikis from 11 April (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 10 April at 15:00 (UTC). See how to join.

Future changes

• You will be able to preview references. This means that when you hover over the link you will get a popup that shows you a preview of the reference. It will work much like page previews. This is so you don't have to go to the bottom of the page to see a reference. This will now be available as a beta feature on German and Arabic Wikipedia. [13][14]
• The Wikidata JSON output will change. Empty containers will be serialised as empty objects. This is a breaking change that will affect tools that use JSON outputs and APIs. It will happen on 30 April. You can read more and see how to test your code.

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

18:24, 8 April 2019 (UTC)

Unsourced works by Bolesław Prus

I have come across several works by Author:Bolesław Prus (e. g. A Legend of Old Egypt (2005)) and marked them as unsourced as I was not able to find there any info about where the translation comes from. Only then I found some old discussion at Wikisource:Copyright_discussions/Archives/2007-10#Works of Author:Bolesław Prus where some OTRS email is discussed. If such an email exists, can it be marked somehow at the works? And should these works be moved into the Translation namespace? --Jan Kameníček (talk) 11:24, 9 April 2019 (UTC)

i see a reprint here [15], but no results at Library of Congress. Slowking4 ‽ SvG's revenge 13:52, 9 April 2019 (UTC)

Mold of the Earth is sourced from this article in The Polish Review. —Beleg Tâl (talk) 15:21, 9 April 2019 (UTC)

Regarding ORTS: you should post on commons:Commons:OTRS/Noticeboard to confirm the ticket number for the permission letter referenced at Wikisource:Copyright_discussions/Archives/2007-10#Works of Author:Bolesław Prus. Once you have the ticket number, you can add {{PermissionOTRS}} immediately following the GFDL tag on the three works that use this permission (namely Mold of the Earth, A Legend of Old Egypt, and The Most General Life Ideals). —Beleg Tâl (talk) 15:23, 9 April 2019 (UTC)

Thanks for the advice, I have asked for the ticket number. --Jan Kameníček (talk) 17:57, 9 April 2019 (UTC)

Ticket added. --Jan Kameníček (talk) 06:57, 10 April 2019 (UTC)

Category:Index - File to check

Would it be possible for someone to empty this category any-time soon?ShakespeareFan00 (talk) 12:19, 10 April 2019 (UTC)

Go for it —Beleg Tâl (talk) 12:51, 10 April 2019 (UTC)

Well I would, if there was more information on the author dates, I don't work on stuff that's still in UK/EU Copyright as far as I can determine. ShakespeareFan00 (talk) 14:55, 10 April 2019 (UTC)

Which is partly why there are still some entries in this category. ShakespeareFan00 (talk) 14:55, 10 April 2019 (UTC)

Match and Split bot

Match and Split bot is not running. Is anyone able to check on it? With Phe's long absence and imminent admin removal, is this tool still maintainable? —Beleg Tâl (talk) 14:11, 11 April 2019 (UTC)

You may need to ask on frWS. Phe took the tool over from ThomasV when they moved on. It should be able to be taken over again by someone else. They need to have the right skillset and accesses, but that should be arrangeable. Beeswaxcandle (talk) 04:56, 12 April 2019 (UTC)

Wikimedia Foundation Medium-Term Plan feedback request

Please help translate to your language

The Wikimedia Foundation has published a Medium-Term Plan proposal covering the next 3–5 years. We want your feedback! Please leave all comments and questions, in any language, on the talk page, by April 20. Thank you! Quiddity (WMF) (talk) 17:35, 12 April 2019 (UTC)

Page disorder in Tales of my Landlord - 3rd series, vol. 1

Hello, In Index:Scott - Tales of my Landlord - 3rd series, vol. 1 - 1819.djvu, pages are not in the expected order: pages 65 and 66 are just after page 56. All pages are there, only 2 pages to move. If someone could help me in fixing the djvu, I'll move the 10 OCR. Thanks in advance. --M-le-mot-dit (talk) 14:00, 6 April 2019 (UTC)

Done. Nothing else is to be done.— Mpaa (talk) 20:21, 9 April 2019 (UTC)

Good. thanks, Mpaa. M-le-mot-dit (talk) 05:09, 13 April 2019 (UTC)

Wikidata items for works?

I know that some people like to create a Wikidata item for works they add to Wikisource, and I'm willing to do that for the contents of the magazines I'm adding here (at least the longer and less-ephemeral contents). Can anyone point me to a few good examples to show what information it is best to include in such items--some particularly full, complete, and correct examples hopefully? Levana Taylor (talk) 15:02, 13 April 2019 (UTC)

You may find it convenient to use Cradle to do so; it has a forms for various types, including one for "book edition". We can add "magazine " and/ or "magazine article" if you wish.

For examples of best practice, and other guidance and support, see d:Wikidata:WikiProject_Books, d:Wikidata:WikiProject Periodicals and d:Wikidata: WikiProject Source MetaData. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:54, 13 April 2019 (UTC)

Wikiproject:Books on Wikidata has rejected "book" and "book edition" as values. The term "book" can refer to a work, a published edition, or an instance of an individual physical object, so if Cradle is using "book" or "book edition" as a model, then it is presenting outdated information. --EncycloPetey (talk) 20:12, 13 April 2019 (UTC)

Also see: Wikisource:Wikidata and d:Wikidata:Wikisource. The former has some good examples, based on Treasure Island. In particular, note the distinction between works (instances of d:Q47461344 or one of its subclasses, generally associated with a {{Versions}} or {{Translations}} page on Wikisource) and editions (instances of d:Q3331189, generally associated with the proofread text on Wikisource). —Beleg Tâl (talk) 20:53, 13 April 2019 (UTC)

Thank you, all! I am going to read all those links and will comment more tomorrow or the day after. @Pigsonthewing: I very much like the idea of creating a form for magazine articles and have posted some very preliminary thoughts at Wikidata talk:Cradle. Levana Taylor (talk) 00:00, 14 April 2019 (UTC)

Copyright discussion

I am aware that we have Wikisource:Copyright discussions for discussions about texts already on Wikisource, but what about texts before they get added?

I recently found https://archive.org/details/lameprince00tolsiala/ that I wanted to add, but only after a lot of research have I thought otherwise due to when it could possibly have been published in the USSR (by Foreign Languages Publishing House between 1946 and 1964), when the author died (1945), copyright in Russia (life+70, making it under copyright in 1996), but then discovering that it was actually life+50 that was done retroactively in 1993 (Copyright law of the Soviet Union#Transition to post-Soviet legislation in Russia) making it PD in 1996.

I have since thrown out that entire paragraph of thinking as the translation was done semi-anonymously, where the copyright depends on when it was published, something I have no knowledge about. So is there a place to discuss this sort of conundrum, or for questions not answered by the existing documentation? -Einstein95 (talk) 08:40, 14 April 2019 (UTC)

WS:CV is fine for these discussions, but here is ok too. For the anonymous translation to have been PD in 1996, it would need to have been published prior to 1946 (1996 - 50). Since the publisher was founded in 1946, this seems unlikely to me. If we can't be sure it's PD, then we can't host it. —Beleg Tâl (talk) 12:39, 14 April 2019 (UTC)

Authors who lived and worked in the "Great Patriotic War" got an additional four years, which Alexei Tolstoy apparently did, which would push it past 1996, and thus restored to copyright in the US.--Prosfilaes (talk) 05:47, 15 April 2019 (UTC)

Tables with braces

Plutarch's Lives (Clough)/Preface and Life of Plutarch#pagenumber xxiii
Is there a better way to go about this table? Also yes, the braces switch directions on the 2nd page compared to the first. -Einstein95 (talk) 10:48, 14 April 2019 (UTC)

use {{brace2}} ? —Beleg Tâl (talk) 12:40, 14 April 2019 (UTC)

Well... I guess. -Einstein95 (talk) 23:27, 15 April 2019 (UTC)

In addition, you can use the "cell-padding" property to prevent the text of the columns from being right up against each other. Levana Taylor (talk) 19:16, 14 April 2019 (UTC)

Tech News: 2019-16

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

• All wikis now have the TemplateWizard for the wikitext editor.

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 16 April. It will be on non-Wikipedia wikis and some Wikipedias from 17 April. It will be on all wikis from 18 April (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 17 April at 15:00 (UTC). See how to join.

Future changes

• Wikidata will get a new constraint status called suggestion. This will change how the WikibaseQualityConstraints constraint checking API works. [16][17]
• You can test the depicts property for structured data on Commons.

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

23:00, 15 April 2019 (UTC)

Technical question about the <pages/> function

When using the <pages/> function, what causes the margin at the left and the appearance of the page numbers? All the function itself does is transclude the pages (from experimentation on a separate wiki). Dovi (talk) 10:19, 16 April 2019 (UTC)

@Dovi: it's MediaWiki:PageNumbers.js —Beleg Tâl (talk) 12:47, 16 April 2019 (UTC)

Thank you, Beleg Tâl! Dovi (talk) 03:06, 17 April 2019 (UTC)

Linking to Wikipedia, Commons etc.

I've been experimenting lately with {{wdl}} for making links to author pages, Wikipedia articles, Commons or Reasonator. It dynamically changes the target based on what's available, so it's easy to add the link (using a Wikidata ID) and to start with it'll link to Reasonator but then later when a Wikipedia article has been created it'll link there. Does this sound like a sensible thing? —Sam Wilson 06:02, 11 April 2019 (UTC)

@Samwilson: I'm having trouble seeing the use cases. Examples? --Xover (talk) 06:10, 11 April 2019 (UTC)

@Xover: Sorry, yeah I should have been more detailed. See for example Battle_of_Minderoo#pagenumber_5 where each person's linked goes to the most relevant page about them. It's basically aimed at saving time when proofreading and not wanting to go searching beyond Wikidata for a mentioned topic's other pages. Sam Wilson 06:19, 11 April 2019 (UTC)

@Samwilson: Hmm. Annotating identities, and possibly also other concepts, with Wikidata QID sounds like a good option to have, and that might be useful for some future fancy functionality (javascript gadget that can show some sort of popup/preview and links; automated analysis of interconnectedness of works; etc.). However, I am less convinced at the utility of linking to Wikidata and Commons in the body of a prose work. Even internal links to Author:, Portal:, and other mainspace works are to some degree controversial; and links to enwp are, I think, actively discouraged by some parts of the community (I disagree, but that's somewhat beside the point in this context).

However, for various reasons I spend a lot of time on digging up interwiki links, and something interactive that made it easy to look up (through the Wikidata index) what's available on various projects and pick the most appropriate one to insert would be very useful (big time-saver). In such a setting, using a template that's fed a QID and a project ID to generate a specific link would have certain advantages. It'd protect against linkrot when other projects (like enwp) moves stuff around (the iw at WD would reflect the move, and our link would automatically update). We could possibly give a "preferred order of links", so the link would show as to Author:Plato if it existed, to Portal:Plato if not, and to :w:Plato if neither one did; with automatic updates if Author:Plato was later created.

There might also be a case for using something like that for internal links to other works, at least where we have multiple editions and a versions page. In at least some cases, you might be more interested in the enwp article about the referenced work than the work itself. By taking the detour through a Wikidata QID for the work we might be able to offer such linking as an optional add-on functionality: a javascript gadget that adds a choice of links for the user to pick from (all the versions we list, plus any enwp article about the work, plus possibly a relevant category or set of files on Commons, and the Reasonator link).

In any case, I do see some potential utility here; but I think maybe it lives somewhere around the functionality it enables, and not the template itself. For example, what would take me the most time in the scenario you describe is probably finding the QID itself, not the link to enwp (Google gets you there pretty fast) or our Author: page (linked from enwp). In other words, for that scenario, enwp is a better source for this than Wikidata in practical use. --Xover (talk) 06:57, 11 April 2019 (UTC)

@Xover: We could definitely add edition-of traversal as a next-level fallback. As you say, it'd be good to be able to link to an edition's Wikidata ID and for the link to go to that work's page on Wikipedia, and then when the edition has been added to Wikisource the link would change to that. I'll add a todo. Oh, and at the moment it supports Portals as well, or rather it just looks for any link from the Wikidata item to Wikisource and uses it. —Sam Wilson 01:14, 12 April 2019 (UTC)

@Samwilson: if you are looking to put such links in text, you need to make sure it falls within our annotations guidelines. Links within English Wikisource aren't considered annotations, but if they fall back to Wikipedia or Wikidata then they are annotations and should be treated accordingly.—If you are looking to put such links in the header, do you intend to integrate this with {{plain sister}}? —Beleg Tâl (talk) 12:30, 11 April 2019 (UTC)

@Beleg Tâl: Yes, within works and not in the header. I totally understand not wanting to add extraneous annotation, and so far I've only used this on works such as letters and diaries, which are more about 'reference' than 'reading'. Do you think this is okay? It's annotation, certainly, but mostly of the names of people and places and so maybe less likely to be controversial. I feel like it's different from e.g. the links we've got in some novels here to Wiktionary. I'm making sure not to add them to just any work. —Sam Wilson 01:14, 12 April 2019 (UTC)

@Samwilson: the current consensus is that if you have an edition with these external annontations, then you also should have a separate unannotated edition as well. —Beleg Tâl (talk) 14:10, 12 April 2019 (UTC)

@Beleg Tâl: I'll make sure I do this for all the ones I've been experimenting on. —Sam Wilson 01:18, 13 April 2019 (UTC)

@Samwilson: I've just stumbled upon {{annotation header}} which might be useful to you —Beleg Tâl (talk) 16:29, 17 April 2019 (UTC)

I like it. Such links should be inline, and can be styled to display or not, acording to community (and individual) preference. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:12, 11 April 2019 (UTC)

I haven't really thought about styling them differently; that's a good idea. They're wrapped with the module-wikidata-link class, so could easily be styled. —Sam Wilson 01:14, 12 April 2019 (UTC)

The Hunchback of Notre Dame

I think, the title of this book is wrong. All editions of Isabel F. Hapgood's translations that I found have title "Notre-Dame de Paris" (eg. 1888/1, 188/2, 1891 (with first chapter starting sentence being: Three hundred and forty-eight years, six months...).

The title "The hunchback of Notre-Dame" is used by other translations:

• Henry L. Wiliams, Jr's (It is to-day three hundred and forty-eight years...)
• Frederic Shoberl's (?) (It is this day three hundred and forty-eight years...)
• anonymous (On the 6th of January 1862 the Parisians...)

I think this is worth to be fixed before we start propagating incorrect info via Wikidata. Any idea how to fix this? Just rename? The text seems to originate from Project Gutenberg, but it is unclear which edition exactly. Ankry (talk) 16:53, 18 April 2019 (UTC)

The Gutenberg text is titled "Notre-Dame de Paris, also known as The Hunchback of Notre Dame". As an older Gutenberg text, it's probably a composite of various different editions. —Beleg Tâl (talk) 17:11, 18 April 2019 (UTC)

For Wikidata, I'd probably consider The Hunchback of Notre Dame to be itself an edition of Hapgood's translation with the title "The Hunchback of Notre Dame". It doesn't correspond to a printed edition, so it doesn't matter. It would be better to pick a good edition and replace our copy with it. —Beleg Tâl (talk) 17:14, 18 April 2019 (UTC)

I can even see that it was allegedly published in 1831, but the translator was not even born in that time... --Jan Kameníček (talk) 18:15, 18 April 2019 (UTC)

1831 is the publication date of the original French work. —Beleg Tâl (talk) 18:44, 18 April 2019 (UTC)

OK, so I created: Index:Victor Hugo - Notre-Dame de Paris (tr. Hapgood, 1888).djvu.

Also if someone interested in another translation: Haynes (1902), Shoberl (1833). Ankry (talk) 21:14, 19 April 2019 (UTC)

Constitution of Macedonia

Should AMENDMENT XXXIII to AMENDMENT XXXVI be added to the text? An administrator has stopped me to do so.--Mike Rohsopht (talk) 05:06, 20 April 2019 (UTC)

@Mike Rohsopht: As said by @EncycloPetey, "please create a new document under another name". This means you should make a page with the text of the new document under the name Constitution of North Macedonia, not move the existing document to that title. This means that people can compare and contrast the two documents. -Einstein95 (talk) 08:10, 20 April 2019 (UTC)

Any Commons admins?

Are there any Commons admins here? I'm trying to get help at commons:Commons:Administrators' noticeboard, and have been waiting over half an hour for a simple bit of file move help. I can't proceed with adding the related data, creating Wikidata entries, or setting up Index pages until the files are renamed, and I need an Admin to do this move. --EncycloPetey (talk) 01:38, 2 April 2019 (UTC)

I can't help with the double file move, but I think one of your targets is wrong. Sonnets moving to Romeo and Juliet? Beeswaxcandle (talk) 02:37, 2 April 2019 (UTC)

Nope. The targets are 100% correct. The Romeo & Juliet file was mistakenly uploaded as "Shakespeare's Sonnets", and the Sonnets file was mistakenly uploaded as "Romeo and Juliet". I can't swap the files myself because I can't overwrite an existing target. I can't correct the problem through a re-upload because it would detect a duplicate file. I can't just choose alternative names because these are part of a series. I temporarily moved one of the files so that the swap could proceed, but cannot complete the swap for the same reasons mentioned above. --EncycloPetey (talk) 02:45, 2 April 2019 (UTC)

Done Thanks to User:Jusjih. --EncycloPetey (talk) 17:43, 2 April 2019 (UTC)

For future reference, our Commons admins are Jusjih, Billinghurst and myself. Hesperian 03:06, 15 April 2019 (UTC)

Yann is also an administrator here and on Wikimedia Commons.--Jusjih (talk) 02:40, 23 April 2019 (UTC)

Template modification request: Roman numerals for article link

I hate to keep bringing up the exact same topic repeatedly, but since my previous two posts, one month ago and two months ago, got replies from exactly one person in total, here goes. Back in February I requested a parameter for {{article link}} that would display volume numbers as Roman numerals. ShakespeareFan00 was kind enough to create one in the sandbox, but it has not been implemented; and no one else has commented on the proposed change. Would people please comment and say whether you think this would be good to implement? Thanks. Levana Taylor (talk) 18:44, 16 April 2019 (UTC)

Go for it —Beleg Tâl (talk) 13:20, 17 April 2019 (UTC)

Thanks for the support, but who is going to actually do the implementation? Levana Taylor (talk) 19:45, 19 April 2019 (UTC)

You can, if you like. Or ShakespeareFan00 can copy their sandbox implementation into the main template. Or any other editor who is able and willing. —Beleg Tâl (talk) 11:40, 20 April 2019 (UTC)

@Levana Taylor, @Beleg Tâl: Done -Einstein95 (talk) 11:43, 22 April 2019 (UTC)

Thanks! I have added it to the documentation. Levana Taylor (talk) 19:07, 22 April 2019 (UTC)

Using TemplateStyles to achieve Semantic HTML

Last August, I mentioned the possibility of introducing TemplateStyles, so that we may use the appropriate HTML tags while emulating the appearance of the original text. The discussion was not particularly impressive.

I have been using TemplateStyles on a personal MediaWiki+ProofreadPages installation, and I do believe that TemplateStyles would be greatly beneficial to Wikisource.

For example, an unordered list is emulated in this page of the Mueller Report using a table (!!!). We can do better than this. There's especially been hubbub about how the original PDF is unaccessible. We can and should apply CSS to a * list, in order to change the bullets into hyphens.

My setup features a template that is manually transcluded on all Page:s, as well as pages that transclude Page: content using the <pages /> tag. I don't know if anyone has any other ideas.

Suzukaze-c (talk) 01:58, 22 April 2019 (UTC)

@Suzukaze-c: Yeah, that was a horrid fix for making the list look like that from me (I still hate it). I have changed it to use {{bulleted list|list_style=list-style: "-  ". The &nbsp; are there as the symbols have no right padding. -Einstein95 (talk) 11:22, 22 April 2019 (UTC)

ia-upload bot

It appears that ia-upload has been giving a 503 Service Unavailable error for a few days now. @Phe, @Samwilson, @Tpt are the maintainers listed on that page, so hopefully one of them can do something about this. iirc there was talk about it being on a different server as a recent ImageMagick update broke jp2 conversion. Does that have something to do with it? -Einstein95 (talk) 11:57, 22 April 2019 (UTC)

Wikilivres is dead?

The web page does not load for me, and hasn't for a while now. Anyone know if it's gone for good? —Beleg Tâl (talk) 17:45, 22 April 2019 (UTC)

I've had slow responses in the past week, but I can still access their site. It's not slow for me today, at least. --EncycloPetey (talk) 17:59, 22 April 2019 (UTC)

That's probably it then. My network connection is slow here; if it's faster now then there might be something going on locally. —Beleg Tâl (talk) 18:08, 22 April 2019 (UTC)

I easily and quickly access Wikilivres. It is live well.--Jusjih (talk) 02:42, 23 April 2019 (UTC)

Links to scan pages missing

I have noticed that only 3 out of 19 pages of Siberia and the Exile System/Volume 2/Index (page no. 557, no.561 and no. 571) appear in the left margin. What can this be caused by? --Jan Kameníček (talk) 20:27, 14 April 2019 (UTC)

@Jan.Kamenicek: Without digging too deeply into it, I would guess it is either a variant of the problem discussed in WS:S/Archives/2018-08#Page numbers borked with hyphenated words or a variant of that problem caused by the pages being just one long table (see the older discussion linked from the 2018 discussion). I had intended to pursue a possible workaround, but there seemed to be little interest and quite a bit of general cleanup needed to the scripts before such workarounds could be safely tested (which is right now hampered by there not being any Interface Administrators on enWS, and no process for getting anybody assigned the bit, cf. #A process and policy for Interface Admins below). --Xover (talk) 04:37, 15 April 2019 (UTC)

My experience is that the appearance of this problem varies by OS and browser, so it may not be a simple a fix. --EncycloPetey (talk) 04:42, 15 April 2019 (UTC)

@EncycloPetey: I tried it with Firefox and Chrome and then again from a different computer at a different place again with Firefox and Chrome (and I suppose the versions of browsers are different although I did not check them at the previous one), and the problem is the same. --Jan Kameníček (talk) 06:10, 15 April 2019 (UTC)

When I have encountered this problem, I have sometimes found that Firefox on a Mac versus Chrome on a PC can yield different results. --EncycloPetey (talk) 14:19, 15 April 2019 (UTC)

Repaired, by checking the formatting for the table used. ShakespeareFan00 (talk) 14:48, 23 April 2019 (UTC)

Report On The Investigation Into Russian Interference In The 2016 Presidential Election

page 49 [18] and page 100 [19] have a link to youtube on the spam list. please white list these links. -- Slowking4 ‽ SvG's revenge 02:46, 19 April 2019 (UTC)

I am supporting the request. I think Billinghurst has the rights to perform black- and whitelisting at meta.wiki. Is there anything that could be done about this? --Jan Kameníček (talk) 20:17, 22 April 2019 (UTC)

youtube.com/watch?v=3kxG8uJUsWU and youtube.com/watch?time_continue=28&v=1CYF29saA9w. - blocking links to c-span? maybe time to revisit the blacklist? - Slowking4 ‽ SvG's revenge 14:25, 23 April 2019 (UTC)

The blacklist it likely OK; just an admin is needed to whitelist the links here. Ankry (talk) 15:29, 23 April 2019 (UTC)

Done, thanks for the link —Beleg Tâl (talk) 17:14, 23 April 2019 (UTC)

thank you. you might call a blanket filter of all youtube OK, i do not. we have ORES functionality, to discern better what is a useful link and what is not. here we have the US DOJ hitting a filter, preventing the saving of a page, with no feedback or graceful fallback. the fact that some prefer a "admin may i" process, is telling. this is everything some of us were arguing against at the EU. Slowking4 ‽ SvG's revenge 20:22, 23 April 2019 (UTC)

Tech News: 2019-17

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 advanced search function URL now shows which namespaces you search in. The namespace field is collapsed by default on the search page. You can also add new fields to the search interface through a hook. [20][21][22]
• The wikis now look slightly different in the mobile web version. [23]

Changes later this week

• There is no new MediaWiki version this week.

Meetings

• You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 23 April at 15:00 (UTC). See how to join.

Future changes

• Wikipedia articles will have the sameAs meta property. It adds structured data. This makes it easier for search engines to find Wikipedia articles. It also makes it easier to reuse content. There will an A/B test. [24][25]

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

19:08, 23 April 2019 (UTC)

Building an ersatz scanning table

This blog post may be of interest: "Building an ersatz scanning table". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:25, 23 April 2019 (UTC)

Wow. Love it! :) -Pete (talk) 22:12, 23 April 2019 (UTC)

Please import w:en:Template:Doi

Thanks. —Justin (koavf)❤T☮C☺M☯ 02:44, 24 April 2019 (UTC)

Why? Where would this be used? Any work can have its DOI added to its Wikidata item, and the DOI will then appear when {{authority control}} is place on that work's page. Why do we need an additional template to do the same thing? --EncycloPetey (talk) 02:56, 24 April 2019 (UTC)

On the work's notes in the {{header}}. If authority control is a better method, then I'm all for that. —Justin (koavf)❤T☮C☺M☯ 03:04, 24 April 2019 (UTC)

The problem I see with having the {doi} template here, is that it will be used all over Author pages in ways that it shouldn't. The {{authority control}} can provide all ID information for a work, and allows us to store it all those IDs at Wikidata, so that the information available everywhere. --EncycloPetey (talk) 03:09, 24 April 2019 (UTC)

Doesn't appear to be working: Fabella prevalence rate increases over 150 years, and rates of other sesamoid bones remain constant: a systematic review. —Justin (koavf)❤T☮C☺M☯ 03:52, 24 April 2019 (UTC)

@Koavf: For some reason I can't quite grasp just now, the template doesn't work when included in the header template. When used at the end of the page (as per the documentation) it does work. --Xover (talk) 05:11, 24 April 2019 (UTC)

Brilliant! —Justin (koavf)❤T☮C☺M☯ 05:34, 24 April 2019 (UTC)

class="prose"

Does anybody know, why <div class="prose"> works well in the Page namespace and in my sandbox too, but does not work in the main namespace? --Jan Kameníček (talk) 21:42, 24 April 2019 (UTC)

@Jan.Kamenicek: What is it you are expecting <div class="prose">…</div> to do? And what is the effect you are using it to achieve? --Xover (talk) 04:28, 25 April 2019 (UTC)

@Xover: I am expecting that it would make the text narower, so that the picture in the top left did not overflow out of the left margin. Above I provided links to my sandbox, where it is much narower and the picture is displayed well, and to the page of the work, where it is not. I used this class following the advice given in the documentation of the template {{Overfloat left}}. --Jan Kameníček (talk) 05:58, 25 April 2019 (UTC)

@Jan.Kamenicek: It works in the Page: and User: namespaces because Dynamic Layouts are not enabled there. In mainspace the script that implements dynamic layouts will unconditionally remove any class="prose" (and several other effectively obsolete CSS classes) so these will never work there. The way to achieve a constrained right margin (actually a maximum width for the text column, I believe) in light of Dynamic Layouts is to use {{default layout|Layout 2}} on the mainspace page. The documentation for {{overfloat left}} is, in other words, incorrect; but I'm not sure how to fix it off the top of my head. Note also that what {{overfloat left}} does is by nature fragile (prone to breaking) so some care is warranted when it is used. If the issue is just the one image, would it not perhaps be an acceptable compromise to simply left align it within the same column as the text? Not a perfect reproduction, but more than close enough for our purposes. --Xover (talk) 06:30, 25 April 2019 (UTC)

Thanks very much both for the solution and explanation.

I was also thinking about having the picture in the text column. However, it looks good the way it is now, and if the display of this only picture got broken in the future, it would not make any harm to the text until somebody would repair it. So I would slightly prefer to leave it as it is now. --Jan Kameníček (talk) 06:39, 25 April 2019 (UTC)

Mueller Report - more hands on deck?

All, I have been watching the progress on transcribing the much-anticipated "Mueller Report," a document of tremendous interest in U.S. politics. Kudos to all those who have been working on it. I've also heard numerous reports of for-profit sales of the report (for instance, here and here). I think this is a great opportunity to demonstrate the value of Wikisource. It's not the easiest transcription, what with all the redactions and footnotes; but I think it would go more smoothly with more people involved. So this is my plea to others to join in...and also, my reminder to myself to do more! -Pete (talk) 23:02, 24 April 2019 (UTC)

i might be motivated to do more, if it weren’t threatened with deletion. Slowking4 ‽ SvG's revenge 10:49, 25 April 2019 (UTC)

It is not threatened, for the following reasons:

• It is not the whole document that was nominated for deletion, only some pictures from the document were asked to be removed
• If you look at the nomination page, there is strong opposition against the removal and no support.
• Even if the document or its parts were removed from Commons, it does not mean that the proofread text at Wikisource has to removed as well. The text can stay here even if it were not backed up by the pdf from Commons. What is more, we can even consider the possibility of hosting the pdf document here at WS, where the rules are not that strict. --Jan Kameníček (talk) 14:24, 25 April 2019 (UTC)

• someone will have to do the work of blanking out the images, or the whole book will be deleted. and then they will argue about the large blocks of quoted text.
• don’t be complacent, books with questioned images are routinely deleted. votes do not count. the admins do not consider the impact on others. i.e. [26]
• books are then routinely up for deletion here, after being deleted there, i.e. Wikisource:Copyright_discussions#Page:American_Seashells_(1954).djvu/1_and_others
• no consensus for fair use here, the rules are just as strict, see also Wikisource:Scriptorium/Archives/2016-10#Exemption_Doctrine_Policy_(EDP) -- Slowking4 ‽ SvG's revenge 16:56, 25 April 2019 (UTC)

Thank you, I had not noticed that nomination (Here's the link for easy reference). Regardless of how that decision comes out, a transcription will have value, and if necessary, can readily be attached to a version of the PDF with the three images blanked/blurred out. I agree that we should adopt an Exemption Doctrine Policy here at Wikisource, but for the time being, we don't have one. -Pete (talk) 20:20, 25 April 2019 (UTC)

Thanks, Pete, Jan Kameníček and Slowking4. We are doing good stuff. I edit a few pages a day and I will keep going. It'a a big project -- 448 pages, not OCR'd, 1100 footnotes, various indentations, text enhancements, photos, precise misspellings in tweets, Russian words, four kinds of redactions, odd legal-text characters, etc, etc. I did invite a large list of acquaintances to participate in this project. I got lots of positive feedback -- "you're doing great! let me know when it's done!" But not actual help. Ha ha! So it goes -- we are the heroes. Thanks for the encouragement. We keep going. -- econterms (talk) 20:42, 25 April 2019 (UTC)

Move titles of History of Mexico series

I think Vol 3 History of Mexico by H H Bancroft and Vol 4 History of Mexico by H H Bancroft should be moved to History of Mexico (Bancroft)/Volume 3 and History of Mexico (Bancroft)/Volume 4 respectively, but figured I'd better check here first. -Pete (talk) 19:01, 23 April 2019 (UTC)

@Ineuw: -- Slowking4 ‽ SvG's revenge 12:12, 25 April 2019 (UTC)

Thanks Slowking, I should have thought to ping Ineuw when first posting. -Pete (talk) 20:22, 28 April 2019 (UTC)

Tech News: 2019-18

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 Wikipedia app for Android now invites users to add Wikidata descriptions to Wikidata objects that have Wikipedia articles but no Wikidata descriptions. It will only invite users who have added a number of Wikidata descriptions in the app without being reverted. This is to avoid spam and bad edits. [27][28]

Problems

• Tech News was late last week because of a MassMessage bug. Other newsletters had the same problem. [29]

Changes later this week

• You will see when you last refreshed the recent changes page. This is so you can see how recent the changes are. [30]
• When you write a comment in Structured Discussions but have not posted it yet your web browser will save it in local storage instead of session storage. This means you do not lose them even if you close your web browser. Structured Discussions used to be called Flow. [31]
• You will be able to turn off milestone notifications. Milestone notifications congratulate you when you have made certain numbers of edits. [32]
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 30 April. It will be on non-Wikipedia wikis and some Wikipedias from 1 May. It will be on all wikis from 2 May (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 1 May at 15:00 (UTC). See how to join.

Future changes

• The Wikidata wb_terms table will be dropped. This will affect some Wikidata tools. They need to be updated. The table has become too big which is causing problems. This will happen on 29 May. You can read more. You can ask for help if you need it.
• Wikimedia wikis will soon use a token when you log out. This changes how the API works. Some tools might need to be updated. [33]

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

22:28, 29 April 2019 (UTC)

{{iwpages}} issues

@Billinghurst, @Beleg Tâl: According to your earlier interest in this matter, just FYI: I have changed behaviour of the underlying script making from- / tosection parameters optional again. Breaking backward compatibility by earlier changes was IMO a bad idea. The template can be used now as:

• {{iwpages|language code|Title of the Index page|page_from|page_to}}
• {{iwpages|language code|Title of the Index page|page_from|page_to|section_from}}
• {{iwpages|language code|Title of the Index page|page_from|page_to||section_to}}
• {{iwpages|language code|Title of the Index page|page_from|page_to|section_from|section_to}}
• {{iwpages|language code|Title of the Index page|page_from|page_to|||section_only}}

Ankry (talk) 06:57, 30 April 2019 (UTC)

Content added to translation not in the original

What is the general Wikisource policy for adding content to an English translation not present in the original? In the following case, this appears to have been done in order to make a translated source easier to navigate. Does that justify adding original research to an article?

The English translation of the German Constitution contains article titles not present in the original German, which contains only article numbers. For example: where the German original has article section headers like Artikel 2, the English translation has Article 2 [Personal freedoms]. The text "Personal freedoms" must have been added by a wikisource editor, and is their original interpretation of what Article 2 is about.

I've checked the Wikisource archives, and although there are several discussions about translation, I didn't find anything related to this. (Additional details at Talk:Basic Law for the Federal Republic of Germany#Material not in original source. )

In my opinion, original content should not be embedded in a translated source, even bracketed, and even to make it easier for English users to navigate. Like any translation, a translated source in Wikisource should faithfully represent the original, as much as possible. If I discover that material has been added, it immediately makes me suspect what else has been altered, and my confidence in the entire article goes down and I wonder if it's reliable at all.

But I wouldn't be opposed to adding additional, non-embedded material that clearly stood apart from the translated content in some way, so that it was clear that it did not represent part of the translated source, either via appendixes, subpages, or other method that was clearly separate.

For example, in a case like the translated German Constitution, I think one could create a subpage containing the additional article descriptions (like "Personal freedoms" for Article 2) in the form of an external table of contents, which could be used to navigate into the translated article. Alternatively, one could create a supplementary page to the translated source page, which would contain the helpful ToC and then transclude the entire existing Wikisource page, and call it "Supplement to Basic Law for the Federal Republic of Germany with table of contents" or some such, with a "See also" section in the main translated source linking to the supplement page. That seems like it would be acceptable and useful compromise, as the "supplement" page could explain that the ToC at the top contained original Wikisource material added in order to make the translation easier to navigate and understand. I may work on a mockup of this so people have something concrete to look at.

In the meantime, I wonder what others think about this? I think Wikisource should have a clear policy stating that embedded original research is prohibited (whether a translation or not). Also, what's the consensus process here, are there Rfc's as in Wikipedia, or how does it work? Thanks, Mathglot (talk) 19:15, 30 April 2019 (UTC)

@Mathglot: Our policy is that hosted material is to be preserved as published. The article section headers on Basic Law for the Federal Republic of Germany were not added by Wikisource editors; they were added by the original translators (Federal Ministers of the Interior, Justice and Finance, July 1991) and therefore must be preserved on Wikisource. —Beleg Tâl (talk) 20:03, 30 April 2019 (UTC)

not interested in a policy disallowing "original research" of translators. we have a hard enough task merely reflecting what the translators wrote. and which constitution? where is the scan? citation needed. Slowking4 ‽ SvG's revenge 02:14, 1 May 2019 (UTC)

I'm not certain I understand your question, but I think I do. It seems to me (as Beleg Tal suggests) Wikisource's purpose is to provide a faithful representation of something that was published. In this case, that thing that was published was the 1991 translation of the constitution. So any annotations that were in the 1991 translation should be preserved, without comment (except for the general metadata reflecting what edition has been transcribed).

We often host multiple different editions on Wikisource, and directing the reader to the original German on German Wikisource (if it exists) is a good thing to do, too.

Ideally, a work like this should be converted to a page-backed format, in which there is a DJVU file or PDF of the original, and each page of transcription can be viewed side-by-side with the original. This would help the reader verify and establish confidence.

Regarding RFC's, I think it's possible to do something more formal like that here, but it's rarely necessary. This is a much smaller community than Wikipedia, and many editors keep an eye on the Scriptorium; usually, a less formal discussion right here is plenty. -Pete (talk) 03:15, 1 May 2019 (UTC)

@Mathglot: As Beleg Tâl wrote, "the original" in this case isn't the German text of the law published by the Bundestag, it is the translated English text also published by the Bundestag. The explanatory pseudo-titles were introduced by the Bundestag's translators, not the Wikisource editors who subsequently transcribed the translation, and preserving them here is the correct approach (in fact, removing them would be against policy).

However, I notice that the document is just a transcription of unknown provenance. Works on Wikisource should ideally be scan-backed: a DjVu or PDF with a OCR text layer is uploaded to commons; a page in the Index: namespace collects various metadata about the work; individual pages are transcribed on subpages in the Page: namespace; and finally the individual pages are transcluded (sort of like if pages were templates) into mainspace. This enables two crucial things relevant to the concern you raise: each page is checked side-by-side against the scan of the original, and each page is first "Proofread" (transcribed) by one editor and then "Validated" by a second editor to ensure quality and accuracy.

If you are interested in this document, I would encourage you to try to remedy this situation. We could upload the 2018 (publ. date not amendment date) edition of the law to commons and set up the Index for it here, and then you could reuse (cut&paste) the existing transcription's text where the text of the law or its formatting hasn't changed. Once done the existing text on Basic Law for the Federal Republic of Germany could be replaced with the wikicode to transclude the transcribed text from the pages in the Page: namespace.

For a case such as this it may also be worthwhile to consider transcribing every published amended edition of the law (parenthetical disambiguation in the title): most of the text and formatting of each edition is likely to be identical and can easily be reused, and having all editions available allows easy lookup and comparison. It's not an insignificant amount of work, but with the level of reuse it's nowhere near insurmountable either. --Xover (talk) 07:57, 1 May 2019 (UTC)

@Xover: The provenance of Basic Law for the Federal Republic of Germany is not entirely unknown. Here is the original published version. Naturally, we will need to confirm that the English translation is free from copyright restrictions in the US (the original German is covered by {{PD-EdictGov}}). In Germany the translation is explicitly copyrighted by the German Bundestag. —Beleg Tâl (talk) 13:53, 1 May 2019 (UTC)

@Beleg Tâl: I didn't specifically look into copyright issues for this work, but did notice the claim of copyright. However, this cannot possibly be a valid claim: this is the official translation of the law into English. IANAL, but I can think of no legal theory by which they could circumvent com:PD-GermanGov for this. A third-party independent translation, sure, but not their own publication of a law in a different language. In any case, yes, like all works we do obviously need to make sure the copyright and licensing is compatible with Wikisource policy. --Xover (talk) 14:46, 1 May 2019 (UTC)

@Xover: I'll take it to WS:CV. —Beleg Tâl (talk) 14:50, 1 May 2019 (UTC)

ws_ocr_daemon robot is not running

How can I activate this when it's not running? — Ineuw talk 11:26, 23 April 2019 (UTC)

I'd like an answer to this question too. My browser is Safari (Mac). - --kathleen wright5 (talk) 02:57, 14 May 2019 (UTC)

Is this possibly the same problem as described in phabricator:T223012? Sam Wilson 05:05, 14 May 2019 (UTC)

@User:Samwilson, @User:Kathleen.wright5. That's right. See: Wikisource:Administrators'_noticeboard#Requesting_the_activation_of_the_OCR_daemon. --Dick Bos (talk) 09:03, 22 May 2019 (UTC)