Wikisource

Wikisource:Scriptorium/Archives/2018-01

< Wikisource:Scriptorium‎ | Archives
Warning Please do not post any new comments on this page.
This is a discussion archive first created in , although the comments contained were likely posted before and after this date.
See current discussion or the archives index.

WS:FTC

Lots of FTC nominations by EP over at Featured Text Candidates, but few contributors offering proposal comments, support, etc. I only notice because I just made a proposal myself after a request by EP. Londonjackbooks (talk) 02:31, 2 January 2018 (UTC)

BBC Radio Times

 
Radio Times - Christmas 1935 - out-of-copyright article by William Temple, (died 1944), with in-copyright illustration obscured. Transcribed as The Coming of Wireless.

The BBC have put the entire run of the Radio Times magazine, for the 1930s, online, as part of the BBC Genome Project

This was the BBC's own magazine, sold to the public. It contains a mixture of programme listings (also digitised as text by the Genome Project), magazine articles (not as text), and images; all with mixed copyright status.

Obviously, the articles may be of interest to Wikisource.

I've started a discussion on Commons, with additional details, and to decide how we can best make use of this content. Your comments, and contributions to the work needing to be done, will be welcome there. It would be good to have liaison between the two projects. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:40, 1 January 2018 (UTC)

None of this is public domain in the US, so it's not suitable for the English Wikisource. Consider taking it to The Canadian Biblio Wiki.--Prosfilaes (talk) 15:24, 1 January 2018 (UTC)
do not see a copyright notice, so pre-1967 is suitable. no record of "radio times" at [1] the illustrations raise the issue of fair use, for images in PD text yet again. if you really think it is not PD, then you need to have the DR at commons, not here. Slowking4 ‽ SvG's revenge 02:43, 2 January 2018 (UTC)
Please see Highlights of Copyright Amendments Contained in the URAA; a copyright notice is irrelevant. (And 1967 has nothing to do with anything in US copyright law, at least not for several more decades.) We have different copyright rules than Commons has.
(The specific example the copyright office gives is: "A French short story that was first published without copyright notice in 1935 will be treated as if it had both been published with a proper notice and properly renewed, meaning that its restored copyright will expire on December 31, 2030 (95 years after the U.S. copyright would have come into existence).")--Prosfilaes (talk) 05:04, 2 January 2018 (UTC)
by your failure to raise this issue at commons, i take it that you agree your extreme URAA views do not have a consensus at commons. what makes you think you have a consensus at wikisource? you need to seek a consensus rather than attempt to impose your views, by fiat. see also m:Wikilegal/Use of Foreign Works Restored under the URAA on Commons Slowking4 ‽ SvG's revenge 12:19, 2 January 2018 (UTC)
It's clear that my views do not have a consensus at Commons. If I were imposing my views by fiat, as an administrator, I have a big fat delete button that I could have deleted the pages in question. Instead I marked it as copyvio and brought it up for discussion.--Prosfilaes (talk) 21:15, 2 January 2018 (UTC)
you have chosen not to continue the drama at commons, but rather, you come here and blank the image, inporting the drama here. your behavior is instructive. the venue shopping says it all: having lost the consensus at commons, will you now take that lack of consensus to each and every other project? the battleground has no armistice, merely new battlefields to fight over. Slowking4 ‽ SvG's revenge 16:47, 3 January 2018 (UTC)

Headers don't show up

The headers do no longer show up in the main namespace. In all books I've been checking you can see it flashing by for a second, and then it disappears. What's wrong? --Dick Bos (talk) 17:55, 3 January 2018 (UTC) Sorry. Forget to tell: it only happens in "Layout 3". --Dick Bos (talk) 18:04, 3 January 2018 (UTC)

Ouch, it is there, though you will need to scroll over to the right of the page. We haven't changes being made to MediaWiki:PageNumbers.js in a long time.
self.ws_layouts['Layout 2'] = {
	'#pageContainer':'',
	'#regionContainer':'width:36em; margin:0 auto 0 auto; font-family:Georgia,serif;',
	'#columnContainer':'text-align:justify;',
	'.sidenote-right':'position:absolute; left:37em; width:16em; text-indent:0em; text-align:left;',
	'.sidenote-left':'position:absolute; left:37em; width:16em; text-indent:0em; text-align:left;',
	'.mw-editsection':'',
	'#headerContainer':'font-family:sans-serif;'
};
self.ws_layouts['Layout 3'] = {
	'#pageContainer':'',
	'#regionContainer':'min-width:60em; float:left; width:100%; margin-right:-23em;',
	'#columnContainer':'position:relative; text-align:justify; margin-right:23em; text-indent:0em; padding-left:0px; padding-right:0px; width:auto;',
	'.sidenote-right':'position:absolute; right:-10em; width:9em; background-color:#eeeeee; text-indent:0em; text-align:left;',
	'.sidenote-left':'position:absolute; right:-10em; width:9em; background-color:#eeeeee; text-indent:0em; text-align:left;',
	'.mw-editsection':'',
	'#headerContainer':'position:absolute; top:0em; right:-23em; width:21em; float:right; text-align:left;'
Seems that we need to amend #headerContainer to bring it back inside one of the other containers. If someone can play inside their special:mypage/common.css that would be brilliant. — billinghurst sDrewth 22:36, 3 January 2018 (UTC)
@Billinghurst: With respect Layout 3 "broke" for some browsers a long time ago but was not going to be addressed until the mobile/Visual Editor interface stabilised. Having received no feedback that either of the above two are not going to further change at a moment's notice please be very careful you are not patching over an abyss you did not even know was there. 114.74.62.196 23:42, 3 January 2018 (UTC)
Good points about how we manage and need to version control our layouts. Let us develop, then test functionality through the proposed layouts functionality.

I wasn't rushing into anything, CSS is not my strength, and as said before we need to get some expertise in this area if we are to progress well. Time we got better control of mobile, VE, and some play with sidenotes. Might need to go through phabricator, and get some attention at either Wikimania, or the proposed Wikisource conference. — billinghurst sDrewth 01:45, 4 January 2018 (UTC)

Problem importing books

For some reason this file and this file failed to import, is this normal? Or should I best ask this question on Wikimedia Commons? -- DonTrung (徵國單)  (討論 🤙🏻) (方孔錢 ☯) 12:37, 2 January 2018 (UTC)

ia-upload is a Commons tool. Best to ask for assistance there. Beeswaxcandle (talk) 18:44, 2 January 2018 (UTC)
log your issue into phabricator: tag with "ia-upload." — billinghurst sDrewth 22:04, 3 January 2018 (UTC)
there is a problem with jp2 which IA uses a lot hanging when trying to convert to dejavu. Slowking4 ‽ SvG's revenge 01:53, 5 January 2018 (UTC)

Transwiki some texts from oc-wiki?

I have a question about some medieval text that is currently in article name space on Occitan Wikipedia, and whether transwikifying it to Wikisource would be a better idea. I was under the impression that most wikipedias prefer references or short excerpts from primary sources, and not whole texts, plus, placing it here seems like the right venue.

I'm improving the article Querimonia on en-wiki, and among the Wikidata language links is one in Occitan. At oc:w:Querimònia, section #Tèxt dera Querimònia has nine links to what appear to be complete source texts written in Occitan, that are all located in oc-wiki article namespace. I'd prefer to see these texts transwikified here, instead; and then I could refer to them more easily from en-wiki (and the other wikis I work on), as well as using the en-wiki templates that provide a linked Wikisource box with a logo, and so on.

Can someone advise? Thanks, Mathglot (talk) 00:29, 6 January 2018 (UTC)

https://wikisource.org/wiki/Main_Page/Occitan is the proper source for Occitan works.--Prosfilaes (talk) 00:35, 6 January 2018 (UTC)
And the community help for that is at mul:Wikisource:Scriptorium and I would encourage you to seek their assistance. — billinghurst sDrewth 03:56, 8 January 2018 (UTC)

Scans not loading?

Is anyone else having problems with scans not loading in the Page namespace (either for view or edit)? Every time I try to edit, the connection times out before a quarter of the scan page loads. I've done everything at my end I can, from resetting the router to checking updates and restarting the computer. --EncycloPetey (talk) 21:57, 7 January 2018 (UTC)

@EncycloPetey: No issue for me, there was a bit of lag with the image presenting, though once started, it came through fine. I tested at Index:The History of Essex.djvu; not sure where you are having issues. — billinghurst sDrewth 04:03, 8 January 2018 (UTC)

Tech News: 2018-02

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

  • On Wikidata, the "save" button when you edit is now called "publish". This means all Wikimedia wikis have now changed from "Save page" to "Publish changes". This is to help new editors understand what it does. [2][3]
  • Some edits will get an automatic tag on all wikis. This will happen when making a page a redirect, blanking a page, removing almost all content, undoing an edit, or rolling back an edit. You can see the tags for example in the recent changes feed, article history, user contributions or on your watchlist. Some wikis had already marked edits like these in other ways. [4]
  • Special:UnusedFiles shows files that have been uploaded but are not used. It will show a file that is not used on the wiki it has been uploaded to, even if the file is used on another wiki. The new Special:GloballyUnusedFiles page on Commons only shows files that are not used on any wiki. [5]
  • Structured discussions now uses the 2017 wikitext editor instead of its old custom one. This will work with your preference for wikitext or visual editor. The documentation has been updated. [6][7]

Problems

  • Older versions of the Chrome web browser on mobile devices may see the PDF download button, but it does not work. The developers are looking into the problem. [8]
  • With the new filters in the recent changes, "Exclude selected" in "Namespaces" did not work for "Saved filters" between 13 December and 2 January. When you loaded the saved filter all other namespaces were excluded instead. This has now been fixed. If you made any changes to your saved filters between 13 December and 2 January, you need to save your filters with excluded namespaces again. [9]
  • The latest version of Google Chrome broke how section links are shown in the address bar. You now see #R%C3%A9sum%C3%A9 instead of #Résumé even if MediaWiki did not encode it that way. This happened in early December. This problem has been solved. The fix will be in Chrome 64 (23 January) or Chrome 65 (6 March). [10]
  •   Some POST requests to the API took longer than usual in parts of December. This affected the Wikidata UI and some gadgets the most. It has now been fixed. [11]

Changes later this week

  • Wikidata will be moved to its own database servers. This is because it is growing and needs more resources. Because of this you will be able to read but not edit Wikidata and the German Wikipedia between 06:00 and 06:30 UTC on 9 January. You might lose edits if you try to save during this time. This includes editing the language links on other wikis. [12]
  • The font size in the editing window will change slightly for some users. It will now look the same on all browsers and operating systems. [13][14]
  •   The new version of MediaWiki will be on test wikis and MediaWiki.org from 9 January. It will be on non-Wikipedia wikis and some Wikipedias from 10 January. It will be on all wikis from 11 January (calendar).
  •   WikiEditor's ResourceLoader modules have been simplified to one: ext.wikiEditor. All the other modules are now deprecated aliases and should be removed. [15]

Meetings

  •   You can join the next meeting with the Editing team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 9 January at 19:30 (UTC). See how to join.
  •   You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 10 January at 16:00 (UTC). See how to join.

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

16:19, 8 January 2018 (UTC)

Comments

  • Admins: We should look at our abuse filters as we have some that flag for blanking, if these new special:tags suitably cover an abuse filter, we can look to deactivate said filters. New names appear to be mw-new-redirect, mw-rollback, mw-removed-redirect, mw-changed-redirect-target and mw-blank. A review of the pages listed shows out good editing and capturing of junk, and not really much junk in the first place. I don't know whether they match up with our abuse pages, that is a check for another time.
  • I see numbers of examples of use of ext.wikiEditor.toolbar : (user: namespace results for the users to fix their issues) and in our Mediawiki: ns I see that we have four uses that need to be resolved

— billinghurst sDrewth 00:52, 9 January 2018 (UTC)

  Done or MW tools; users should do their own, or ask for help from an administrator. — billinghurst sDrewth 12:32, 9 January 2018 (UTC)

Wikidata and years in legal templates

Is there any way we could take the death year from Wikidata for the Pd/1923 style legal templates? I understand that it might be concerning to change a legal template based on Wikidata, but I've been cleaning up some author pages, and found a couple cases where Wikidata and the year in the template disagree. Maybe a category for disagreements, if automation is a step too far.--Prosfilaes (talk) 01:52, 13 January 2018 (UTC)

Keep in mind that some works require multiple dates, or rely on multiple date considerations. If a work has both an author and translator, or bot an author and illustrator, or multiple authors, we may require more than one license. I'm not sure we could easily automate those situations, and they're fairly common. --EncycloPetey (talk) 02:18, 13 January 2018 (UTC)
It would think that it would be possible, the one issue though I would think that it would also mean that we would want to pull all the data fields from Wikidata, rather than just the licence template dates. If the right data is at WD, e.g. author, translator, etc. that should allow template creation. Also, in these situations we have always allowed for manual overwrite. So {{pd/1923|}} or {{pd/1923}} would do {{pd/1923|(author|translator) year of death}}, though {{pd/1923|1923}} would be the override. We would also still control the templates on a page under this mechanism. I personally would like to explore the recording of licence templates at WD rather than locally, as that is a far easier and resilient place to check for presence and absence. — billinghurst sDrewth 04:20, 13 January 2018 (UTC)
Wouldn't that mandate that we have a WD item for the work / edition (and all relevant individuals) in order to have the license appear at all? Doing so would require editors who wish to add a license on a work here to understand the procedures at WD in order to add the license. --EncycloPetey (talk) 04:27, 13 January 2018 (UTC)
It requires the item to be present to pull that data, it doesn't require it to exist or compel a user to enter that data. Though once configured, one would think that it would also be readily bot-able. Bits of that could already be done using PLbot's harvest templates toollabs:pltools/harvesttemplates — billinghurst sDrewth 13:17, 13 January 2018 (UTC)
I was thinking purely about the author page, where you just need to the death data; work pages would be harder. It might be nice to have a category of Author pages without WikiData information, so users willing to insert data into WikiData could find them.--Prosfilaes (talk) 05:12, 13 January 2018 (UTC)
See Category:Wikidata maintenance.— Mpaa (talk) 13:05, 13 January 2018 (UTC)
Or Category:Author maintenance— Mpaa (talk) 13:15, 13 January 2018 (UTC)

Index:Occult Japan - Lovell.djvu validated and needs transclusion

Parking this here as I have just found this work has been validated for six months, and yet no pages are transcluded. I don't have the space do it now, and it needs parking in case someone else wishes to get to it. — billinghurst sDrewth 06:37, 12 January 2018 (UTC)

Was this one I validated or proof-read? It may have been parked owing to concerns about the comptence of my proofreading or validation.
No objections to giving it more passes to ensure it's 100% transcribed per the scans (within Common sense obviously).
ShakespeareFan00 (talk) 22:19, 12 January 2018 (UTC)
Looks good to me. Didn't go through all pages, but the starting pages did need a bit of minor cleaning. -Einstein95 (talk) 03:34, 15 January 2018 (UTC)
  Done the transclusion, merging some of the drop capital images. — billinghurst sDrewth 13:08, 15 January 2018 (UTC)

{{header}} and unrecognised dates

I recently found Category:Works with unrecognised dates and started going through and trying to make them in line with what is described for the year field on {{header}}'s doc. There's a couple things I've noticed:

  1. Dates
    A number of pages have the full date of publication (mainly for transcriptions of speeches). Should there be a |date= field so that the date can be standardised/localised? Much like {{date}} tbh.
  2. Unrecognised standard dates
    In the {{header}} doc, it says:
    Decades, centuries or periods can be used instead of a year (e.g. 1060s, 11th century or Medieval).
    [...]
    To use a approximate choice of two years, enter it as "Y/Y" (e.g. 1066/1067). This will display as it is written.}}
    However, using either of these still makes it appear in the aforementioned category.
    (Addendum: In the case of the latter where it spans multiple years, would it be better to show {year1}–{year2} and classify it as one of the years?)
    Edit:
    To use a tenuous year, enter it as "Y/?" (e.g. 1066/?). This will display as, for example, "1066?"
    As can be seen on Cleansing Wave, this doesn't do what's documented.

