Wikisource:Scriptorium/Archives/2018-12

Other discussions

Placing template for globally locked accounts

Hi, I am looking to comment regarding locked accounts (with same edits as well). Today I have created template on EN Wikisource: {{Locked global account}} which should be placed on currently locked accounts. Thanks! 109.102.201.49 11:46, 1 December 2018 (UTC)

comment you should have sought a consensus before doing that. i suggest that importing this drama is disruptive. i look forward to deleting this template and an ip block. Slowking4 ‽ SvG's revenge 15:53, 1 December 2018 (UTC)

That template does not appear to serve any useful purpose. --Mukkakukaku (talk) 18:01, 2 December 2018 (UTC)

Discussion at Wikisource:Proposed_deletions#Template:Locked global account. --EncycloPetey (talk) 21:05, 2 December 2018 (UTC)

Granularity on progress color bar?

As I look at the progress color bar at top of The_Sea_Lady it looks completely green, even though (at the moment) there are 24 out of 300 text pages not validated. I check the (HTML) page source and see

<td class="quality4" style="width:100%;"></td>

meaning "completely validated".

Playing with counts of pages, including or discarding empty pages and/or non-text pages, I keep coming up with a figure of 92% or 93% validated. Yet we see a 100% complete green bar.

Is the color bar computed using some large granularity? Like 10% increments? That would produce such a mistaken impression as 'done' with dozens as yet unvalidated?

