Wikisource:Scriptorium/Archives/2019-08

Border/table interaction problem

Template interaction failure found: If you try to surround a piece of text containing a table with {{border}}, this is the result. I don't actually need to use this combination at the moment, but I thought I'd give a heads-up because it's probably going to come up for somebody else sooner or later. Levana Taylor (talk) 16:33, 1 August 2019 (UTC)

@Levana Taylor: Have you tried escaping the equals signs and other characters that are significant inside a template invocation? Everything in there is a single parameter to the border template so any equals signs or vertical pipes will confuse the parser. —Xover (talk) 17:01, 1 August 2019 (UTC)

OK, that explains the problem but it doesn't fix it, since it leaves you unable to use other templates inside the border. Levana Taylor (talk) 17:08, 1 August 2019 (UTC)

@Levana Taylor: Use {{border/s}} at the beginning, and {{border/e}} at the end, and it should work. —Beleg Tâl (talk) 17:14, 1 August 2019 (UTC)

It does work! Is that documented somewhere? Levana Taylor (talk) 17:20, 1 August 2019 (UTC)

Yes, but only for the use case of spanning page breaks - Help:Page breaks —Beleg Tâl (talk) 17:26, 1 August 2019 (UTC)

I guess the thing to do is to figure out which templates this sort of thing is an issue for and put a note on each one's page. I am doing that for {{border}} now. Levana Taylor (talk) 17:53, 1 August 2019 (UTC)

Database error

Anyone else getting database errors when creating pages this morning?

A database query error has occurred. This may indicate a bug in the software.

[XUMaQgpAADsAAJzbhxIAAAAA] 2019-08-01 16:58:42: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"

—Beleg Tâl (talk) 17:23, 1 August 2019 (UTC)

Great news: 80% of books published between 1924/1963 are public domain

https://www.crummy.com/2019/07/22/0 —Justin (koavf)❤T☮C☺M☯ 20:51, 1 August 2019 (UTC)

First, that's 80% of books published in the US. Also, I've spent some time looking at non-renewed books, and that's not what it feels like. I would bet that 80% of all copies of books were renewed; that is, books printed in a million copies that you can find copies of and that you might have heard of are virtually always renewed, and that most of those non-renewed books are printed in tiny numbers and forgotten. I arbitrarily chose the bestselling novels of 1930, and all ten were renewed. This is not to discourage anyone, but I've been quite discouraged by that 80% figure and comparing it to what I've found in real life.--Prosfilaes (talk) 21:28, 1 August 2019 (UTC)