-Einstein95 (talk) 03:49, 15 January 2018 (UTC)

  • if full dates: move date to notes field, year should only be a year; full dates to wikidata if able

to the others, it sounds like "ugh", and some work is needed. :-/

— billinghurst sDrewth 13:12, 15 January 2018 (UTC)

Tech News: 2018-3

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

  • Bureaucrats on Wikimedia wikis where the Translate extension is installed can now add and remove the translation administrator permission by default. Administrators of wikis where this extension is enabled can add and remove this permission to or from themselves. Wikis that used a different configuration before have not changed. [16]
  •   There is a new Discourse test support channel for Wikimedia developers. You can ask questions or answer others questions about MediaWiki and Wikimedia software development. [17]

Problems

  • Last week's MediaWiki update was rolled back. This was because of a bug that changed non-ASCII characters when a page was edited. [18][19]

Changes later this week

  •   The new version of MediaWiki will be on test wikis and MediaWiki.org from 16 January. It will be on non-Wikipedia wikis and some Wikipedias from 17 January. It will be on all wikis from 18 January (calendar).

Meetings

  •   You can join the next meeting with the Editing team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 16 January at 19:30 (UTC). See how to join.
  •   You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 17 January at 16:00 (UTC). See how to join.

Future changes

  •   A few hundred wikis with less than ten high-priority errors in Linter categories will switch to use the Remex parsing library. This is to replace Tidy. It will happen on 31 January. Other wikis will be recommended to switch soon when they have fixed the errors that must be fixed. Tidy will be removed in the middle of 2018. [20][21]

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

18:45, 15 January 2018 (UTC)

Marking updates... in a document...

This is a pragmatic response:- Page:UK Traffic Signs Manual - Chapter 8 - Part 1 (Traffic Safety Measures and Signs for Road). Designs 2009.pdf/8 Given that Part 3 (not currently on Wikisource, published subsequently, and available here-https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/594446/traffic-signs-manual-chapter-08-part-03.pdf) published at a later date makes some amendments and updates a few cross references to more recent legislation or regulations.

Before I can continue adding revision annotations, I'd like a consensus on whether these should be added, or the document transcribed in it's 'as published' state, given that in other works annotations for subsequent revisions were not added.

If there's no consensus or objection, I'll revert the changes. ShakespeareFan00 (talk) 21:23, 15 January 2018 (UTC)

Requesting permission to delete Index

Index:The Complete Poetical Works and Letters (1899).pdf has a very poor text layer &c., and I personally would not want to transcribe from it. I have created a new Index Index:The complete poetical works and letters of John Keats, 1899.djvu to replace it, and request permission to delete the former Index and associated pages. There are no longer any pages that link to its created Index:pages other than the Index itself. Londonjackbooks (talk) 14:46, 16 January 2018 (UTC)

This request makes sense to me, I don't know what kind of permission is required but you've got my vote. If and when the index is deleted, it sounds like the PDF file should be deleted from Commons as well, in favor of the DJVU. I'd be happy to put in a request over there if you'd like, just let me know. -Pete (talk) 16:53, 16 January 2018 (UTC)
I don't know that permission is required, but ever plagued with self-doubt, I want to make sure I have dotted every i &c. before doing so. Another set of eyes on the particulars sometimes turns things up that I have overlooked. I'll let you know if a request to delete at Commons becomes a good thing. Thanks! Londonjackbooks (talk) 17:04, 16 January 2018 (UTC)
Can someone please remind me what Speedy Delete reason I should give for deleting Index:pages in the manner proposed above? "Updated/deleted source file"? or "Redundant"? or other? Thank you, Londonjackbooks (talk) 02:42, 17 January 2018 (UTC)
I use F8 Updated/deleted source file with the reason "changing from pdf to djvu" for this sort of thing. Beeswaxcandle (talk) 05:50, 17 January 2018 (UTC)
Thank you, BWC. @Peteforsyth: The Index and related pages have now been deleted here, so I suppose it is a "go" for you to request a Commons deletion. The File to delete is at Commons:File:The Complete Poetical Works and Letters (1899).pdf, and if needed for reference, the new (better) file is at Commons:File:The complete poetical works and letters of John Keats, 1899.djvu. Thanks much, Londonjackbooks (talk) 11:39, 17 January 2018 (UTC)
Listed. -Pete (talk) 18:28, 17 January 2018 (UTC)