(Or is this similar to Microsoft's version of a progress bar, that says 100% for the last 20 minutes of some process, or worse, goes backward!) Shenme (talk) 03:33, 2 December 2018 (UTC)

The bar you are looking at is only for the pages currently displayed, which consist solely of the front matter. The progress bar indicates progress only of pages transcluded to the particular page title you are currently viewing, and the front matter has been completely validated. The unvalidated pages are from end chapters of the work. --EncycloPetey (talk) 04:39, 2 December 2018 (UTC)

Tech News: 2018-49

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

• Admins will not be able to unblock themselves if they are blocked by someone other than themselves. This is because it can cause damage if someone else takes over an admin account and other admins can't block them. If this is a problem for your community you can report it on Phabricator. You can also ask questions on Meta. There is a discussion on Phabricator about how to solve this if two admins fight with each other on a small wiki. [1]
• Small SVG images are now bigger when you see them in MediaViewer. [2]
• You can go to a section from the edit summary by clicking on the section name. Before this you had to click on the arrow. [3]
• When you jumped to a footnote that was referenced several times in an article it could be difficult to see where you were in the text. Now there are jump marks and highlights to help you find your way back. [4][5]

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 5 December at 16:00 (UTC) and at 23: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:12, 3 December 2018 (UTC)

E. P. Robins

Can we find evidence either to confirm or to reject my suspicion that the E. P. Robins who translated the current PotM, Tales of To-day and Other Days, is Elizabeth Robins Pennell? She seems to be in the right period, and the right sort of person, a prolific writer, and was known to write under noms-de-plume, including jumbled up versions of her name. --EncycloPetey (talk) 20:37, 3 December 2018 (UTC)

An E.P. Robins (can't say whether the same) published several other translations from the French during the same time period, with different publishers. Présence de Stendhal aux Etats-Unis p. 87 has a brief discussion about the identity of the translator which you might view here if Google Books is willing to play nice, they only appear to narrow it down to an American. It might be circumstantially interesting to compare the rate of Pennell's known output of work with the years of the translations published under that name and see if she has a lull at the right time. I've hopelessly lost the link now but the US copyright catalog in which Tales of To-day and Other Days was registered listed the publishing company as the party, so no help there, but maybe looking up other works under the name may provide information. Prosody (talk) 00:23, 4 December 2018 (UTC)

That helps a little. The fact that the translations were published in London, but that the translator used Americanisms, does fit with my suspicion. Elizabeth Robins Pennell was an American, but spent most of her life in London. --EncycloPetey (talk) 01:05, 4 December 2018 (UTC)

The author also appears to have published a few translations under the name "E. P. Robbins" -Einstein95 (talk) 04:07, 5 December 2018 (UTC)

Selection of the Wikisource Community User Group representative to the Wikimedia Summit

Dear all,

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

The Wikisource Community User Group could send one representative to the Wikimedia Summit 2019 (formerly "Wikimedia Conference"). The Wikimedia Summit is a yearly conference of all organizations affiliated to the Wikimedia Movement (including our Wikisource Community User Group). It is a great place to talk about Wikisource needs to the chapters and other user groups that compose the Wikimedia movement. For context, there is a short report on what happened last year. The deadline is short and to avoid the confusing vote on the Wikisource-I mailing list of last year, we created a page on meta to decide who will be the representative of the user group to the Wikimedia Summit.

The vote will be in two parts:

1. until December 7th, people can add their name and a short explanation on who they are and why they want to go to the summit. Nomination of other people is allowed, the nominated person should accept their nomination.
2. starting December 7th, and for a week, the community vote to designate the representative.

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

For the Wikisource Community User Group, Tpt (talk) 15:15, 5 December 2018 (UTC)

Author linked to Wikispecies

Author:Cyrus Thomas is linked to Wikispecies in the Sister projects section and the text of the link is "taxonomy", which does not seem appropriate for an author. Is it possible that the text was different for links from author pages? --Jan Kameníček (talk) 20:17, 5 December 2018 (UTC)

Since it's the {{author}} template, I assume it should always be text relevant for an Author page. --EncycloPetey (talk) 20:35, 5 December 2018 (UTC)

The link is from the {{plain sister}} template within the Author header, so it is possible to be different when transcluded in other namespaces. As it happens, however, it is not different. —Beleg Tâl (talk) 21:47, 5 December 2018 (UTC)

None of the names change depending on the namespace. The code responsible for the issue is line 13 in Module:Plain sister. -Einstein95 (talk) 03:13, 6 December 2018 (UTC)

If it is not possible to change the text depending on namespace, maybe a different text could be chosen instead of "taxonomy", e. g. "Wikispecies page". --Jan Kameníček (talk) 07:58, 6 December 2018 (UTC)

New Wikimedia password policy and requirements

The Wikimedia Foundation security team is implementing a new password policy and requirements. You can learn more about the project on MediaWiki.org.

These new requirements will apply to new accounts and privileged accounts. New accounts will be required to create a password with a minimum length of 8 characters. Privileged accounts will be prompted to update their password to one that is at least 10 characters in length.

These changes are planned to be in effect on December 13th. If you think your work or tools will be affected by this change, please let us know on the talk page.

Thank you!

CKoerner (WMF) (talk) 20:02, 6 December 2018 (UTC)

Tech News: 2018-50

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

Changes later this week

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

Future changes

• New accounts will need passwords that are at least 8 characters long. Admins, interface admins, bureaucrats, oversighters, CentralNotice admins, global renamers, check users, stewards and some other user groups will need passwords that are at least 10 characters long. This is because an attacker could cause damage to the wikis if they took over these accounts. [6][7]
• When you hover over a footnote it will show you the reference as a pop-up. This is so you don't have to jump down to the bottom of the page to see a reference. This will happen in 2019. Some wikis already have gadgets that do this. You will be able to turn it off. [8]

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

17:33, 10 December 2018 (UTC)

SpokenWikipedia

It was suggested by Cygnis insignis (talk) that I post here to let folks know I am doing this.

I used to do a lot of work on the SpokenWikipedia project. That project isn't very active anymore. Lately I've been more interested in recording Wikisource text, specifically short stories. I've had a lot of fun with the old sci-fi magazines. Some examples: The Mentanicals, The Carnivore. I have no idea if anyone is interested in hearing these recordings, but I enjoy doing them even though they often take a long time.

Now that I've introduced myself, there is an open issue for me over at Index talk:Democracy in America (Reeve, v. 1).djvu, if anyone can help. That is, if collectively we do want spoken stuff on Wikisource. PopularOutcast^talk2me! 14:11, 12 December 2018 (UTC)

If you have an issue for discussion, then please post it here. Wikisource is a small community, so our discussion in centralized. Hosting a discussion in the Talk page of a DjVu scan is a weird place to discuss audio files, especially since the issue is not about the scan. --EncycloPetey (talk) 14:30, 12 December 2018 (UTC)

Okay, thanks for the heads up. PopularOutcast^talk2me! 16:57, 12 December 2018 (UTC)

PopularOutcasttalk2me! 23:42, 12 December 2018 (UTC)== Spoken sources ==

Copied from Index talk:Democracy in America (Reeve, v. 1).djvu where I posted by mistake.

I need some help. I created a spoken version of the first chapter (so far) and have no way of adding it to the Chapter 01 page. Generally, the {{listen}} tag goes in the notes parameter of the {{header}} template. If I add {{listen}} above or below the <pages> code, the listen gadget is placed where it does not look good. My understanding of the header parameter of the <pages> tag is that it can choose between different styles of header or header fields can be overwritten. Seems that the former method is used in the pages associated with this work. I don't know enough about how all this works to boldly edit this index page to try to get a second styled heading. Can anyone help? If it is impossible, can you suggest a way to list the spoken work so that it is related to this source? PopularOutcast^talk2me! 17:00, 12 December 2018 (UTC)

Oy, that work is a mess. It looks as though the creator did not follow Wikisource standards, and the whole volume may need to be cleaned up to current style. The first volume is not identified as the first volume, but the second volume is. It also needs manual headers if you're going to link in the spoken files, which is one reason manual headers are preferred.

It looks like you need an experienced editor to (1) move a lot of pages, (2) correct all the links after the move, and (3) switch to manual headers. This won't be a quick job unless someone has a clever bot. --EncycloPetey (talk) 17:06, 12 December 2018 (UTC)

To specifically answer the question, does a work require manual headers in order to modify the contents of the "notes" field in the header? —Beleg Tâl (talk) 19:58, 12 December 2018 (UTC)

Yup, if it's possible to do this without moving to manual headers then it would be the easiest way. PopularOutcast^talk2me! 23:01, 12 December 2018 (UTC)

As far as I know, the PAGE tag pulls all information from the Index page only, using a toggle value. If you need to add or change anything at all with regard to the information displayed in the header, then you have to use a manual header. --EncycloPetey (talk) 23:25, 12 December 2018 (UTC)

Thanks EncycloPetey. Putting my recording in may not be worth the effort to move all that. I doubt very much that I will read the entire work. Over at Wikipedia we had a page that listed all the spoken articles so people could quickly find files. That's an alternative. That Wikipedia page linked to the article which had the embedded play thingamabob but there's no reason it can't just link to Commons. PopularOutcast^talk2me! 23:01, 12 December 2018 (UTC)

Another option would be to record for LibriVox, and organize everything there. Then you can supply a single link to the recording. --EncycloPetey (talk) 23:21, 12 December 2018 (UTC)

Yeah, LibriVox is an option. It's not one I am likely to take. Like, I said, it's not that important. The recordings will be over on Commons if anyone ever wants them. In any case, apparently it has already been recorded in its entirety by someone on LibriVox. They linked to it from Wikipedia rather than from Wikisource (which is what I was considering doing). PopularOutcast^talk2me! 23:42, 12 December 2018 (UTC)

Other display oddities

Are any patrollers seeing the same problem with Page:The Word and its Inspiration - vol 2.pdf/3?

Instead of [Mark as patrolled], as we used to see, I am seeing the left bracket on one line, the text on the second line and the right bracket on the third line. I am seeing this on any unpatrolled page. --EncycloPetey (talk) 18:03, 14 December 2018 (UTC)

Same here. Seems to be caused by the CSS .prp-page-content > * {display: flex;} which, to be honest, I'm not very good with CSS flex boxes and I don't know why it's using it. I think someone must have changed the HTML/CSS of the Page namespace because I also don't remember the text on the left side being right up against the middle vertical dividing line without any padding which looks bad IMO. --Riley AJ (talk) 18:16, 14 December 2018 (UTC)

I believe there used to be padding on both sides. --EncycloPetey (talk) 18:43, 14 December 2018 (UTC)

Note the bug phab:T209939 referenced in above discussion by Beleg Tâl. Beleg Tâl made a note in Phab asking the developers to look at the above discussion. I've added another note asking them to look at _this_ discussion also. Shenme (talk) 18:53, 14 December 2018 (UTC)

Tech News: 2018-51

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

Tech News

• Because of the holidays the next issue of Tech News will be sent out on 7 January 2019.

Recent changes

• Some templates that show notices about the content of the page will now be shown on the mobile website. In many cases they were hidden before. [9][10]
• Admins can no longer unblock themselves, except for self-blocks. A blocked admin can block the user who blocked them but no one else. This is so no one can block all admins on a wiki without being stopped. [11]
• The ParserMigration extension has been removed. It compared the result of two versions of the MediaWiki wikitext parsing pipeline. It was used when we moved to the Remex parsing library instead of Tidy.

Problems

• <ref> tags can use parameters such as "name" or "group". For example <ref name="adams" group="books">. If a <ref> tag has more than two parameters all parameters are ignored. You don't get a warning that they don't work. This will soon be fixed. [12]

Changes later this week

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

Future changes

• The Wikimedia Foundation Android app team are working on making it easier to edit on mobile phones. You can read more about these plans. If you have an Android phone and speak at least two languages you can help testing in English. Tell Dchen (WMF) you want to be part of the testing by writing on her talk page or email her.
• tiles.wmflabs.org and wma.wmflabs.org will stop working. They have no maintainers and run an old operating system. Tools which use it could stop working. This includes the mapnik gadget, hill shading, and hike and bike layers. New maintainers could help out and keep it going. [13]

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

20:35, 17 December 2018 (UTC)

youtube invoking spam filter

I can't properly create this page, because the spam filter gets invoked: The battle for open/Bibliography What's the best way to proceed? -Pete (talk) 20:17, 10 December 2018 (UTC)

I added those specific links to the whitelist. If it's a continuing problem, we could discuss adding youtube itself to the whitelist, but right now adding specific links used in a bibliography like that seems like the right way to go.--Prosfilaes (talk) 23:53, 10 December 2018 (UTC)

the over use of filters where there no history of misuse here, is a problem. it is the swatting of fleas with sledgehammers. the escalation of gate-keeping will adversely affect work going forward. Slowking4 ‽ SvG's revenge 03:20, 20 December 2018 (UTC)

interwiki link wikilivres

Please redirect the interwiki link wikilivres to the new address wikilivres.org. S8w4 (talk) 08:19, 15 December 2018 (UTC)

@Billinghurst: could you do the honours? —Beleg Tâl (talk) 14:42, 18 December 2018 (UTC)

Is this related to the fact that the links on, for example, The Coming of Wireless are currently redirecting to a commercial site? This needs an urgent fix. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:31, 26 December 2018 (UTC)

It is, and I agree this is an "Unbreak now!" issue. Pinging all admins who've been active after the 24th: @Kathleen.wright5, @Ineuw, @Beeswaxcandle, @EncycloPetey, @BD2412:. Anyone with the right permissions (I'm assuming +sysop will do) should be able to edit the interwiki table at Special:Interwiki (normal users can only see the table). If the local table is missing the wikilivres: prefix then a new local entry for it should override the global setting, and a fix for the global prefix needs to be implemented on meta. --Xover (talk) 14:54, 26 December 2018 (UTC)

I don't see any option to edit the page on the page. BD2412 T 15:11, 26 December 2018 (UTC)

Crud. Then it probably requires the special bit +interwiki, or we need to get a steward to do it. On the other hand, the Wikilivres config appears to exist on Meta too per m:Special:Interwiki, and thus affects all wikis without a local override, so it may be that taking the issue there is the right approach in any case. Anyone familiar with the request venues at Meta and up to bringing it there? I can probably figure it out but it's exceedingly rare that I visit Meta so I'd have to do some digging first. --Xover (talk) 15:26, 26 December 2018 (UTC)

I have asked at MediaWiki. BD2412 T 15:40, 26 December 2018 (UTC)

I popped into the stewards' IRC channel to ask about this and it looks like the global interwiki map has already been fixed: m:Special:Diff/18733804. The problem is that the change won't propogate to other wikis until someone runs an actual deploy (ala new versions of the MediaWiki software), those with the right access are all off having a life and stuff, and the next scheduled deployment isn't until 7 january. The person I talked to (MarcoAurelio (talk • contribs)) is trying to raise someone with the right access, but odds are probably pretty poor until tomorrow at the earliest (and not unlikely to be a week from now, given the holidays). Incidentally, I learned that the interwiki map is currently global-only (no wiki has a local map), and the global map for all WMF wikis is at m:Special:Interwiki. Local admins on enWS won't have the permissions to edit it; you'd need to be an admin on meta (which only Billinghurst is among those mentioned in this thread). --Xover (talk) 20:32, 26 December 2018 (UTC)

Special:Interwiki is just the "pretty" face of m:Interwiki map. But it does not suffice to edit the Meta page as I explained to Xover (talk • contribs) on IRC and to BD2412 (talk • contribs) at mediawiki. I sent a message to the Wikimedia operations IRC channel but so far no reply yet. I'll send some emails and see if we can have the map updated soon, given the huge number of links that now point to the taken-over site. Best regards and Merry Christmas for those celebrating (otherwise Happy Hollydays). MarcoAurelio (talk) 20:37, 26 December 2018 (UTC)

I've made some temporary fixes at Template:Wikilivres page, hard-coding the links, to bypass the interwiki form. Those changes should be reverted, once the Interwiki map is working again. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:06, 26 December 2018 (UTC)

Hello. Good news. The change is now live (cfr. phab:T212650) and bibliowiki: should be working as expected now. Best regards, --MarcoAurelio (talk) 15:55, 27 December 2018 (UTC)

Awesome news indeed, MarcoAurelio. And someone needs to buy Bawolff a $BEVERAGE on behalf of the Wikisources. Above and beyond, both of you!
I see EncycloPetey has already reverted Andy's temporary workaround, so everything should be back to normal now. Big thanks to everyone involved! --Xover (talk) 20:20, 27 December 2018 (UTC)

Invitation from Wiki Loves Love 2019

Please help translate to your language

Love is an important subject for humanity and it is expressed in different cultures and regions in different ways across the world through different gestures, ceremonies, festivals and to document expression of this rich and beautiful emotion, we need your help so we can share and spread the depth of cultures that each region has, the best of how people of that region, celebrate love.

Wiki Loves Love (WLL) is an international photography competition of Wikimedia Commons with the subject love testimonials happening in the month of February.

The primary goal of the competition is to document love testimonials through human cultural diversity such as monuments, ceremonies, snapshot of tender gesture, and miscellaneous objects used as symbol of love; to illustrate articles in the worldwide free encyclopedia Wikipedia, and other Wikimedia Foundation (WMF) projects.

The theme of 2019 iteration is Celebrations, Festivals, Ceremonies and rituals of love.

Sign up your affiliate or individually at Participants page.

To know more about the contest, check out our Commons Page and FAQs

There are several prizes to grab. Hope to see you spreading love this February with Wiki Loves Love!

Kind regards,

Wiki Loves Love Team

Imagine... the sum of all love!

--MediaWiki message delivery (talk) 10:12, 27 December 2018 (UTC)

A suggestion related to main page

I have a small suggestion related to the sidebar of the main page (ie. this one). My suggestion is to collapse the list of 'In other languages' so that it doesn't go long down the page. For reference, you can see this.Adithyak1997 (talk) 07:19, 29 December 2018 (UTC)

Category:Index - File to check

It would be nice to "empty" the category before the end of January 2019.

Some of the works might be copyright encumbered for non US contributors, which is why I am asking here. ShakespeareFan00 (talk) 18:09, 29 December 2018 (UTC)

Celebrating Public Domain Day

For the first time since Wikisource has existed, new works will enter the American public domain en masse on 2019-01-01. How are we going to celebrate? I have a queue of works to upload late on the 31st. —Justin (koavf)❤T☮C☺M☯ 06:29, 20 December 2018 (UTC)

So far we have Wikisource:Requested texts/1923. I've got some stuff I need to scan; it'd be good to coordinate on uploading.--Prosfilaes (talk) 07:21, 20 December 2018 (UTC)

i may have to go to library to scan w:Tulips and Chimneys, and w:New Hampshire (poetry collection). Slowking4 ‽ SvG's revenge 14:07, 20 December 2018 (UTC)

I have my eye on several dramatic works available at the Internet Archive, to upload to Commons on 1 January, and begin working on at least one of them. --EncycloPetey (talk) 01:00, 21 December 2018 (UTC)

Earlier this evening I was picking through old copyright discussions to find a few previously deleted works from 1923:

• Wikisource:Copyright_discussions/Archives/2007-05#The_Silken_Tent,_etc.
• Wikisource:Copyright_discussions/Archives/2010-08#Mystic_treatises_(Isaac_of_Nineveh)_and_Index:Mystic_treatises_(Isaac_of_Nineveh)
• Wikisource:Copyright_discussions/Archives/2010-08#The_foundation_of_the_general_theory_of_relativity
• Wikisource:Copyright_discussions/Archives/2007-12#The_case_of_the_purloined_short_fiction
• Wikisource:Copyright_discussions/Archives/2010-07#Snake
• Wikisource:Copyright_discussions/Archives/2009-06#On_the_Electrodynamics_of_Moving_Bodies
• Wikisource:Copyright_discussions/Archives/2008-07#Author:G._K._Chesterton
• Wikisource:Copyright_discussions/Archives/2008-09#The_United_States_of_Lyncherdom

Of course it might be preferable to just start fresh from ProofreadPage'd facsimiles where available. Prosody (talk) 10:42, 1 January 2019 (UTC)

Download a book

Hi, is there any feature to download the validated books in English wikisource? I could see download option for the featured text displayed in homepage. How can i get a similar option for other books?

In my local community, I have a friend who holds a doctorate degree in English Literature. He wants to read a wider range of books, but he is visually challenged. Since the books in Braille language are limited in our locality, he uses a software which would read out the digital content.

He can read the wikisource pages directly using the software, however it would read out the entire page including menus and headers. It would be easier for him if these books are available in word/pdf/epub format, as it would be comlicatd for him to navigate the webpages. Can anyone please help me? --Cyarenkatnikh (talk) 11:39, 31 December 2018 (UTC)

You should see "Download as *" links in the left sidebar in the main namespace. I'd recommend EPUB, as Wikimedia's PDF generation is notoriously shoddy. BethNaught (talk) 11:50, 31 December 2018 (UTC)

With that option, I would be able to download that particular chapter/page. How can I get the whole book, like the one in featured texts of community home page? --Cyarenkatnikh (talk) 12:27, 31 December 2018 (UTC)

To the contrary, you get the whole book, at least if you use the link on the work's root page. Go to Aaron's Rod (Lawrence) and try it: I get the whole book as an EPUB.

That's not to say that the converter tool works in all cases, but it's worth trying. BethNaught (talk) 20:38, 31 December 2018 (UTC)

see also m:Community Wishlist Survey 2017/Wikisource/Improve export of electronic books; m:Community Wishlist Survey 2019/Wikisource/Improve export of electronic books; it is a perriennial wishlist, but not much interest among the devs. Slowking4 ‽ SvG's revenge 22:40, 1 January 2019 (UTC)

Editing window woes (again)

Today, I find that I can no longer adjust the size of the header or footer window when side-by-side editing. Before today, I was able to drag the corner of either window to enlarge or shrink it. But today they now appear at a fixed size, and one that is much larger than they used to do.

I assume this is a side-effect of the latest update. --EncycloPetey (talk) 04:41, 13 December 2018 (UTC)

Appears to be due to phab:T209939 —Beleg Tâl (talk) 14:17, 13 December 2018 (UTC)

I've made a patch to fix this, by making the header/body/footer ratio 1:8:1. However, as Tpt pointed out, the earlier fix for the layout has meant that the resize handles (lower right corner of the textarea, for dragging to change the height) no longer work. My patch actually turns these off (instead of showing ineffective controls) but how should resizing work for these? It seems to me that if one makes the header bigger, then the body should get smaller: i.e. that the three textareas should always take up the same amount of space, but their relative heights can be adjusted easily. Comments welcome on phab:T209939. Sam Wilson 15:59, 15 December 2018 (UTC)

Esme Shepherd (talk) 15:04, 3 January 2019 (UTC) Is this the reason my header/body/footer ration is now 0:10:0 and has been ever since that time? I hope you can fix this soon as obviously headers and footers CANNOT be edited and, as you say, resizing is not available.

audio works

I propose that works produced in an audio format be incorporated into our collection as separate versions and that inclusion be emphasised within the defined scope of wikisource. This would include works that are termed audio books, spoken word, talking books, and so on, but not necessarily limited to those products.

As I see it, the solution to making these works available is to link them from their title in mainspace. This allows more bibliographic data to be appended, rather than an icon appearing at the title and subpages of the text version. I will note this is not my solution, lest that damn the notion, this is how libraries provide access through their catalogues and the perspective we should be applying to a highly desired format. Aside from their separation and that more detail be added or transcluded from commons / wikidata, I would also prefer the integrity of these works be indicated; there is currently no process of verification for audio that is already served here. This proposal is intended to clarify and facilitate the contribution of these works, and eventually be applied the existing audio be provided here.

The consequence of this might be that an audio book is available when the text is absent or unprepared. Another effect may be that this provides another way to contribute to wikisource. CYGNIS INSIGNIS 02:55, 14 December 2018 (UTC)

So, if there is an audio version of a work that we also have as a written text, the user will have to go to another page to find it, instead of having the relevant audio linked from the text? --EncycloPetey (talk) 03:04, 14 December 2018 (UTC)

Correct. CYGNIS INSIGNIS 14:17, 14 December 2018 (UTC)

I am inclined to partially support this proposal in a limited way. Audio works are properly the scope of Commons, not enWS, so we should not treat them as "in scope" here. However, if a versions page exists for a work, it would be beneficial to include links to relevant versions on other wikis such as Commons, mulWS, wikibooks, and so forth. — I will also point out that a transcription of an audio file can definitely be considered in scope here, if the contents of the audio file satisfy WS:WWI. —Beleg Tâl (talk) 01:44, 9 January 2019 (UTC)

Language tagging

The documentation of the template {{Lang}} states that Texts on Wikisource should be tagged to specify the language in a machine readable format. All pages on English Wikisource are are automatically tagged as "English". Any piece of text that is not in English should be tagged as such with this template or one of its derivatives.

For this reason I started tagging non-English texts, but Mpaa noticed me that it is not good to use it to wrap text containing templates using <div> tags, such as {{center}} (see the discussion at my talk page). This can be a problem at pages like Page:Bedřich Smetana, The bartered bride, Die verkaufte braut.pdf/8. One possible solution might be not to use the lang template for the whole page but repeat it many times for every separate piece of the text in the page, which is not very user-friendly. Does anybody have any other idea how to solve it? --Jan Kameníček (talk) 16:11, 30 December 2018 (UTC)

This template was intended primarily for blocks of texts that do not use Roman script. So it is not necessary to tag Latin, German, or Czech. But it can be useful to tag Hebrew, Greek, Hindi, or other languages that might require a font for display that the user is not expecting. However, some of these languages, such as Greek, have dedicated templates. Thus {{Lang}} is really for languages in non-Latin scripts that do not have their own language-specific template. --EncycloPetey (talk) 17:01, 30 December 2018 (UTC)

I believe we should not care only about the visual side of the problem. Some people (not only blind ones) may read the text using various speech applications, for which it is important to know the language to be able to pronounce the text correctly.

I also went through the documentation in detail and it seems to me that the template is not intended only for non-Latin scripts, but for foreign languages generally: 1) It states that also Greek transcribed in Latin script should be tagged as Greek 2) It informs that all pages in English Wikisource are tagged as English language (not as Latin script), and it does not seem correct to have a page written in German tagged as being in English.