It also seems that bibliographical databases like HathiTrust do not bother checking whether the work was renewed or not and for sure limit access to all works published after 1923 :-( --Jan Kameníček (talk) 21:55, 1 August 2019 (UTC)

Even IA will sometimes bow to claims, even if the claims are unfounded. An incredible 1912 anonymous publication was pulled from their listing because a later edition (with added content and altered text) was under copyright. --EncycloPetey (talk) 23:24, 1 August 2019 (UTC)

Prosfilaes might be right on 80% of physical books, though it's really a matter of the sorts of things you're interested in. Most of the stuff I've looked up has been academic histories and I've generally found them un-renewed (even though they're typically from major university presses). The ones that were seem to have been at the initiative of the author if I read the copyright records correctly, so the publishers weren't doing it automatically. Anyway, it's a good reason to always double-check the renewal status. —Nizolan ^(talk) 17:57, 2 August 2019 (UTC)

doesn't matter when commons won’t do the work of an actual renewal inquiry. we could have a work flow of non-renewed works, but why bother, when you would have to defend them in perpetuity. the open source librarians are doing the research. and their efforts will continue to show up in press reports. Slowking4 ‽ Rama's revenge 02:31, 3 August 2019 (UTC)

Also on BoingBoing: "Data-mining reveals that 80% of books published 1924-63 never had their copyrights renewed and are now in the public domain" - [1]. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:34, 2 August 2019 (UTC)

Roman Numerals in Page titles...

Elsewhere a template was updated {{article link}}, with the reasoning that English Wikisource had opted, to use standard digits in page names (on the LEFT hand side of piped links) as I understood it, with another contributor returning the relevant template to this in respect of both sides of the template.

Whilst the use of roman numerals for DISPLAY purposes is a different issue, I decided to check on how many works linked using roman Chapter Numerals, in Main namspace.

https://tools.wmflabs.org/grep/index.php?lang=en&project=wikisource&namespace=0&pattern=Chapter+%5BMCLDXVI%5D

At least 19,000 entries use Roman numerals ( based on Chapter numbers only.) . As there isn't as such anything wrong with these, I'd like opinions as to whether there should be a bot derived move and standardisation of format (including updating all links.).

If there's a standard, it should be used correctly? ShakespeareFan00 (talk) 11:50, 2 August 2019 (UTC)

I am considering if looking for roman numerals used as sub page links would be reasonable ShakespeareFan00 (talk) 11:50, 2 August 2019 (UTC)

https://tools.wmflabs.org/grep/index.php?lang=en&project=wikisource&namespace=0&pattern=volume+%5BMCLDXVI%5D (volume) ShakespeareFan00 (talk) 11:50, 2 August 2019 (UTC)

https://tools.wmflabs.org/grep/index.php?lang=en&project=wikisource&namespace=0&pattern=section+%5BMCLDXVI%5D (section) ShakespeareFan00 (talk) 11:50, 2 August 2019 (UTC)

https://tools.wmflabs.org/grep/index.php?lang=en&project=wikisource&namespace=0&pattern=part+%5BMCLDXVI%5D (part).

We've been moving away from using Roman numerals for volumes, chapters, or sections. There are some exceptions where they might be more reasonable to use than standard numerical values, but I think that would depend on the reasons for using them. There should be some reason for preferring one numerical system, and this is one instance where "following the source" isn't (by itself) enough of a reason. Most 19th century works give their year of publication in Roman numerals, but we don't record the date that way; we use the standard numerical system of Arabic numerals for dates.

The trend in both publishing and library science has been to move away from Roman numerals. And using Roman numerals for volume, issue, or chapter numbers makes sequential sorting impossible. The only place I use them with any regularity is in the Acts of plays, where Roman numerals are still standard for bibliographic purposes. Also, because the number of such Acts in a play is also typically limited to five or fewer, sorting is not a serious issue. In fact they will sort correctly up to VIII because the Roman numerals I to VIII are in alphabetical as well as numerical order. The problem begins with IX, which alphabetically falls between IV and V. --EncycloPetey (talk) 18:58, 2 August 2019 (UTC)

The other main reason for transitioning away from Roman numerals is to allow for a standard approach to linking. Newly added works should all be using Arabic numerals at all levels. Works without scans should be updated as scans are found. Older scan-backed works will need careful management as internal links (e.g. TOC) will also need to be updated at the same time. In other words transitioning our entire collection is a major undertaking. Do not rush into it. Beeswaxcandle (talk) 20:38, 2 August 2019 (UTC)

Movement Strategy online surveys - opportunity to share your thoughts about reworking movement structures

Community conversations are an integral part of movement strategy “Wikimedia 2030”. They have been ongoing in multiple formats and in numerous languages over the last 2.5 years. Now it is possible to also contribute to the development of recommendations on structural change via an online survey. We are keeping the survey open for additional 2 weeks and post it to wikis to provide wider opportunities to participate for people interested in it.

The survey is available in 8 languages: Arabic, English, French, German, Hindi, Portuguese, Simplified Chinese, and Spanish. They contain designated questions about each of the nine thematic areas that the working groups are analyzing and drafting recommendations for. You can freely choose the thematic areas you want to contribute and respond to. The survey questions have been created and designed by the members of the working groups.

Here is the link to the survey.

Here you can find more information about the survey.

With any questions, please contact me on my meta user talk page.

Thank you for your kind attention! --KVaidla (WMF) (talk) 14:39, 4 August 2019 (UTC)

p.s. If this is not the right place to post such message on your wiki, I apologize. Feel free to move it where appropriate according to your guidelines. Thank you!

use LinuxLibertine font in wikisource logo.

Tracked in PhabricatorTask T229769

retouned, kerning adjusted to match original File:Wikisource-newberg-de.png

For consistency with Wikipedia logo. Viztor (talk) 02:31, 5 August 2019 (UTC)

The current WikiSource logo is graphic drawn from here. Are you suggesting that this particular font was not used when constructing that image? Will the change process not require resort to a new Phabricator request, even assuming the change is justified? 114.78.171.144 11:11, 5 August 2019 (UTC)

Logo updated to commons. The current logo does not use that font as it was created in 2006 and was not updated following a font change of wikipedia logo in 2010. Notice the related phab task will also add hd logo to display.Viztor (talk) 16:12, 5 August 2019 (UTC)

Also discuss on Multilingual Wikisource Viztor (talk) 16:13, 5 August 2019 (UTC)

Tech News: 2019-32

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 6 August. It will be on non-Wikipedia wikis and some Wikipedias from 7 August. It will be on all wikis from 8 August (calendar).

Problems

• A change in RelatedArticles extension accidentally enabled it for everyone, not just for mobile users. This has been fixed. [2][3]

Meetings

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

Future changes

• Today everyone can see IP addresses if someone edits without an account. In the future this could be more hidden. This is to protect unregistered editors so fewer can see their IP address. This would only happen after we make sure the tools for vandal fighting can still be effective. You can read more and comment.

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

13:25, 5 August 2019 (UTC)

Emoji symbols

Symbols such as ⚓ (anchor) ✈ (airplane) ⚙ (gear) ⚒ (hammers) ⚔ (swords) that might appear in dictionaries have a dual nature in Unicode, either as printed text symbols or as emojis (possibly with coloured background). Friends tell me that they can be followed by 0xFE0E to enforce text style (⚓︎⚙︎⚔︎) or 0xFE0F to enforce emoji style (⚓️⚙️⚔️). (It seems Mediawiki doesn't show any difference, at least in my browser.) Should e-texts in Unicode/UTF-8 contain these additional characters? Or should we expect that an e-text always contains only printed text symbols, and make the software produce the right HTML/CSS markup for this? Has this ever been discussed? --LA2 (talk) 15:09, 6 August 2019 (UTC)

There shows a difference in my browser. Messing with MediaWiki is unlikely, so we might want to make a note or template to enforce text style where necessary. I don't know that it matters that much; a dictionary that used an anchor to mark nautical words, which seems to be one of the more obvious uses of characters like these, in the environment of a full-color screen, would be better off with emoji forms, and letting the system choose would be easier and arguably a better solution.--Prosfilaes (talk) 01:40, 7 August 2019 (UTC)

The character ☞︎ appears in a large number of texts, and is increasingly shown as ☞️. I don't think it's possible currently to control this display in a meaningful way using CSS or similar, but it looks like this is in the works for a future CSS specification. I am okay to leave it be in the meantime, but otherwise a template would be the most reasonable solution. —Beleg Tâl (talk) 13:17, 7 August 2019 (UTC)

By default, that's displayed as ☞.--Prosfilaes (talk) 18:55, 7 August 2019 (UTC)

I only see the difference in IE; Chrome on Windows 10 and Android show only the plain text style. But the bright yellow finger in IE really does stand out, but not in a good way. We will start having works best displayed in emoji style, though; wait until Wikileaks dumps the important texts of some millennial law maker.

We could have one template like {{textstyle}} or one for each character; it might be easier for the later. Subst or no?--Prosfilaes (talk) 19:01, 7 August 2019 (UTC)

Picture reproductions

While preparing the image on this page I found out that a much higher quality, colour version of the picture is already available on Commons here. There's no additional info on the book page, as there sometimes is with e.g. photographs of paintings, so is there any reason not to use the better version given that the quality of the book copy is presumably a technical limitation and not the author's intention? I've already cleaned up the book version so it's no skin off my back either way, but it did occur to me that it's potentially odd not to just use the better one. —Nizolan ^(talk) 22:05, 7 August 2019 (UTC)

The two versions can be compared in this version of the page (which I have since reverted). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:39, 8 August 2019 (UTC)

I've used a crop of the colour version now, it can be seen in context at the chapter subpage here. —Nizolan ^(talk) 12:31, 9 August 2019 (UTC)

Auth. control squashed

Recently, something has changed that has horizontally squished the width of {{Authority control}} in the main namespace. The template no longer disaplys full width on the page, but is bounded by whatever margins are set by the transcluded page text.

There has been no change to the template itself since 2015, so I assume something has been down to another template or to some other function in the way that the template is displayed. --EncycloPetey (talk) 20:48, 4 August 2019 (UTC)

If I recall correctly, {{authority control}} was one of the boxes that gets repositioned via JS after the page loads. Perhaps this change to the navbox module caused the repositioning script to no longer work? —Beleg Tâl (talk) 12:10, 5 August 2019 (UTC)

Note: I am also seeing the Auth. Control template displayed within the page content, such as HERE where the footnotes appear below the template. Can no one help with this issue? --EncycloPetey (talk) 21:55, 7 August 2019 (UTC)

Fixed in this edit (ignore my edit summary, which was in error). References will always appear last, unless a template such as {{reflist}} or {{smallrefs}} dictates otherwise.

If I have understood it right, the problem is not that references are displayed at a wrong place, but that the authority control box is displayed as narrow as the width of the text (such as at Henry IV Part 1 (1917) Yale), instread of being stretched across the whole page regardless of the text boundaries. --Jan Kameníček (talk) 10:58, 9 August 2019 (UTC)

Two unrelated issues were reported; I responded to the second. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:58, 9 August 2019 (UTC)

Indeed, but the point of my previous post was that its behavior shows the template is being displayed as if it is part of the body text, and that it should not be displayed that way. The display problem persists'. --EncycloPetey (talk) 14:53, 9 August 2019 (UTC)

It's displaying exactly as expected, given the placement of it and other templates on the page. How would you like it to be shown differently? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:23, 9 August 2019 (UTC)

It's supposed to be displayed below the license tag, the same width as the license tag. —Beleg Tâl (talk) 17:17, 9 August 2019 (UTC)

← On the page in question, the templates are occur in the markup in this order:

{{Authority control}}
{{Pd/1923|1927}}

and so they display in that order. The solution to this issue is left as an exercise for the reader. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:39, 9 August 2019 (UTC)

@Andy Mabbett: Can you please specify the alleged solution instead of the irony? Thank you. --Jan Kameníček (talk) 06:50, 10 August 2019 (UTC)

Arbitrary break (Auth. control squashed)

This needs an interface admin to fix (ping Billinghurst: are you up for it?).

The problem here is that MediaWiki:PageNumbers.js uncritically wraps all page content (everything generated directly from the wikimarkup that we can edit) in a set of layout containers that it needs to do the layout it needs. That leaves things like authority control and license boxes inside those layout containers and makes them subject to the same layout that the rest of the content are. Since this is not desirable there are manual fixup functions added to MediaWiki:Common.js that move these page elements outside the layout containers that PageNumbers.js just wrapped them in (note the fragile dependency on load order here, btw).

The code that moves {{authority control}} out of the layout containers is:

  …
  $( 'table.acContainer' ).insertAfter( $( 'div.printfooter' ) );
  …

Note that it uses a selector specifically for a HTML table element, and it looks for a specific class attribute. When Module:Navbox was updated from enwp two things happened: 1) the custom code we use here for adding a class to a navbox (which authority control makes use of) was overwritten and thus stopped adding that class, and 2) navboxes switched from being based on tables and are instead based on div elements. Thus neither part of the selector would match, and the authority control box was no longer moved out of the layout containers, leading to the squashed appearance noted here.

I have added back in the custom code to Module:Navbox, so the ".acClass" part of the selector will now match. But the assumption that the box is a table needs to be changed in MediaWiki:Common.js which requires interface admin rights to modify. The needed change is to simply drop the "table" bit of the selector, making the line:

  …
  $( '.acContainer' ).insertAfter( $( 'div.printfooter' ) );
  …

I can't really test this change (all this stuff is happening in global javascript that is loaded unconditionally), but so far as my code analysis can determine that should be sufficient. And that selector shouldn't be that specific in any case: selecting for the class name should be both sufficient and a lot more flexible. --Xover (talk) 10:02, 10 August 2019 (UTC)

Done change made; if it isn't right, then it isn't going to kill much. — billinghurst sDrewth 10:35, 10 August 2019 (UTC)

Thanks! I've also started a discussion at enwp to see if we can get the necessary parameter added upstream so we won't have to keep patching it in every time we resync from there. --Xover (talk) 10:39, 10 August 2019 (UTC)

deterioration on subpages

It seems that we have had what I call an less than desirable practices occurring on subpages, and not being picked up in patrolling

1. The addition of year parameter
2. running and repeating notes
3. The use of a hard title rather than [[../]]

For the first two, they should only be appearing at the top level of a work, the subpages would only appear if the detail differs from the parent page. The third point, enables a link to the top of the work. — billinghurst sDrewth 12:06, 5 August 2019 (UTC)

Also to note that I am coming across numbers of hard links for prev/next rather than relative links. — billinghurst sDrewth 12:08, 5 August 2019 (UTC)

There is no guideline recommending the date be omitted on subpages. For many works hosted here, subpages can contain complete works in and of themselves (poems, plays, translations), for which the year is a desirable inclusion. Notes can be especially helpful on articles to provide the citation form for academic articles. The use of a sem-hard title is sometimes necessitated (i.e. [[../|TITLE]] ) especially in cases where the work's main page title is a disambiguative title containing elements which are not part of the title itself. In short, none of these things you've listed is a problem, in and of itself. You'll need to provide specifics as to what sort of instances you see as problems. --EncycloPetey (talk) 15:01, 5 August 2019 (UTC)

Ditto, I’m not sure what the problem is. Yeah, I wouldn’t need to repeat the year every page if it was inherited from the volume, but as for the others ... do you object to the use of the notes field as a place to put something to page through the parts of a serial work [see example]? It’d be nice if there was a dedicated way of putting that at the head and foot of the serial part, but otherwise, notes is the natural place for it at the top, and at the bottom, I link the "to be continued" to the next part. For the latter I use a hard link so it is clickable from Page namespace. --Levana Taylor (talk) 15:24, 5 August 2019 (UTC)

There is the template {{series}}, though in my opinion it's kind of ugly and your solution is nicer. —Beleg Tâl (talk) 02:26, 6 August 2019 (UTC)

Just a note, the "year" parameter is supposed to be the year of the edition, so having a different year on different subpages should only be the case for works that are published in parts over the course of several years (such as some multi-volume works). —Beleg Tâl (talk) 02:11, 6 August 2019 (UTC)

Indeed, I have worked on a three volume series in which each volume was published in a different year, or where our local copy of a particular volume comes from a different year than the other volumes. But it is also not unusual in works I have done for the subpage to contain a work complete in and of itself (journal article), or complete edition or translation of a work (play or poem) included within a volume that contains multiple works. It is useful then to have the date of publication displayed on the same page with that edition/publication, rather than force the reader to go to another page looking for the date that particular edition was published. --EncycloPetey (talk) 22:01, 7 August 2019 (UTC)

Is this written somewhere? I'm not arguing about the points, but it's hard to know what to do or expect others to know what to do if it's not written down anywhere.--Prosfilaes (talk) 02:01, 6 August 2019 (UTC)

Auto generated headers always include the year, and personally I will add the year to subpages if it is omitted. —Beleg Tâl (talk) 02:07, 6 August 2019 (UTC)

It's worth noting that despite the disagreement on this point, I agree that it is undesirable to have general notes regarding the work repeated on every subpage, and of course hard title links on subpages are a bad practice and should be fixed when seen (and I mean specifically [[Title]] and not [[../|Title]], the latter of which is excellent practice). Even worse are works where the subsections are top-level pages, though these are usually really old collections of poetry, and I haven't seen any new works added in this way recently. —Beleg Tâl (talk) 02:15, 6 August 2019 (UTC)

•  Comment The year in the header replaced the manual addition of [[Category:YYYY works]] and categorises the work (primary purpose), and tagged the top level the work, and was added as a parameter to be a good cue to do the addition, as it had been sporadic in its addition in the early years [check archives of this page]. Why would we want every subpage categorised? The year has been the year published, and has been for years; and the practice for the use of the notes field for specific additional detail is the purpose of the notes field, and has regularly carried additional detail like "written in YYYY", "first published in ...". Where we have a three volume/three different year work, then that is the time that we would look to identify volumes specifically, and it is why it remains as an option to be used as required.— billinghurst sDrewth 11:48, 10 August 2019 (UTC)

The dating of the volumes of Once a Week seems problematic, then, because the collected volume was assembled in e.g. 1862, but some of the contents had appeared in 1861. Currently the date is being entered as "1861-1862," which prevents "xxxx work" from being created automatically. I have no problem with entering only 1862 for the volume’s own page, but it leaves me puzzled what to do on subpages. There should be a date on each subpage so that stories and articles are categorized by date. But, the ones that appeared in 1861 should probably be "1861 work." The problem is that when you enter the year parameter the year is displayed next to the title of the main work. What to do when you want to enter a year that is different from that of the volume? Admittedly, this may not be a very big problem, since the only issue from the previous year included in the volume is the last week of December! So if you categorized a story from Dec. 27, 1861, as an "1862 work" that’d hardly be very inaccurate… Levana Taylor (talk) 16:01, 10 August 2019 (UTC)

The categorization of the work is not the only purpose of the year in the header (otherwise it would categorize only and not display). I think that having the year in the header of a subpage is as valuable as having the author in the header of a subpage, if only so that the top line of WORK (YEAR) BY AUTHOR remains relatively consistent on all pages of the work. —Beleg Tâl (talk) 01:16, 11 August 2019 (UTC)

• The notes fields was designated to cover all the non-published content that was going to be of valuable to a page. It is why we poke {{CompactTOCalpha}}, {{Illustrator}}, and the like in that space. — billinghurst sDrewth 11:49, 10 August 2019 (UTC)

OT re illustrators -- Is it encouraged to creat "Author" pages for illustrators who don't have text works? I couldn’t find anything about this in help. Levana Taylor (talk) 16:01, 10 August 2019 (UTC)

@Levana Taylor: definitely create Author pages for illustrators. See Category:Illustrators for examples. —Beleg Tâl (talk) 01:13, 11 August 2019 (UTC)

{{Illustrator}} has an #ifexist statement, so reactively it will hyperlink to existing author pages.

Template:URL to diff

Please can someone import w:Template:URL to diff from en.Wikipedia? Its use is described over there. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:15, 9 August 2019 (UTC)

Done — billinghurst sDrewth 08:30, 10 August 2019 (UTC)

@Billinghurst: Thank you, but it seems to be missing w:Module:OutputBuffer and w:Template:Subst only. Please could you also import those and an further child items? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:30, 10 August 2019 (UTC)

Brought over the module. Not brought over the template, we will need to edit it out of wherever it is. You will need to work out whether there are other templates that need importing and let us know. — billinghurst sDrewth 12:40, 11 August 2019 (UTC)

Thank you. Let's see 9533417. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:12, 11 August 2019 (UTC)

No :-( the displayed text is "diff", it should be "if this works". It seems that {{diff}} works differently on this project. Can anyone see any issues with updating it to work like w:Template:diff? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:16, 11 August 2019 (UTC)

Tech News: 2019-33

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

• Editors using the mobile website on Wikipedia can opt-in to new advanced features via your settings page. This will give access to more interface links, special pages, and tools. Feedback on the discussion page is appreciated. [4]
• Due to the absence of volunteer maintenance of Cologne Blue skin, the link to activate it will be hidden. The skin will still work, but editors using it are encouraged to switch to another skin. [5]

Changes later this week

• Due to Wikimania, there is no deployment this week. [6]

Meetings

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

Future changes

• The "Wikidata item" link will be moved from "Tools" to "In other projects" section on all Wikimedia projects, starting on August 21. Full announcement, Phabricator task.

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

18:19, 12 August 2019 (UTC)

SVG?

For simple graphics like the image on Page:Aircraft in Warfare (1916).djvu/250, is it best to take a screenshot, or find someone who can recreate them as SVG graphics? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:54, 12 August 2019 (UTC)

It's definitely worth recreating them as SVG if possible, but screenshots are ok too if you don't have someone to recreate them in SVG. —Beleg Tâl (talk) 20:25, 12 August 2019 (UTC)

Suggested changes Template:Header

Template:Header has been mishandling translations of subpages where the subpages have page specific & different information from the work, I started a discussion at Template talk:Header a little while back. I have made suggested changes to the sandbox for the template with testcases. I would appreciate if someone could look at the changes, and if considered problematic, then please put such commentary and suggestions on the template's talk page. Thanks. — billinghurst sDrewth 10:56, 13 August 2019 (UTC)

The Works of the Right Honorable Edmund Burke/Volume 2 (minor admin request)

Was meant to be a simple replacement of an unsourced text with a scan but for some reason I've been having a complete brainfart putting these in the right place. This and the one subpage at The Works of the Right Honorable Edmund Burke/Volume 2/Speeches at Bristol, 1774 should be at The Works of the Right Honourable Edmund Burke (or possibly something more specific like The Works of the Right Honourable Edmund Burke (1887) because there are a bunch of versions by different publishers all called that). Would be grateful if an admin could move them and delete the pointless hanging redirects I've been leaving while bumbling around (Works of the Right Honorable Edmund Burke/Volume 2/Speeches at Bristol, Works of the Right Honorable Edmund Burke/Volume 2/Speeches at Bristol, 1774, Works of the Right Honorable Edmund Burke/Volume 2). —Nizolan ^(talk) 16:16, 14 August 2019 (UTC)

Done

This section was archived on a request by: — billinghurst sDrewth 02:17, 15 August 2019 (UTC)

I've bascily had enough...

Index:Ruffhead - The Statutes at Large, 1763.djvu

Having tried various approaches to get the sidenotes to behave CONSISTENTLY over the long term, (and in a manner which is translateable to the other Wikisource on which the equivalent French and Latin parts are transcribed. I've effectively found it's IMPOSSIBLE to use ANY of the approaches in a way that would adequately represent the text this particular volume.

If this kind of work can't be adequately represented (and currently I feel it can't), then it's not worth the hassle in retaining it, despite the considerable effort expended in trying to find appropriate ways to represent what's present figuratively, and ALL nine volumes should be removed from English Wikisource. (The scanned volumes can be retained at Commons, until someone is actually prepared to make the back end changes needed to adequately represent it.). ShakespeareFan00 (talk) 14:21, 13 August 2019 (UTC)

I've mentioned the issue with the side-notes as well as various incompatibilities with other typographic templates repeatedly in the past (with certain contributors apparently unwilling to attempt an update to either the templates or back end code, for entirely practical reasons). Currently when there are a number of indivdual sidenotes close together, or another "floated" template, the positioning of sidenotes can be unexpected, and they can also undesirably overlap. This is down to the use of "position:absolute;" and an inline span. The use of this means that in the absence of specfying a vertical shift on the subsequent sidenotes in a line, they all map to the same horizontal postion on the SAME line, which means naturally that they will overlap (which is not what is typically desired.)

The alternative approach, and the one which would be considerably more benefical to contributor sanity in the long-term is to finally STOP trying to shorehorn sidenotes and sidetitles in as "inline" content in the first place. They should be in a seperate part of the "dynamic" layout. However, based on past experience I don't see this being implemented any time in the next decade.

ShakespeareFan00 (talk) 14:48, 13 August 2019 (UTC)

Sidenotes are problematic, and we know it. Few of us have the CSS skills, and they don't translate well to modern broad landscape screens from portrait pages. Most of us just shy awy from such works, and do something else. We don't keep hammering away on the blindingly difficult. — billinghurst sDrewth 14:52, 13 August 2019 (UTC)

Well on that basis, I will certainly consider putting all the content related to this at Proposed Deletions. If it can't be adequately represented, there's no point in hosting a partial and poor version. Most of it's raw unproofread OCR in any instance. ShakespeareFan00 (talk) 15:47, 13 August 2019 (UTC)

I also from your comment, will reconsider if certain other partially transcribed works, should also continue to be hosted in their current formats, if there's a lack of expertise to support the functionality necessary. ShakespeareFan00 (talk) 16:13, 13 August 2019 (UTC)

I will also (again) note that the sidenotes issue isn't assisted by a lack of documentation of how the underlying code is intended to function, (such as the relevant classes and document structuring), as i found when attempting to figure out what broke in the various approaches used.ShakespeareFan00 (talk) 16:35, 13 August 2019 (UTC)

i would support a consensus of proceeding without sidenotes. we could note that at these works, and move on. Slowking4 ⚔ Rama's revenge 17:32, 13 August 2019 (UTC)

no need to delete, it is not a deletion rationale, rather a lack of consensus of how to proceed, with a backlog. raw OCR is better than nothing. Slowking4 ⚔ Rama's revenge 19:19, 13 August 2019 (UTC)

I agree with @Slowking4: The presence of sidenotes is rarely something I'd view as a make-or-break issue. Texts are generally just fine without them, and it's not mission-critical that all printers' decisions be represented accurately. That said, I appreciate the efforts of @ShakespeareFan00: and others to create tools to make it work as well as possible. -Pete (talk) 18:05, 13 August 2019 (UTC)

yeah, it was an attempt to replicate the marginalia of manuscripts.[7] and we attempt to preserve the anachronism. it was worth an effort, but i would move on, without them. it’s a wiki and if a better solution comes along, we can always add them in. Slowking4 ⚔ Rama's revenge 19:22, 13 August 2019 (UTC)

It would also be nice if (as opposed to having various ever so slightly different templates), there was ONE template for doing sidenotes, margin notes etc, that actually worked in all use-cases, so far there have been various and inconsistent different templates used in this work, which is why it may be easier to start again completely, with someone else ENFORCING and FULY DOCUMENTING a SINGLE approach for how it's SUPPOSED to be done, as opposed to the various inconsistent experimental approaches, various contributors (myself included) have attempted. ShakespeareFan00 (talk) 20:48, 13 August 2019 (UTC)

For sidenote references like the ones in the works linked above the obvious option imo, which I suggested recently for Index:Commentaries of Ishodad of Merv, volume 1.djvu recently but haven't summoned up the interest to implement properly yet, is simply to convert them into an ordinary group of footnotes, with notes in the text. Looking at the text I don't see any reason why that would be an inadequate representation of the data in this case. The only problem is deciding where exactly to put the notes in the text, but that's an issue for sidenotes anyway. They can't just be ignored, though, they are an integral part of the work. —Nizolan ^(talk) 00:21, 14 August 2019 (UTC)

Noting ftr that discussion is split here and Wikisource:Proposed_deletions#Index:Ruffhead_-_The_Statutes_at_Large,_1763.djvu —Nizolan ^(talk) 00:32, 14 August 2019 (UTC)

An aside , but it's essentially Biographical research on 18th and pre-18th century English Jurists and legal scholars, would be the list I started compiling here- Index_talk:Ruffhead_-_The_Statutes_at_Large,_1763.djvu#Identification_of_references.. Knowing the authors cross refrenced (and the editions of the works concerned) might help in placing the sidenotes. ( especially if the cross-referenced editions are now online in scanned form somewhere.)ShakespeareFan00 (talk) 07:26, 14 August 2019 (UTC)

British English in an American work

I'm new here, and I can't find any guidelines on this. The question came up as I read Jack London's John Barleycorn. London is an American author, and the book is a memoir set in the US, but the Wikisource version contains distinctly British spellings such as 'meagre' and 'centreboard'. The original at Project Gutenberg has no obvious publisher information. Google Books has versions published in the US, with American spelling (e.g. this one from Century) and others published in the UK, with British spelling (e.g. this from Mills & Boon).

The WS version with British spelling is true to the source in the sense of being faithful to the Project Gutenberg file, but not, I believe, in showing the book as it was originally written and published. What should be done? I see several options, in order from least amount of work required to most:

1. Do nothing.
2. Change the current WS version to American spelling.
3. Add a new source file with the American version.

My preference would be the second: The book's language would then reflect its American origin, and the amount of labo(u)r involved would be minimal. Would this violate any policies or guidelines? BlackcurrantTea (talk) 04:50, 14 August 2019 (UTC)

We do not do ad-hoc changes to works. WS:Annotations is limited, and is only ever done on a separate copy of the work. If you want this, you'll need to add a new source file and transcribe it.--Prosfilaes (talk) 05:55, 14 August 2019 (UTC)

If the original edition used different spelling, than the best solution is to upload scans of the original edition to Commons and transcribe it separately. --Jan Kameníček (talk) 08:15, 14 August 2019 (UTC)

Here is a full scan of the Mills & Boon edition, which uses the spellings of "meagre" and "centreboard" as in our edition. I'd guess it's the edition that the Gutenberg text is based on, and we could use it as a starting point for backing our own copy. —Beleg Tâl (talk) 12:28, 14 August 2019 (UTC)

•  Comment @BlackcurrantTea: Add a new source file with the American version. We publish versions/editions of work and reproduce them as they were published. We are not restricted to one copy of a work, so if you have the time and inclination to work on a publication that is in the presentation from the publisher/edition that you prefer, then that power to you. — billinghurst sDrewth 22:56, 14 August 2019 (UTC)

I'll leave the language in the current one in its UK form, and keep the option of adding a new source text in mind. Thank you all for your replies. BlackcurrantTea (talk) 05:12, 15 August 2019 (UTC)

Scans not showing, again

Having recently uploaded the DJVU file and created Index:Aerial Flight - Volume 1 - Aerodynamics - Frederick Lanchester - 1906.djvu, I am again left with editing windows where the PDF scan is not showing, at all, on the right-hand side, for any of the pages.

If I click on the "image" tab, they render correctly and immediately.

For a while they did show correctly in the editing view.

This occurs even after restarting my browser, and my laptop.

Can anyone advise or assist, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:55, 14 August 2019 (UTC)

@Pigsonthewing: [you mention pdf, for a djvu, so I am presuming that is a slip of the tongue.] I am seeing images, where I visit. What you are mentioning is often (usually?) an artefact of the thumbnail rendering of the media, and it pops its head up at times. One of the means you can force something if it is stuck is to change the image size via the Index page Scan resolution in edit mode, and just change the default by a pixel (here it is a unitless field). It isn't a perfect scenario. — billinghurst sDrewth 23:12, 14 August 2019 (UTC)

@Billinghurst: Yes, I meant Djvu. As you say, it seems to be working OK now. Thanks for the tip. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:54, 16 August 2019 (UTC)

This section was archived on a request by: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:55, 16 August 2019 (UTC)

Update on the consultation about office actions

Hello all,

Last month, the Wikimedia Foundation's Trust & Safety team announced a future consultation about partial and/or temporary office actions. We want to let you know that the draft version of this consultation has now been posted on Meta.

This is a draft. It is not intended to be the consultation itself, which will be posted on Meta likely in early September. Please do not treat this draft as a consultation. Instead, we ask your assistance in forming the final language for the consultation.

For that end, we would like your input over the next couple of weeks about what questions the consultation should ask about partial and temporary Foundation office action bans and how it should be formatted. Please post it on the draft talk page. Our goal is to provide space for the community to discuss all the aspects of these office actions that need to be discussed, and we want to ensure with your feedback that the consultation is presented in the best way to encourage frank and constructive conversation.

Please visit the consultation draft on Meta-wiki and leave your comments on the draft’s talk page about what the consultation should look like and what questions it should ask.

Thank you for your input! -- The Trust & Safety team 08:03, 16 August 2019 (UTC)

Biodiversity Heritage Library template

Based on {{Google Book Search link}}, I have just created {{BHL page link}} for linking to scans on the Biodiversity Heritage Library. {{BHL}} is available as a shortcut. The template adds pages to Category:Scans from BHL.

The Google template is multilingual; should we do the same with the new template? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:34, 16 August 2019 (UTC)

Smithsonian Transcription Center

I just saw https://transcription.si.edu/about at wikimania:2019:GLAM/The Smithsonian: A Partnership to Improve Gender Representation Online. It was started in 2013 and apparently it has hundreds of volunteers transcribing catalogue cards etc. It's based on Drupal and I'm told they're trying to publish it as free software. Nemo 13:11, 16 August 2019 (UTC)

yes, if you get tired of wikisource there is always transcribe.si, and https://crowd.loc.gov/ and https://www.archives.gov/citizen-archivist institutions are rolling out crowd transcription of archival collections to increase find-ability. a lot of their star performers are disgruntled wikipedia editors. Slowking4 ⚔ Rama's revenge 13:09, 17 August 2019 (UTC)

Birth& death dates

I just created Author:Alfred Davidson. Where did the birth & death years come from? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:11, 16 August 2019 (UTC)

From Wikidata, which got them from the Wikipedia article. Beeswaxcandle (talk) 19:17, 16 August 2019 (UTC)

I believe that they come straight from enWP, without a query of WD. It looks for the same named article at enWP and pulls the birth and death years categories. — billinghurst sDrewth 15:07, 17 August 2019 (UTC)

This occurs through the gadget preloader which is OFF by default ... MediaWiki:Gadget-TemplatePreloader.js — billinghurst sDrewth 15:40, 17 August 2019 (UTC)

From which Wikidata item/ Wikipedia article? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:19, 16 August 2019 (UTC)

From w:Alfred Davidson, specifically from the categories, I believe. See {{author}} for details. --Xover (talk) 19:26, 16 August 2019 (UTC)

Which is about sometime else entirely. That's very unhelpful, possibly harmful. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:36, 16 August 2019 (UTC)

That's why the phrase "once matched" is in the automatic header fields. If it's a different one, then enter the correct years and disambiguate the name. Beeswaxcandle (talk) 19:45, 16 August 2019 (UTC)

There's no need to do that; if the correct yeays are known, they can or will be in - and transcluded from - Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:15, 17 August 2019 (UTC)

welcome to disambiguation. constant vigilance required for authors and consider careful authority control. Slowking4 ⚔ Rama's revenge 12:57, 17 August 2019 (UTC)

Having worked on Wikipedia since 2003, and Wikidata since 2012, I'm very familiar with disambiguation issues. I'm still not seeing any advantage in incuding dates such as those in my OP. Can anyone give evidence of any? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:01, 17 August 2019 (UTC)

It pre-dates WD, and was done to assist in matching to WP with the provision of data, and it has worked very well over the years. These days, as we encourage all years of birth and death to be removed and for that data to be in WD, it doesn't particularly matter. As pretty well every author page created is reviewed, then it is moot point, and the evidence of thousands of additions over many years it has not been problematic. That said, we can have the review of the continued usefulness of the function. — billinghurst sDrewth 15:03, 17 August 2019 (UTC)

I think Andy has a good point here -- now that Wikidata matching has become common, and useful in so many cases, it might be time to turn off this once-useful feature that sometimes leads to incorrect information. It's not immaterial, because sometimes it takes a while for somebody to get around to linking up the Wikidata item with the Wikisource page. I agree with Andy, it would be better in such cases if the dates were blank, than to have possible errors. -Pete (talk) 17:31, 17 August 2019 (UTC)

Index:Experimental researches in chemistry and.djvu

The file was moved at Commons. So another contributor in good faith, moved the Index. However, the associated Pages did not move at the same time, (and the transclusions would need updating if they were.) I thought consensus was that actually moving an entire Index (and Pages:) was pain, that it wasn't typically done unless there had been a consultation for this reason. Maybe an admin would like to sort out the mess created? ShakespeareFan00 (talk) 10:57, 18 August 2019 (UTC)

I've moved it back in the meantime. It will continue to work ok via redirect. I support the idea to rename it, but there's no way I'm going to go through all that myself. —Beleg Tâl (talk) 13:20, 18 August 2019 (UTC)

Undone at Commons; undone here. @Ixocactus: please don't move djvu and pdf files that are in use at the Wikisources, it can just be problematic. — billinghurst sDrewth 13:30, 18 August 2019 (UTC)

Hi people. Sorry for the mess. I tried be bold. Thanks @Billinghurst: for notice me and for the correction of my unexpected errors. I will take care. Ixocactus (talk) 14:53, 18 August 2019 (UTC)

The quirks of all the systems, and the various designs and interactions! <shrug> Thanks for your understanding Ixocactus — billinghurst sDrewth

Concerns...

No longer relevant.

As some of you have concerns about my apparent inability to raise concerns without going into undesirable rants, would it be better if I just stopped contributing altogether? ShakespeareFan00 (talk) 14:17, 16 August 2019 (UTC)

And given my apparent lack of expertise to figure out certain issues, I am considering leaving anyway. ShakespeareFan00 (talk) 15:05, 16 August 2019 (UTC)

???? -Pete (talk) 16:26, 16 August 2019 (UTC)

The response to certain queries I made in the last few days has been pretty blunt.ShakespeareFan00 (talk) 17:09, 16 August 2019 (UTC)

Like you feel frustration with the technical limitations and lack of volunteers with the requisite expertise or capacity to work around them, others may get frustrated with your expressing those frustrations and express that in turn. I don't think you should take that as anything more serious than just that: an expression of frustration.

But when you bang your head against the wall to such an extent that every little quirk frustrates you, you either need to change your approach (don't aim for such a high level of perfection, for instance; or find a simpler problem to work on) or take a break until you're able to work at the problem again without causing yourself unreasonable stress. Contributing here is supposed to bring you joy or a sense of achievement or fulfilment; not endless frustrations.

While I'm sure everyone would prefer if you managed to slightly tone down the "rants", I'm also sure most are perfectly comfortable overlooking them as needed. We all get frustrated now and again so you're hardly alone there. Take to heart feedback when you get it, certainly, but don't blow it out of proportion: "your expressions of frustration are getting to be a bit much" does not mean "you're not welcome here", no matter how bluntly delivered. --Xover (talk) 18:01, 16 August 2019 (UTC)

I don't know the backstory at all, but I'll say this much:

1. I think you make a ton of useful contributions, and can't imagine a reason I wouldn't want you around
2. Xover's words above seem particularly wise, and apply to many situations I have seen or been involved in on wikis...I don't know enough to know how well they apply here, but my gut says...this is good advice
3. I hope that it doesn't become commonplace to discuss the welcomeness of project members here on the Scriptorium, it seems to me that cases where somebody actually is unwelcome are vanishingly rare, and probably better handled in a more private and respectful way than on the main project discussion page. -Pete (talk) 21:43, 16 August 2019 (UTC)

doesn't bother me. diplomacy makes communication better received. your self-care is important and up to you. need to take breaks if necessary for long term health. this is a pretty laid back project, but your results may vary. Slowking4 ⚔ Rama's revenge 13:03, 17 August 2019 (UTC)

This section was archived on a request by: --Xover (talk) 07:43, 19 August 2019 (UTC)

Tech News: 2019-34

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

• There will be no Tech News issue next week. The next issue of Tech News will be sent out on 2 September 2019.

Problems

• Some abuse filters stopped working because of a code change. Only variables for the current action will work. Variables defined inside a branch may not work outside of that branch. You can read more to see how to fix the filters.
• Only six accounts can be created from one IP address per day. Between 12 August and August 15 this was two accounts per day. This was because of a security issue. It is now six accounts per day again. [8]

Changes later this week

• Only a limited number of accounts can be created from one IP address. An IP address can be whitelisted so that it can create as many accounts as needed. This is useful at events where many new persons learn to edit. IP addresses that are whitelisted for this reason will also not show CAPTCHAs when you create accounts. This will happen on Wednesday. [9]
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 20 August. It will be on non-Wikipedia wikis and some Wikipedias from 21 August. It will be on all wikis from 22 August (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 21 August at 15:00 (UTC). See how to join.

Future changes

• There is an RFC about creating a new global user group with the right to edit abuse filters. This will be used to fix broken filters and make sure all filters will still work when software changes happen. You can read more and comment.
• Special:Contributions/newbies will no longer be working. This is because of performance reasons. It showed edits by new accounts. You can see this in the recent changes feed instead. [10]

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

15:21, 19 August 2019 (UTC)

Namespace link only for main namespace

Would it be possible to modify the {{Namespace link}} and add a parameter that would enable not to show the link when transcluded to other namespace than the main namespace? I often use this template in the contents pages (example), but when the links are made relative the resulting red links in the index pages (example) are quite confusing. --Jan Kameníček (talk) 08:10, 20 August 2019 (UTC)

Whilst I created it, I simply don't use it any more. Just do normal links, rather than template them. — billinghurst sDrewth 10:13, 20 August 2019 (UTC)

@Billinghurst: Not using the template would not solve anything: relative links would turn red anyway. The main advantage of the template is for relative links, which are blue in the main namespace, but would turn red in the Page namespace. However, it would be good if they stayed black also when transcluding to other namespaces besides the main namespace. --Jan Kameníček (talk) 12:44, 20 August 2019 (UTC)

Sure, but do absolute links. What is it achieving with non-display? Nothing particularly valuable. — billinghurst sDrewth 12:53, 20 August 2019 (UTC)

Well, relative links are much better than absolute links. There are often really many links in the Contents page of the work, and when later the work is moved to a different name, all absolute links have to be changed, while relative links work even after the move. The disadvantage is, that relative links turn red in the Page and Index namespace, which is really confusing (if you look e. g. at Index:Pictures In Rhyme.djvu, it looks as if the work has not been transcluded yet), and so it is better if they stay black. --Jan Kameníček (talk) 13:03, 20 August 2019 (UTC)

I think in this case absolute links are better than no links. Noting also that the links in the TOC field interact with the ProofreadPage extension directly, especially when auto-generated headers are being used. A better way would be to have it generate the correct links automatically, but IDK if that is even possible —Beleg Tâl (talk) 13:09, 20 August 2019 (UTC)

(ec) You don't really need to tell me about the links, I think I am pretty aware by now. In a table of contents, if a page is moved, it is a simple process to run a regex through and update them all.

The advantage of having proper active links that display with functional links from the ToC page is most beneficial when transcluding these pages into the Index namespace, and then using that page to create subsidiary pages of a work. — billinghurst sDrewth 13:14, 20 August 2019 (UTC)

LinkedLintErrors

I made a thing: it's a sidebar link that retrieves a list of lint errors for any page, and all the pages linked from that page. If anyone wants to give it a whirl, add this to your common.js:

mw.loader.load('//en.wikisource.org/w/index.php?title=User:Samwilson/LinkedLintErrors.js&action=raw&ctype=text/javascript');

I just wanted a way to get lint errors for a single Index page. It seems to work.

Sam Wilson 10:54, 20 August 2019 (UTC)

Thanks, please note that there are some LintErrors whose repairs might be considered cosmetic. ShakespeareFan00 (talk) 11:21, 20 August 2019 (UTC)

@ShakespeareFan00: Good point. I'm mainly hunting down issues being reported by epubcheck, so will mostly ignore other minor ones. Sam Wilson 22:16, 20 August 2019 (UTC)

Scans of La Fayette, or, the Castle of Olmutz needed

If somebody were able to get scans of La Fayette, or, the Castle of Olmutz, a drama in three acts, they would make me (an Olomouc/Olmutz citizen) particularly happy :-) --Jan Kameníček (talk) 14:45, 20 August 2019 (UTC)

@Jan.Kamenicek: Not a scan, but a transcription; File:La Fayette, or, the Castle of Olmutz.pdf. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:03, 20 August 2019 (UTC)

Thanks very much! However, I am not sure, what to do with the notice at the end of the transcription, which reads: Database copyright © 2019 ProQuest LLC. All rights reserved... What do you think? --Jan Kameníček (talk) 15:42, 20 August 2019 (UTC)

proquest is a US company, so i do not know why they are flouting US law. i would ignore it as copyfraud. see also w:Database_right#United_States -- Slowking4 ⚔ Rama's revenge 20:16, 20 August 2019 (UTC)

I agree with Slowking4. In any case, are we copying the database? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:17, 20 August 2019 (UTC)

no - that looks like a gutenbergish transcription from the microfilm which is widely available [11]; i see a hard copy at villanova [12] and elsewhere [13] the metadata is bad as an old script, we need to do the legwork to get it to Internet Archive.

interesting question if transcriptions are sweat of the brow copyright. in US probably not. hence the invocation of databases. -- Slowking4 ⚔ Rama's revenge 20:21, 20 August 2019 (UTC)

I see. Thanks very much again. --Jan Kameníček (talk) 20:34, 20 August 2019 (UTC)

As it is not very clear from the available pdf what the original book looked like, so I think I will just transcribe the text and will not take the formatting into account that much (it can be improved later if scans of the original get available).

The introductory table of the characters and actors seems quite confusing, so it would be great if somebody had a chance to check it in a printed original.--Jan Kameníček (talk) 22:28, 20 August 2019 (UTC)

New tools and IP masking

Hey everyone,

The Wikimedia Foundation wants to work on two things that affect how we patrol changes and handle vandalism and harassment. We want to make the tools that are used to handle bad edits better. We also want to get better privacy for unregistered users so their IP addresses are no longer shown to everyone in the world. We would not hide IP addresses until we have better tools for patrolling.

We have an idea of what tools could be working better and how a more limited access to IP addresses would change things, but we need to hear from more wikis. You can read more about the project on Meta and post comments and feedback. Now is when we need to hear from you to be able to give you better tools to handle vandalism, spam and harassment.

You can post in your language if you can't write in English.

Johan (WMF)

14:19, 21 August 2019 (UTC)

Proposal to enable blocking functionality for abuse filters

A proposal is open at WS:AN#Upgrading our abuse filters to allow blocking until August 29. All community members are invited to contribute to the discussion. BethNaught (talk) 07:21, 23 August 2019 (UTC)

Template issue

I've used {{Plainlist}} over multiple pages, by closing and reopening them in the headers/footers, but they don't render correctly on Aerodynamics (Lanchester)/Contents. Where have I gone wrong? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:14, 21 August 2019 (UTC)

You have to use the "split" templates: {{plainlist/s}} and {{plainlist/e}}, e.g. this diff. Because the individual pages are rendered one at a time, and then transcluded all templates opened with {{ in the page body must also be closed within the page body. Otherwise the {{ and }} are part of two separate rendering processes. By using split templates, you can "open" the template's effect, while not crossing the body/footer boundary with an unclosed template syntax. Inductiveload—talk/contribs 15:43, 21 August 2019 (UTC)

You can use the simple process on the intermediate pages as it will still have the complete template, and display properly, the important part is to have the open (/s) and close (/e) versions on the first and last pages. We tend to just use the /s & /e versions wherever they are split as it is more transparent and informative. — billinghurst sDrewth 04:24, 23 August 2019 (UTC)

Old taxonomists, published, but missing from Wikisource

This Wikidata query may be of interest:

https://w.wiki/7MQ

It shows people, who died before 1949 (so whose works are out of copyright, by the lifetime + 70 years rule), with a Wikispecies entry, but no entry in any Wikisource.

There are currently 4,413 results.

Some caveats:

• If these people co-authored papers with others who died later (or still live), those papers are not out of copyright
• Some of them authored no works in English
• Some taxonomists, who have an entry on Wikispecies and in a non-English Wikisource (so are not included in the results), could still have an entry here
• Wikispecies lists no publications, for some of their entries.

-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:08, 22 August 2019 (UTC)

Very interesting! Just one small problem: I have noticed that quite a lot of people (e.g. Jean Antoine Arthur Gris) are being listed twice in the query. --Jan Kameníček (talk) 17:36, 22 August 2019 (UTC)

Fixed. That brings it down to 4243 results. —Beleg Tâl (talk) 18:33, 22 August 2019 (UTC)

I will try to proofread some texts of a couple of them. --Jan Kameníček (talk) 19:42, 22 August 2019 (UTC)

There's a big caveat that we use US copyright laws, so life+70 is irrelevant. Lots of those authors may have published only after 1923, and lots of authors with US-PD works may have died less than 70 years ago.--Prosfilaes (talk) 03:41, 23 August 2019 (UTC)

Yes and no. We would still apply copyright status and copyright tags, so pages would be tagged BUT I still don't think that we should be creating pages if we don't have one of: works reproduced, or a list of works, or the pages are wikilinked targets for authors in reproduced works. If we are adding something of value, then create the author page, if it is to contain the {{populate}} tag and nothing else, then please don't bother, there is not a lot of value in such pages for us or for users. — billinghurst sDrewth 06:40, 23 August 2019 (UTC)

I'd also note that we have 1463 works with non-existent author pages already here on Wikisource, which in my opinion is a slightly higher priority if people want to create missing author pages. —Beleg Tâl (talk) 13:06, 23 August 2019 (UTC)

• If someone (possibly using a bot) could create a page that lists all the names, I could go through and mark which names have (1) no works published, (2) no works published in the English, or (3) no works published in the public domain. TE(æ)A,ea. (talk) 21:30, 23 August 2019 (UTC).

  I truly don't believe that it is a priority; tail wagging dog stuff. Crete stuff that is known to be needed, not stuff that does not represent what we have. — billinghurst sDrewth 06:23, 24 August 2019 (UTC)

Links to authors in Wikispecies

If an author, such as Ferdinand Stoliczka, has an entry in Wikispecies, the entry automatically is listed in the Sister projects box in the header. However, the link is labelled as "taxonomy", which is imo quite confusing. Is there a possibility to change it? --Jan Kameníček (talk) 08:13, 24 August 2019 (UTC)

It is our label, it can be whatever the community decides. It went through a discussion at the time, and it was a tough one to find the exactly right label for all links to wikispecies from all namespaces. — billinghurst sDrewth 08:16, 24 August 2019 (UTC)

"Wikispecies". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:29, 24 August 2019 (UTC)

Agree: It is easy, expected and should be OK for all namespaces. --Jan Kameníček (talk) 22:57, 24 August 2019 (UTC)

Template:unsigned2

Please will someone import w:Template:unsigned2 from en.Wikipedia? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:36, 24 August 2019 (UTC)

Can't you just use {{unsigned}}? Seems fairly redundant to have competing templates. — billinghurst sDrewth 23:53, 24 August 2019 (UTC)

They are not "competing". {{unsigned2}}, when it is Subst, leaves behind a copy of {{unsigned}}; but the inputs it takes are in reverse order, so can more easily be copied and pasted from page histories. This is all explained in the documentation of w:Template:unsigned2. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:41, 25 August 2019 (UTC)

They both put "unsigned", how is that not competing? We have been trying hard for years to not have template gumph and bloat, and to make do. Just put 2= and 1= in the front and you achieve the same thing with positional parameters. It isn't that hard. — billinghurst sDrewth 11:46, 25 August 2019 (UTC)

No, I wont "adapt" (per your edit summary), because {{unsigned}}, even with positional parameters, requires me to do more work (both cognitive, and physical keystrokes) than does {{unsigned2}}. They do not "compete" because one aids use of the other, and is not an alternative to it. {{unsigned2}} is used, without issue, on en.Wikipedia, seventeen other Wikipedias, Wikidata, Wikinews, Wikiquote, Wikiversity, Wiktionary, Meta-wiki, and Commons. Providing templates to make contributing to Wikisource easier - and less RSI-inducing - for volunteers is not "template gumph", nor "bloat". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:25, 25 August 2019 (UTC)

Multiple transclusions

@RaboKarbakian: Why do we have both Amazing Stories/Volume 01/Number 02/The Infinite Vision and Amazing Stories/Volume 01/The Infinite Vision? IMO, we should usually transclude a work at one spot. I have a mild preference for the first one, but just one so things don't have to be fixed in multiple places.--Prosfilaes (talk) 16:10, 23 August 2019 (UTC)

WS:CSD#G4 says we can delete the duplicate copy - it looks like Amazing Stories/Volume ##/Number ##/Work Name is the standard for this work, so duplicates in other locations should be deleted. Users who can't delete the pages should tag them with {{sdelete}} so that they will be deleted. —Beleg Tâl (talk) 17:35, 23 August 2019 (UTC)

Turn the unwanted into a redirect, either hard or dated soft. — billinghurst sDrewth 06:24, 24 August 2019 (UTC)

From The Infinite Vision, sure. But hard redirects from a subpage to a different subpage are generally deleted anyway as "unneeded redirect", so we may as well skip the redirect step. —Beleg Tâl (talk) 13:29, 24 August 2019 (UTC)

I was making a whole volume and the individual stories. Like taxonomy with family and species. Complex? Maybe. Complicated -- not as much. -- RaboKarbakian (talk) 14:57, 24 August 2019 (UTC)

Is there a problem with having the story in tact? Is there a better way? My answer to both was no, but maybe I am wrong. --RaboKarbakian (talk) 15:25, 24 August 2019 (UTC)

@Prosfilaes: --RaboKarbakian (talk) 17:27, 24 August 2019 (UTC)

Duplicating entries like that means that things have to be fixed twice. It's also confusing; are Amazing Stories/Volume 01/Number 02/The Infinite Vision and Amazing Stories/Volume 01/The Infinite Vision two distinct editions? There's nothing on the pages that makes it clear that they're not. It's impossible to link Wikidata for one edition to two separate pages.--Prosfilaes (talk) 10:57, 25 August 2019 (UTC)

see also Wikisource:Proposed_deletions#The_Dragon-Fly--Slowking4 ⚔ Rama's revenge 13:01, 25 August 2019 (UTC)

... That is completely different, because both versions of "The Dragon-Fly" are clearly different editions. —Beleg Tâl (talk) 13:12, 25 August 2019 (UTC)

we differ on the interpretation of version. they are typographically the same work, as in this example. so now you need a thesis of how a book and periodical are different editions, and two periodicals are not. Slowking4 ⚔ Rama's revenge 15:23, 25 August 2019 (UTC)

Two periodicals are different editions; one periodical transcluded twice is not.--Prosfilaes (talk) 18:10, 25 August 2019 (UTC)

@Prosfilaes: Transclusion is not a duplication. The editable original (as seen with the scanned page is the only thing that might need "fixing". It is more of a reflection than a duplication. You can check this yourself by attempting to alter a properly transcluted page.... I wanted the whole story for the author links and the edition for the magazine to be as it was. --RaboKarbakian (talk) 13:33, 25 August 2019 (UTC)

Transclusion still requires duplication of the header and surrounding text. It's just not clear to the reader that they're different texts, and it's not clear to the editors which page to link to. This started because I was creating Author:Charles C. Winn, and didn't know which to link to.

I'm not sure what your goal exactly is. Why is having Amazing Stories/Volume 01/... better than Amazing Stories/Volume 01/Issue 0x/...? They're all linked together either way. Is this for serialized works? It would be better to link serialized works together in their header than have multiple transclusions of them.--Prosfilaes (talk) 14:23, 25 August 2019 (UTC)

The original publication was in editions with parts of stories. I imagine people waiting for the next edition to come via mail or in the local store or whatever. Like the cliffhanger at the end of a television series. The edition was how these stories were first shared with the public. 100 years later, some of these stories are well known and some of the authors also. Via current technology they can easily be presented both as they were originally published and as a whole. Wikidata can more easily handle them both ways. No additional editing. Author links are easier and if you would like more journalistic accuracy on the whole story a "published in such and such edition on such and such date" statement can be styled and templated in. It's beautiful and simple and not easily accomplished at other ebook sites.--RaboKarbakian (talk) 23:56, 25 August 2019 (UTC)

I think you're confusing "edition" and "issue". An edition would be the same work, but slightly different from other editions. Magazines come in issues.

Magazine volumes do not necessarily contain the whole of a serialized work. Weird Tales, Volume 4, Issue 1, for example, contains the second part of Draconda, continued from the previous issue. Instead of creating a volume collection, I would think it better to take just the serialized works, and transclude them as, say, part by part as Weird Tales/Volume 4/Issue 1/Draconda (part 2) and as one part directly in mainspace as Draconda. This reduces the duplication to just the works that need to be duplicated, and keeps the duplication in different forms.--Prosfilaes (talk) 07:47, 26 August 2019 (UTC)

Oops. s/edition/issue/g --RaboKarbakian (talk) 13:42, 26 August 2019 (UTC)

Wikidata, volumes and editions, and serialized tales

The whole story as shown under the volume namespace gets linked at wikidata to the author and the volume.

The edition also gets linked to the volume.

The story links to every edition it was "part of".

The edition links back to every story that it has a portion of.

It is complicated to look at as a whole but viewing from different perspectives it is complete

(I wrote this on Prosfilaes talk page and pasted it here) --RaboKarbakian (talk) 00:05, 26 August 2019 (UTC)

Organisations as authors

How do we deal with corporate, governmental, and similar authors, for example the red link for "Parliament of India", on Flag Code of India?

I have looked for examples, but have been unable to find any. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:17, 25 August 2019 (UTC)

Portals! See Stratemeyer Syndicate, Council of Trent, Brothers Grimm, Truth and Reconciliation Commission of Canada, &c &c —Beleg Tâl (talk) 18:25, 25 August 2019 (UTC)

Note that with regard to government works, it is common to use something like Parliament of Canada, but linking to Portal:Acts of Parliament of Canada, as there is currently no portal for Portal:Parliament of Canada —Beleg Tâl (talk) 18:28, 25 August 2019 (UTC)

Thank you, but I don't see the answer to my question there. For example on Portal:Stratemeyer Syndicate I selected a random entry, Dick Hamilton's Fortune (one of several I tried, on the various portals you suggest) and it has Author:Howard Roger Garis - a person, not a not a corporate entity. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:53, 25 August 2019 (UTC)

That's because that particular portal includes many texts that do have individual authors. See Canons and Decrees of the Council of Trent from another of BT's suggestions for a better example of what you're looking for. —Nizolan ^(talk) 20:21, 25 August 2019 (UTC)

Most of the "authors" on the Stratemeyer Syndicate portal are nom de plumes that were used by several people. Garis is the odd one out as Stratemeyer allowed him to write the Dick Hamilton series under his own name in return for writing several of the Tom Swift and Bobbsey Twins books under those series' nom de plumes. A portal was the best way we have of gathering the various series together in a coherent way. Beeswaxcandle (talk) 08:48, 26 August 2019 (UTC)

Right, I wasn't questioning the use of the portal lol, just pointing to a more direct example. —Nizolan ^(talk) 12:38, 26 August 2019 (UTC)

•  Comment Wikisource:Portal guidelines is the guidance. Authors is solely people who wrote/illustrated/scored/… and everything else that is compilation should be in portals. — billinghurst sDrewth 10:09, 26 August 2019 (UTC)

Talk pages consultation, Phase 2 report

Please see the mw:Talk pages consultation 2019/Phase 2 report. This relates to Wikisource:Scriptorium/Archives/2019-05#Talk pages consultation: Phase 2.

The main consultation is over. However, we still need to hear from you! Please put the mw:Talk pages project page on your watchlist. Whatamidoing (WMF) (talk) 17:33, 28 August 2019 (UTC)

Updated templates to support curly quotes

Hooray for the adoption of curly quotes! Who’s going to take care of creating equivalents for {{" '}} et al.? I think probably a template that simply places a gap of 0.15em between any pair of characters would do well enough. (Or 0.1em? I am no typographer). Levana Taylor (talk) 18:17, 24 August 2019 (UTC)

In my opinion, {{" '}} should be deprecated in favour of "' and “‘; spacing should be handled by the browser and the font and not by the content. That's just my opinion though. —Beleg Tâl (talk) 22:26, 25 August 2019 (UTC)

Like a couple of people pointed out in the last discussion, browsers don't handle it and there's no real prospect of them doing so any time soon, so I don't see the point of purism here. It's not WS-exclusive either: Wikipedia does the same hack automatically in citations, for example, and once there is widespread support the templates can just be disabled anyway. @Levana Taylor: Spacing arbitrary characters is already possible using {{sp}}, e.g. for “‘ you can do {{sp|“}}‘ for “‘. —Nizolan ^(talk)

That {{sp}} result looks pretty good to me; if other people think so, we don't need the quote-pair template at all. Levana Taylor (talk) 12:53, 26 August 2019 (UTC)

{{sp}} produces a passable visual result—if in a somewhat suboptimal way—by applying a .15em CSS letter spacing. However, creating a template for this one case is trivial: the sum total of the code would be “ ‘ and ’ ” for its mate. This renders as “ ‘ and ’ ” (vs. “‘ and ’”). The challenge is accounting for all the possible combinations we end up permitting, and under sufficiently mnemonic names. --Xover (talk) 15:36, 26 August 2019 (UTC)

Imo the CSS option should actually be preferred to inserting a thin space character, for the reason explained at Wikipedia's documentation: "… It does this with CSS, and does so because the insertion of an extraneous space character of any kind (e.g., &nbsp; or &thinsp;) would violate the semantic integrity of web content in an article or another page in which it appears." {{' "}} etc. also use CSS at the moment, but via padding rather than letter-spacing. Though I'm not particularly bothered either way. —Nizolan ^(talk) 16:37, 26 August 2019 (UTC)

Nah, that's just wankery. These Unicode characters (which does not include &nbsp;, which is an actual space character) are intended specifically for this purpose and has no affect on semantics. The so-called "CSS" approach, however, is not actually a CSS-based method: it uses HTML markup whose sole purpose is formatting, making it no better than <b> or <u> or other physical markup. --Xover (talk) 17:19, 26 August 2019 (UTC)

{{sp}} changes the appearance so that it looks like there is a space between the characters, but there actually isn’t: browser search and cut-and-paste treat it like two consecutive characters (and search can find them). This is what we want! By contrast, &thinsp; is treated as a character for both purposes, it’s not good: shows up as a box when cut-and-pasted, and is not found by typing either '" or ' " into browser search. Levana Taylor (talk) 14:49, 27 August 2019 (UTC)

How it works in practice is of course an important consideration for choosing the best approach, and will need good testing as you have done here. However, I must also say, if your browser/OS/application turns a thin space into a � (or other replacement character) then it is time to look for a replacement. This is a bog standard Unicode character that's been in the spec forever, and not in any way an obscure one. Falling down and showing the replacement character would have been somewhat forgivable a decade ago, but it is inexcusable in 2019. --Xover (talk) 17:51, 27 August 2019 (UTC)

The issue is, really, that underlyingly the text is a consecutive pair of characters, which just need visual separation, not an actual space between them. The {{" '}} templates represent it that way, and so does {{sp}}. But inserting a thin space or a gap doesn’t achieve that result.

@Prosfilaes:, you’ve mentioned that there are font/browser combinations that automatically adjust spacing between pairs of quotes, and I suppose you have a concrete example in mind. Could you check how that interacts with {{sp}}? Levana Taylor (talk) 19:30, 27 August 2019 (UTC)

I don't have a concrete example in mind; it's just the simple fact that fonts have supported such automatic adjustments for decades, and every browser needs a complex shaper to support Arabic and such languages anyway, so not supporting that seems bizarre.--Prosfilaes (talk) 22:48, 28 August 2019 (UTC)

Indeed. Lack of support for even moderately advanced typographical features in current web browsers is mind-boggling and incredibly frustrating. And WS' use cases seems to be hitting a lot of the gaps in that support, so that even the areas where browsers do have advanced features help us only but a little. Because I absolutely agree that the perfect solution for this issue would be for fonts+browsers to handle it automatically with zero intervention from us (apart, perhaps, from picking a suitable default font). --Xover (talk) 05:38, 29 August 2019 (UTC)

@Xover: I disagree that it's just wankery—for example, if I copy and paste from a text with the "' sequence I'm not going to want an extraneous space to be inserted between the two, though I'm hardly going to tear my hair out over it. For the record I'm not sure font support for adding space between the straight versions is particularly advanced. I just checked, and in Indesign the sequences ''', "', and '" are pretty well indistinguishable without manual kerning not just in Arial but even in professional typefaces like Garamond Premier Pro, though smart quotes are handled fine. —Nizolan ^(talk) 00:31, 30 August 2019 (UTC)

@Nizolan: The issue itself is a fair one, certainly. The "wankery" comment was more addressed to the template docs at enWP that describe the issue as if it were about <font>…</font> tagsoup vs. <em>…</em> and semantic markup. That's just not the case, and even to a degree gets it completely backwards.

As you and Levana note, using a hair or thin space has certain effects that may or may not be desirable, and which must be weighed against other concerns. That you get the relevant character along when you copy the text is not only not surprising but rather is the expected and, in that circumstance, desired behaviour: why should the spacing we had added disappear when copied? But whether we want it there in the first place is a separate issue. I don't think there will often be a case where readers use in-browser search to search for the quotation marks, but it might be enough of a downside on its own to prefer another method.

And provided we use at least vaguely semantic markup and TemplateStyles I have no strong objection to a <span class="ws-quotation-marks">…</span> type approach (overloading {{sp}} I am less enamoured of). Its verbosity and sheer overhead (one character vs. 40!) offends my sensibilities, but nothing strictly wrong with it.

Thanks for checking Indesign! It's been a while since I touched that or FrameMaker etc., and I can hardly claim any expertise in either, but I must say I'm a little surprised not even Indesign would take advantage of this font feature. Perhaps it is a deliberate choice on a theory that anyone using straight quotation marks really means to have basic untweaked quote marks? I take it it applies some form of spacing for "smart" quote marks(?), so it would seem it does support this feature. And in any case, I agree this isn't very "advanced". I'm continually surprised at what web browsers don't yet support (like drop-initials. Still not?!? Wow! And where're my historical ligatures? I want my long-s with CSS control, darnit!). --Xover (talk) 08:00, 30 August 2019 (UTC)

Making our validated texts discoverable

Wikisource has thousands of validated texts that are typically higher quality than Project Gutenberg. There's one minor problem though: they are virtually impossible to find. Why are we putting all this hard work into creating beautiful accurate transcriptions if no one's ever going to see them. According to Alexa, Wikisource's bounce rate (the percentage of visitors who immediately leave) is 77%, while Project Gutenberg's is 41%! While English Wikipedia enjoys hundreds of millions of pageviews per day and has dedicated software development support from the WMF, English Wikisource is competing for lowest pageviews among the English projects and (unsurprisingly) gets virtually no support from the WMF, despite the great potential of the content here. I think one solution to this problem is to better surface our best content to site visitors and make our validated texts more discoverable.

To this effect, I would like to propose that we run a 3-month experiment (which is the period of time that Alexa's stats are based on). The experiment involves the following:

• I would tag (with a bot) all validated texts with the {{validated}} template (which I just created)
• This template would put all validated texts into a flat category called Category:Validated texts (similar to Category:Featured texts)
• I would add a special search box to the Main Page that lets users search the validated texts category. See Main Page/sandbox2 for a potential mock-up.

If after 3 months, our bounce rate has not improved, I'll remove the dedicated search box from the main page and put it back how it was. What do folks think about this idea? Kaldari (talk) 18:08, 28 August 2019 (UTC)

•  Support Would be nice also to make the ebook (Epub/Mobi) downloads more discoverable (the feature text is the only place that this is obvious to me). Is there any idea how many times WSexport is used from enWS? Also, any page that doesn't have a complete list of the pages on the front page will not produce the right ebook. In that case, there should be complete instructions on how to create an ebook somewhere, and it should be part of promotion to validated status. An example where the export is not working: Anna Karenina. Inductiveload—talk/contribs 18:20, 28 August 2019 (UTC)

  @Inductiveload: https://tools.wmflabs.org/wsexport/tool/stat.php, there is a link from the your choice own link. frWS has lots, and we have some. Whatever frWS is doing seems to have success. — billinghurst sDrewth 06:35, 29 August 2019 (UTC)

  Brilliant. frWS has a utility bar header at the top of all works (contains dynamic layout toggle, PDF download, print version and a citation button). When a work is in the category fr:Category:Bon pour export (good for export), it adds an epub/mobi download link to the bar. It's done with JS: fr:MediaWiki:Gadget-stockText.js. They also have a ebook links for all the "new texts" on the front page, not only the featured text. Inductiveload—talk/contribs 09:37, 29 August 2019 (UTC)

  That's a good point. I wonder if there's some way we could integrate something like {{Featured download}} into the header template, which could be turned on for validated texts. Kaldari (talk) 18:29, 28 August 2019 (UTC)

•  Support I think this could be a good idea, and if it is only for three months I think we can just go for it. —Beleg Tâl (talk) 19:05, 28 August 2019 (UTC)
• Support --Jan Kameníček (talk) 19:29, 28 August 2019 (UTC)
•  Support As an experiment this is a splendid idea. I am a little doubtful about its chances of success, though. 3 months is a pittance in terms of turning around this kind of trend, and I think the discoverability issue this is addressing needs multiple avenues of attack. But as a start, and as a component of an overall push for discoverability, this is a great idea and I would be inclined to support its extension beyond the three months unless any actually negative results are observed.
  Incidentally, I would also welcome any efforts to refresh the design of the main page and the visual design of common elements like the header, footer, and AuxTOC; as well as "something" to improve the various curated collections. There's also something in the gap between raw categories and plain search (Tags? Facets?) that might help, but I have only the vaguest possible idea of what that might be. --Xover (talk) 05:11, 29 August 2019 (UTC)
•  Support, though I'd rather not have an automatic reversion if we don't see immediate improvement in the bounce rate. Rather see some discussion of the results and the best path forward at that time. Thanks Kaldari. -Pete (talk) 16:36, 29 August 2019 (UTC)
•  Support The intermingling of poor-quality and incomplete texts with complete ones is unquestionably a serious problem and this is worth trying out as one part of a solution. I am not sure this is actually what's causing low traffic though so I wouldn't make its continuation dependent on fixing that. —Nizolan ^(talk) 21:40, 29 August 2019 (UTC)
•  Support Great idea! Although, how will the bot determine what's validated? There's not stricktly a relationship of validated-index to validated-work, because some works contain more than one index. It can also be hard to determine which work relates to any given index, for example Index:Austen - Northanger Abbey. Persuasion, vol. I, 1818.djvu is part of a 4-index set that contains 2 works (although, admittedly, if that was being proofread these days it'd probably all go under a single mainspace top-level page). I've tried sometimes to scrap things by following the links in the title field of an index, but it feels imperfect. —Sam Wilson 00:40, 30 August 2019 (UTC)
• Comparing Gutenberg with Wikisource is not fair to Wikisource. People go to Gutenberg to read and not proofread. We advertise ourselves as "the free library that anyone can improve". If more visitors wanted, provide prominent links to lists of completed works and promote downloading and printing. The proofreading aspect should be moved further down and not be immediately visible.
  In addition, 99% of the people I talk to, know nothing about other Wikimedia web sites, or what Wikimedia is. Perhaps we should focus on promoting prominently the completed main namespace works. Perhaps promote our existence by explaining that we are related to Wikipedia. Do we have a category indicating completed main namespace volume titles? Is there a way to exclude incomplete Main namespace works not to be added to search engines?
  P.S: Did a simple web search on two words, "Proofreading" and then "free book downloads" and the results are not very encouraging. — Ineuw (talk) 04:28, 30 August 2019 (UTC)

  The proofreading aspect should be moved further down and not be immediately visible. Yes! The best way to recruit new Wikisourcerors is to showcase what we have already achieved. To rope them in to contributing should be done more subtly with lots of little hints everywhere that communicate "You can edit this!", "We're missing this work from your favourite author, maybe you want to add it?", and so forth (to be clear, I mean by way of visible "Edit" buttons and lists of works with red links etc., not literal banners or talk page messages or such!). The main page has to throw as many finished and high-quality works as possible at the visitor: site maintenance and coordination is for people who are already contributing far more than for new visitors. PotM and similar should only be displayed on the main page to the degree, and in such a way, that they can help attract new contributors.

  And the same goes for unfinished works, or works below a certain level of quality: when entering through the main page, these should be hidden from you unless you search specifically for them. Anything displayed on the main page or which is navigable to simply by clicking links from the main page should be something we're proud to show off, not a fixer-upper! --Xover (talk) 08:26, 30 August 2019 (UTC)

  I agree with all of this. The key principle needs to be to distinguish firmly between the maintenance and preparation aspect of the project and the presentation of complete texts, while also encouraging people using the second to dive into the first. Imo, apart from this, the other main problem is the abstruse and poorly maintained portal and category hierarchy which limits text discoverability. There are also issues which can't be sorted out through decisions here: lack of serious integration with Wikipedia is probably another major issue for attracting traffic. —Nizolan ^(talk) 09:53, 30 August 2019 (UTC)

  +1. I think Xover's framing is good strategic prioritization. And Kaldari's suggestion is a good ingredient that sets the stage for further efforts to improve the way we present Wikisource to a broad audience. -Pete (talk) 20:44, 30 August 2019 (UTC)

  Good points. In the same spirit, how about removing redlinks from author pages? They add nothing (but we should keep the list of works, it is interesting, and can be accompanied by external links). The links on visible pages like author pages should highlight the texts we have, not the ones we don't! Perhaps (although this’d be way too much work to implement) we could go further and, on author pages, have a full link to completed works and a discreet smaller link, in the style of {{small scan link}}, to ones that are incomplete and unproofread. Drawback to this is how hard it’d be to keep it synchronized with the progress of work, with proofread works being promptly updated to full link status.

  BTW I myself am guilty of adding a boatload of links to unfinished works to author pages; I would welcome thoughts on how to improve the situation. Levana Taylor (talk) 23:06, 31 August 2019 (UTC)

  I don't think the red links should be removed per se. The red links serve an important purpose in pointing readers towards work they can do—hence why I try to make sure to add external links to any available scans alongside them. I do agree that author pages could be rearranged to better distinguish complete works, ongoing transcription projects, and works that haven't been started yet, though it would be a huge project at this point. —Nizolan ^(talk) 23:20, 31 August 2019 (UTC)

  Redlinks are generally a good thing: studies at enwp have demonstrated that they lead to contributions. But they need to be deployed correctly. Maybe some kind of approach where the list of works tells you the next step needed? "No scan available for this work. Please locate and upload one!", "This work has a scan but lacks an index, can you create one?", "This work has a scan and index but not all pages have been proofread yet. Can you help?", "This work has been proofread, but is not yet validated.". That sort of thing. A red link to mainspace in that context may actually be a deterrent to contributing. --Xover (talk) 10:13, 1 September 2019 (UTC)

Broken EPub download link on mobile pages

On en.m.wikisource (the default for mobile viewers), we do have a script MediaWiki:Mobile.js that places an EPub download link in the top bar. However, this link doesn't actually work. The "a" tag inside the list item seems to way over to the left and zero sized when I inspect it, but I can't immediately work out why that is. This means, since the mobile view is default for most visitors, and severely crippled in terms of menus, that there is no way a mobile viewer can actually access an ebook, unless they revert to desktop view and find it in the sidebar (which no visitor is going to do naturally). Inductiveload—talk/contribs 12:47, 30 August 2019 (UTC)

Hmm, actually, looks like this list item is just constructed all wrong (Probably the UI has changed since this JS was written in 2015). I think it should be something like this:

			$( '#page-actions' ).append(
				$( '<li>' ).attr( {
					id: 'page-actions-export-epub',
					class: page-actions-menu__list-item',
					
				} ).append(
					$( '<a>' ).attr( {
                                                id: 'ca-export-epub'
						class: 'export-epub mw-ui-icon mw-ui-icon-element',
						href: '//tools.wmflabs.org/wsexport/tool/book.php?lang=en&format=epub&page=' + mw.config.get( 'wgPageName' ),
                                                title: 'Download an EPUB version of this page'
					} ).append("Download EPUB")
				)
			);

Inductiveload—talk/contribs 13:01, 30 August 2019 (UTC)

@Inductiveload: Is that a complete script replacement, or a partial? — billinghurst sDrewth 12:39, 31 August 2019 (UTC)

@Billinghurst: partial, from line 6 onwards. Here is a complete script, which I managed to invoke manually from locally-served JS on my machine:

/* Any JavaScript here will be loaded for users using the mobile site */
( function ( mw, $ ) {
  $( function() {
    //link "download as ePub in the toolbar
    if( $.inArray( mw.config.get( 'wgNamespaceNumber' ), [ 0 , 114 ] ) !== -1 ) {
      $( '#page-actions' ).append(
        $( '<li>' ).attr( {
          id: 'page-actions-export-epub',
          class: 'page-actions-menu__list-item',
        } ).append(
          $( '<a>' ).attr( {
            id: 'ca-export-epub',
            class: 'export-epub mw-ui-icon mw-ui-icon-element',
            href: '//tools.wmflabs.org/wsexport/tool/book.php?lang=en&format=epub&page=' + mw.config.get( 'wgPageName' ),
            title: 'Download an EPUB version of this page'
          } ).append("Download EPUB")
        )
      );
    }
  } );
} ( mediaWiki, jQuery ) );

Inductiveload—talk/contribs 20:43, 31 August 2019 (UTC)

Done Thanks J. Others may wish to test on their mobile devices — billinghurst sDrewth 00:36, 1 September 2019 (UTC)

Working for me, on mobile and also PC with 'm' subdomain. Thanks! Inductiveload—talk/contribs 10:12, 1 September 2019 (UTC)

When to let someone else find typos and omissions?

I proofread Index:Public General Statutes 1896.djvu a few years ago, yet on review I am still finding a lot of mistakes and scanos. At what point is it time to ask someone else to admit you need a second person to look as well? When you think it's perfect, or when you "know" it's perfect? ShakespeareFan00 (talk) 17:00, 18 August 2019 (UTC)

If you "know" a transcription is perfect, then either you are mistaken or it needs no review. The same applies if you "think" a transcription is perfect. Therefore this question misses the mark. Everyone should admit that they make mistakes and, when seeking perfection, always need someone else to check their work. Admitting that, we then ask ourselves what sensible steps we can take to improve the quality of our work so we make fewer mistakes. BethNaught (talk) 22:38, 18 August 2019 (UTC)

yeah, i find the philosophizing over degrees of doubt unproductive: it is essentialism used to justify conduct. as at PRP on commons, the misuse of doubt tends to undermine its evocation. we all improve over time, and this is a consensus project with error levels subject to the validater’s checking. Slowking4 ⚔ Rama's revenge 20:10, 20 August 2019 (UTC)

Everyone faces the same issues with their with proofreading. The boundaries of "think" or "know" are fluid and vary for the same individual. This is what validation by others is important. But, even validated pages have overlooked errors. — Ineuw (talk) 21:09, 3 September 2019 (UTC)

Updating the images in the text quality templates

In an above discussion, the text quality templates , and so forth are mentioned. It seems to me that it would be desirable to update the imagery of these icons to reflect our scan-based work process (which these icons predate) and to match the icons used on Wikidata: , , and so forth. Does anyone object to this idea? —Beleg Tâl (talk) 13:21, 28 August 2019 (UTC)

Makes sense to me to replicate the badges, and we should be implementing similar for listing of features articles, and other components that come through the badges. — billinghurst sDrewth 13:35, 28 August 2019 (UTC)

I think it would be terrible to use those badges here. Their meaning is completely obscure to anyone that isn't a Wikimedian. I would recommend using something like for validated texts. For other statuses, I don't think it would be practically possible to keep their badges up to date everywhere a work is listed, nor would it be especially useful for readers. Kaldari (talk) 16:29, 28 August 2019 (UTC)

I strongly disagree with this for a few reasons. First, a mark for works that are complete and proofread is much more useful, comparatively, than a mark for validated works: the quality difference between proofread and validated is far smaller than the difference between proofread and non-proofread. Both statuses should be indicated, but if I were for some reason forced to pick one I would go with "proofread at least once", not validated. I also don't think it's much less impenetrable to only mark validated texts: if you don't know what validation means then exclusively marking validated works, which implies that only they are satisfactory, could be positively misleading. Finally, I don't think the work added is that much—Category:Index Proofread is actually smaller than Category:Index Validated, so it wouldn't even double it for scans. —Nizolan ^(talk) 17:54, 28 August 2019 (UTC)

If we are talking about placing badges on work pages (which is kind of beside the point of this discussion), I would say that the best way to handle this would be to have all scan-backed works badged based on the status of the linked Index page. —Beleg Tâl (talk) 19:01, 28 August 2019 (UTC)

Question: can't the badge state for a given page be read directly from Wikidata? Surely we wouldn't need to manually keep them in sync? Inductiveload—talk/contribs 18:27, 28 August 2019 (UTC)

It can be automatically read from Wikidata, but Wikidata cannot automatically pull the info from Wikisource and needs to be kept updated manually. —Beleg Tâl (talk) 18:55, 28 August 2019 (UTC)

I do not think is less obscure than , but at least they are both less obscure than the current image . However, there is one very important reason why is preferable to , namely that is already hard-coded into Wikidata, and therefore has the advantage of consistency. Actually, scratch that last bit; Wikidata uses for featured texts, but this doesn't impact our choice of icon for featured texts, so I guess consistency doesn't matter here. —Beleg Tâl (talk) 18:55, 28 August 2019 (UTC)

Anyway, I guess I'm open to replacing with , but then what are your suggestions for icons for , , , and ? I suppose would make the most sense for . —Beleg Tâl (talk) 19:08, 28 August 2019 (UTC)

Okay, how about this for suggestions.

• = null (formerly )
• in purple = problematic (not used in old system)
• or in red = not proofread (formerly and )
• in yellow = proofread (formerly )
• as-is = validated (formerly )

—Beleg Tâl (talk) 19:44, 28 August 2019 (UTC)

I would prefer that we kept it simple and aligned. Whatever is used here and WD should be the same. We only really need to indicate proofread and validated texts, everything else is less relevant, and not what we are trying to highlight. Every bit of complexity is something that someone doesn't or won't do. — billinghurst sDrewth 22:37, 28 August 2019 (UTC)

Which to me means that you do not think we should update all the textquality templates as I suggested, but to do something pretty much entirely different. That's fine. —Beleg Tâl (talk) 23:10, 28 August 2019 (UTC)

@Beleg Tâl: I like your proposed icons above. I also agree with billinghurst that there's not much point to highlighting texts that aren't proofread or validated. If we adopted the icons you propose, I bet I could get the badges at Wikidata changed to match. Kaldari (talk) 00:24, 29 August 2019 (UTC)

I don't like any of the alternate images proposed so far. None of them are as crisp or clear as the originals—which I think is an important aspect of them—and none communicate better (the originals aren't great either) what we want to convey. I also think we should clearly delineate the two axis here: "progress" in a percentage only really makes sense for unfinished works in the proofreading stage, while "Not proofread", "Proofread", "Validated" are categories or overall status of a work. The old icons do an admirable job communicating both aspects: imperfect, but as good as can reasonably be hoped for. New icons would be easier and do better if we clearly differentiate those two uses (including which namespace they are envisioned to be used for: there seems to be two separate discussions going on here).

I also think choosing icons would best be done in conjunction with a refresh of the visual design, the context in which the icons will appear, but I realise that is a much much taller order.

That all being said, I do not actually oppose this proposal so much as wish it went farther and did more. If perfect is the enemy of good here, by all means let's make something that's merely good and then iterate! --Xover (talk) 05:30, 29 August 2019 (UTC)

•  Comment for an immediate action, let us just poke the amber badge into 75%, and the green badge into 100% for the moment, and work from there. They are templates, and this isn't rocket science. The amber and the green are universal for WSes, to move from something standard and expected should be a pretty good reason. — billinghurst sDrewth 06:14, 29 August 2019 (UTC)

@Billinghurst, @Xover, @Beleg Tâl, @Kaldari: I re-colored as some of the icons as suggested (as well as the green one to make a Analogous colors scheme. Here are the results below:

• = null
• = problematic
• = not proofread
• = proofread
• = validated

Is this a acceptable design set? –MJL ‐Talk‐^☖ 22:55, 31 August 2019 (UTC)

Looking at it.. could be a bit darker actually... :/ –MJL ‐Talk‐^☖ 22:57, 31 August 2019 (UTC)

@MJL: Nice! The grey and yellow have insufficient contrast against a white background, and the green is borderline, so they tend towards illegibility. The identical shape in yellow and green uses only colour to convey its meaning, making the difference invisible to people with certain forms of disabilities (think colour-blind people). We also need to use them at a slightly larger relative size to be legible on mobile. (Incidentally, if we use them in a context where they are significantly larger we should have a thin border around the shapes for contrast) I see the logic in the symbols here, but I have a slight worry their meaning won't be clear to a fresh visitor and when you only see one of them alone. --Xover (talk) 10:35, 1 September 2019 (UTC)

Agree that the yellow and green need to be darker (similar to the original green). Kaldari (talk) 17:08, 2 September 2019 (UTC)

@Xover:I admire your concern for colourblind individuals and I agree with your perspective, but I will also point out that our page status system is already 100% colour-based and has little-to-no provision for accessibility whatsoever, including the Wikidata icons that my original proposal was based on. —Beleg Tâl (talk) 18:19, 2 September 2019 (UTC)

You're right that we have multiple things that need to be fixed. However, our existing systems are not "100% colour-based". The page quality icons (, , , ) are different shapes as well as different colours and have alt text describing their meaning (well, some oof them: 25% = Incomplete, 50% = Text complete, 75% = no alt text, 100% = no alt text); and the radio buttons for "Without text", "Not Proofread", "Problematic", etc. in the Page: namespace have text labels in addition to the colour circles. The colour-only page status indication on Index: pages is problematic, but most likely fixable if we stop abusing the title attribute. Etc. --Xover (talk) 19:47, 2 September 2019 (UTC)

@Xover, @Beleg Tâl: This is a non-issue because I have already checked for this before picking out the exact shades. For all listed variants of color-blindness, Green looks significantly darker than yellow. I encourage you both to compare the two and see if they can be differentiated. [Also, they are now darker as requested] :) –MJL ‐Talk‐^☖ 17:12, 5 September 2019 (UTC)

I am not understanding the need for most of this complexity. In most contexts, a three-way division of scan-based texts should be plenty: unfinished (has some blank or blue pages), unproofread (has none of those, but some pink pages), proofread (has only green or yellow pages). This suffices both for people who want to read (can go straight to the proofread texts) and people who want to contribute, since they can then decide if they want to do just proofreading or the more complex formatting involved in working on new or blue pages. If more details are needed, look at the index itself. Levana Taylor (talk) 20:27, 2 September 2019 (UTC)

Maintenance of the Month questions

I was studying the list in the Wikisource:Works but I don't know what to contribute.

For example: What is supposed to be done with the 3 author pages without any works in Wikisource? Ditto, what is needed to be done to the displayed images? Some enlightenment is much appreciated. — Ineuw (talk) 03:33, 30 August 2019 (UTC)

@Ineuw: Based on a quick look, it appears that template has not been updated since 2014. I question why we even have that on the main page. And, no, I don't understand what "Work index revision" is supposed to be in practical terms either. --Xover (talk) 10:02, 1 September 2019 (UTC)

Time to kill it from the main page, at least while it is not actively curated. — billinghurst sDrewth 13:08, 1 September 2019 (UTC)

Removed. I would suggest that we could do well to have a list of proofread works that require validation, as that is often an area where work is required. — billinghurst sDrewth 13:10, 1 September 2019 (UTC)

We have a page listing for completed proofread files of the Index ns waiting to be validated. I am working on a copy of the list to switch the links to the main namespace. — Ineuw (talk) 23:50, 1 September 2019 (UTC)

@Ineuw: Please check out WS:WPV, and if you want to make that a subpage there; then by all means! :D –MJL ‐Talk‐^☖ 17:17, 5 September 2019 (UTC)

@MJL: Thanks for the link although I am unclear as to why we have so many lists for validation. It is confusing.

1. Category:Index Proofread is an alphabetically ordered generic list.
2. Wikisource:Validation_of_the_Month/validation_works#QUEUED I assume this to be in date order as any proofreader can add their completed work.
3. Wikisource:WikiProject_Validate#Candidates_to_be_validated In what order is the list? I think that these two should be combined. — Ineuw (talk) 22:09, 5 September 2019 (UTC)

   Ad 3: The list ist not ordered as no order is needed. --Jan Kameníček (talk) 22:23, 5 September 2019 (UTC)

┌─────────────────────────────────┘
@Ineuw: Validation of the Month is a separate project that no one really is participating in AFAIK. The list you mentioned is just a voting page to decide the featured tasks should be. There's no particular order you can go in, but the project is limited to seven works it can consider validating at a time. As for the merging, that was considered at one point. The problem is that VotM is older and comes with it a large list of projects people just put there. WS:WPV generally only takes up works people actively nominated for consideration. –MJL ‐Talk‐^☖ 22:20, 5 September 2019 (UTC)

In essence, these two lists are in addition to any validations users make? — Ineuw (talk) 02:11, 6 September 2019 (UTC)

A new category for validated texts?

The most frustrating thing about Wikisource to me is that it's virtually impossible to find good quality texts to read here (which is ironic given the purpose of the project). Let's say, for example, I want to read a non-fiction book about birds. Here are all the steps I try:

• Search for "birds" in the search bar: This sends me to Birds, which includes: a link to an unvalidated page of Encyclopædia Britannica, a link to the play by Aristophanes (also unvalidated), and links to 4 different poems, two of which are unvalidated, and one of which is a redlink!
• Main Page -> Site index -> Books -> scroll down to non-fiction which gives me: links to 19 books, some of which aren't even proofread yet, and none of which are about birds.
• Main Page -> EXPLORE WIKISOURCE: By subject -> Category:Nature -> Category:Biology -> Category:Zoology -> Category:Animals -> Category:Vertebrates -> not a single thing about birds.
• Main Page -> EXPLORE WIKISOURCE: By subject -> Category:Science -> Category:Physical sciences -> Category:Biology -> Category:Zoology -> Category:Animals -> Category:Vertebrates, same as above.
• Main Page -> Site index -> Portals -> Science -> Zoology -> scroll down a couple pages to Birds which gives me: links to 24 general works about birds, almost all of which are magazine articles from Popular Science Monthly. Of the 3 links which aren't to magazine articles, 2 are unfinished transcriptions, and one is a link to a small collection of essays about real and fictional birds (35 pages, but at least it's validated).

So after all that effort, I sort of found what I was looking for, but not really. And sadly, I didn't encounter any of our validated full-length non-fiction books about birds, such as Natural History, Birds or Bird Haunts and Nature Memories (which I found through the external Wikisource category browser tool).

I would like to propose that we create a new category called Category:Validated texts which is prominently linked from the Main Page and subdivided into categories by topic and format. That way it will be easy to find high quality texts to read about whatever you're interested in without having to dig through hundreds of unfinished and unproofread texts in the process. Kaldari (talk) 17:56, 25 August 2019 (UTC)

Portal:Birds is supposed to be the to-go place for finding good quality works about birds. We should probably make a better effort to maintain portals, and I encourage you to add Natural History, Birds and Bird Haunts and Nature Memories to Portal:Birds where they belong. —Beleg Tâl (talk) 18:31, 25 August 2019 (UTC)

It is a matter of imperfect categorisation. Specifically Category:Birds is quite confusingly a subcategory of Dinosaurs, which are at the same time considered to be only Prehistoric reptiles, and so from Vertebrates you can get there only thus: Category:Vertebrates --> Category:Reptiles --> Category:Prehistoric reptiles --> Category:Dinosaurs --> Category:Birds :-D

The only help is to keep improving the categorization. --Jan Kameníček (talk) 18:40, 25 August 2019 (UTC)

Fixed. --Jan Kameníček (talk) 18:45, 25 August 2019 (UTC)

@Kaldari: It is meant to be Portal namespace for curated pages. <shrug> The system is not perfect to flow from validated in Index: ns through to main ns. We have Category:Validated, Category:Index Validated and Category:Indexes validated by date. Or you can look at them via Special:IndexPages and even run searches there for Index pages/ Then we have works where we have put them into WD, and badged them (validated). Ideally we would have all our works in WD and have them categorised there and run searches, though that is clearly a pipe dream. Unfortunately there is no ready means to move between proofreading status of a complete work from its index page. Of course we also have our completely crap Wikisource:Works. As an example of how we do ourselves no favours, poke your eyes listed in Wikisource:Works/2017 and Wikisource:Works/2018 and see the poor use of portals and categories. It seems we prefer to transcribe and replicate the work of a typographer rather than present books to the public. — billinghurst sDrewth 11:11, 26 August 2019 (UTC)

@Beleg Tâl, @Billinghurst: The problem with Portals is that you can put anything in them (even barely started transcriptions and redlinks). Although they have some organization to them, there's no curation, and they tend to be more-or-less random lists of works, many of which aren't even readable. There needs to be a place on Wikisource somewhere that you can go to find finished works to read. The closest we have to that currently is Category:Featured texts, but it only has 126 pages in it. Would there be any downside to creating a category for validated works (with subcategories for topics and formats)? According to Category:Index Validated, there are only 3299 validated works on Wikisource. That doesn't seem like it would be impossible to manage. Then we could put a little blurb on the Main page that says something like "Looking for something to read? Check out our completed works." Kaldari (talk) 21:21, 26 August 2019 (UTC)

1. Is there maintenance that searches for validated indexes that haven't had their status set to validated? That should help with generating a list of works, though not necessarily with generating a list of articles in validated magazines.

2. Can there be a policy that only finished, proofread (though not necessarily validated) works should be on portal pages? That'd give someone tidying up a portal grounds for removing things. Levana Taylor (talk) 21:52, 26 August 2019 (UTC)

Portals are too versatile for your second idea to work. Like Author pages, sometimes it is valuable to list all relevant works even if they are not all hosted here yet. It can also be valuable to list works that are in progress so that editors interested in the topic can contribute to the works they are interested in. —Beleg Tâl (talk) 22:40, 26 August 2019 (UTC)

There is no ready ability to find Index works that have been proofread/validated though have not been marked so. We have enough issues with works being proofread and validated without being transcluded, and you may have seen my recent efforts to update those. We do have series of checks for works that need work in the transclusion space, or checks, and you will see a number of petscan queries on my user page that I utilise. It is manual work checks, and it is okay as it takes manual resolution, so it is about being in the space. — billinghurst sDrewth 11:47, 27 August 2019 (UTC)

Plus if you want to check our completed works, I would point you to Wikisource:Works/2018, Wikisource:Works/2017, Wikisource:Works/2016, etc. as these are proofred and transcluded works, or electronic documents not in need of transclusion. — billinghurst sDrewth 11:49, 27 August 2019 (UTC)

I agree with @Kaldari:'s original point. It's strange, and tends to defeat our purpose, for it to be so difficult to find fully validated works. (Making it easy to find fully proofread works, separately, would also be valuable, as the number of works would be vastly increased, and the quality drop would be minimal.) I can see how the various mechanisms are problematic; it seems to me that categories are the most natural fit, in the MediaWiki software.

I also think if we get this right, it should ultimately improve discovery. Search engines should learn to favor validated works over non-validated works, and our best material should become more discoverable through web search. -Pete (talk) 23:27, 26 August 2019 (UTC)

Really good point. Said category maybe should be flexible enough to be applied to individual articles in magazines that are proofread even if the entire issue isn’t finished, another way of increasing the number of works. Levana Taylor (talk) 23:30, 26 August 2019 (UTC)

The issue is that categories are bland and give next to no information about the work. They give neither scope nor detail to a work, and that is why we went to curated author pages (rather than author categories), and then started working on portals. If we were to do things properly we would be having auto-generated pages that pull wikidata. We need to be more assiduous with listing our works. If someone could find assiduous cataloguers that would be nice. By the way, if you do add pages to portals, we do have {{75%}} and {{100%}} to indicate proofread and validated works. For any portal, if you think that it looks ugly, we encourage you to fix it, or make it workable. With regard to red links, there are some who revel in adding redlinks to our curated pages, and while I dislike it it isn't necessarily wrong. — billinghurst sDrewth 11:42, 27 August 2019 (UTC)

on wiki search is so bad, i don’t use it. rather a google search is better. maybe a wikidata query by wikisource work with a proofread status, would be better. then you could have a proofread work page, with the wikidata query result. Slowking4 ⚔ Rama's revenge 03:41, 28 August 2019 (UTC)

(Just wondering aloud) Would it be feasible to have these icons automatically display as badges on a work based on the status of the underlying Index? Would it be feasible to make a template similar to {{scan}} which automatically shows the relevant icon based on the work's status? —Beleg Tâl (talk) 13:28, 28 August 2019 (UTC)

Are you meaning on the work, or in a built list? We usually just need to ask, and @Mike Peel: has been able to work with developers at Commons to get components together. Still the biggest issue is that we simply don't have enough people putting their works into Wikidata, let alone the badges. Further, the WEF framework, and all other tools that I have seen don't give us an easy means to bulk apply badges, they have to be manually applied per work. Ugly. Personally I gave up the data extraction approach from WD, just got too frustrating, and too much time editing in WD, and not enough here. — billinghurst sDrewth 13:40, 28 August 2019 (UTC)

What about a tool that would show results of intersection of a chosen category of works and validated/proofread works? Something similar to what they have in Commons in the top right corner of each category, with which you can filter out e.g. only featured images. However, it would be good if it were able to filter out not only validated works directly in the category, but also in the subcategories, so that a person interested in vertebrates received all mammals, reptiles, fish... --Jan Kameníček (talk) 15:18, 28 August 2019 (UTC)

Reply to @Billinghurst: Is your point about the software feature of categories, or is it about how categories were previously implemented here on Wikisource? (Do you have a link to the discussion, or remember roughly what year the change was made?) It seems to me that if categories are "bland," that's because nobody has taken the trouble to implement them in a way that is more useful. I have worked on MediaWiki-based wikis which put article-length commentary on category pages. If there's something missing from the category feature on a software level, I'd like to better understand what it is. If it was merely missing in implementation, it seems to me that shifting from categories to portals may have been a decision based on an imprecise understanding of the problem or the available solutions. -Pete (talk) 15:40, 28 August 2019 (UTC)

@Peteforsyth: Categories didn't then, and don't now meet our needs to neatly display our works. They are simple a page title, and add in the requirement of subpages, it just goes from bad to worse. We curate author pages, have a think about why we do that rather than rely on categories. Manual curation does suck, though until we can autogenerate lists on a daily basis pulled from something like WD, we are stoinkered. Until users properly attach to WD each article in a biographical dictionary, a journal, and link to an author, and fill those gaps we are stoinkered. Until we can create books <-> editions, we are stoinkered. So at this point, I will just go back to my maintenance, as tidying up after people here is way more than a fulltime task anyway. — billinghurst sDrewth 22:50, 28 August 2019 (UTC)

I think you've established with your comment that you and I have some pretty basic disagreements on the subject, but if you intended to communicate more, could you try again? I'm still interested to see the earlier discussion. (I can search myself I suppose, but without knowing any of the backstory it'll probably take me a while.) -Pete (talk) (originally posted along with the point now below, beginning the section #Problems with subpages.)

I'd like to make a few points on this and I'm very happy this conversation and the making texts discoverable conversation have come up

• Categories may have their benefits but I think portals are the way to go for wikisource for users that are searching for works or subject matter. They are more customizable for our purpose and works can be better presented in portals than categories.

• I think when a work has been proofread it it is ready to be presented to the public, so we shouldn't be focusing so much on only validated works.

• Portals should be the first thing to come up when users are searching for subject matter, then works, authors, index pages etc.

• Our main page sucks at advertising what this site has to offer. I think we need to seriously have a look at this. Navigation to subject matter for example.

• To sum up I think portals are the best way to present subject matter to the public in wikisource.

• This subject matter must be discoverable via the search bar or main page.

• Proofread texts are good enough to be presented to the public. Anything else (auto generated OCR) etc shouldn't be presented at all.

• Ideally in my opinion, if a user is searching for Birds, they would type Birds in the search box and be directed to the portal Birds. Whether this portal is properly maintained and up to scratch is up to us. Jpez (talk) 20:58, 29 August 2019 (UTC)

Problems with subpages

The "subpage" convention we use is somewhat related to this point. In my view, the subpage convention is less than ideal, for two reasons: (1) it creates page titles with slashes in them, i.e., they deviate from plain English and look like code. I would expect to see "The Lord of the Rings, Book 1" rather than "The Lord of the Rings/Book 1" – the latter is not proper English syntax. (2) The breadcrumbs it creates are redundant of the information in our headers. The "Book 1" page header should allow you to get to the main work, and also to Book 2, etc. Breadcrumbs that let you navigate "up" in the hierarchy are therefore redundant and cluttery. I prefer categories as a means of organizing pages on a wiki; they are much more flexible than subpages, and they do not impose restrictions on the titles of the pages they organize, or introduce redundant breadcrumb trails. -Pete (talk) 16:45, 29 August 2019 (UTC)

Incidentally, you can override the displayed title of a page in Mediawiki (with some limitations that I can't recall ottomh), which might be a way to alleviate the "slash-in-title" issue if needed. --Xover (talk) 16:57, 29 August 2019 (UTC)

Do you mean that some template can be placed on the page to change its displayed title? If, on the other hand, it’s a settings change on the user end, that doesn’t help the casual vistitor. Levana Taylor (talk) 17:07, 29 August 2019 (UTC)

If we feel the current displayed title for subpages is a problem, one possible way we could explore solving it is using Mediawiki's functionality for overriding the displayed title. There are several possible ways it could be deployed, but one of them would be to simply have the {{header}} that we already include on every page do the overriding. For an article in a periodical, for example, the header template has enough information to ask for "Awesome Article (The Magazine)", or whatever format we want.

For reference, the functionality I'm thinking of is the so-called "magic word" {{DISPLAYTITLE:…}}. It has some limitations in what it can do so we might need code changes in Mediawiki if our needs exceeds that scope. --Xover (talk) 17:34, 29 August 2019 (UTC)

This is related, too, to the ongoing discussion about visibility of our works. There’s an issue with the visibility of works that are, although complete in themselves, subpages of periodicals or collections. When you google them, it may not be immediately obvious that the long compound page name you see in the search results is THE text of the work you’re looking for. Also you don't pull them up when typing the subpage name into the search box here. What can be done about this? Redirects, or a fundamental rethinking of subpages as Peteforsyth suggests? Levana Taylor (talk) 17:04, 29 August 2019 (UTC)

Agree with User:Levana Taylor. Altogether, is it necessary for subpages to be visible in search engines? There many main namespace subpages that are not proofread? — Ineuw (talk) 23:05, 2 September 2019 (UTC)

Yes, it is necessary. My point was that many things that are currently filed as subpages are standalone works (even if in anthologies/collections/periodicals) and it ought to be easier for searches to find them as such; and that page-names ought to be rethought so that it would be easier to recognize what you have in front of you when you first see it. Levana Taylor (talk) 06:48, 6 September 2019 (UTC)

Why have we allowed ToC to slip to subpages?

Not certain when this little trend started to occur, however, we seem to have allowed the transcluded table of contents slip to a subpage. For us, this has to be a no no as it breaks the book tools ability to create works with all the subpages. This is even happening with editors who have been here for a while.

We need to be doing better with our patrolling, and ensuring that these things do not happen. That we have focus and bickering over curly apostrophes and cannot get the basics right with ToC and volumes is just maddening. Our standards have been slipping with deviations from the style manual, and from our focus on making it easy for transcription and proofreading. We used to focus on the words of the author, and now we have what seems to a blinding observance to have facsimiles of what a publisher output.

I have also seen a preponderance to start using {{Page}} more loosely rather than <pages>. This just leads to holes in transcriptions, OR poor page numbering, OR no page numbers. Why? We have a standard and a style that has been developed for really good reasons, and this seeming casual discarding of it has consequences. — billinghurst sDrewth 12:35, 31 August 2019 (UTC)

I see this a lot in older works; I fix it when I see it, but it's a long-entrenched trend, just like the practice of using a "front matter" subpage for the cover and title page (which I also fix when I see). —Beleg Tâl (talk) 16:44, 31 August 2019 (UTC)

Although I have never put TOC on a subpage, it is the first time (after a year of regular contributing here) I read that it is actually wrong. If it is important, it should be written in some rule, so that all newcomers were able to learn it.

However, it is not true, that the front matter subpage is wrong: see Help:Front matter: "Sometimes some or all of the front matter is transcluded into subpages instead." If the front matter is extensive, it is better to create a subpage, so that the readers did not have to scroll down before they find the TOC with links to subpages. For accesibility reasons it is better if the TOC is immediately visible when opening the base page (and the most important info from the title page is in the header of the base page anyway). --Jan Kameníček (talk) 17:23, 31 August 2019 (UTC)

I'd be interested to see links to (a) policies or guidelines that define how it's supposed to work, and (b) examples of how it should be and how it should not be. Both would make it easier for me to follow and learn more about this. -Pete (talk) 17:25, 31 August 2019 (UTC)

Yes exactly, there are no written rules about it, and it's a long-established way of doing things. As for front matter, I will assert that the practice of transcluding front matter on a subpage is bad even though Help:Front matter acknowledges that it has always been done. If the author and publisher designed the book such that readers must leaf past a cover, title page, and so forth before getting to the TOC, then that is what readers should expect to see here as well. Readers expect to see the beginning of the work when they start at the beginning, not to have to navigate backwards to get to the top. —Beleg Tâl (talk) 17:36, 31 August 2019 (UTC)

And if the publisher designed the book such that readers must leaf through the entire volume? :) Seems that what you're advising is in direct contradiction to what @Billinghurst: says in a case like that. I'm curious to learn about policies and norms, and if policies and guidelines need to be written, I'm happy to pitch in. I'm not sure what it accomplishes though, to talk about what's "bad" or what's a "no-no" if such documents don't exist, or are incomplete or inconsistent. What are the goals we're trying to serve here? I can see three, which might sometimes be in conflict with one another:

• Accommodate software which knows how to build books only if certain rules are met (as billinghurst says)
• Approximate the appearance of the original published text as closely as possible (as Beleg Tâl says)
• Provide text in the way that is most useful to the reader, with minimal deviation from original format (what I'm inclined toward)

I'm not sure any of these deserves to be "the one and only principle" -- it seems to me that guidelines that help us balance these considerations are what would help the most. -Pete (talk) 17:47, 31 August 2019 (UTC)

My experience: Sometimes I scroll down to find a TOC, click on a link to open a chapter, find out that it is not what I was looking for, return back, have to scroll down again, click, return, scroll down, click, return scroll down... I have to say that the fact I have to keep scrolling down really sucks, while simple click-return-click-return is much friendlier to me.

BTW: It is not true that readers who open a book always expect title page to see first, not even with paper books. I as a reader expect it when I am choosing which book I want to open and read among a row of books, but Wikisource does not offer this feature anyway. After I have already chosen a book and decided to open it, I want to get to the contents as quickly as possible. --Jan Kameníček (talk) 18:29, 31 August 2019 (UTC)

I agree with the above. I don't see how the ToC point can be criticised as a "deviation from the style manual" when where to put the table of contents is not in fact stated anywhere in the style guide; people cannot be slipping from a guideline that doesn't exist and if it is a technical issue then this needs to be made explicit. Regarding the broader issue of the front matter, I think we should only follow the exact order where convenient. Long prefaces can sometimes come before the table of contents in printed books, but I doubt anyone would disagree with putting the ToC on the root page and the preface in a subpage in that case, for example. I also have a personal policy generally not to transclude pieces of front matter that serve no particular purpose to the reader (half-titles, publisher pages, copyright notices etc.), precisely in part because of Jan's point about the table of contents being pushed down by junk. —Nizolan ^(talk) 22:58, 31 August 2019 (UTC)

Maybe I need to take a step through a potted history of that development of WS, and some of this relates to tool development.

1. Goals
   • Understand the concept of the page/work/... pretty quickly (is that what I wanted?)
   • Enable reader to get into the work quickly/easily not have to fumble or be burdened (does this interest me?)
   • Not make it unreasonably difficult to transcribe/proofread
   • To guide, and not have a prescriptive rules that you have to read just to contribute; and so to support new users to our styles, and our practices (ie. watch what we do as one set of prescriptive rules is problematic when working with publications over the centuries but we can work it out so it aligns with our other works)
2. Headers were developed (the want and interest)
   • to get the metadata together in reproducible fashion
   • to enable easy navigation forward and backwards in a work
   • not too big to stop a person to easily get into a work, so somewhat minimal
3. Table of contents (replicate works, or as auxiliary as navigation where not originally in work)
   • Before we had scans, people just started with a table of contents on a work, the essence of navigation of a work whether to a strip article or to subpages; this should be the essence of root page of a work
   • When we had scans people people had the front pages, so started to transcribe them, and some did not, and that is still the case today. It was personal choice whether people added those pages to the root page, though it was seen of value for the other meta data related to the edition and author (printer, copyright, other works, etc.) to be able to capture those pages, so poked them into front matter. Available for those interested in the particulars, though not imposed upon people interested in the work.
   • Doesn't work for serials as they have too many subpages, so subsidiary/detailed ToC on subpages, with a coarse ToC at top.
   • They were most useful when we had scans to transclude them to the Index: pages
4. Tools
   • WSexport tool came along and it requires the navigation to subpages from the root page, which compounded the need for a ToC to exist on root page where ToCs are required for the work. As it helps for good web presentation, it was pretty much a nobrainer

— billinghurst sDrewth 00:30, 1 September 2019 (UTC)

PS. Can we please focus on ToC on the root page, and not get distracted by other factors. Yes they are important and deserve their own separate conversations. And yes, I started the diversions, but when one is always caught up in fixing what are considered the basics :-/ We need to focus our feedback tightly on one issue in such a forum. — billinghurst sDrewth 00:38, 1 September 2019 (UTC)

As people have said, the basics are that there's no written guideline against putting ToCs on subpages at the moment, so I would focus on rectifying that. —Nizolan ^(talk) 04:29, 1 September 2019 (UTC)

Taking @Nizolan:'s suggestion to heart, here are two examples of how the front page of a work might look, when the original has the TOC buried deep in the work.

1. Looters of the Public Domain front page as it was before (presented very consistent with the original published work, but with a note in the header indicating that there is a TOC to be found if one knows where to look.)
2. Looters of the Public Domain front page as I just redid it, to conform more to what billinghurst has suggested -- making sure the TOC is on the main page.

I do think option #2 is better, and it explains the change in the header, so it's not like readers will be in the dark about the variance. What do others think? -Pete (talk) 23:56, 1 September 2019 (UTC)

I think it's much better now. It's much more intuitively navigable for someone landing on the work's main page. Also the EPub export works now. Due to the {{FI}} templates, the images are full size, so the EPub is nearly 300MB, but that's another issue, I suppose. Inductiveload—talk/contribs 10:47, 3 September 2019 (UTC)

In the magazines I’m doing, I’m putting both the TOC and the index on the main page -- is that a problem for epub export or for anything else? Levana Taylor (talk) 15:30, 3 September 2019 (UTC)

It seems to work. You get the "artifical" boxed TOCs first, and then the index, and there is an epub index that you can access from the reader program sidebar. You can check yourself by downloading the epub either on a PC or on a phone. The dotted tables look pretty bad on a mobile device, but, again, a different issue. Inductiveload—talk/contribs 16:31, 3 September 2019 (UTC)

Thanks for the feedback. @Beleg Tâl: Could you comment on the two options above? Do you feel that there are any instances in which it's worthwhile to exercise judgment about what best serves a reader on our platform, which could differ from the printed original? (@Inductiveload: I'm happy to discuss the best way to present images, maybe at Talk:Looters of the Public Domain?) -Pete (talk) 19:10, 4 September 2019 (UTC)

• I'm only half following this discussion, but I just want to note that as far as wsexport goes, we could change it to support TOCs on subpages (i.e. follow every subpage link recursively) so as long as there's a link from a work's top page to its ToC page then the export function would work correctly. It sounds like there are other good reasons to have the ToC on the top page, but the technical requirement of the export tool needn't be one of them. —Sam Wilson 23:33, 4 September 2019 (UTC)

Use of Page template

Can anyone explain why we use {{page}} at all instead of <pages …/>? Is there some situation where the latter does not work but the former does? Does it confer some kind of advantage in some way? --Xover (talk) 09:51, 1 September 2019 (UTC)

A simple (and simplistic) reason for this is that <pages> always encloses its output in a <div>… there is simply no way of getting around this without modifying the ProofreadPage extension. On the other hand {{page}} utilises a different but similar mediawiki extension, Labeled Section Transclusion which does not enforce this enclosure. This is one of the fundamental reasons why page-crossing table transclusion is such a royal pain. 114.78.171.144 10:10, 1 September 2019 (UTC)

Also, <pages> doesn't work in the Index namespace, so if you want to transclude a TOC to the index you have to transclude pages one-by-one with this template or something equivalent. Inductiveload—talk/contribs 10:17, 1 September 2019 (UTC)

<pages> was purposefully made not to work in Index: ns, and anyway we transclude the page, not use {{page}}

Index: is a bit of a special case, so I'm not immediately too concerned with use there (and it sounds like something that might conceivably be fixed in ProofreadPage anyway). It's the (extensive) use in mainspace that sounds a little worrisome to me. --Xover (talk) 10:21, 1 September 2019 (UTC)

Each <pages> invocation, or each Page: within a <pages> invocation? --Xover (talk) 10:21, 1 September 2019 (UTC)

Each <pages> invocation (it is easy enough to verify!) I proposed a ProofreadPage modification many, many moons ago when I was still active here but the proposal died because of disinterest and in the pre-HTML-lint days nobody noticed anyway. 114.78.171.144 12:18, 1 September 2019 (UTC)

Then my next question is, why is that a problem? Why would that affect multi-page tables? --Xover (talk) 12:24, 1 September 2019 (UTC)

 Comment there are some special cases where we would use {{page}} in main namespace, when you wish to insert multiple pages side-by-side rather than sequentially. Also, you can use {{page}} to exclude sections, rather than include sections, so it has uses, though they would be quite uncommon. — billinghurst sDrewth 12:32, 1 September 2019 (UTC)

further  Comment, in some of our transclusions based on image type (jpg/png/other, etc.) the <pages> syntax cannot be used to exclude pages, so this can be a case for use of Page:, usually when there is a plate and image that is out of order of the components of the work. — billinghurst sDrewth 11:15, 7 September 2019 (UTC)

New pdf and index repairs for Once a Week volume 2

One of the pages of the existing file for Index:Once a Week, Series 1, Volume II Dec 1859 to June 1860.pdf is in the wrong place in the pdf. I tried to upload a repaired pdf but couldn’t figure out how to overwrite the existing file using chunked upload. I have stored the better pdf at the following filename on the Commons: c:File:Once a Week, S1 V2.pdf. Could someone please use that file to overwrite c:Once a Week, Series 1, Volume II Dec 1859 to June 1860.pdf and then delete my temporary storage file? Also, the index needs to be corrected as follows (numbers are the file pages, not the magazine numbering). The main namespace transclusion page numbers are already correct for the new numbering.

• no change: new 1-88 = old 1-88
• new 89-100 = old 90-101
• new 101 = old 89
• no change: new 102-635 = old 102-635
• in the new version, there are 4 no-content pages after the last page; in the old one, there are 8.

Levana Taylor (talk) 20:14, 30 August 2019 (UTC)

@Levana Taylor: I've uploaded the new version over c:File:Once a Week, Series 1, Volume II Dec 1859 to June 1860.pdf and tagged c:File:Once a Week, S1 V2.pdf for deletion. But someone with AWB or similar tools must take care of the rejigging of pages in the Page: namespace here. --Xover (talk) 20:45, 30 August 2019 (UTC)

Thanks, that was fast! Levana Taylor (talk) 20:48, 30 August 2019 (UTC)

Once a Week pages shifted

Pages 76 to 88 of Index:Once a Week, Series 1, Volume II Dec 1859 to June 1860.pdf are shifted, is there some automatic way to repair it? --Jan Kameníček (talk) 06:18, 9 September 2019 (UTC)

Done.Mpaa (talk) 20:04, 24 September 2019 (UTC)