Wikivoyage Edit-a-thon 2018

 

A special edit-a-thon will be held at the English Wikivoyage through February 2018 to celebrate the fifth anniversary of Wikivoyage. The main goal of this edit-a-thon is to encourage new editors to share travel information at Wikivoyage. Anyone interested in contributing, whether by updating outdated information or by adding listings of prominent sites/businesses such as a prominent museums, restaurants or hotels, is more than welcome to participate in the edit-a-thon.

The edit-a-thon is going to be held at several other editions of Wikivoyage including the German, French, Spanish, Italian, Ukrainian, Russian, Portuguese, Hindi, Hebrew and the Chinese editions of Wikivoyage. In addition, the use of a central notice banner has been requested to promote the edit-a-thon. ויקיג'אנקי (talk) 16:55, 17 January 2018 (UTC)

Atlantic Monthly link

The {{Atlantic Monthly link}} does not seem to be working properly. The issue number should link to the page for that issue, but it does not do so. Consider the documentation example 

{{Atlantic Monthly link|link=The Birds of the Pasture and Forest|volume=2|number=7|year=1858}}

The (7) should link to The Atlantic Monthly/Volume 2/Number 7, but instead points to the incorrect The Atlantic Monthly/Number 7. Can anyone see how to repair this? --EncycloPetey (talk) 22:59, 17 January 2018 (UTC)

  Done problem was in underlying {{article link}}. — billinghurst sDrewth 00:23, 18 January 2018 (UTC)

LintErrors

I've been trying to resolve some of this , but for some reason, fixing one of them seems to uncover others.

I'm essentialy reaching a stress point again... and would appreciate some support in ensureing pages don't break due to well intentioned 'fixes'.

Thanks. ShakespeareFan00 (talk) 23:42, 16 January 2018 (UTC)

On second thoughts , can someone give me a list of what's broken? ShakespeareFan00 (talk) 00:28, 17 January 2018 (UTC)
These for example show up with errors after my attempts to properly balance tags in them

I've now tried SEVERAL time to figure out why these are unbalanced in some ways, as the Linter extension is assumed not to be mis-detecting. Perhaps someone else can figure out what went wrong and silence the Linter extension which seems to be pedantic to the point of annoyance? ShakespeareFan00 (talk) 10:55, 17 January 2018 (UTC)

Agreement relating to Malaysia between United Kingdom of Great Britain and Northern Ireland, Federation of Malaya, North Borneo, Sarawak and Singapore/Annex E/table of contents - Putting a block into a span-style template is never going to work! So can someone suggest what an appropriate fix for this would be? Would providing the nominal documentation navigation in an alternative manner be appropriate?

ShakespeareFan00 (talk) 11:22, 17 January 2018 (UTC)

Looking at things just from your links is too hard, and to know the lint problems which you are discussing. The edit link each with their lintid are pertinent. Don't stress over it, not worth the effort. For some I am wondering whether it isn't the lint check itself may be the problem. — billinghurst sDrewth 13:53, 17 January 2018 (UTC)
That was my concern as well. I'll use the lintid in future? Goes off to code a link template.ShakespeareFan00 (talk)

Short Titles Act

https://en.wikisource.org/w/index.php?title=Short_Titles_Act_1896/First_Schedule/Pre_Union&action=edit&lintid=746406 Sigh. The monster of a template used to create this finally gave up. Maybe it's time to redo EVERY single entry in it manually :(, Where do I send the bill? XD ShakespeareFan00 (talk) 22:09, 17 January 2018 (UTC)

With due respect that approach still isn't going to work, evidently need to step back further with an explanation.

Special:LintErrors has numbers of subsets looking at very different component and it also shows the type of error and an indicator of where it is seeing it. Knowledge of the type of error is clearly important if that is what we are going to fix. From that it shows the edit link and again contextualises that. All that said, when Lint shows the result of a page that is full of transcluded pages, it highly unlikely to be on the parent page and instead be in the subsidiary pages. Unfortunately the lint system is not sufficiently mature to identify the errors in the Page: ns regularly enough, and that has already been highlighted back to the developers. Still cannot help you, haven't dug into wherever you are seeing it, but personally don't think it is anything over which to be stressed. — billinghurst sDrewth 03:03, 18 January 2018 (UTC)

Chronological_Table_and_Index_of_the_Statutes

And this has finally trigged my stress point again.... Can someone PLEASE find ONE approach on where to CONSISTENTLY place {{nop}} so that I'm not constantly having to go back and forth trying to figure out where stray DIV tags, linefeeds in the table headers and so on are coming from....

I've had problems with this particular work at least twice before and no satisfactory long term solution was ever reached. I've placed this work up for deletion on the basis that it's layout is 'experimental', and it would at this point be better to start again from scratch. Let's fix things like this once and for all, or decide such works are too complex to be transcribed , Okay? ShakespeareFan00 (talk) 02:35, 18 January 2018 (UTC)

<and this is where I get frustrated as this has been covered multiple times and explained here and in our help pages. I don't know how to make it easier to explain.

  • With continuing tables, in the body of a page: ns page a {{nop}} needs to start the body section, and then on a new line you start your table row; subsequently
  • on the page where table continues over (the preceding page(s)), we do not terminate a page or a table with a new table row marker tr |- or with a cell marker td |. Primarily it is redundant and unnecessary code. Secondarily, it causes problems for the code for our style of page numbering with transclusions.

example

Page:Chronological Table and Index of the Statutes.djvu/850 as per this edit shows the underlying code as 