Although I need it for German and Czech parts of texts, somebody else may face the same problem with the whole pages written in non-Latin scripts as well (example here). --Jan Kameníček (talk) 18:17, 30 December 2018 (UTC)

Note that the documentation you refer to was created in 2012 by a single user. Before applying his ideas generally, I would recommend a community discussion. The response I gave previously may not appear in Adam's documentation, but it was the result of community discussion about the application of this template. --EncycloPetey (talk) 18:22, 30 December 2018 (UTC)

Maybe it would be good to know first if it is possible to rewrite the template so that it did not cause the above mentioned problems. If it is possible, than we can discuss whether it should be used in that way or not. I personally believe that it can be useful, especially for various speech applications. --Jan Kameníček (talk) 19:20, 30 December 2018 (UTC)

"This template was intended primarily for blocks of texts that do not use Roman script. So it is not necessary to tag Latin, German, or Czech. "

The former may or may not be true; the latter certainly is not. All text that is not in English should be marked up as such. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:00, 1 January 2019 (UTC)

What effects would it have if the <span></span> tags were changed for <div></div> tags? --Jan Kameníček (talk) 18:41, 1 January 2019 (UTC)

That would be incorrect when used inline - the majority of its instances, I suspect. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:00, 1 January 2019 (UTC)

@Pigsonthewing: And would it work as expected when used in pages like Page:Bedřich Smetana, The bartered bride, Die verkaufte braut.pdf/8? If so, maybe we could have to language templates: one for inline usage and the other for larger parts of text... --Jan Kameníček (talk) 22:37, 1 January 2019 (UTC)