<noinclude><pagequality level="1" user="" />{{rh|832|INDEX TO THE STATUTES.|}}
{{c|{{sc|Appendix VII. Inclosure.}}}}
{|</noinclude>|-
|Osehill Common||16 & 17 Vict. c. 3. 
|-
||Osmotherley||22 Vict. c. 3.
...

Note the third line where the header ends and the body starts and it shows that the row of the table will not be seen as a row as it does not start the line. Codewise what we need for this to be is 

<noinclude><pagequality level="1" user="" />{{rh|832|INDEX TO THE STATUTES.|}}
{{c|{{sc|Appendix VII. Inclosure.}}}}
{|</noinclude>
|-
|Osehill Common||16 & 17 Vict. c. 3. 
|-
||Osmotherley||22 Vict. c. 3.
...

and due to the vagaries of mediawiki, it needs to look like 

<noinclude><pagequality level="1" user="" />{{rh|832|INDEX TO THE STATUTES.|}}
{{c|{{sc|Appendix VII. Inclosure.}}}}
{|</noinclude>{{nop}}
|-
|Osehill Common||16 & 17 Vict. c. 3. 
|-
||Osmotherley||22 Vict. c. 3.
...

aka 

{{nop}}
|-
|Osehill Common||16 & 17 Vict. c. 3. 
|-
||Osmotherley||22 Vict. c. 3.
...

as the code has been known to swallow blank first lines.

Rider: There is code error in line 7 with || starting the line, so let us ignore that at this time. — billinghurst sDrewth 03:34, 18 January 2018 (UTC)

As an afterthough, what we probably may be able to do is to generate a {{nop}} equivalent that is just a fake templated statement that could be seen to sit into the style line of the table, and that is not a format-forcing line. We will need to have a play as putting in a forced blank class or style statement may ruin existing styling, so it just needs to be something table and formatting neutral. Ideas for {{nopt}} welcome. — billinghurst sDrewth 04:42, 18 January 2018 (UTC)
This is complicated by the sectionlisation. You seem to be saying it needs a {{nop}} after each section tag in the Page: body and not in the relevant Templates? {{Statute table}} should be placing a {{nop}} for each row (which to me seems like overkill). However on some pages this may have caused the Linter expression to see an error in respect of stray DIV's or P which are escaping. The {{nop}} at page start also causes the Page: where this situation arises to be erronously flagged as containing 'fostered' content. Should this specifc exception case be flagged as something Linter should ignore? ShakespeareFan00 (talk) 09:11, 18 January 2018 (UTC)
As I said elsewhere at this point , it would be more straightforward to delete the current broken transclusion until there's a long term solution.ShakespeareFan00 (talk) 09:14, 18 January 2018 (UTC)
In respect of something else you mentioned https://phabricator.wikimedia.org/T185203, I would appreciate your thoughts. ShakespeareFan00 (talk) 11:45, 18 January 2018 (UTC)
I started updating some other tables I noted had some of the issues you mentioned, attempting to follow the advice you gave. Following that advice led to "Missing end tag" errors being recorded, despite there being no apparent mismatching present in the supplied markup.

Because this seems to be occuring on a number of pages when they are edited, https://phabricator.wikimedia.org/T185221 has been opened.

As I've said previously, it would be nice to have ONE consistent approach from Mediawiki, that meant I don't have to spend hours playing hunt the estorica on every single edit made. At this point I am not just frustrated but disappointed that Mediawiki is having so much difficulty in rendering something which according to the advice you gave should not be giving errors at all. ShakespeareFan00 (talk) 15:45, 18 January 2018 (UTC)

On nopt and other termination/continuation issues

I'd apparently raised a phab ticket on my own iniative back in April of last year... https://phabricator.wikimedia.org/T163073 If anyone want to reopen in , I have no objections. ShakespeareFan00 (talk) 12:45, 18 January 2018 (UTC)

Edit window font size

Is there a means to increase the font size in the edit window without increasing the font size in my browser? I can find nothing in the Preferences.

I find the font size in the edit windows here is suddenly much smaller than it used to be, even though all the other text still displays at sizes that it used to. This makes proofreading (or participating in discussion) difficult as I have to keep adjusting font size in my browser every time I go into or out of the editor, and I'd prefer not to do that. I assume that other readers and editors with vision problems could be facing similar challenges.

I first noticed this problem late last week, but did not post at that time and have been recovering the the flu since then. Did someone mess with something fundamental again? --EncycloPetey (talk) 23:03, 17 January 2018 (UTC)

@EncycloPetey: the editing preference page is where you control the typeface, and I use monospaced and it gives me a decent font size. Otherwise you will have to modify the font-size element through editing your special:mypage/common.css for the editing box
<textarea tabindex="1" accesskey="," id="wpTextbox1" cols="80" rows="25" style="" class="mw-editfont-monospace" lang="en" dir="ltr" name="wpTextbox1">
— billinghurst sDrewth 00:33, 18 January 2018 (UTC)
Monospace gives me a decent font size but is utterly worthless for working with Greek text, which becomes unrecognizable in the monospace font. --EncycloPetey (talk) 01:36, 18 January 2018 (UTC)
have you tried Wikisource:WikisourceMono? that appears to change font on the style sheet. or a different skin? monobook seems larger to me, or even timeless. Slowking4 ‽ SvG's revenge 00:28, 18 January 2018 (UTC)
Not yet. I wanted to to first find out why this has changed recently (and all of a sudden) for me, and to find out what solutions there might be. But checking Monobook, it does not solve the problem. Nor does Timeless solve the problem; and it worsens the issue by reducing available screen space for side-by-side editing. --EncycloPetey (talk) 01:33, 18 January 2018 (UTC)
here is an old discussion about fonts Wikisource:Scriptorium/Archives/2015-01#What_is_the_mediawiki_code_editor's_font-style_and_size? -- my appearance gets tweaked all the time, what with zoom in / out; tech update. the timeless skin does do the "flat sidebar gadget" over at wikipedia (giving more room for side by side) alas does not work here. if customizing script, you could try different fonts, and pick one that has greek support. i’m trying to save my grumpiness for the culture, and not the tech, as that is out of my control (other than wishlist). Slowking4 ‽ SvG's revenge 02:14, 18 January 2018 (UTC)
I'm largely clueless about editing preferences manually. I would probably need to have someone tell me exactly what code to edit and exactly how and exactly where in order to achiieve the resuts I needed. Apologies for the typos; I'm not going to keep messing with the browser settings in order to see what I'm typing. (I can see there is red, but I can't read the text that's underlined at that size.
It really seems to me that (a) font size for a given fount should remain the same whether reading or editing, and not have a 70-80% difference in size between the two, and (b) adjusting font size should be a simple thing to deal with, as editing is a fundamental part of all MW projects, and (c) given the supposed desire to accomodate people with disabilities such as vision impairment. Suddenly dropping people's edit font size to 70% or so is counter to that. I have now verified that this problem affects me on all projects where I edit, so it is a general MW change that happened at some point about a week ago. I'll be following this thread, but otherwise, the annoyance and eyestrain are too much for me. I have to take a wikibreak from all editing until this problem can be sorted out. --EncycloPetey (talk) 03:00, 18 January 2018 (UTC)
There has been numbers of modernisations/standardisations happening over months as they convert to OOUI style. I am _guessing_ that this is an artefact of those changes with the vector skin, though you would need to look to through the recent upgrades at mw: and search for what is happening. Monobook and monospaced has had no apparent changes, so I cannot comment on specific changes. — billinghurst sDrewth 04:13, 18 January 2018 (UTC)
I could look through the upgrades, but I would be none the wiser because I would not understand anything I was reading. Guess I'm stuck not editing then. --EncycloPetey (talk) 16:09, 18 January 2018 (UTC)
This is straightforward with your user CSS (it's what it's for). The following increases serif fonts in the editor by 20%:
.mw-editfont-serif {
	font-size: 120%;
}
You can have different settings for ".mw-editfont-serif", ".mw-editfont-sans-serif" and ".mw-editfont-monospace" if you like (you could change font, colour, weight, size, line spacing, whatever). Just add the CSS to User:EncycloPetey/common.css. Inductiveload—talk/contribs
here is the phabricator https://phabricator.wikimedia.org/T182320 ; here is the mediawiki https://www.mediawiki.org/wiki/Editing/Projects/Font_size_in_the_editing_window -- i feel you pain, they need to stop tweaking the interface, or make it easier to adjust settings, without having to know code. it is not straightforward. (that is basic UX project management practice) Slowking4 ‽ SvG's revenge 19:06, 18 January 2018 (UTC)
Thanks for the links. I have posted a summary of the problems I'm experiencing in the thread on mediawiki. --EncycloPetey (talk) 21:55, 18 January 2018 (UTC)

Wikibible editors wanted

The wikibible project, located at Translation:Bible is in need of editors, especially those that know Hebrew and Greek(Latin and Syriac/Ethiopian knowers are also appreciated).

In addition, the bible transcription projects could also use editors(see Bible and also look for transcription indexes for the translation you want to work on). Most useful are editors who understand archaic typography, though there are multiple translations that use modern typography and still aren't done(or even close). JustinCB (talk) 16:33, 18 January 2018 (UTC)

{{copyright until}} template broken by SDrewthbot

Going through Category:Pages claiming copyright without date and found this edit which broke the templates back in 2015. Thought I'd bring it to attention as I'm not sure if @Billinghurst: was aware of it. -Einstein95 (talk) 01:37, 19 January 2018 (UTC)

again here as well: https://en.wikisource.org/w/index.php?title=Author:James_Thurber&diff=5668150&oldid=4827554 -Einstein95 (talk) 01:44, 19 January 2018 (UTC)
User talk:SDrewthbot would be a good starting point. —Beleg Tâl (talk) 04:02, 19 January 2018 (UTC)

Lua coder sought..

Are there any Lua coders active on Wikisource?

I had some tables currently generated by a series of templates, that for performance reasons and layout concerns might be better generated using a suitable module.

Matters are complicated by the need for the relevant generated tables to be 'sectionalised' as the entire table cannot be transcluded in one go. ShakespeareFan00 (talk) 09:00, 19 January 2018 (UTC)

@Pigsonthewing: Andy doesn't edit here much but he's been very helpful to me with issues like this elsewhere. If he has the time and energy, he's my go-to. —Justin (koavf)❤T☮C☺M☯ 09:13, 19 January 2018 (UTC)
Thank you. I'm OK at templates, but I'm not a Lua coder; try asking on Wikipedia talk:Lua. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:28, 19 January 2018 (UTC)
Perhaps you'd like to look at Special:LintErrors, and try figure out why certain templates cause the Linter extension to have concerns? ShakespeareFan00 (talk)

Notifying the community about a Bot Request

Courtesy notification.

Wikisource:Bot_requests#Reset_proofreading_status_of_Page:s_flagged_by_Linterrors_to_"Problematic"

It would be nice to have some indication of just how much breakage the parser migration is going to cause.

Attempting to have a break from editing, but on checking in I keep seeing works I put considerable effort into showing up in Special:Linterrors ShakespeareFan00 (talk) 18:16, 19 January 2018 (UTC)

Important, fascinating and timely transcription: US House interview with Fusion GPS founder Glenn Simpson

All,

I'd like to request some help with a project. Yesterday, the U.S. House Intelligence Committee released an unredacted transcript of its interview with Glenn Simpson, founder of Fusion GPS, concerning the "Trump dossier".

It's a truly fascinating document, outlining many details of how the Trump Organization does business. It's already been widely covered in the media, but there are many aspects of the 165 page document that have not received much attention. I believe this is a rare case where a solid and timely Wikisource transcription could have a significant impact. Researchers and journalists could do machine translation, search, etc. on a Wikisource transcription, more easily than on the OCR'd PDF document released by the government.

Currently, there are two of us (myself and Jasonanaggie) actively working on it, and we're about halfway done with proofreading (and about a quarter of the way through validation). It's a pretty easy project, the OCR is highly accurate. Even one additional set of eyes would significantly speed up the process. -Pete (talk) 18:39, 19 January 2018 (UTC)

The House transcript is redacted in certain places: some interviewers' names are themselves redacted throughout the document. Pete's request should extend to validating the Senate Judiciary Committee Interview of Glenn Simpson as well. Mahir256 (talk) 19:07, 19 January 2018 (UTC)
Thanks Mahir. Just to be clear-
  1. What I meant by "unredacted" is that the substance of the testimony is entirely (or at least mostly, perhaps I've missed something) unredacted. The redactions, as far as I've seen, are limited to the names of lower-level government staffers and lawyers. I don't believe any of the testimony of the interviewee has been redacted, which I find remarkable for a document like this.
  2. As for what my request is, of course validating the Senate testimony would be worthwhile, but I find the House testimony more interesting, and in my view getting all the pages proofread is a higher priority than validation. The Senate testimony is fully proofread, but we're only about halfway through on the House testimony.
Anyway, thanks for your interest Mahir. I'm not arguing with your statements, just trying to be clear about what mine are. -Pete (talk) 19:24, 19 January 2018 (UTC)

Guidelines for removal of line breaks

Help:Beginner's guide to typography suggests it is best practice to remove any line breaks... Agreed. But it adds that it may be easier to do this after proofreading. I suggest that the latter note be eliminated, in that 1) it describes a matter of personal proofreading practices and 2) is ambiguous as to whether "after proofreading" means during validation or just prior to hitting the proofread button.

It is my opinion that line breaks ought to be removed during the first proofread process, for if left to a validator, it presents a possible distraction to other errors that may be present in the text. And new editors perhaps not familiar with guidelines may be completely unaware that line breaks ought to be removed at all (and validate as-is)—or as to technical issues that can arise when line breaks are kept. Londonjackbooks (talk) 14:19, 17 January 2018 (UTC)

  Support I agree with everything written above. Jpez (talk) 17:23, 17 January 2018 (UTC)
  Support I have personally seen "validated" pages that don't have the linebreaks removed. Just a pet peeve, but one backed by guidelines. -Einstein95 (talk) 19:41, 17 January 2018 (UTC)
  Support Seems reasonable enough (the text below). I like that it's a recommendation not a requirement, because sometimes it isn't a problem. -Pete (talk) 20:48, 17 January 2018 (UTC)
Not always a problem, but for me, like Einstein95 states, it is a pet peeve of mine. Often, I will not validate a page if whole paragraphs of line breaks remain. I may remove them, but will not mark the page as validated (in case I miss other errors for having been distracted by break removal). I am making an exception with the current PotM, however. I would like to see another short, quirky work get worked on before the end of the month! :) Londonjackbooks (talk) 21:14, 17 January 2018 (UTC)

I recommend a rewrite along the following lines:

Remove line breaks.
Printed books break lines of text to fit lines to a page. Scanned texts often render line breaks at the end of each line according to how they appear in the original text. Such breaks are considered artefacts of the printing process. When transcribing a text from its source into a Wikisource page, it is best practice to remove these line breaks. Although web browsers will naturally wrap text for the individual reader, there are cases where leaving in line breaks proves problematic. It is recommended that line breaks be removed during the proofread stage of editing to lessen distraction during the validation stage. There are tools available for this purpose if manual removal proves tedious:
[Alternate] Removal of line breaks.
Printed books break lines of text to fit lines to a page. Scanned texts often render line breaks at the end of each line according to how they appear in the original text. Such breaks are considered artefacts of the printing process. Although web browsers will naturally wrap text for the individual reader, there are cases where leaving in line breaks proves problematic. Therefore, when transcribing a text from its source into a Wikisource page, it is recommended that these line breaks be removed during the proofread stage of editing. Doing so at this stage lessens distraction during the validation stage. There are tools available for this purpose if manual removal proves tedious:

Londonjackbooks (talk) 20:44, 17 January 2018 (UTC) updated section content above Londonjackbooks (talk) 11:43, 20 January 2018 (UTC)

i kinda suppport. if you remove line breaks for the last paragraph, it displays correctly at page level. would not want to make it mandatory, although it is my current practice, i can leave more red pages with no line break fix, if you like. Slowking4 ‽ SvG's revenge 00:23, 18 January 2018 (UTC)
I don't wish to make it about what I like. I'm just trying to simplify things by eliminating exceptions ("keep line breaks—if you like—as long as you eliminate them here and here and here") by keeping things tidy & uniform. I am at a loss to explain practically why I believe it is best practice to eliminate line breaks (I was hoping for help). At least, however, one paragraph "should" match another on a single page where line breaks are concerned. No need to leave red pages if it indeed has been proofread according to guidelines... Londonjackbooks (talk) 01:02, 18 January 2018 (UTC)
well - we do need to delete the ghost soft carriage returns, so text will flow for the e-readers and phone use of digital document. if we have a tool that would be good too. we all agree should be done at validated, now debating as prerequisite for proofread step. (i have done both). Slowking4 ‽ SvG's revenge 02:10, 18 January 2018 (UTC)
Only encouraged/recommended at proofread step—for those not comfortable with making it mandatory. Londonjackbooks (talk) 02:15, 18 January 2018 (UTC)
  •   Comment The guidance was given as some works are easier to proofread with original formatting, primarily the encyclopaedic-type works, eg. look at Page:EB1911 - Volume 13.djvu/387. I hesitate to direct where it doesn't break the formatting and we have some pretty good TemplateScript regex that make it easy to update. — billinghurst sDrewth 00:40, 18 January 2018 (UTC)
    Is to "recommend" akin to "direct"? Londonjackbooks (talk) 01:06, 18 January 2018 (UTC)
    BTW, current wording of the subject line "Remove line breaks." already implies the direction to remove. If that is not the "spirit" of the section, then I propose rewording the section title to read "Removal of line breaks" or simply "Line breaks". Londonjackbooks (talk) 01:25, 18 January 2018 (UTC)
    And in the case of collaborative efforts, shouldn't the practice—to remove or not to remove—be followed by all contributors within a single work just as with other formatting for uniformity purposes? Londonjackbooks (talk) 02:00, 18 January 2018 (UTC)
    I support the above idea of making it clearer in Help:Beginner's guide to typography, and it's always possible for individual works to have their own standards to follow. Perhaps some works are better off with the original linebreaks left in; if so, they can say so on their Index page I reckon. (In fact, this reminds me of something that I've wanted for a while: a standard boilerplate for works to use to specify what their local style guides are — e.g. line breaks, headings, etc....) But yeah, the default should be to remove them (I use a PageCleanUp toolbar button for that). Sam Wilson 08:15, 18 January 2018 (UTC)
  Comment For those that aren't aware there are tools that automatically get rid of these page breaks. For example Wikisource:Tools_and_scripts#PageCleanUp. I separate the paragraphs and then use this tool to get rid of all the line breaks. It also changes curly quotes, joins hyphenated words at line breaks, fixes some typos etc. Maybe this should be mentioned in the beginners guide also. Jpez (talk) 05:00, 18 January 2018 (UTC)
I have updated the section wording above to include a mention of tools. If there is more than one tool that can be used for this purpose, it would be good to list it/them somewhere in the Beginner's guide or elsewhere so it can be properly linked to from the section. Londonjackbooks (talk) 09:49, 18 January 2018 (UTC)
I have also provided alternate wording of the section/section title above for those who favor a less stringent approach. Anyone is free to suggest different wording. Londonjackbooks (talk) 13:23, 18 January 2018 (UTC)

Can someone please point to any tools/methods other than PageCleanUp that can be used to remove line breaks? Thanks, Londonjackbooks (talk) 12:24, 19 January 2018 (UTC)

I hacked together User:Inductiveload/LineCollapse.js from the cleanup script. It collapses line breaks and also removes hyphens from words hyphenated across line breaks. Use it like importScript('User:Inductiveload/LineCollapse.js');. The tool is added to the sidebar as it is a TemplateScript tool.
Note: For hyphenation, this is sometimes wrong (e.g. "antidis-|establishment" should be "antidisestablishment", but "forty-|two" shouldn't be "fortytwo"). This is a hard one to get right 100% of the time, you'd probably need a whitelist and some heuristics to even get rudimentary awareness of when hyphens should be retained, which is not worth it IMO since you still need to proofread and a wrongly-contracted word should show up under spellcheck anyway. Patches always welcome, however! Inductiveload—talk/contribs 00:04, 20 January 2018 (UTC)

Parser migration issues ; Identifying "Interrupted phrasing" due to mis-nested templates, or tags?

Having learnt a little bit more, and testing something. It was found that a not inconsiderable number of the concerns identifed by the Linter extension are due to attempting to place a block level element (such as P, DIV, IMG, TABLE, UL, OL, LI) inside a span (or phrasing style) level element. This understandably leads to the potential for malformed HTML5 to be generated.

In my somewhat limited efforts, I've encountered pages where this mis-nesting occurs because an attempt or usage has been made template that uses a block level element (typical a DIV), inside (or as a parameter to) a template which uses a span to wrap the relevant content.

With that in mind it would be appreciated that over time (it's not a high priority) additional information was noted (ideally as part of the template documentation as to whether the template is block or span based (i.e whether its phrasing based or not per HTML5 models), or consideration given to a hireachy chart of templates so it's easier for those proofreading to note where something like {{larger|{{rh||Heading|Page_num}} should ideally be replaced with {{rh||{{larger|Heading}}|{{larger|Page_num}}}}.

It is also noted that currently using [[File:name|size|caption]] inside a span is also considered bad structuring because on examining the HMTL generated, mediawiki in many instances wraps the IMG tag generated in a series of DIV's. It may also be that unless told otherwise some browsers treat IMG as a block level element in it's own right. Is there a way to generate the relevant A/IMG pair without the wrapping diffs (one use case being an image that is inlined, perhaps to show a rare character which is not easily supported purely by text.)?

I encountered this issue when trying to use {{anchor+}} to make an image itself an anchor point, {{anchor+|fig3.1|[[File:figure3.1svg|500px|center]]}} for example is NOT going to work given that {{anchor}} on which it is based uses a classed span to create the anchor. The current work-around is to replace instances of this with usage with {{Anchor|fig3.1}}[[File:figure3.1svg|500px|center]] which solves the immediate Linter concern, essentialy moving the IMG (and wrapping DIV's outside the anchor templates generated span.

(Aside: Longer term and following a disscussion on the #wikimedia-tech IRC channel, the possibility of an a, @, anchor option in File synatx was raised. No phabricator ticket has been filed on this as it would need further discussion.)

My apologies for my some heated initial responses to such issues. ShakespeareFan00 (talk) 09:26, 20 January 2018 (UTC)

But having played another round of hunt the pednatic minutiae I've had enough - https://en.wikisource.org/w/index.php?title=User:ShakespeareFan00&oldid=7206988, thanks to the parser migration issues you've potentially lost a long-term contributor, whose reached frustration point with respect to feeling obligated to "repair" many of their past contributions. I am however more than happy to continue repairing stuff, when
  • The tools flagging up concerns are able to identify the precise point in a page where the concern is, a generic "Not from single template" does not aid this in any manner, Nor does in-effective highlighting.
  • There is a consistent and clearly DOCUMENTED behavior for things like table continuations over multiple pages, how whitespace is dealt with in all situations, which templates can and can't be nested in each other &c. &c.

ShakespeareFan00 (talk) 01:12, 21 January 2018 (UTC)

Migration user guide

I've taken a look at a few of the linter errors (out of the ~500k that are reported). Many of them appear to be essentially "harmless", as the two parsers appear to produce (visually at least) the same results. You can check with the Parser migration tool in Preferences under Editing. Any case where the two parsers agree that that wikitext is not quite right, but still produce the same output is not a worry. For example, obsolete tags and table continuations causing fostered content with nops is rendered the same. Nice to fix, but not going to explode soon.

I have written a quick guide at User:Inductiveload/Parser migration to describe some of the errors, the tools you can use to localise them, and what you can do about them. If anyone wants to recycle it for a proper help page, they're welcome to any part of it.

Probably the most important one is the use of block formatting inside span-based elements. This does actually cause breakage of the output under common use cases like this: 

{{larger|Line 1

Line 2}}

In the new parser, only the first line will be larger. For templates that increase the font size, a simple replacement with the block equivalent like {{larger block}} should suffice. For going smaller, the block templates affect line height where the span templates would not. An alternative is to use the span templates, but one per line and leave the paragraph breaks on the outside of the span.

The problem is there are something like 15k pages with this linter error on them, and I not sure it's a trivial bot job, though, perhaps it is not that hard. Inductiveload—talk/contribs 03:31, 22 January 2018 (UTC)

I have had a look at lots of examples and it doesn't look easily and reproducibly bot'able if we wish to remain 100% true to the work formatting, due to some of the differences in line height. That said it is the perfection to the word that is important and slight variation in formatting is not going to be horrendous, so I don't believe that this section is that not problematic where it is the size-related formatting and contained to one page. Where formatting starts on one page and finishes on the next, or some subsequent page, bots just know the problem that they see on a per page level, they are not aware of the impact of text previous or subsequent pages.
The biggest fail with the converting to the block templates is where the formatting has been applied to multiple paragraphs or a complete page. So rather than properly use a {{.../s}} {{.../e}} pair they use the span templates for single or multiple paras. So we would need to check for \n commencement/termination if botting. The pages with a starting and closing span size template need to have those templates pushed to header and footer, though eyeballing all the curly brackets on a page and knowing the start and finishes is less than perfect.
My anecdotal evaluation of the biggest use of the problematic span templates that wrap <p> or <div> is with title pages, and with quoted texts. Title pages are pretty easy to identify and then resolve. The quotations and the weird uses, not so. If we know that it is contained to a page, then it just affects the view of the text, if we get the replacements wrong, then we run the risk of broken templates, and sometimes these only show when you transclude, not at the Page:ns level.
Anyway, that is my initial feedback from doing about some thousands or so of these cleanups. — billinghurst sDrewth 05:23, 22 January 2018 (UTC
Follow-up. The output of these special lint filters are not visible to tools like AWB to build lists. Or it may be more accurate to say that AWB cannot pull these lists, so that is a hindrance. Similarly, the produced error pages have superfluous text, so you cannot even easily copy and paste to pull a list. So their access to bots I have found problematic. So is there a means to pull lists of pages, without gumph via the api? — billinghurst sDrewth 05:27, 22 January 2018 (UTC)
It turn out there is a linter API, for example a list of mis-nested tags which will break can be found at https://en.wikisource.org/w/api.php?action=query&list=linterrors&format=json&lntcategories=html5-misnesting
API documentation is at the extension page at MediaWiki (not the Help page): mw:Extension:Linter#API Inductiveload—talk/contribs 12:47, 22 January 2018 (UTC)
Support requested to pywikibot: https://phabricator.wikimedia.org/T185519 .— Mpaa (talk) 19:01, 22 January 2018 (UTC)
Example of a page where we need to block and to /s /e https://en.wikisource.org/w/index.php?title=Page:EB1911_-_Volume_06.djvu/162&action=edit&lintid=507667

Tech News: 2018-04

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

Problems

  • With the new OOUI look menus and popups can open upwards instead of downwards. This was meant to make long dropdown menus easier to use. Sometimes these menus have been overlapped by other things. This is now fixed. [24]

Changes later this week

  • There is no new MediaWiki version this week.

Meetings

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

Future changes

  • irc.wikimedia.org will be rebooted on 22 February. Some bots use this to get the recent changes feed. They need to be able to reconnect automatically or they will not work until they have been fixed. Most bots can reconnect automatically. [25]

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

23:55, 22 January 2018 (UTC)

Formatting UK legislation...

ON a slightly more positive note.

In checking back on something, I happened to look into the CSS style-sheet used at legislation.gov.uk. What's noted is that apparently the Style Sheet has an OGL notice on it. This means potentially that if someone had the interest, it may be possible to implement a set of appropriate classes to format UK legislation on Wikisource in the same way it appears on the official site. ( A quick glance at some of the page source suggests classed spans are used to do the numbering for some "paragraphs" much in the way sidesnotes are 'partially' supported on Wikisource at present.

I'd made some previous efforts in trying to get templates like {{cl-act-paragraph}} working, but was eventually running up against mediawiki.

Perhaps someone that is technically able could like into overhauling the {{cl-act-paragraph}} and {{uksi}} families into something that's genuinely usable, longer term?

ShakespeareFan00 (talk) 23:31, 17 January 2018 (UTC)

On a related, someone on IRC noted that the UK Government had seemingly placed some technical information as to how legislation.gov.uk worked internally on Github [26] (effectively it's a set of XML Schema and CSS.), Not directly usuable, but it may give some hints on how the Cl-act, family of templates could be re-worked.. It's interesting to note that they in one of the XSL sheets the back end content is being converting to DIV's not paragraphs as the template does currently.. Hmmm.... The previous version of the problematic {{cl-act-paragraph}} was using a div based approach until complications arose. ...

It would need a VERY experienced coder to make sense of it, but I remain hopeful that if such a person exists, it should be possible to display any UK legislation on Wikisource in an identical way to the official site. (Albiet not necessarily exactly like any given printed scan though) (But then sometimes there have to be compromises.) ShakespeareFan00 (talk) 00:17, 25 January 2018 (UTC)

Indentation

Hi. How can I indent a title? I mean what template do you have here which I can use in Persian wikisource so to indent the title you see in this page to look like the source? --Yousef (talk) 21:16, 24 January 2018 (UTC)

@Yoosef Pooranvary: If you're talking about "دیپلوماسی", try {{float left}} and {{float right}}. Mahir256 (talk) 21:22, 24 January 2018 (UTC)
Would that give the desired padding? For one work—although not a template—I used (as suggested by another contributor) <span style="float:left;font-size:smaller;line-height:100%;margin:0.7em 1em 0.7em 0;width:7em;">'''TITLE'''</span>. It behaved well no matter the length of the title. Just an option. There may be a better one. Londonjackbooks (talk) 21:28, 24 January 2018 (UTC)

Thank you both. The template didn't work but the HTML tag worked perfectly. --Yousef (talk) 21:46, 24 January 2018 (UTC)

@Yoosef Pooranvary: If you come to find that a single word is longer than the 7em width setting resulting in overlapping of text, merely adjust the width length. You probably know this already. Londonjackbooks (talk) 01:02, 25 January 2018 (UTC)
@Yoosef Pooranvary: I would recommend that you try and implement a template for this sort of issue. A template allows for a more standardise presentation, and as we are finding out with linter errors, that it allows for easier fixing. I also see that we are learning that rigour on div and span usage and knowledge to the community is important. — billinghurst sDrewth 01:23, 25 January 2018 (UTC)

Global Collaboration products newsletter: 2018-01

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

What's new?

  • The Global Collaboration report for December is now available (in English).
  • Filters are better integrated on Related Changes (see below).
  • Structured discussions now use the 2017 wikitext editor (see below).

Edit Review Improvements [More information • Help pages]

Bug fixes

  • When searching, a click on a filter capsule moved the list of filters. [27]
  • On Related Changes page, the page name entry box didn't show the entirety of long page names. [28]
  • Transcludeing Special:RelatedChanges on a page added unexpected parameters to the URL. [29]
  • Filter menu was opening upwards. [30]
  • ORES preferences on Recent Changes and Watchlist preferences pages have been rationalized. [31]
  • Users are now prevented from clicking on a link when they click outside of the dropdown menu to close it. [32]

Work in progress

  •   Filters on Related Changes page are better integrated and get new features, for instance: [33]
    • The standard auto-completion mechanism is available when you search for a page to look at.
    • It is more clear if you are looking to pages linked from the target page or to the target page.
    • You no longer need to click the "Show" button; the page updates automatically when a page is positively identified via autocompletion.

Content translation [More information • Help pages]

Recent changes

  • Further enhancement are made for list (Suggestions/In-progress/Published) items on mobile screens. Long titles no longer overflow or overlap with other interface elements. [34]
  • Various changes to the "New translation" dialog and the selected page for translation have been made: [35]
    • Longer titles of selected pages are displayed in smaller. Some space has been added around to increase readability.
    • Language codes are not truncated by ellipsis anymore. Only full, autonym language names are subject to truncation.
    • Minimal screen sizes and selected suggestion dialog have been revisited. They are more consistent in responding to screen size changes.
    • Discard button is no longer shown on small screen sizes.
  • Language filters no longer render wrong or non-existent language codes. [36]
  • The "New translation" dialog now shows a loading indicator and doesn't display an error when you change the source language after an unsuccessful research. [37]

Structured discussions [More information • Help pages]

Recent changes

Future changes

  • Structured discussions does not always follow wiki's configurations concerning talk pages indexation. This will be fixed. [40]
  • Hidden topics will not be indexed by search engines anymore. [41]

Notifications [More information • Help pages]

Bug fixes

  • User rights change notifications were displaying a broken link. This is now fixed. [42]
  • "Mark as read" buttons had a bad appearance for users who don't have JavaScript activated. [43]

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

00:56, 25 January 2018 (UTC)

Esoterica in regard to Proofread page....(and yes this is also partly Linter and RmexHTML related)....

1. Currently proofread page uses this as a header sequence: <noinclude><pagequality level="1" user="ShakespeareFan00" /></noinclude> to give an example. However I have had instances where I am wanting to put content in the main body of a page, that isn't necessarily header content, but not have that content transcluded (such as table "ribbon" headers, continuation text from an item on a previous page where it wouldn't make sense to put that content directly into the transcluded version and so on.). Why does Proofread page not have <noinclude element="header"> , <noinclude element="footer"> defined for the 'special' regions, which would be less confused with standard <noinclude></noinclude> at the very start or end of a "body" of page text?

2. Something that I am also still having trouble figuring out is just where line feeds occur, and am in respect of various of my templates wondering if {{nop}}, {{nopt}} etc should be replaced with precisely defined item-termination or item-continuation parser functions. One of the issues identified elsewhere was the need to do things like the templates mentioned because there's no in markup way to tell the parser the previous item's ended... A nop isn't needed so much as "Yes the item being transcluded on the previous page has finished", Unwind back to the appropriate level tag closing/wrapping as needed, and start reading any following markup as though it was on a new line.. Experimentally {{nopt}} may work in some cases, but an explict "I've finished/not finished this item" marker implemented to tell the parser to change it's handling would to me be far better than trying to force line feeds using implied white-space or "interruption" by block elements (the current approach in {{nop}}.

I'd appreciate some feedback as when and where to put in or take out whitespace to get templates working as intended can get very confsuing very quickly..ShakespeareFan00 (talk) 21:50, 25 January 2018 (UTC)

It seems to handle having <noinclude> at the beginning of the body just fine. You need to actually put the <noinclude> tag there, it doesn't happen automatically like in the header and footer, but it doesn't brake either. {{nop}} and {{nopt}} just stop the newline from being swallowed by the software during the transclusion process(so if you have a template that needs to end with a newline, put {{nop}} or {{nopt}} by itself on the newline[they're also used in the Page: namespace for the same reason because pages get transcluded as well]). Sometimes if you have white space(specifically new lines) within a template, it can brake, but you can use "<--"(without the quotes) at the end of the line and "-->"(again without the quotes) at the beginning of a line(this is if you want newlines for readability, &c.). If you have a more specific question, ask it and someone can answer it for you). JustinCB (talk) 20:41, 26 January 2018 (UTC)

{{cl-act-paragraph}} desired behaviour for split=table in rewrite(User:JustinCB/cl-act-p)

Anybody knowledgeable and/or with a vested interest in this template, what is the desired behavior for split=table ? Do you want it to cause the template to be able to contain a table & use other values(ex. split=table-start) for handling if it's starting, continuing, or ending, or do you want it to pass through like it does(which doesn't allow it to apply styles to the table[margins, indent, &c.])? Any feedback will be appreciated. JustinCB (talk) 20:39, 26 January 2018 (UTC)

Building single function complex templates is generally only of interest and understandable to the user. Getting someone else to try and resolve something that is very specific in context is difficult, laborious and time-consuming; and not necessarily of value to other requirements on site. Most of us writing more complex templates will break a templates function down into parts utilising subpages. Look at something like Template:Collaboration and have a look at its page information. — billinghurst sDrewth 23:32, 26 January 2018 (UTC)

Page:Public General Statutes 1896.djvu/35

In good faith I replaced the {{nop}} I had been using here with a {{nopt}}. The result was in: https://en.wikisource.org/w/index.php?title=Page:Public_General_Statutes_1896.djvu/35&oldid=7221293

I'd already subst my header template and the rows for performance reasons, and I can't see an obvious whitespace that's leaking in. Perhaps some other more experienced contributors will be able to comment? (It seems hard to get a consistent rendering between a Page: and mainspace...)

As I've said repeatedly in the past, expecting contributors to know precise whitespace handling rules is perhaps unreasonable.

ShakespeareFan00 (talk) 11:08, 27 January 2018 (UTC)

Import from mul.ws

s:mul:The Morals of Chess, per a discussion on that Scriptorium. It looks like our only importer or transwiki importer is User:Jarekt who hasn't been active here in awhile. Can someone with advanced user rights please assist? Thanks. —Justin (koavf)❤T☮C☺M☯ 22:49, 28 January 2018 (UTC)

Technically, we really don't need to preserve attribution on the uploader of the original text. As for the paraphrase, I think it's out of scope here; we allow translations, but the language of the original text is clearly Modern English, not even the Early Modern English of Shakespeare.--Prosfilaes (talk) 23:16, 28 January 2018 (UTC)
Sorry, I don't understand--are you saying this isn't the original work itself. —Justin (koavf)❤T☮C☺M☯ 23:53, 28 January 2018 (UTC)
The uploader added a paraphrase to the bottom of the original text, shortly before you posted this. The top part is, as far as I can tell, the original. https://archive.org/details/columbianmagazin17861787phil is the source; it's page 159. I hesitate to upload it, because it's not a perfect scan (some words are lost in the margins), and just making a page list for it would be a lot of work.--Prosfilaes (talk) 00:01, 29 January 2018 (UTC)
I actually had no contributions to en-wikisource since my work on Index:Ambulance 464 by Julien Bryan.djvu in 2013. All my other edits were done on Commons and than imported by others to this project. To my knowledge I never had any advanced rights on Wikisource, but if I can help somehow I can try. --Jarekt (talk) 00:16, 29 January 2018 (UTC)

Tech News: 2018-05

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

  • There is no new MediaWiki version this week.

Meetings

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

Future changes

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

17:06, 29 January 2018 (UTC)

Sound file to Commons question

I have saved a sound file (ogg and mp3) derived from Lily Pond sheet music created with @Beeswaxcandle:'s help at my sandbox. The sheet music is based on public domain material, but the sound file incorporates corrections and tweaks to the original for output. Can I upload the sound file to Commons, and if so, what license should I apply? and should I upload an ogg or mp3 version? Thanks for any help/insight, Londonjackbooks (talk) 15:34, 29 January 2018 (UTC)

I would presume that the license is however you or @Beeswaxcandle: want to license it as, due to modifications of public-domain works being able to be copyrighted by the modifier (https://fairuse.stanford.edu/overview/public-domain/trouble-spots/#public_domain_works_that_are_modified). The original source does not legally have to be given, however it is in good faith to do so. -Einstein95 (talk) 20:17, 29 January 2018 (UTC)
@Londonjackbooks: Yes to upload to Commons, and you are moving into c:Commons:Derivative works territory, so step through that. Some thoughts to explore, not answers ... I would look to the licensing of the spoken articles from WP that have been uploaded to Commons, and maybe mimic what they have done. My gut feel is that we would do something like wrap the original license in a shell license like we can do with scans ... {{PD-scan|PD-old}}, so poke {{PD-scan}} or {{PD-art}}and look in shared cats if the derivative works page doesn't give suitable guidance. Other things that we could consider are what other computer-generated works are at Commons and their licensing. — billinghurst sDrewth 22:23, 29 January 2018 (UTC)
Thanks both... I briefly searched for other Lily Pond-generated works uploaded to Commons, but not in depth... This will likely take me some time, and I will wait to hear as well from BWC for their input as collaborator. Londonjackbooks (talk) 22:30, 29 January 2018 (UTC)
I've used {{self|cc-by-sa-3.0}} for the few .ogg files that I've derived and uploaded to Commons. e.g. File:Cox and Box Overture audio.ogg and File:The Fair (Gurlitt).ogg. Beeswaxcandle (talk) 06:01, 30 January 2018 (UTC)
@Beeswaxcandle: While the notes will be "off" in the following output, I use it as an example to illustrate how I tweaked bar 32 using scale durations for the sound file. My formatting might be technically incorrect, but it plays well. Is that acceptable? or do you think we should use this version (which is a copy of the original with corrections for sound) without my scale duration tweaking of bar 32? Londonjackbooks (talk) 12:06, 30 January 2018 (UTC)
 
P.S. I have created an Index page for Nocturnes Op. 9 (Kistner version) here. Londonjackbooks (talk) 12:14, 30 January 2018 (UTC)
Sound files at Commons (both versions) below. Please tweak information as necessary. Hope I have done so correctly. Bar 32 differences featured at 2:55 for comparison. Londonjackbooks (talk) 14:09, 30 January 2018 (UTC)
Nocturne (3 min 23 sec, help | file info or download)
Nocturne (3 min 23 sec, help | file info or download)
The tempo for the cadenza is marked as senza tempo—which is Italian for "without tempo". This means that the figure should not be played in strict time—which is what the auto-generation does. This means that tweaking the tempi of bar 32 for the sound file is more than acceptable and should be done to provide a realistic performance of the work. Beeswaxcandle (talk) 05:54, 31 January 2018 (UTC)

IMO (and an O is all it is), you might consider using the CC-0 "license" (or, more technically, "dedication") for your creative additions. What others have said above is true, you can legally attach any copyright license you like to your derivatives of a PD source; but CC-0, which attaches no requirements whatsoever, is the most friendly to reuse and modification.

And...looks like a cool project, I'm looking forward to listening to the files! You can't upload MP3 to Commons, but OGG should be just fine. -Pete (talk) 00:15, 31 January 2018 (UTC)

@Londonjackbooks: If the files are already here, try using Move to Commons but make sure there is a compatible license in the summary. This tool has the advantage of doing much of the work for you but you’ll need to tidy up the description page on Commons afterwards. Ping me if you need help with any of it. Green Giant (talk) 11:50, 31 January 2018 (UTC)
@Green Giant: I uploaded the files directly to Commons (see Commons links above). Feel free to check the descriptions for errors! Thanks, Londonjackbooks (talk) 12:04, 31 January 2018 (UTC)
@Londonjackbooks: Ack! My bad. I missed that. I’ve tidied up the file pages, particularly to make the authorship clearer, and removed self from the license (it says "I", but doesn’t have the capacity to say "We" yet). Green Giant (talk) 12:26, 31 January 2018 (UTC)

Wikisource's birthday

According to Wikipedia, Wikisource was born on November 24, 2003. Would this be it's official birthday? It would then be turning 15 come November. Perhaps we could find a text begun that year to feature as FT for this November—ideally one that has been improved over the years. Is there a good way of generating a list of works created during 2003? Londonjackbooks (talk) 13:14, 15 January 2018 (UTC)

Special:AncientPages might work, but for some reason the earliest pages shown are from April 1, 2006, plus they all seem to be articles from reference works. —C. F. 17:43, 15 January 2018 (UTC)
But oldwikisource:Special:AncientPages shows works from 19 October 2004. —C. F. 17:44, 15 January 2018 (UTC)
See s:mul:User:Angela. —Justin (koavf)❤T☮C☺M☯ 18:30, 15 January 2018 (UTC)
Thank you both. Have made note of your links. Londonjackbooks (talk) 19:34, 15 January 2018 (UTC)
Came across Dovi's mention of an enWS anniversary as being 11 September 2005? Londonjackbooks (talk) 19:37, 15 January 2018 (UTC)
Looks like these redlinks are some of the earliest listed works at the old WS—to include Kipling's "If—" Londonjackbooks (talk) 20:03, 15 January 2018 (UTC)
We did the 10th Anniversary proofreading competition in November 2013 (WS:10) based on the 2003 date. Beeswaxcandle (talk) 06:27, 16 January 2018 (UTC)
a personal reflection here [45] and article w:Wikisource#Early_history -- Slowking4 ‽ SvG's revenge

Rudyard Kipling's "If—" has come a long way since it was first added to Wikisource in November 2003 (one of the first WS adds). I have just linked the page to its 1910 source in Rewards and Fairies—which has yet to be proofread. I would like to eventually nominate the poem (not the whole work)—which could use validating—for Featured Text for November as it will mark the 15th anniversary (as I understand it to be, as per above) of Wikisource. Does only the poem itself need to be fully validated in order to be nominated (I will try to have the whole work proofread by then, but if not, I was just wondering...)? The WP excerpt in the notes section—should it stay or go? I figure if the poem makes Featured status, most of that info will go into the blurb anyway. Am I missing anything? Thoughts? Thanks, Londonjackbooks (talk) 03:04, 7 February 2018 (UTC)

Moved struck content to Wikisource talk:Featured text candidates Londonjackbooks (talk) 23:59, 11 February 2018 (UTC)

Shakespeare's Works

Does anyone know of a 'good' (i.e., 'authoritative') complete set of Shakespeare's works at IA that are not riddled with notes/footnotes? Londonjackbooks (talk) 16:45, 28 January 2018 (UTC)

This one looks good on a quick perusal. —Beleg Tâl (talk) 17:19, 28 January 2018 (UTC)
I see that we already have Index:Shakespeare - First Folio Faithfully Reproduced, Methuen, 1910.djvu. I'll take a look at it as well. Londonjackbooks (talk) 17:28, 28 January 2018 (UTC)
The First Folio has been done a lot. It's got a limited audience that's probably transcriptions with copies of the First Folio. Shakespeare has several, sometimes very distinct, early editions, and much academic interest producing new consensus editions, so it's hard for us to produce a truly useful text, and I hardly see how producing an unannotated version helps that one bit. Some discussion at Distributed Proofreaders indicated that the Yale Shakespeare might be the most authoritative PD Shakespeare. It's a huge task, and ease of finding scans should not be a big part of it. We can download from HathiTrust, or even possibly scan some stuff ourselves.--Prosfilaes (talk) 23:55, 28 January 2018 (UTC)
@Prosfilaes: OK. My motivation is that I would like to read the works myself, and I might as well do that as I edit to benefit not only myself, but to improve what we have here at Wikisource (and getting the works backed by scans)—which is why I am seeking opinions on versions. I know little to nothing about his works, but if I can be pointed in the right direction, I'll do the work! Londonjackbooks (talk) 00:02, 29 January 2018 (UTC)
P.S. How about the "New Variorum" volumes by Shakespearian scholar Horace Howard Furness?
That sounds great. Do you want me to load it for you, or have you got that?--Prosfilaes (talk) 22:06, 14 February 2018 (UTC)
@Prosfilaes: If you think it is a good, useful set, I can do it... I have a a few works on my plate at the moment, and a possible upcoming move that may affect what I can proofread in the future, so once I figure all that out, I'll give it a go. Lots of notes in those volumes, which I wanted to avoid, but whatever is most valuable/useful to have here. Thanks :) Londonjackbooks (talk) 22:12, 14 February 2018 (UTC)

Scan-backed

The term "scan-backed" is a piece of jargon, apparently specific to Wikisource, whose meaning is not clear to many visitors. The page Wikisource:Scan-backed does not yet exit. Please will someone create it, or redirect it if a suitable target exists elsewhere? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:56, 3 January 2018 (UTC)

I never realized until recently that WS had a Glossary of terms (which could use some updating—to include "scan", "Index", "scan-backed" etc.—and perhaps should be linked to from the Help:Contents page; it is almost an orphan). Having a work scan-backed helps insure reliability of content, which is important, and helps keep WS relevant. Whether all terms "specific to Wikisource" rate a MS page, I do not know, but updating the Glossary and increasing its findability might be a start. Londonjackbooks (talk) 16:43, 3 January 2018 (UTC)
I added a link to the Glossary at Help:Contents; feel free to move the link where appropriate. If no one else gets to adding "scan" or "scan-backed" &c. to the glossary list, I will attempt it later. Londonjackbooks (talk) 17:08, 3 January 2018 (UTC)
Huh, never heard of that page until now. In the meantime, the relevant page is Help:Page scans. —Beleg Tâl (talk) 17:24, 3 January 2018 (UTC)
The pages mentioned, are a click away in the welcome message on your talk page. Follow the "proofreading" link, and the "help" link both get you to good pointers. That someone used scan-backed was their usage on the day, it definitely is a piece of jargon, though I wouldn't have said that it is overly common. That all said, it is probably worthwhile our again reviewing Template:Welcome to see whether it is the assistance that we want it to be, and it has been a while. —unsigned comment by Billinghurst (talk) .
and the desire to move from text only transcription to side by side scan backed, is an ongoing quality improvement. not a deletion rationale. Slowking4 ‽ SvG's revenge 16:39, 4 January 2018 (UTC)
That is correct. —Beleg Tâl (talk) 20:20, 4 January 2018 (UTC)
Help:Page scans does not include the string "scan-backed" (nor "scan backed"). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:42, 12 January 2018 (UTC)
Are you wishing to make it a part of the WS lexicon? I am not understanding what it is you are seeking. Personally, I like the term and have used it myself. I can think of no better way to describe 'the thing'. I would have no objections to your adding it to the Glossary... Londonjackbooks (talk) 22:07, 12 January 2018 (UTC)
@Londonjackbooks: You wrote earlier: "If no one else gets to adding "scan" or "scan-backed" &c. to the glossary list, I will attempt it later". that would be a good outcome. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:27, 18 February 2018 (UTC)
@Pigsonthewing: Yes, as you can see, I prepped for it last month and it is still on my mental to-do list. "Later" was purposely ambiguous, as I voluntarily edit based primarily on my own motivation and prompting. Thanks for the reminder though! Londonjackbooks (talk) 20:03, 18 February 2018 (UTC)
Alright, gave it a go. Londonjackbooks (talk) 20:53, 18 February 2018 (UTC)

Change wording for guidance on line break removal

As per discussion at Wikisource:Scriptorium#Guidelines for removal of line breaks

I propose wording for guidance on line break removal at Help:Beginner's guide to typography be changed to one of the following options:

Remove line breaks.
Printed books break lines of text to fit lines to a page. Scanned texts often render line breaks at the end of each line according to how they appear in the original text. Such breaks are considered artefacts of the printing process. When transcribing a text from its source into a Wikisource page, it is best practice to remove these line breaks. Although web browsers will naturally wrap text for the individual reader, there are cases where leaving in line breaks proves problematic. It is recommended that line breaks be removed during the proofread stage of editing to lessen distraction during the validation stage. There are tools available for this purpose if manual removal proves tedious:
Removal of line breaks.
Printed books break lines of text to fit lines to a page. Scanned texts often render line breaks at the end of each line according to how they appear in the original text. Such breaks are considered artefacts of the printing process. Although web browsers will naturally wrap text for the individual reader, there are cases where leaving in line breaks proves problematic. Therefore, when transcribing a text from its source into a Wikisource page, it is recommended that these line breaks be removed during the proofread stage of editing. Doing so at this stage lessens distraction during the validation stage. There are tools available for this purpose if manual removal proves tedious:

Option 1 considers removal "best practice" and is more stringent in wording; option 2 is less stringent, yet recommends removal. Suggestions welcomed. [updated] Londonjackbooks (talk) 11:54, 25 January 2018 (UTC)

If neither option is desirable, then please state that as well and we can go back to the drawing board. But it is my belief that the current wording needs to be less confusing and contradictory than it is. Londonjackbooks (talk) 01:06, 12 February 2018 (UTC)

@Londonjackbooks: I think option 1 sounds good. Also, the heading is a guideline in its own right, so if someone doesn't read anything more than the ToC they'll get some idea of the recommended practice. Sam Wilson 03:01, 12 February 2018 (UTC)
I had hoped for more input. I don't believe the wording should remain as is for the reasons listed in the previous discussion linked to above (if not yet archived). If there are no objections in the next day or so, I will change the wording to option 1 and take any lumps from there. Thanks! Londonjackbooks (talk) 00:11, 18 March 2018 (UTC)
I wouldn't mention the tools or link to them in the Beginniner's Guide. That's a more advanced technique. --EncycloPetey (talk) 00:16, 18 March 2018 (UTC)
Why not at least leave mention of the availability of tools? Londonjackbooks (talk) 00:18, 18 March 2018 (UTC)
My reasoning for including mention as well as links: While it may be more advanced, it gives a further option. Some (like myself) may not have even known to ask about the availability, and it would spare the question being brought up at Scriptorium or elsewhere in the future for those who would think to ask. The answer would already be supplied. Londonjackbooks (talk) 00:29, 18 March 2018 (UTC)
The intention of the Beginner's Guide was to provide a straightforward explanation for complete beginners. Complete beginner's need not have the distraction of all the bells and whistles. Any gadget or script the deals with line breaks will assume the user understands how to deal with certain forms of end-of-line punctuation, Victorian hyphenation rules, and other advanced points of editing. --EncycloPetey (talk) 00:31, 18 March 2018 (UTC)
Me belaboring: I always assume even the "complete beginner" comes with more technical know-how than I do. Do you think it would distract so as to possibly discourage a potential editor? If not, it may even serve to inspire—? We may get questions about it, or it will simply be information that is ignored (which would have been my approach had I come across it way back when). If I've still not convinced you, I can leave it out, but it would be good to include it somewhere. Londonjackbooks (talk) 00:49, 18 March 2018 (UTC)
By all means include it on some more advanced Help page or guide. My point is that such tools are more advanced than desirable for a "Beginner's Guide". --EncycloPetey (talk) 00:56, 18 March 2018 (UTC)
OK. Thanks, Londonjackbooks (talk) 00:59, 18 March 2018 (UTC)
  Done Londonjackbooks (talk) 22:46, 23 March 2018 (UTC)
Retrieved from "https://en.wikisource.org/w/index.php?title=Wikisource:Scriptorium/Archives/2018-01&oldid=7427453"