I would not want to see two templates; as that increases the maintenance workload. Better (if we need to go down this road at all) to have one, with a switch parameter depending on the context, which is set as, say |inline=yes, and make the default value whichever is the most common usage. We could then make a wrapper avaialable for the secondary usage. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:40, 4 January 2019 (UTC)

Note that, provided I understood you correctly, this is functionally equivalent to having two templates. --Xover (talk) 15:42, 4 January 2019 (UTC)

If we decided to have two templates, I can found the other one, as it requires just a minor change. If we decide to incorporate it into the existing template, I would be really appreciate if somebody more experienced did it. --Jan Kameníček (talk) 00:25, 6 January 2019 (UTC)

So I will keep using the template {{Lang}} as it is and it can be fixed any time later. --Jan Kameníček (talk) 10:55, 10 January 2019 (UTC)

Adapting Template:pd/1996 or a new template

As per previous conversation started by Prosfilaes, from next year US-published works published in 1923 will be out of copyright, and progressively year by year others will follow. We need to start working on whether we will adapt Template:pd/1996 to have wording that says that the work is out of copyright, and reconfigure that template to set triggers. Or whether we are going to implement a new template for post 1922 works. (Full coverage at copyright tags.) — billinghurst sDrewth 09:34, 5 August 2018 (UTC)

Don't the 1996-series of template primarily apply to works published outside the US? For works inside the US, we've been using the 1923-series of templates, and I would assume that it's the 1923-series that would need to be adapted to accommodate US-published works from 1923. It would be odd to have "published before 1923" to be a reason a work is in PD, if works published before 1924 is the actual set of works in PD. --EncycloPetey (talk) 15:55, 5 August 2018 (UTC)

You are correct that the pd/1996 has been non-US first publications to this point, and there would be complications in updating the template. Template:pd/1923 is set, and incrementing Template:PD/19xx is possible, though becomes a lot of templates. It is why I brought up the issue as we have to get the wording right, and look to the easiest means to progress through the years. As 1977 is the next US copyright milestone, maybe it is something like pd/1978 with both a year of birth AND year of publishing as parameters, where year of publishing flicks between copyright and not copyright.

• Pd-1923
• Pd-1996
• Pd-US
• Pd-anon-1923
• Pd-old
• Pd/1923
• Pd/1996
• Pd/1996/doc
• Pd/US
• Pd/us
• Pdusgov

— billinghurst sDrewth 22:46, 5 August 2018 (UTC)

Let us keep watching for the rest of 2018 to be sure that the US copyright term is not extended. Then I may want to introduce "PD-pub-95" to mean "public domain for being published more than 95 years ago. Renaming Pd/1923 will probably be too disruptive, so making a new template may be better.--Jusjih (talk) 04:48, 9 September 2018 (UTC)

It's not going to happen, and part of the reason it's not going to happen is because we are going to rip the hell out of Congress if they try. Being able to say that are already preparing for this change will only help our case. And when the ball drops in New York, I will be uploading 1923 works, and will need an appropriate tag.

I'd like a single PD tag that takes publication year and author death year (if known), and it shouldn't mention in the name the exact rules, just applying all the rules that can be deduced clearly from publication year and author death year. Maybe just naming it PD-old would be too much?--Prosfilaes (talk) 06:35, 10 September 2018 (UTC)

I support the single-PD template idea. While it would be rather an in-depth template, I don't think it would be particularly difficult to implement (just a series of if-elsif-else conditions). Mukkakukaku (talk) 00:56, 13 September 2018 (UTC)

The US Copyright Office already considered the copyright terms too long. Mid-term election will be soon. Template:Pd/1923 is heavily used, so renaming will be harder than adding new template like "PD-pub-95". I will wait for the ball to drop in Times Square.--Jusjih (talk) 03:00, 18 September 2018 (UTC)

•  Comment Looking back at this and thinking again, I think that we should be building a template based on 1978 cutoff, aligning with 1923 and 1996 cutoff usage. We already have our subset of use templates (<1923; 1923<1996) that have a series of #if statements (well #ifexpr) that get implemented. At this stage we need to have some output templates that work in main ns that cover 1923 to 1977 at least
• published in US between 1923-1963 with notice and renewal
• published in US between 1964-1977 with notice
• published outside of US between 1923-1977 (two scenarios)

where we will be incrementing per year. So we just use a #if expression for currentyear - 95 > publicationyear where it shows the PD template when true, and copyright violation when it fails. It is a few years until we need to worry about PD-old for post 1923, so we can work that bit out later. If someone uses this new license for a pre-1923 work, we can simply apply the {{pd/1923}} logic.

We still need a licence to display and the wording to use for US users, bottom half replicates pd/1996. — billinghurst sDrewth 10:03, 25 September 2018 (UTC)

•  Comment what's the status of this discussion? Thousands of works will have their copyright expire in 3 days. Mathmitch7 (talk) 14:05, 28 December 2018 (UTC)
• @Billinghurst: Have you been working on this issue? --EncycloPetey (talk) 01:29, 1 January 2019 (UTC)

•  Comment Commons has been having a similar discussion at Commons talk:Public Domain Day. The main consensus of which is to create a new template {{PD-US-expired}} to accommodate the new year's worth of expired renewals, as well as in future years (note the absence of a date in the name). --EncycloPetey (talk) 03:02, 1 January 2019 (UTC)

If I'm understanding what they're doing properly it looks like they moved their {{PD-1923}} etc. to {{PD-US-expired}} and modified it, I don't know if there are any problems associated with that, the redirecting previous name is still used all over the place but it doesn't appear to break things. If we want to follow suit I guess we just have to identify the changes we need to make a US expired tag that's applicable for all years of the old publication date based regime, as described above? Prosody (talk) 12:13, 1 January 2019 (UTC)

Took a stab at implementing the logic of a wrapper around the existing US PD templates, dunno if it'll be of any use. User:Prosody/pd-expired/test. Prosody (talk) 15:07, 1 January 2019 (UTC)

commons:Template:PD-old-auto-expired looks like a better one than Pd/1923, but doing away "1923" in all relevant templates in bulk should better have a bot.--Jusjih (talk) 23:09, 6 January 2019 (UTC)

Why would we need to do away with that template? The point of the above discussion is that we don't have to do away with it. And there are some templates where we want to keep the date of 1923. Also, Commons templates have to do double duty: PD in the US and PD in the country of origin for everything they host. On Wikisource, the rules are different, and we are concerned primarily just the former, though we note other licensing. --EncycloPetey (talk) 23:24, 6 January 2019 (UTC)

Keeping naming 1923 because many works published since 1923 would remain copyrighted in the USA due to the Copyright Term Extension Act in 1998 is simpler. It looks okay this year. Using {{#expr:{{CURRENTYEAR}}-95}} would get 1924 this year, but 1925 next year, so how about it in templates named "1923" to avoid massive renaming?--Jusjih (talk) 05:11, 7 January 2019 (UTC)

I don't understand what you are asking. The 1923 still works. The change in US law has different effects on different sources of copyright. For works registered for copyright in the US, the change is to works whose copyrights were renewed but have now expired. The cutoff for all publications that had such renewals was 1923. The proposal above was for a new template to deal with these cases of expired copyright, instead of having to check and replace everything. But for works that were already in the public domain because they were published without a copyright statement, or wre not renewed, the license is still correct, and does not need to be changed. --EncycloPetey (talk) 05:54, 7 January 2019 (UTC)

For the new template, how about Template:PD-US-expired? This does not require changing PD-1923 series.--Jusjih (talk) 02:40, 9 January 2019 (UTC)

We could tag works published before 1924 with PD-US-no notice and other such tags, but there's nothing special about 1923. We have never made a tag to say that a work was published outside the US before 1909 and thus was never in copyright. It is sufficient now to say that it was published more than 95 years ago, and new works should only be tagged as such, for simplicity and clarity.--Prosfilaes (talk) 06:24, 11 January 2019 (UTC)

Wikidata vs Versions pages, part 2

I'm fighting a losing battle at Wikidata to get the admins there to respect Wikisource conventions... again... d:Wikidata talk:WikiProject Disambiguation pages/guidelines#Moved from the page section "Editions pages" —Beleg Tâl (talk) 19:09, 18 December 2018 (UTC)

this is one problematic admin displaying some German drama. might have to provide him with an edition / work ontology solution wrapped in a bow. Slowking4 ‽ SvG's revenge 17:52, 17 January 2019 (UTC)

Sub-disambig pages by author

It is a common practice to have works by the same title and by the same author on a separate disambig page from other works by that same title. You can see many such examples at Song, such as Song (Anne Brontë), Song (Burns), Song (Coates) and so forth. I don't think that this really makes sense, since all of those works on those sub-pages are called simply "Song" and should really be listed at Song directly.

Does anyone have substantial objections to me merging such sub-pages when I see them in the wild? @Londonjackbooks: you seem to have created some of these sub-disambig pages, so I'd value your opinion here. —Beleg Tâl (talk) 15:35, 18 December 2018 (UTC)

Yes, I object. Some of those are versions pages, not disambiguation. However, if they are indeed different works that merely share the same title and author, then I agree. --EncycloPetey (talk) 16:59, 18 December 2018 (UTC)

I am not talking about versions pages, those are completely different and have nothing to do with this. I am talking about separate disambig pages that are created to disambiguate between different works with the same title, but which for some reason have been split off into separate pages by author. —Beleg Tâl (talk) 17:27, 18 December 2018 (UTC)

I am also not talking about editions pages like Song (Aldington) or redirects like Song (Le Gallienne), for the record. —Beleg Tâl (talk) 17:29, 18 December 2018 (UTC)

@Beleg Tâl: your work with the music here has appeared in my watchlist, and is fairly wonderful. I must confess, however, that I find the list of works at Song to be confusing, even with the first lines. Also, I learned here that I am using the word disambiguate wrongly in my summaries. So, a thanks, an apology for being easily confused and another for being confusing.--RaboKarbakian (talk) 18:28, 18 December 2018 (UTC)

Apologies @Beleg Tâl:. I have been away and have just returned. I will read the above in more detail soon, try to think critically (ouch), and respond, unless your question has already been successfully answered. Thanks, Londonjackbooks (talk) 15:25, 20 December 2018 (UTC)

@Beleg Tâl:. Can you possibly point me to a couple Coates "sub-disambig" pages you would like to see "merged"? Is Song (Coates) one of them? I guess I'm not understanding why it would not be desirable to have such a disambig page, but I am not an expert in the science of organization. Are you saying you would like to see "Song (Coates)" deleted and the contents transferred directly to the "Song" disambig page? Londonjackbooks (talk) 21:40, 21 December 2018 (UTC)

@Londonjackbooks: yes, Song (Coates) is one example, as are the others listed in my original comment. Here are some of my reasons:

• Main reason: all of the works listed at Song (Coates) are works entitled "Song". All works entitled "Song" should be listed at Song, because Song is supposed to be a list of all works entitled "Song". Therefore, all works listed at Song (Coates) should also be listed at Song. Once all these works are listed at Song, then Song (Coates) will contain only information already available at Song. Therefore Song (Coates) is redundant, and is therefore a candidate for speedy deletion.
• Additional reason: A page that disambiguates works called "Song" but only if they are by Coates, is not in keeping with the Manual of Style or current practice.
• Additional reason: Song (Coates) is, by force of our standards for disambiguation, a list of works called "Song (Coates)". None of the works at Song (Coates) are actually called "Song (Coates)", as all of them are called only "Song". We have no works on Wikisource entitled "Song (Coates)". Therefore there is no need for a list of works entitled "Song (Coates)".

I therefore propose that yes, all the contents of Song (Coates) (and Song (Anne Brontë) and Song (Burns) and all the other such pages) be transferred directly into Song, and that the same occur with sub-disambig pages for other titles whenever I encounter them. However, rather than delete Song (Coates) I would redirect it to Song, because it is likely that users will link or search for Song (Coates) to find a song called "Song" and written by Coates. If we are feeling generous, we can use an anchor or section header to redirect Song (Coates) to the specific location at Song that lists works by Coates with this title.

I also want to point out that the only contrary argument I can think of, is that Song is a massive list and merging will make it even more massive. My response to this is: firstly, it doesn't matter that Song is massive so long as it is functional; secondly, we have better, more standard methods for dealing with massive lists (such as {{TOC}} and alphabetical sections, for example; or in simpler situations a simple nested list) which are more in keeping with existing practices and expectations of readers; thirdly, we have lots of massive lists on Wikisource that are perfectly acceptable both from a user experience perspective and from a policy and consensus perspective; I am sure I could come up with more if I had time.

All of which is to say: Song (Coates) is an anomaly in our practices; consolidating all this on Song and redirecting Song (Coates) to Song is how it should be done in order to match with our practices and expectations. —Beleg Tâl (talk) 22:33, 21 December 2018 (UTC)

Makes sense to me, including the suggestion to make the long list more accessible by dividing it into alphabetical sections. --Jan Kameníček (talk) 23:35, 21 December 2018 (UTC)

Thank you for spelling things out. I understand some of your reasoning, and am trying to think through the logic in baby steps. So, if someone is viewing one of Coates' poems entitled "Song" at WS, they would currently see (via the use of the {{similar}} tag) that there are other works available here by the same title—not only by different authors, but also by the same author. That would not be the case were we to be rid of Song (Coates), and I am trying to get over my obtuseness and stubbornness to understand why having such a disambiguation would not be useful in the interest of research. Why is such a redundancy (in certain cases) necessarily a bad thing? And I can't find at the dab help pages exactly where it specifically goes against guidelines. More questions are in my head, but I'll leave it at this for now. Londonjackbooks (talk) 06:11, 22 December 2018 (UTC)

@Londonjackbooks: For an example of what I am proposing, see Song: "Lordly gallants!" by George Wither. You will notice that the hatnote says "For works with similar titles, see Song." Users that click on the link will see a list of works called "Song", some of which might be by Wither, and some of which might not be by Wither; which is exactly what users expect when they click on that link. More generally, I do not deny that pages like Song (Coates) are useful in the interests of research; I only deny that Wikisource is the place for them. We should not maintain lists of works called "Song" by Coates for the same reason that we should not maintain lists of works called "Song" published in the USA, lists of works called "Song" written in 1896, or for that matter, works called "Song" written by Coates in 1896 and published in the USA. Structured queries like this are better handled by Wikidata, which is designed explicitly for this purpose. On Wikisource, users already have two ways to find works by Coates called "Song": 1) search for "Song" at Author:Florence Earle Coates; or 2) search for "Coates" at Song. —Beleg Tâl (talk) 14:33, 29 December 2018 (UTC)

@Beleg Tâl: "We should not maintain lists of ... for the same reason that..." Thank you. I can wrap my head around that reasoning :) I only ask that I be permitted, if your proposal is agreed upon, to do the cleanup for Coates' works myself. Obviously, this request can't necessarily be regulated, but I'm at least putting it out there. Thanks :) Londonjackbooks (talk) 05:09, 30 December 2018 (UTC)

@Londonjackbooks: That works for me. Song would be the first one for me to tackle but I'll hold off until you take care of the ones by Coates. —Beleg Tâl (talk) 18:58, 2 January 2019 (UTC)

Will do. Thanks. I've not been very active here recently, but will make an effort. It may be after January's end. Should I wait until a general consensus is reached on the proposal? Londonjackbooks (talk) 20:26, 2 January 2019 (UTC)

I think we have sufficient consensus to proceed. I'll begin work on Song but I'll leave the Coates part for you. —Beleg Tâl (talk) 16:25, 11 January 2019 (UTC)

@Esme Shepherd: you've made a few of these for Landon, do you have any thoughts on this proposal? —Beleg Tâl (talk) 18:56, 2 January 2019 (UTC)

Esme Shepherd (talk) 20:56, 2 January 2019 (UTC) I did make such a page for 'Change' because I knew Landon had written six poems with that title. These were moved into the main disambiguation page, which didn't bother me although the result is a little confusing because Change (L. E. L.) still also exists as does Change (And this is what is left of youth!), which is for versions of the same poem.

I do have reservations with regard to "Song" because Song (L. E. L.) contains 92 poem entries and I cannot see any advantage in amalgamating these into one disambiguation page with all the other 'Songs'. Surely these pages are to make finding works easier for the user, not more difficult. On the other hand, maybe listing them both ways would be even better - catalogued by the first line, as well as by the poet.

@Esme Shepherd: I am not worried about versions pages at the moment, although I agree that Change (L. E. L.) is a confusing name for a versions page. I understand that merging Song (Letitia Elizabeth Landon) into Song will be very long, but I also intend to make the page easier to navigate as well, so I think it will work out in the end. —Beleg Tâl (talk) 21:15, 2 January 2019 (UTC)

Esme Shepherd (talk) 22:08, 2 January 2019 (UTC) Okay, ease of navigation is the main issue. I would like retention of first lines, as they are the principal identifier. The problem as far as I can see is that someone looking at a Landon song wishing to see other poems with a similar title will be redirected into Songs in general rather than specifically Landon songs. How are they to reach that specific subset if it is lost in a very long list?

Esme Shepherd (talk) 17:09, 30 January 2019 (UTC) Very good. I like what you have done.

Issue with the FI Template display.

Tracked in PhabricatorTask T209939

I am not sure if this a new problem or a local issue with my system, but thought I'd better raise it.

I've been using template FI to add images in "A general history for colleges and high schools" for a while now and everything has been displaying as expected, however tonight, the images I have floated left or right have all appear centered when I save the page.

Looking at the image as transcluded in the chapters they still display as expected i.e. to the left or right side of the page.

i.e. a recently added image is Page:A general history for colleges and high schools (Myers, 1890).djvu/219

Could someone confirm if this a site issue?

Thanks Sp1nd01 (talk) 22:26, 19 December 2018 (UTC)

yes, it looks like another side effect of this change. Zdzislaw (talk) 20:03, 20 December 2018 (UTC)

FWIW {{img float}} is still working. --EncycloPetey (talk) 22:06, 20 December 2018 (UTC)

Only inside a single paragraph, not across paragraphs. See eg. here. Ankry (talk) 00:43, 21 December 2018 (UTC)

@Ankry: Thanks for the phabricator link. They should probably be made aware as well (explicitly) of the issues with image placement and unwanted paragraph separation. We have also noted (above) that padding on the left and right margins in the Page namespace has gone to zero, which is not desirable. Until now the focus has been on the window resizing, and not the other issues that are now surfacing. --EncycloPetey (talk) 00:53, 21 December 2018 (UTC)

It seems that {{rule}} is also no longer displaying from the header in the Page namespace. E.g.: Page:Richard II (1921) Yale.djvu/120 --EncycloPetey (talk) 23:38, 21 December 2018 (UTC)

This last, at least is readily fixable. Simply replace

width: {{{width|{{{1|auto}}}}}};

in {{rule}} with flex-compatible

width: {{{width|{{{1|100%}}}}}};

I would do it myself except for it being protected… 114.74.46.230 05:22, 22 December 2018 (UTC)

• there is no need to make any changes. {{rule}} (and many other) will be visible again after reverting the changes - see: phab:T209939#4840870. Zdzislaw (talk) 23:34, 22 December 2018 (UTC)

@Zdzislaw: Agreed. In fact I have some sympathy for the frustration of TheDJ over this change… but the fact he has not edited here for over four years implies the :flex proposal was based more on a theoretic basis than actually thought out and tested?

And while on the topic of untested alterations, have you (O.K. not you—no insult intended—more precisely somebody with editsitecss rights would be needed!) considered putting in place something like

div.mw-parser-output{display:block;}

into (maybe)MediaWiki:Common.css as a stop-gap until such time as the Phabricator patch is backed-out or sensibly resolved? 114.74.46.230 04:38, 23 December 2018 (UTC)

{{block right}} is also behaving oddly now. E.g. On this Page it displays to the left of the screen, but in Preview mode, the same code displays to the right (where it should). --EncycloPetey (talk) 19:18, 25 December 2018 (UTC)

That is really strange: I have copied the code out of the page namespace to my Sandbox, where it is displayed correctly... --Jan Kameníček (talk) 18:54, 26 December 2018 (UTC)

Indeed. When the same content is placed in a different namespace, or transcluded to another namespace, it's fine. All of the issues appear to stem from use in the Page namespace when items are displayed side-by-side. --EncycloPetey (talk) 18:58, 26 December 2018 (UTC)

Related spacing issue?

If the extra blank line near the bottom of Page:Choëphoroe (Murray 1923).djvu/22 in the Page namespace a related issue? There should not be an extra blank line above the last line of the ending stanza, and there isn't one coded in the text, but the software inserts one anyway. --EncycloPetey (talk) 22:55, 1 January 2019 (UTC)

Most probably not related. It gets worse though: note just above Choëphoroe_(Murray_1923)/Text#19 the necessary blank line between stanzas is missing. Two thoughts: should <poem> have been utilised; and/or should each stanza have been forced into its own, individual, paragraph <p>/</p>? 114.73.65.234 00:30, 2 January 2019 (UTC)

The <poem> tag is notoriously unreliable and fussy, especially across page breaks. I stopped using it ages ago. --EncycloPetey (talk) 00:37, 2 January 2019 (UTC)

I've frequently seen the parser put the last line of a page in a separate paragraph, long before the above issues started. It doesn't happen when it gets transcluded so I've just ignored it. —Beleg Tâl (talk) 00:35, 2 January 2019 (UTC)

When I first began I was encouraged to always check preview before saving. Recently however I note that every time one previews, a blank line is added to the bottom of the page (yes, three previews equals three blank lines!). As I know about this, I always make sure to delete before saving. There may be some who have not noticed this. Esme Shepherd (talk) 10:49, 5 January 2019 (UTC)

Greek and polytonic templates

Tracked in PhabricatorTask T208901Resolved

The templates {{Greek}} and {{Polytonic}} force the text to start a new paragraph when used in the Page namespace, see e. g. Page:The Labyrinth of the World and the Paradise of the Heart.pdf/18, but this issue does not occur in other namespaces. --Jan Kameníček (talk) 12:09, 4 January 2019 (UTC)

Not the same issue. Looks like the TemplateStyles plugin is causing the parser to split the paragraph in two. —Beleg Tâl (talk) 13:15, 4 January 2019 (UTC)

I found this problem affected not only in this wiki but also in Wikipedia. In w:Zhang-Zhung language I saw this problem also occur in main namespace. So I think TemplateStyles plugin has a regression. --Great Brightstar (talk) 16:10, 9 January 2019 (UTC)

I found <indicator> tag can be used to avoid this behavior, and the problem is fixed. --Great Brightstar (talk) 09:45, 24 January 2019 (UTC)

I found Wikipedia put an icon at the right top corner of the help desk while I saw it on my phone, I will see how they did it, and is it possible to make use of that. --Great Brightstar (talk) 13:21, 13 February 2019 (UTC)

Oh that is not so suitable than <indicator> tag which can inject an element only once, don't use that. --Great Brightstar (talk) 13:54, 13 February 2019 (UTC)

This bug is fixed, so everybody will enjoy to use TemplateStyles anyway. --Great Brightstar (talk) 05:56, 1 March 2019 (UTC)

Chart2

Is this problem related? The template {{Chart2}} is no longer working reliably either. In some cases, the text and the connecting lines appear in different parts of the screen, in two separate diagrams instead of a single one. The effect does not seem to be limited to the Page namespace. --EncycloPetey (talk) 21:35, 5 January 2019 (UTC)

Or can someone see what's wrong in this chart?

				Tros.
Ilus.								Assaracus.
Laomedon.								Capys.
Priam.								Anchises.
								Æneas.

--EncycloPetey (talk) 21:47, 5 January 2019 (UTC)

Wow that template is massively complex. What I've determined so far:

• In between the two "separate" diagrams are hidden empty elements
• The hidden empty elements are tagged as class=mw-empty-elt
• The class mw-empty-elt is added by the parser to all empty elements in order to resolve some issues from when Tidy was retired [14]
• The class mw-empty-elt is set to display:none, see phab:T129375, phab:T150742, phab:T172896, phab:T49673
• When you disable the display:none rule, the chart displays properly.

—Beleg Tâl (talk) 23:35, 5 January 2019 (UTC)

With that information, despite having no idea what's going on, I seem to have fixed it. —Beleg Tâl (talk) 23:48, 5 January 2019 (UTC)

Thanks. The really frustrating part was that the example on the Template consistently worked, but every other instance I located or tried myself wouldn't work. Glad it has been corrected. --EncycloPetey (talk) 00:22, 6 January 2019 (UTC)

Possible fix coming

Pinging some of the folks bitten by or who might otherwise be interested in this problem: Sp1nd01, Zdzislaw, EncycloPetey, Ankry, Jan Kameníček, Beleg Tâl, Esme Shepherd, Narky Blert.

According to the latest Tech News from WMF (in the section #Tech News: 2019-02 below), they will deploy the 1.33/wmf.12 version of MediaWiki "on test wikis and MediaWiki.org from January 8. It will be on non-Wikipedia wikis and some Wikipedias from January 9. It will be on all wikis from January 10." As I understand it, that means we'll get this version on either January 9 (most likely) or January 10 (at the latest). The release notes for this version is at mw:MediaWiki 1.33/wmf.12, and for the ProofreadPage extension (the module that provides the Wikisource-specific functionality, including headers and footers and other special features in the Page: namespace) it lists "Avoids to use display: flex for now". This is the reversal of the change (deployed around December 15 last year) discussed in task T209939, which is the one that appears to have caused the majority of the issues discussed in this thread (and several other threads here and at /Help).

So, short version: it looks likely that these problems will go away today or tomorrow.

Which also means that any issues that still remain this coming weekend were not caused by this change and will have to be looked into and if necessary reported separately. Specifically, the whitespace / paragraph splitting issue discussed in #Greek and polytonic templates and #templatestyles inserting paragraph breaks does not appear to be fixed in the version under deployment now. --Xover (talk) 06:41, 9 January 2019 (UTC)

Based on phab:T208901, the devs are still debating how to address the paragraph-splitting issues with templatestyles. —Beleg Tâl (talk) 13:28, 9 January 2019 (UTC)

The 1.33/wmf.12 version of MediaWiki is now live here, and based on a quick check it fixes the missing horizontal rule issue, returns the header and footer fields to a reasonable size, and makes them resizable again. It would be a good idea for anyone who have experienced problems suspected to be related to this issue to test whether their problem is now resolved. Re-pinging previous list: Sp1nd01, Zdzislaw, EncycloPetey, Ankry, Jan Kameníček, Beleg Tâl, Esme Shepherd, Narky Blert. --Xover (talk) 20:54, 9 January 2019 (UTC)

I can now see and (I trust) edit the header and footer boxes in English WS in both PaleMoon and WaterFox, which I could not before. They are still absent from multilingual WS; but that's a lesser problem, and it's always possible that the fix will percolate through slowly. Narky Blert (talk) 21:28, 9 January 2019 (UTC)

Grrr. Problem solved. Preferences/Editing "Show header and footer fields when editing in the Page namespace" is disabled by default in multilingual WS. I've enabled it, and can now see and edit the header and footer boxes. Narky Blert (talk) 08:01, 11 January 2019 (UTC)

To confirm that I see the images are now floating left and right as expected, thanks. One other issue that I spotted on a random page proofread was that the blackletter font wasn't displaying, I thought it may have been related to this issue, but on just rechecking the page blackletter is still not displaying. i.e. Page:Vaccination a delusion.djvu/7 Sp1nd01 (talk) 22:03, 9 January 2019 (UTC)

@Sp1nd01: I can see the blackletter font from the computer I am currently using, so it may be a browser, OS, or personal skin issue, or something similar. Try a different browser or computer, I you can, and see if the problem persists. --EncycloPetey (talk) 22:56, 9 January 2019 (UTC)

Thanks for the suggestion, I should have thought of trying that before! I confirm that if I use the Edge browser it does show the blackletter fonts fine, but my default Firefox browser still does not. I'm 100% certain that it used to display fine, maybe its caused by a recent update either to the browser or OS. Sorry for the false alarm. Sp1nd01 (talk) 23:20, 9 January 2019 (UTC)

The blackletter font renders for me in both PM and WF. Oddly, in both browsers the blackletter line, unlike the other formatting, initially appeared in a plain font and only turned into blackletter at the very end of page loading. That suggests a coding issue of some sort. Narky Blert (talk) 04:53, 10 January 2019 (UTC)

Thank you. Now I can edit headers and footers again at my own desk - that's great! Esme Shepherd (talk) 22:33, 9 January 2019 (UTC)