Wikisource:Scriptorium

From Wikisource
Jump to navigation Jump to search
Scriptorium
The Scriptorium is Wikisource's community discussion page. Feel free to ask questions or leave comments. You may join any current discussion or start a new one; please see Wikisource:Scriptorium/Help. Project members can often be found in the #wikisource IRC channel webclient. For discussion related to the entire project (not just the English chapter), please discuss at the multilingual Wikisource. There are currently 306 active users here.

Contents

Announcements[edit]

Added gadget to sort Special: pages output[edit]

Within the development section of Preferences I have added a gadget that allows for the manipulation of the output of Special: pages. The script is written by User:PerfektesChaos and you can read more about its use and customisation. When activated if in monobook skin you get tabs at the top, if using vector skin then you have options under "More". Thanks to PerfektesChaos for pointing me to the gadget, and his development of the gadget. There for a trial, and if we have sufficient users we will retain it. Noting that users can have it through their common/global scripts if they prefer. — billinghurst sDrewth 11:58, 20 May 2018 (UTC)

The Popular Science Monthly Project[edit]

The Popular Science Monthly Project project is completed and for what it's worth, my thanks to the 410 editors. This is the link to the List of contributors who helped worked on the project. — Ineuw talk 03:40, 28 May 2018 (UTC)

PSM project home page

Some statistics:

  • Page namespace pages: 74,131
  • Images 11,482
  • Main namespace pages: 8,955

Proposals[edit]

Bot approval requests[edit]

Repairs (and moves)[edit]

Designated for requests related to the repair of works (and scans of works) presented on Wikisource

Strip google notices[edit]

Could someone remove the google notices for the following works?;

Thank you GhostOrchid35 (talk) 09:20, 23 March 2018 (UTC)

I'm curious, when removing the notice page (especially in a case like this, where transcription has already been started), is it preferable to replace the notice page with a blank page, so that pagination doesn't get messed up? -Pete (talk) 21:06, 23 March 2018 (UTC)
It's certainly easier; if you remove the page completely then you need to move all the existing pages and ensure the redirects get deleted. Because of this, I would replace with a blank page. —Beleg Tâl (talk) 21:59, 23 March 2018 (UTC)
The Google page often shifts the pagination. In practical terms, it usually works either way, but having a blank page ahead of the front cover is weird, and having even and odd pages flopped in the DjVu can makes for some unfortunate consequences when trying to read that file like a book. --EncycloPetey (talk) 22:41, 1 April 2018 (UTC)
As we have existing files, and we only wanted to build the one tool, it was determined to simply replace the problematic page with a blank page; that means no other manipulation. We don't start with a clean slate. <shrug> @Mpaa: where are we with having wikisource-bot or another bot doing those replacements? — billinghurst sDrewth 06:38, 19 April 2018 (UTC)
Hi. Far away unfortunately. RL took over for a while. Hope to have some time soon.— Mpaa (talk) 09:35, 5 May 2018 (UTC)
I have a script that can be used, still experimental. If someone wishes to use it, you have to tag the File page at Commons with {{blank djvu cover}}. I'll keep an eye on it.— Mpaa (talk) 16:56, 28 May 2018 (UTC)
@GhostOrchid35: Yes check.svg DoneHrishikes (talk) 02:19, 23 May 2018 (UTC)

Comic History of England[edit]

Can someone move Comic History of England (and subpages) to Bill Nye's Comic History of England (as per the titlepage) as there's also a book with the same title by Gilbert Abbott à Beckett. -Einstein95 (talk) 20:17, 13 May 2018 (UTC)

@Beeswaxcandle: Your work, care to manage? — billinghurst sDrewth 23:03, 13 May 2018 (UTC)
Yes check.svg Done and dab created. Beeswaxcandle (talk) 07:25, 16 May 2018 (UTC)

Page missing in France and the Levant peace conference 1920.djvu[edit]

Page 26 is missing in the djvu file Index:France and the Levant peace conference 1920.djvu. This page can be found in hathitrust.org. Is it possible to add is in the Wikisource djvu file? Bradype (talk) 09:35, 24 May 2018 (UTC)

Done.— Mpaa (talk) 20:16, 24 May 2018 (UTC)

Statutes at large Missing pages[edit]

Index:Ruffhead - The Statutes at Large - vol 6.djvu Index:Ruffhead - The Statutes at Large - vol 8.djvu

Both of these volume seem to be missing a blank page and the first the page of the 'List of Titles', would it be possible for 2 blank pages to be inserted after the nominal title page, and any contributions on these volumes to be shifted accordingly? Thanks.

I have no idea where replacement scans might be found, Neither Google or Hathi Trust have an exact match for the specfic edition (although Hathi Trust has some volumes of a much later edition by Charles Runnington, that may enable a 'reconstructed' page to be made if someone want to do a lot of image work :( ) ShakespeareFan00 (talk) 15:41, 31 May 2018 (UTC)

Other discussions[edit]

Page images errors - FIXED![edit]

Looks like the latest update is causing more problems loading page images in the edit window. A hard purge seems to fix the problem, but it must be done every time on every page. --EncycloPetey (talk) 19:56, 2 April 2018 (UTC)

yeah - wow, hard to do initial proofread at this rate, at least the coloured buttons are pretty… Slowking4SvG's revenge 01:16, 3 April 2018 (UTC)
Lovely buttons indeed! But the absence of the image is not so lovely. Quite often the image is shown as a small stripe in the upper left corner of the image-window. I found that clicking on the page number in the Index often brings the image back. Sometimes two times clicking is necessary. --Dick Bos (talk) 11:02, 3 April 2018 (UTC)

Here’s a temporary fix one can add to their individual css page:

.prp-page-image { overflow: visible !important; }
.prp-page-image > img { min-width: 80% !important; height: auto !important; width: auto !important; }

It’s ugly but it works for the moment. χchi (talk) 11:23, 3 April 2018 (UTC)

i can always go to tasks that do not require an image, but it does strike at the purpose of this site. is it related to the old problem with index page not showing colour status of pages? that needed a purge to refresh "null edit" as well. Slowking4SvG's revenge 14:07, 3 April 2018 (UTC)
@User:Χ, Thanks, but the fix does not really work. It shows the image far too large. --Dick Bos (talk) 14:42, 3 April 2018 (UTC)
Yes I’m aware. You can play around with the min-width of the image to fit your screen, but in the end it’s not really meant to fix the actual bug, just a quick and dirty workaround to be able to see the image. χchi (talk) 14:45, 3 April 2018 (UTC)
  • Pictogram voting comment.svg Comment quick look shows that it is setting an image height of 15px, and looks to be poking into the toolbar. If you view the image and return, then it resets the page fine. So guessing that it is a page rendering order issue, and nothing to do with the image itself. [That is all I currently have time to do. ]— billinghurst sDrewth 23:50, 3 April 2018 (UTC)
    It is definitely a rendering issue, as if I go back and then forward (rock and roll) from the page, as the image is available it renders to size just fine when I revisit. Purging will not necessarily fix the issue as it will try to do everything from scratch, and that then faces same rendering timing issues. Seems that it is a javascript issue where we need to get the script to better dynamically deliver the page, and not get caught in the toolbar image rendering. — billinghurst sDrewth 05:06, 4 April 2018 (UTC)

We're about a week later now, and this nasty problem still exists. Is anyone looking after it? That would be great. It's far beyond my technical knowledge to do anything, so please.... Greetings, --Dick Bos (talk) 10:35, 10 April 2018 (UTC)

This seems to be fixed by the latest update, I may have needed to undo the temp fix in order to see that it was working Flannel (talk)

The (changed) title of this paragraph suggests that the problem is fixed. It is not! We are one and a half month further in time, and the problem, caused by some update of the software or so, is still there, and still causes extra work (I have to move from the page that does not show an image; and the next time the image is there), and most of all: it makes te working of Wikisource absolutely unclear for new users. --Dick Bos (talk) 12:17, 20 May 2018 (UTC)

@Dick Bos: It has been noted on the Phab ticket by several WS communities that it is still unresolved. The fix failed, or it was due to another component. The simple adjustment is to flick back and forward on the browser page (do not push a reload). The first time in the time taken to get the right thumbnail and the page loads before the image is ready. When flick back and forth, the image is already generated and available and loads fine. A question for you, which skin and which toolbar are you using? — billinghurst sDrewth 13:02, 20 May 2018 (UTC)
@Billinghurst: Thanks for your answer. Let's hope that it can be fixed. About the skin and the toolbar: I don't know. Where can I see that? --Dick Bos (talk) 16:34, 20 May 2018 (UTC)
@Dick Bos: Both in your preferences, for your skin Appearance and for your toolbar Editing. I am guessing that you will have Vector, and the Advanced Enhanced toolbar checked on the respective tabs. — billinghurst sDrewth 21:27, 20 May 2018 (UTC)

The issue is certainly not fixed for me. I'm using the Vector skin and the advanced toolbar. --EncycloPetey (talk) 23:09, 20 May 2018 (UTC)

@Billinghurst: I don't see a checkbox for "advanced toolbar" under the "editing tab." I'm using Vector, and this problem has persisted for me for some time, across several browsers. Mostly (and maybe entirely) under the most recent Ubuntu Mate (upgraded from 17.10 to 18.04 a couple weeks ago, with no impact on this issue.) I thought I had the problem under Windows as well, but I can't be sure without testing (happy to do so if it's helpful).
I tried the CSS fix above, but it just introduced a new problem -- now the preview is too big and the white margins crash into the text in the editing window. (Can provide screenshots if helpful.) -Pete (talk) 23:31, 20 May 2018 (UTC) (p.s. I notice from the discussion above that the CSS foibles are already known, and something I can work around with some tweaking.) -Pete (talk) 23:33, 20 May 2018 (UTC)
All fixes and commentary should be added to the phabricator ticket. Noise there is far more productive than noise here.
Smacking my forehead...I looked and looked, and somehow missed "enhanced." However, perhaps useful info...I did not have it enable. (And yes, I'll add info to the phab ticket -- good point.) -Pete (talk) 04:35, 21 May 2018 (UTC)

@Billinghurst: - your guess was correct. I have a vector skin and I have the enhanced editing toolbar enabled. @Peteforsyth: - I made a remark in the phabricator thing (for me, after about fifteen years, a complete new corner of the Wikimedia-world! Never to old to learn new things). Let's hope it will bring us a solution. --Dick Bos (talk) 09:57, 21 May 2018 (UTC)

Happily it looks like the problem is fixed now! Thanks a lot. --Dick Bos (talk) 14:10, 31 May 2018 (UTC)

Tech News: 2018-19[edit]

16:27, 7 May 2018 (UTC)

Comment[edit]

High priority
    Table tag that should be deleted (7 errors)
    Misnested tag with different rendering in HTML5 and HTML4 (16,270 errors)
    Miscellaneous Tidy replacement issues (0 errors)
    Multiline table in list (37 errors)
    Multiple unclosed formatting tags (4 errors)
    Paragraph wrapping bug workaround (1 error)
    Self-closed tags (2 errors)
    Tidy bug affecting font tags wrapping links (2,221 errors)
    Tidy whitespace bug (1 error)
    Unclosed quote in heading (0 errors)
Medium priority
    Bogus file options (10 errors)
    Fostered content (4,033 errors)
    Misnested tags (196,818 errors)
    Multi colon escape (0 errors)
Low priority
    Missing end tag (229,180 errors)
    Obsolete HTML tags (193,926 errors)
    Stripped tags (102,542 errors)

Looking at the big one, Misnested tag with different rendering in HTML5 and HTML4, there may be some subtle error in {{header}} causing some of them. Ante-Nicene Fathers has a bunch of them; the one I looked at had unclosed spans due apparently to careless imports by Polbot. I'm almost tempted to argue for blowing away the whole collection, as it's webscraped, apparently somewhat carelessly, and lacks scans. The pages I looked at all had the same history; Polbot creating it in 2008, SDrewthbot making some changes in 2009, and Spangineer's bot changing header2 to header in 2012. In any case, that chunk should not be handled manually.--Prosfilaes (talk) 07:19, 8 May 2018 (UTC)
@Prosfilaes: This is why I've been gradually uploading the first (British) edition (called Ante-Nicene Christian Library), rather than the later A-NF plagiarised edition. At some time we will want the later edition in a good state, but the poor quality imports make the current version only of use for linking until we've got all 24 volumes of the first edition up. I'm half-way through the fifth volume. Beeswaxcandle (talk) 06:49, 9 May 2018 (UTC)
@Beeswaxcandle: I don't understand what you mean by "only of use for linking" - ? I noticed that "span class=c1", which appears at least on title pages, doesn't seem to do what it's supposed to. From looking at the original, I think it's supposed to center the text, but the class probably isn't defined here. A verstige of web scraping? See: Ante-Nicene Fathers/Volume VI/Title Pages -Pete (talk) 14:15, 9 May 2018 (UTC)
@Peteforsyth: By "linking" I'm referring to wikilinks from other texts we hold. Until I bring in the other ANCL volumes the ANF is the only copy we hold of Irenaeus, Hippolytus, Origen and Tertullian. Beeswaxcandle (talk) 07:17, 10 May 2018 (UTC)

(Moved from Template talk:Header)

According to Wikisource:Scriptorium#Tech_News:_2018-19, it's important that we fix high priority lint errors. Looking at Special:LintErrors/html5-misnesting, there are 17,000 of this one high priority lint error, and at least some of them come down to this template. (The example I looked at was not clearly misusing the template.) There's a misnesting of HTML tags involving a span tag that might break stuff when going to HTML 5. I started to try and debug it, but there's a lot of scary code here.--Prosfilaes (talk) 07:04, 8 May 2018 (UTC)

So if I'm reading this right, linter errors seem to be errors in wikitext that could cause rendering problems. @Prosfilaes: what do you think needs to happen? Is there an easy way for less technical folks to pitch in? -Pete (talk) 07:12, 8 May 2018 (UTC)
And what are the consequences if we don't take care of this? trying to wrap my head around the level of urgency and scope of the problem. -Pete (talk) 07:14, 8 May 2018 (UTC)
The consequences, according to the post above, is that they're going to change us from Tidy to a different parsing library by the end of July (which is way too little warning if they think it's actually going to break things, IMO), and every one of those errors represents something that could break. I'm guessing a lot of them won't, but most all of them are still theoretical problems.--Prosfilaes (talk) 07:26, 8 May 2018 (UTC)
They should be fixed. It depends on how less technical you are; if you have some understanding of HTML, it should be possible in some cases to find where tags are improperly nested; this edit, for example, was pretty obvious knowing that a sup tag wasn't properly nested.--Prosfilaes (talk) 07:35, 8 May 2018 (UTC)
I think one of the errors with {{header}} is the use of a span element for the section parameter. In cases where there's a newline in the section, the latter part(s) of the section are given a <p> wrapper. For example, this:
 | section    = Book 1—Classical fables
 Part 2—Babrius
results in this:
<span id="header_section_text">Book 1—Classical fables</span><p><span id="header_section_text">Part 2—Babrius</span></p>
The fix seems to be to either remove the linebreak, or turn the span into a div and make it display:inline (because we follow it with an italicised contributor statement in inline elements). Like this.

Of course, similar issues may exist for other fields of {{header}}, but this is the one that I've seen a few of.

Sam Wilson 09:42, 8 May 2018 (UTC)
I've added a test to Template:Header/testcases#Newlines_in_sections. The above fix might be the wrong way to go: perhaps we want to permit section to contain paragraphs? If we do, the text that follows (from override_contributor and contributor) should be fixed up instead. Sam Wilson 09:53, 8 May 2018 (UTC)
Specific case example is [https://en.wikisource.org/w/index.php?title=An_Illustrated_Flora_of_the_Northern_United_States,_Canada_and_the_British_Possessions/Commelinaceae&action=parsermigration-edit&lintid=513184 here. Problems that I see. 1) Too much information being added at every page in the work, that resides at the root page; 2) Incorrect use of fields, not certain why we have author information in the section space; 3) abundant use of <br/> through the section.

Suggested solutions: 1) trim repeating information, and add at top if missing; 2) use author, override_author, and contributor, ... properly; 3) Remove line breaks and make cascading sections flat; noting that this also fits in with our long-held position of keeping our headers smaller and not intruding on the body content.

At this stage I do not wish to modify header to make it a <div> component. — billinghurst sDrewth 22:42, 8 May 2018 (UTC)

I don't see any way around making at least the "notes=" parameter a div. There is too much varied information that has to be placed into that parameter to do it any other way. The single parameter must potentially handle notes about the work, notes about the edition, and notes about format, audio, etc. Tossing all of that together into a single paragraph does the reader no service. --EncycloPetey (talk) 22:58, 8 May 2018 (UTC).

Pictogram voting comment.svg Comment We have numbers of issues, and I think that we need to work through them as sets, and look at model solutions. The major problem has been that it simply hasn't mattered as the system has had the robustness to cover for poor coding, and that is about to change as things become more code compliant. Some reflect the development of our templates; some are the ignorance of users between span and div (and I have so been there), and that we don't help that with clear documentation of with our templates; some is poor patrolling with unwillingness or lack of confidence to intervene, again unsupported by the community.

We have numbers of things to change, and it is going to take an all of community approach to fix the basics, and to fix the code that exists, and that we still continue to add to poor coding today. — billinghurst sDrewth 22:42, 8 May 2018 (UTC)

I agree, there's masses of stuff to fix. Lots of the errors are located in the template usage, and we can easily (well, time-consumingly) go around and fix those. But I think we should decide whether section should be inline or block-level (maybe it should stay inline, that certainly makes sense in lots of ways as it's just meant to be a name, and then we'd just need to go around and fix the incorrect usages of it). @EncycloPetey: notes is already a div; are you seeing linting errors with it? Sam Wilson 00:17, 9 May 2018 (UTC)

Interjecting with a specific question...I clicked on this one, and I see a number of <br> tags, which I think should be <br />. Is that the problem, or is it something else? Do we need to add the trailing "/" into all break tags? If so, isn't that something a bot could do pretty easily? -Pete (talk) 00:24, 9 May 2018 (UTC)

And here's another one, that appears just fine -- safe to conclude that the problem is in the template itself? [6] -Pete (talk) 00:42, 9 May 2018 (UTC)
@Peteforsyth: No, those are different causes: the first is not due to the brs but rather to the newlines in the section parameter (i.e. after the brs). So that section name could be run together into one line (still with the brs) and it'd fix the nesting (might not be the best way to do it though). The second problem I've fixed I think with this change. Sam Wilson 00:51, 9 May 2018 (UTC)
Thanks -- and sorry, I realized they were separate cases, was just grouping my questions together. These both help, and probably give me enough info to jump in and start fixing some stuff. Thanks! -Pete (talk) 01:20, 9 May 2018 (UTC)
@Samwilson: For the "br" and line return in section, if we concatenate to a line, we resolve the linter error, and can look at the general use at a point in time (suggest that as our solution). Though it is can be difficult to know that it is the solution without opening and drilling down. [Namespace solutions would be helpful here, though not available with the current special tools.] As we know some of the main namespace works, might be able to prefixindex through those, though the "Nicene" works are bleeding ugly.

We do not need to fuss the less than perfect BR semantics of the closing forward slash, browsers manage that resolution without mediawiki fussing it.

With regard to the time-consuming stuff, bot fixing things at this time is crap as 1) it doesn't seem you cannot easily pull a simple list of pages to work upon (AND definitely not for AutoWikiBrowser); 2a) our size div and span templates do have a different line-height, and 2b) they work differently where they cross a page, and the irregular use of /s /e template pairs is uncertain without looking at the scan (which is not bot'able). — billinghurst sDrewth 03:12, 9 May 2018 (UTC)

In pywikibot there is support for -linter option for pagegenerators. You can select also subcategories, and combine it with other existing filtering methods.— Mpaa (talk) 18:24, 10 May 2018 (UTC)
Does it work in the Page namespace, where we may have only the start or the end tags? Where such tags cross into the header or footer? Will is recognize problems in the Main namespace for transcluded works, or only Page by Page? --EncycloPetey (talk) 18:44, 10 May 2018 (UTC)
The option allows selection/creation of lists of pages belonging to the different lint-error categories. Pages can be further filtered (e.g. by ns, prefixindex, regex on title etc.). The logic to fix page content needs to be coded aside, as it is usually done with other tasks. replace.py and possibility for regexex fixes is a good tool. I have cleaned quite a lot of pages with it.— Mpaa (talk) 19:21, 10 May 2018 (UTC)
But that doesn't answer my question. Can it, for example, determine whether the opening tags (set by template) on one Page, are closed in the correct reverse sequence on another Page, when the formatting straddles two or more Pages? --EncycloPetey (talk) 19:41, 10 May 2018 (UTC)
@EncycloPetey: Mpaa is only talking about page generators, not the ability to check and resolve. General info for the api is mw:API:Query#Generators and the implementation through pywikibot is mw:Manual:Pywikibot/Page Generators. What your asking is above and beyond the power of the generator, it relates to the content. — billinghurst sDrewth 06:45, 11 May 2018 (UTC)
Fascinating, and kind of depressing to hear that automated solutions won't work so well! I just cleared out all the font-color ones in user space (a few dozen), and it seems that one might be regex and AWB-able...no? I'd be happy to give it a shot if nobody else has, unless there's some deal breaker I'm not thinking of. (I do see that getting an input list into AWB will be a challenge, and maybe just impossible. But I'll ponder it a bit.) -Pete (talk) 03:32, 9 May 2018 (UTC)
I wouldn't fuss anything in user namespace, if its presentation is borked, who cares. The content areas are where we should be fixing things where the guests come to read, so primarily page and main nss. — billinghurst sDrewth 06:38, 11 May 2018 (UTC)

Category for our dear friend Anon?[edit]

What's the difference between Category:Works by unknown authors and Category:Anonymous texts? —Sam Wilson 06:32, 10 May 2018 (UTC)

The former is filled by use of {{anon}} and is subcategory to the second, which is category filled by another means through the header template. So the difference is due to the mechanisms. — billinghurst sDrewth 06:36, 11 May 2018 (UTC)

Tech News: 2018-20[edit]

22:22, 14 May 2018 (UTC)

LIFE magazine[edit]

I've done a check of periodical renewals, and it seems like Time forgot to renew vols. 16 and 17 (1944) in 1972. In 1971 they renewed v. 15, in 1973 they renewed v. 18. These issues can be read in full on Google Books without limitation or any download.

-Einstein95 (talk) 10:31, 15 May 2018 (UTC)

Volume 16 to Volume 18 Number 13 are in public domain as their copyright was not renewed. Copyright was renewed from No. 14 of Vol 18 (1). In IA: Vol 16 No. 17, Vol 16 No. 23. Hrishikes (talk) 12:31, 15 May 2018 (UTC)

Mark proofread gadget[edit]

Hi all. I've an idea to modify the mark-proofread gadget to make it faster: MediaWiki_talk:Gadget-mark-proofread.js#Query_more_than_one_page_at_a_time. (Spamming here because I don't think that page will be on everyone's watchlist.) Sam Wilson 06:00, 16 May 2018 (UTC)

Wow...night-and-day difference on pages I see every day. Great work! -Pete (talk) 16:31, 16 May 2018 (UTC)
Nice! Gets it done in a blink of an eye now. Jpez (talk) 16:45, 16 May 2018 (UTC)

How can we make it easier for Wikimedia contributors to understand Wikidata?[edit]

Noun Project author icon 1642368 cc.svg

Dear all

Over the past year or so I've been working quite a lot on Wikidata documentation and have been thinking more about the needs of different kinds of user. I feel that currently Wikidata can be difficult to understand (what it does, how to contribute, what issues there are and what is being done to address them etc) even for experienced Wikimedia project contributors. To help address this I've started an RFC to try and collate this information together. It would be really helpful if you could share your thoughts, especially if you find Wikidata hard to understand or confusing, you can just share your thoughts on the talk page and we will synthesize them into the main document.

Wikidata:Requests for comment/Improving Wikidata documentation for different types of user

Thanks very much

John Cummings (talk) 12:54, 18 May 2018 (UTC)

Lint fsx[edit]

Hi. There are about 300 pages in Page ns that have issues with {{fsx}}, due to multi-paragraph or and fsx-sized text across pages. Suggestions on alternative templates? Or new ones, if no available?— Mpaa (talk) 19:13, 18 May 2018 (UTC)

{{fsx/s}} {{fsex/e}} seems to be the approach used in other circumstances. ShakespeareFan00 (talk) 19:14, 18 May 2018 (UTC)
{{fsx}} is span-based and so are the existing {{Font-size-x/s}}/{{Font-size-x/s}}. We need an equivalent div-based template, I guess.— Mpaa (talk) 19:22, 18 May 2018 (UTC)
One change to {{Font-size-x/s}} and {{Font-size-x/s}} implemented a temporary fix. I'll update the single use as well.. Please check my coding..ShakespeareFan00 (talk) 20:11, 18 May 2018 (UTC)
The change is to add an element parameter to switch the span for some other element, div works to suppress the lint concerns, P doesn't. However it's still my view this is only a temporary fix until someone can pin down a Mediawiki developer to properly re-do Proofread page so we don't have to play hunt the 'bodge' on things like this. If anything the parser migration has exposed a weakness in that there's no easy way without documentation to tell if a template is span based or block based, having that as something the parser could warn about... (cough cough cough etc. XD)...ShakespeareFan00 (talk) 20:18, 18 May 2018 (UTC)
I leave it to others to comment on the implementation, templates are not my playground. IMHO we should not deviate from the convention inline vs. block templates and the fact that we need to specify a parameter such as element=div is definitely not user-friendly or understandable by newcomers.— Mpaa (talk) 20:32, 18 May 2018 (UTC)
If the font-size percentage is near enough, we could switch to {{fine block}} or {{smaller block}} --EncycloPetey (talk) 19:25, 18 May 2018 (UTC)
I would endorse this suggestion. In standard body text, sticking in percentage templates is just more levels of confusion to proofreaders. There is enough issues with span/div templates so please let us remove complexity wherever we can. — billinghurst sDrewth 00:36, 19 May 2018 (UTC)

LintHint script is incompatible with constructions that are widely used in Page: namespace on English Wikisource.[edit]

I was having problems with w:User:PerfektesChaos/js/lintHint not analysing the 'additional' fields when on the Edit form.

So I left a note for the developer: w:de:Benutzer_Diskussion:PerfektesChaos#LIntHint..._Option_to_check_entire_source_code,_from_EDIT_form...

The basic response seems to be that the relevant templates should be coded to be self contained in the header/body/footer respectively. This has NOT been the way things have been done on English Wikisource for some time with respect to the use case mentioned, and the use of {{{template/s}}{{template/e}} pairs has been recommended as standard usage for formatting that's split over pages.

As the original maintainer of the script seems unwilling to make it more compatible are there any developers or coders here that would be able to do so? ShakespeareFan00 (talk) 17:43, 19 May 2018 (UTC)

Page number corrections in {{dotted TOC line}} template.[edit]

The {{dotted TOC line}}, when used with a djvupage argument, apparently displays page numbers as links (to the djvu page) in the Index and Page namespaces, but not in the Main namespace, which makes sense. However, I'd like to "correct" a misprinted page number with {{SIC}}, so I can't use a plain number as djvupage. I can put it in pagetext, but then it's not linked in Index, and if I write it as a link, it is linked in Main. Is there some way to have the corrected page number behave just the same as the normal ones? I have the impression I have discussed this already some time ago, but I can't find it. An example: Page:Tales from the Arabic, Vol 2.djvu/15, transcluded in Tales from the Arabic/Volume 2 (collapsed), page 193 is wrong. Jellby (talk) 18:08, 19 May 2018 (UTC)

The "djvupage" element is an embedded {{DJVU page link}} which you can play with to achieve the desired effect. —Beleg Tâl (talk) 18:53, 19 May 2018 (UTC)
Thanks. {{DJVU page link}} doesn't help, because it expects a number, and not a {{SIC}} template, but {{DJVU page link 2}} allows arbitrary text and an explicit target for the link (instead of just an offset). As a side question, is there a similar template that allows linking to some other file (for multi-volume works)? ETA: Nevermind, I found {{double link}} which I think is what I actually want. Jellby (talk) 07:21, 20 May 2018 (UTC)

Referencing a specific footnote from another work/volume[edit]

I'd like to add a hyperlink to a specific footnote in Main namespace. I can do it with [title#cite_note-xx], but xx is the footnote/endnote number, which might change (if some section with footnotes is added/removed from the document, for instance). Even if the footnote was given a name with <ref name="foo">, the link still includes the number as "cite_note-foo-xx". Is there some way to have a fixed reference for a footnote, without using {{Anchor}} (which I presume would not result in the same highlighting as when linking to a footnote)? Jellby (talk) 08:17, 20 May 2018 (UTC)

@Jellby: I can never remember this coming up in discussion. Best I can suggest is to look through mw:Extension:Cite to see if there is any mention. Best I can recommend is to list to the "subpage#pagenum" and let them find the ref. Getting out of dynamic numbering out of refs isn't something that I think that I would favour. — billinghurst sDrewth 12:35, 20 May 2018 (UTC)

Sorted through gadgets[edit]

I have just moved out all bar one of the existing gadgets out of development into other sections (certainly out of development). I reckon that someone can come about with a better set of criteria, so feel happy to take suggestions at MediaWiki talk:Gadgets-definition. — billinghurst sDrewth 12:30, 20 May 2018 (UTC)

Tech News: 2018-21[edit]

17:33, 21 May 2018 (UTC)

Puzzled - No page numbers on Lengths and Levels To Bradshaw's Maps/Canals and Railways in the Northern Map ?[edit]

It's using a standard pages tag. Suggestions? ShakespeareFan00 (talk) 07:55, 22 May 2018 (UTC)

Also - Lengths and Levels To Bradshaw's Maps/From Actual Survey (1832) Page number display at side is messed up for some reason. ShakespeareFan00 (talk) 08:05, 22 May 2018 (UTC)

Page numbers never display correctly when a table spans several pages. --EncycloPetey (talk) 17:13, 22 May 2018 (UTC)

Ah... Another long standing issue that remains unresolved. :( ShakespeareFan00 (talk) 18:57, 22 May 2018 (UTC)
Probably entirely unrelated, but I just ran into a chapter that didn't display the page numbers. There was an extraneous <br /> tag in the header; removing it seemed to do the trick. [9] -Pete (talk) 19:10, 24 May 2018 (UTC)
EncycloPetey: Page numbers never display correctly when a table spans several pages. That is not exactly true, or maybe I should say I don't believe that it happens with the works that I produce. I believe that the page number display is hosed when they are coded where there is a table row header at the end of the page. I am pretty certain that I have been trying to reflect this for an extended period of time and sometimes reflecting on the templating used that produces such a result. — billinghurst sDrewth 02:42, 25 May 2018 (UTC)
The problem with the table may be that the width is set to 100%. Maybe trying a different width might fix the problem? Jpez (talk) 06:00, 25 May 2018 (UTC)

FYI Index:Darwin Journal of Researches.djvu[edit]

Courtesy notice here on Index:Darwin Journal of Researches.djvu, because I'm not sure how the system works on the next step. Don't know if bots pick this up. The original editor hasn't been around since 2015. Everything is validated on this file, except 12 remaining images needed. Maile66 (talk) 16:27, 25 May 2018 (UTC)

The system works like this: if a user comes, uploads images at Commons and include them, then the status can step to Validated. Otherwise, unfortunately, it has to stay like this.— Mpaa (talk) 22:44, 25 May 2018 (UTC)
I've inserted the images, if anyone would care to finish the validation. Mudbringer (talk) 06:21, 26 May 2018 (UTC)
Thank you. I finished the validation. Maile66 (talk) 15:16, 26 May 2018 (UTC)

Requesting input on the main namespace titles with Roman numerals[edit]

This project has no chapters, only sections. Unfortunately, the sections are numbered with Roman numerals, which I personally would like to keep as the part of the main namespace title. Just don't know what are the rules for this, if any. — Ineuw talk 23:37, 27 May 2018 (UTC)

There is no hard and fast rule, but the community preference is for "Arabic" numbering (1, 2, 3, ...) over Roman numerals. There are some exceptions here (mostly older Wikisource works), but we tend now to use Arabic numbering. One reason for our preference is that Arabic numbering is more universally accessible, especially to readers from non-Western cultures where Roman numbering is seldom or never used. Consider that even in China and Japan, the numbering 1, 2, 3, 4, 5, ... is usually understood, but I, II, III, IV, V, ... is not. There are other reasons, but I think that's the most reasonable one. --EncycloPetey (talk) 00:19, 28 May 2018 (UTC)
@EncycloPetey: I agree with you that Arabic numerals are far better for continuity. My rational was that since all sections headings are characters (which Roman numerals are), readers would not have to convert to numbers. If I use the Arabic style, then I should add the number alongside the Roman like VI (6). What do you think? In any case, it will be so in my Table of Contents where VI to XII would be complemented by (6 to 12) — Ineuw talk 02:38, 28 May 2018 (UTC)
The application of arabic number applies to the page titles, and the underlying links, and does not disallow the presentation of section parameters, or the visible text in prev/next.

Apart from personal preference, is there a rationale to why the community style guide should not apply? This was well-discussed years ago in this forum and there were numerous reasons why roman numbering is dysfunctional in wikis and modern page presentations. I don't favour it any new works, and I don't think adding both to page titles enhances the work. — billinghurst sDrewth 09:00, 28 May 2018 (UTC)

Hate it when search fails me. Reasons included: understanding of roman numerals vs. arabic, consistency of approach, linking to and future proofing linking, sorting order for pages, ability to increment numbers with scripts, the numbers of mistakes that were being made and needed to be corrected. — billinghurst sDrewth 09:10, 28 May 2018 (UTC)
@Billinghurst: As I said earlier, I have no problem using Arabic numerals in the main namespace article titles. But, the original text title shows Roman numerals, which I can also replace with the Arabic:
Would this be OK, and which of the two styles below are preferred?
1. LXX (Section 70)
2. Section 70 (LXX) — Ineuw talk 17:16, 28 May 2018 (UTC)
The preference for Arabic numerals applies to names of pages, not to the display or contents. See for example Jane Eyre (1st edition), where the displayed numbers for volumes and chapters are in Roman numerals to match the originals, but the pages themselves are numbered using Arabic numerals, per our preferred house style. So Volume II, Chapter IV is linked as Jane Eyre (1st edition)/Volume 2/Chapter 4, even though the original Roman numerals of the text are retained in the Table of Contents and in the page headers. --EncycloPetey (talk) 17:26, 28 May 2018 (UTC)
Thanks for the example. — Ineuw talk 18:02, 28 May 2018 (UTC)
Which is what I said above. Titles = names of pages, please see mw:Manual:Page title, and replies were addressing the subject line. The words used in the presentation layer within the {{header}} has more latitude. — billinghurst sDrewth 07:08, 29 May 2018 (UTC)

Tech News: 2018-22[edit]

12:40, 29 May 2018 (UTC)

Text of the new Swedish "negligent rape" law[edit]

Hello. I've tried to find the final text of the well-known law that was passed about a week ago and will take effect in July in order to translate it into English using translating apps and dictionaries and upload it here, but have been unable to locate it. Dear Swedish speakers, could you please help me find it (firstly, I need the text of the law, not an edition of the bill that can differ from the former, and secondly, AFAIK it hasn't been published here yet, but there may be other official publication resources)? --185.79.103.3 13:10, 29 May 2018 (UTC)

The first step is to find a scan of the Swedish original, and use it to create a scan-backed copy on the Swedish Wikisource, with appropriate licensing. See Wikisource:Translations. In our to reach the Swedish-speaking Wikisource contributors, you should contact the Swedish Wikisource. --EncycloPetey (talk) 16:00, 29 May 2018 (UTC)

Introducing Toolhub[edit]

What does your participation on the Wikimedia projects look like? Do you edit articles? Upload files? Patrol vandalism? Translate articles? Translate interface messages? Do you organize people, online or offline? Do you train new editors, or new trainers? Do you write code?

There are many different ways to contribute to Wikimedia – more than you would expect just from reading Wikipedia articles. Over the past several years, volunteers have developed technical tools that help Wikimedians improve content, patrol vandalism, and perform many other tasks. They make it possible to do what the wiki software alone cannot accomplish. Without these tools, many of our projects would slow down to a crawl.

I am very happy to announce a new project called Toolhub which seeks to create a searchable index of these tools in all languages. We are building this tool catalog based on what our communities need. If you would like to help, please take a look at m:Toolhub and review the question at the top of the page. You can also leave feedback in any language on the talkpage. You can also email me private feedback. Harej (WMF) (talk) 00:21, 3 June 2018 (UTC)

Anchor points in How To Adjust Spirella corsets.[edit]

On page 9 the previous editor has attempted to create links to anchor points to three illustrations within the main text, however they do not appear to work.

Unfortunately I don't understand anchor points so I am unable to correct these.

Would somebody be able to take a look and correct these for me?

Thanks Sp1nd01 (talk) 10:17, 3 June 2018 (UTC)

@Sp1nd01: Clash of anchors. Our page numbers have anchors, and the style used in the figures was the same, so the link was finding the first rendering. I have changed both the links and the targets to be "figure1", "figure2", "figure3", so those are fixed. Can I leave you with the remainder? — billinghurst sDrewth 11:20, 3 June 2018 (UTC)
Yes, now I understand what was wrong I'll continue my work. Thanks for the quick fix! Sp1nd01 (talk) 11:50, 3 June 2018 (UTC)

{{double link}} across pages[edit]

Can I have a {{double link}} that's broken across pages work properly? Adding the template separately to the parts of the link before and after the pagebreak results in only half of the text being underlined when hovering, and the space between the two parts not belonging to any of the links. Jellby (talk) 18:44, 4 June 2018 (UTC)

@Jellby: Can I say that I would simply not use that template, it is approaching ridiculous to do so; that adds complexity for no real value. Please don't try to add page: ns to page: ns wikilinks. They are of next to no value, only create work, and in terms of transclusions just add underlying gumph. — billinghurst sDrewth 22:04, 4 June 2018 (UTC)
I would suggest that the parts that you want to link that you put them into the footer. On the subsequent page just do something like {{hwe|aftertext|[[beforetext aftertext]]}}. It does not create a hyperlink in the Page: ns but who cares, it creates one in the transcluded work. Pure and simple and how I do such works like DNB where we regularly have authors and internal links split. — billinghurst sDrewth 22:04, 4 June 2018 (UTC)
This is what {{lps}} and {{lpe}} are for [Linked Phrase Start and Linked Phrase End], rather than fudging hwe. Beeswaxcandle (talk) 07:05, 5 June 2018 (UTC)
The "start" components, which are a hack from before footer availability, maybe are useful for helping newbies, are otherwise useless. The LPS/LPE pair are just painful, overly complex templates with not the benefit on the other side of the use, and I suspect just deter users through more complication for no special benefit. We could have just done the same thing with noinclude and includeonly tags. — billinghurst sDrewth 10:49, 5 June 2018 (UTC)

Tech News: 2018-23[edit]

21:54, 4 June 2018 (UTC)

Tools for Wikipedians: Keeping track of what’s going on on Wikidata from Wikipedia[edit]

This article by Jens Ohlig may be of interest to some Wikisourcers

It has some pertinence for our editing, and as it is a blog there is the opportunity for direct feedback opportunity if you would like different articles or approaches for sister wikis. — billinghurst sDrewth 00:22, 5 June 2018 (UTC)

Image problems when editing[edit]

Esme Shepherd (talk) 10:14, 5 June 2018 (UTC) I am experiencing image distortions when editing. These correct if I select 'show preview' but are nevertheless annoying. The issues are: 1. Image appears very squashed horizontally thus rendering it unreadable. 2. Image appears extremely enlarged, so that only a little of it can be seen.

This has been going on for some days and doesn't seem likely to go away without intervention. Can you help?

RfC: Plans to graduate the New Filters on Watchlist out of beta[edit]

Collaboration team is announcing plans to graduate the New Filters for Edit Review out of beta on Watchlist by late June or early July. After launch, this suite of improved edit-search tools will be standard on all wikis. Individuals who prefer the existing Watchlist interface will be able to opt out by means of a new preference.

The New Filters introduce an easier yet more powerful user interface to Watchlist as well as a whole list of filters and other tools that make reviewing edits more efficient, including live page updating, user-defined highlighting,the ability to create special-purpose filter sets and save them for re-use and (on wikis with ORES enabled) predictive filters powered by machine learning. If you’re not familiar with the New Filters, please give them a try on Watchlist by activating the New Filters beta feature. In particular, it would be very helpful if you can test the new functionality with your local gadgets and configurations. The documentation pages provide guidance on how to use the many new tools you’ll discover.

Over 70,000 people have activated the New Filters beta, which has been in testing on Watchlist for more than eight months. We feel confident that the features are stable and effective, but if you have thoughts about these tools or the beta graduation, please let us know on the project talk page. In particular, tell us if you know of a special incompatibility or other issue that makes the New Filters problematic on your wiki. We’ll examine the blocker and may delay release on your wiki until the issue can be addressed. - -Kaartic (talk) 17:31, 5 June 2018 (UTC)

Paged layouts that laternate between right and left...[edit]

As many contributors are aware there are plenty of works that have layout which alternates between left and right shifted elements for items like sidenotes, line numbering, or section markers amonst other things...

Whilst there are versions of (some templates that take into account this left/right split and transclude cleanly) I am wondering in the interest of reducing complexity if there was a wider consensus for the sake of simpler markup and approaches if for some works this left/right split was in effect ignored and the relevant work was written as though it has one consistent layout throughout, the scans notwithstanding. This would for example make the transcriptions of some works easier to maintain longer term, and would hopefully reduce the complexity of some templates as a common layout could be assumed on each page. This was the approach I was considering on a fairly extensive work with so termed side-titles given certain interactions between templates. (Specfically interactions between multiple {{MarginNote}} and {{di}} i found in some test cases here User:ShakespeareFan00/Sidenotes testing with some contrived soloutions I'm unhappy with long term.).

It is my view if theres's a guideline to ignore paged layouts in scans, it should ideally be a consensus view, and documented.

ShakespeareFan00 (talk) 00:56, 6 June 2018 (UTC)

Statutes at large, a different approach...[edit]

No lengthy arguments needed but in deprecating a template (that was for technical limitations never ideal.), this was implemented Page:Ruffhead_-_The_Statutes_at_Large_-_vol_3.djvu/100, because it isn't possible to cleanly implement the original layout in web form . I will note that other than {{frame}} it's only using existing templates (or footnotes), not some over-complicated half-baked attempt to get it exactly like the print layout (a critical view from certain other contributors). Whilst the logical intent of the original is followed, given that "annotated" copies are generally disliked, I wanted a second opinon. ShakespeareFan00 (talk) 08:56, 7 June 2018 (UTC)

I think your layout does justice to the demanding, idiosyncratic formatting of the source text even if it doesn’t perfectly duplicate its visual appearance on the page. The marginalia serve their purpose as annotations to the original text whether they appear in sidenotes or at the bottom of the page, and I have a feeling that when multiple pages are transcluded together in the final version, the use of footnotes will make the finished product much easier to read. I find the box produced by the {{frame}} template a little distracting and I’m not sure it’s really unnecessary, although it does call attention to the presence of easy-to-overlook content that the reader might have been expecting to see in the sidenotes, which is at least somewhat beneficial. In time, I hope the annotations can be linked up with the content to which they are referring. Tarmstro99 13:18, 7 June 2018 (UTC)
Well I used {{frame}} as I wanted to box out the sidenotes from the run of the original text, it's style can be tweaked if needed. Cross referencing an entire work like this would be a BIG project, which you are welcome to attempt. (Noting of course that: Whereas many early Statutes, having been long since expired or been rendered void, as such have no official "Short-titles" applied for convenience of citation, and although various Acts have since subsequently applied official "short-titles" for the convenience of citation, many of the aforesaid statutes without short titles as included on English Wikisource, the said included Statutes have had unoffical short-titles applied on Wikisource for convenience, &c. ) you'd probably need a law student or academic specialist to have definitive titles. See the notes here for the official ones: User_talk:ShakespeareFan00/Archive1#Acts_that_confer_short_titles. ShakespeareFan00 (talk) 15:46, 7 June 2018 (UTC)
yeah, good work. i would go for a broad consensus for either going left sidenote or even ignoring sidenotes, and converting some to footnotes. if we get an end product with more readability, that is an improvement. while we strive to replicate the layout of the original, we should not be wedded to it, to the point of stopping progress as "too hard". Slowking4SvG's revenge 14:58, 12 June 2018 (UTC)

Lillypond scoring[edit]

Statutes of the Realm[edit]

Is anyone with a HathiTrust partner membership able to grab these 12 volumes of the Statutes of the Realm and upload them to Commons? —Beleg Tâl (talk) 11:51, 9 June 2018 (UTC)

&aelig;[edit]

Is there a problem with me changing the template {{ae}} and kin to use the html/xml &aelig; (æ) rather than the non-ascii æ? --RaboKarbakian (talk) 19:02, 10 June 2018 (UTC)

Why would you want to do that? Wikimedia uses Unicode; I'd say that æ should be used instead of {{ae}}, but {{ae}} is easier for some people, I guess. There's no need to obfuscate it further by using &aelig; instead of æ.--Prosfilaes (talk) 19:07, 10 June 2018 (UTC)
Portability. I think it is cool that a book can be downloaded here for ereaders. The only advantage is portability. {{dq}} uses &ldquo; and &rdquo; which made me assume the same for {{ae}}.--RaboKarbakian (talk) 20:03, 10 June 2018 (UTC)
These pages are in Unicode, and most ereaders can handle Unicode. The exporter needs to fix things if there's one that can't. If there's a real problem with a real ereader, it can be fixed, but changing one template isn't going to do anything about all the non-ASCII stuff we have throughout the system.--Prosfilaes (talk) 04:04, 11 June 2018 (UTC)
  • Pictogram voting comment.svg Comment {{dq}} should be deleted as it is outside our style guidance.

Please see Wikisource:Style guide and where you need to deviate please have an exceptional reason for doing that beyond what others would consider personal preference. We keep things simple so that proofreading is available to all and reproducible, not a speciality skill, wherever possible. Noting thatnumbers of bots will replace that code back to the unicode. Feel free to "subst:" the ligature template to have it put the hard character in place. — billinghurst sDrewth 11:34, 11 June 2018 (UTC)

Two things. 1. {{dq}} can be altered to match the style guide (and perhaps should have been if there is such a problem with it). and 2. An apologetic explanation where I divulge the enormous number of discussions I have encountered or participated in which determined that it is always better to let the rendering software make the non-ascii decisions (but I have not yet written this apologetic exp....)--RaboKarbakian (talk) 14:09, 11 June 2018 (UTC)

Problem with page display[edit]

I've added an old book in Persian to the commons (here is the file in commons and here is its index in fawiki). It’s resolution is so high that mediawiki can not display its pages. I tried different methods to compress it but I failed. Is there anyway to solve the problem? --Yousef (talk) 20:18, 10 June 2018 (UTC)

@Yoosef Pooranvary: It seems to be a problem with the rendering of the thumbnails, as I cannot get them at file:Montazem Naseri.pdf either. It may be the file, or it may be the rendering. I would start at c:Com:VP and see if you can get some help, and if that fails, then try a phabricator ticket. I am presuming that you can see the pdf file properly through other means. Alternately, try uploading it to archive.org, then pull back as a djvu using toollabs:ia-uploadbillinghurst sDrewth 11:24, 11 June 2018 (UTC)
@Yoosef Pooranvary: Yes check.svg Done -- please check. The problem with the file was high compression, beyond the handling competence of mediawiki software. I decompressed it, and now it displays properly, at least in my browser. Hrishikes (talk) 13:26, 11 June 2018 (UTC)
@Hrishikes: It would be worthwhile noting that with a phabricator ticket for the thumbnail/rendering. Capturing as much information as possible into the ticket is useful, and also your alternate solution. Having them in phabricator, with alternate solutions helps others until the issue is addressed. — billinghurst sDrewth 23:06, 11 June 2018 (UTC)
@Billinghurst: -- phab:T196961. Please amend as needed. -- Hrishikes (talk) 01:23, 12 June 2018 (UTC)

Okay why is the header sometimes "bouncing" to the bottom?[edit]

Broadcasting Act 1981 (United Kingdom)/Schedule7

I've looked through the code and can't find anything that's obviously misaligning it? Suggestions are welcome, as I've had this with other pages as well.ShakespeareFan00 (talk) 23:46, 10 June 2018 (UTC)

Guessing that you have the lint javascript activated. It doesn't play well in our main ns with the way that header is coded. — billinghurst sDrewth 11:41, 11 June 2018 (UTC)
That was one of my culprits, and I've left a note for the scripts maintainers ("upstreaming" the concern so to speak to borrow a term from other projects)ShakespeareFan00 (talk) 14:50, 11 June 2018 (UTC)

Formatting UK legislation..[edit]

Having reworked some of my contributions in this area, I was going to ask if someone has a style manual for formatting UK legislation? This is likely to either be an official document, or notes to printers in some older work.

Exact reproduction will not be possible (due to Mediawiki) limitations of course.ShakespeareFan00 (talk) 09:45, 11 June 2018 (UTC)

Page status buttons[edit]

It looks as though page status buttons have been modified once again! No longer do they resemble easter eggs, but are now perfectly rounded. I would make further changes to affected help pages such as Help:Page status again, but I think it is close enough to leave as is, if others are in agreement. Londonjackbooks (talk) 19:52, 11 June 2018 (UTC)

{{Rule}} not centering?[edit]

Is rule no longer automatically centering? [31] A previous page proofread on another day formatted the same way is still centered [32] Londonjackbooks (talk) 20:34, 11 June 2018 (UTC)

Here you go. BethNaught (talk) 20:40, 11 June 2018 (UTC)
Ugh. Time for bed. Thanks :) Londonjackbooks (talk) 20:42, 11 June 2018 (UTC)
Silver lining...now I know how to handle those pesky rules from the left side that so often precede a footnote section. Something I've been meaning to look into for ages. Thanks, and goodnight! :) -Pete (talk) 21:46, 11 June 2018 (UTC)

Tech News: 2018-24[edit]

21:55, 11 June 2018 (UTC)

FYI: Changes to numbers of "link" templates in author ns:[edit]

I have been migrating the suitable internal link templates to utilise Template:authority/link as the base, generally used for reference works. I think that I have captured all the quirks and variations that have occurred in the templates, though ask users to check the author ns: pages, when passing, to look for new irregularities in display. Any problems or suggestions for a particular template should be noted on the respective talk page of the template, and users can feel welcome to ping me. Similarly if you need templates developed for your reference work.

For suggestions for the base template, please note those at Template talk:authority/link. I still need a better way to notate in the documentation that there is a base template, and as templates are created for these reference-type works that the base template exists.

The migration to utilise a base template allows for consideration of additional fields to existing templates where considered pertinent, and further development of better standardised/coding. It should provide potential for better data extraction capability and manipulation due to being standardised.

Notes
  • templates that only had positional parameters, will now also have named parameters for those fields
  • templates utilise <onlyinclude> to tighten display components; the display generally shows minimum requirements of required parameters
  • in changed templates the old code has been left and rem'd out—feel free to delete those components when comfortable that the job has been done successfully
  • there is an extensive set of testcases in the base, and each template is documented for its uses and variations of parameters
  • Template:authority/lkpl exists for the lkpl-type templates
  • Template:article link does a similar job for periodicals.
To do
  • Work out what to do with the DNB stuff, that is non-standard
  • Continue to find those hand-coded references and run a bot through and convert them (if you have these, please list them at Wikisource:Bot requests)
  • Templatedata should be added, and identified that much documentation can be improved

If there are any questions, fire away.— billinghurst sDrewth 23:32, 11 June 2018 (UTC)

I have based also {{CE lkpl}} on the lkpl base template (hopefully correctly). Not sure if it was skipped intentionally, so I report it here.— Mpaa (talk) 20:19, 12 June 2018 (UTC)

Update on page issues on mobile web[edit]

CKoerner (WMF) (talk) 20:58, 12 June 2018 (UTC)

"Short-titles" and related...[edit]

The review of internal link templates previously has been noted (in relation to Author pages), If there is a wider review of link templates underway I'd like to politely request that {{short-title}} and {{topic-link}} also get reviewed as part of this.

{{Short-title}} in it's current form will not scale well, and currently would be unable to cope with disambigs between short-titles used to distinguish between otherwise identically titled works in different jurisdictions. It was however converted to a Lua module which may make it easier to maintain.

The issue of short-titles is not just about the template however, given that Wikisource seems to be use a combination of both "official" short titles (directly mentioned in legislation.), widley known but not necessarily official 'short-titles' based on a long-title or widely used name/title, and unofficial short-titles seemingly derived from subject descriptions in Chornological Tables.

To the extent that it's ever possible to have one standard on Wikisource, it would be nice to have ONE standard, and be able to tweak any relevant templates/module to that standard so that as new Acts get transcribed redlinks turn blue without additional effort. On the other hand I am more than willing to throw the whole thing out and hard-code relevant links, which would be simpler, but create more effort when "missing" items in redlinks were added.

{{topic-link}} is not widely used outside one highly specfic work. It was originally written with works that in print are essentialy a specialist index with page numbers. In main space the transclusions would be to anchors in an article page, whereas in Page namespace: they would either suppress of be references to other pages. It could be argued that the template is too complex, and should be abandoned in favour of coding only for mainspace use, suppressing in the Page: and other namespaces.

Given past concerns, I felt these issues needed a wider discussion. ShakespeareFan00 (talk) 13:02, 13 June 2018 (UTC)

Two very similar disambigs: Moon & the Moon[edit]

Too tired to be reasonable in my decision making. Would someone be kind enough to look at and resolve Moon and The Moon. We did have an earlier discussion that we would look to not have such similar disambiguation pages. Thanks if someone can. — billinghurst sDrewth 15:42, 13 June 2018 (UTC)

I've merged the two.--Prosfilaes (talk) 20:06, 13 June 2018 (UTC)
Agree. FWIW, I believe the result of the previous discussion was to not have separate disambiguation pages where the only difference was "A", "An", or "The" in the title, although lengthy lists might be subdivided. In this situation it's certainly a short list and not worth keeping them separate. --EncycloPetey (talk) 22:18, 13 June 2018 (UTC)

A Lost Lady[edit]

I cannot remember which person here was compiling a list of works which will enter PD in the US next year. Please remind me who you are!

Also, please add A Lost Lady (1923) by Willa Cather to your list of such works. --EncycloPetey (talk) 21:47, 14 June 2018 (UTC)

I've got the list at Wikisource:Requested texts/1923. A Lost Lady is on the part of the list copied from w:1923 in literature.--Prosfilaes (talk) 21:56, 14 June 2018 (UTC)
@Prosfilaes: Thanks. I've added a play translation by Murray, a novel by Edith Wharton, and a collection of poetry by E. E. Cummmings. --EncycloPetey (talk) 23:08, 14 June 2018 (UTC)

A little off topic but we/I do this every year at bibliowiki:. E.g. bibliowiki:Bibliowiki:1968 deaths, therefore now in the Public Domain. If the mystery user wants to work together on PD issues at en.ws and bw, that would be great. —Justin (koavf)TCM 21:52, 14 June 2018 (UTC)

I'm in the US, so I'm going to put most of my time into 1923 works.--Prosfilaes (talk) 21:56, 14 June 2018 (UTC)
@Prosfilaes: Great. You're probably familiar with this already but in case you aren't, Public Domain Review publishes a "Class of [Year]" every December. E.g. https://publicdomainreview.org/collections/class-of-2018/Justin (koavf)TCM 22:03, 14 June 2018 (UTC)
This is a little bit of a bigger deal in the US than elsewhere, since the PD cutoff has been frozen at pre-1923 for a very long time. In January 2019, that will advance to pre-1924, which is the first cutoff advance in the US in a very long time. One consequence of the frozen cutoff is that works published in 1923 generally aren't available through Gutenburg, IA, Hathi, etc., except in cases where a work can be "checked out". I'm assuming you're in Canada, so you might be able to help us get a head start scanning the works of Willa Cather, who died in 1947, so that all her works went into PD for most countries outside the US at the beginning of 2018. However, because she is an American author, many of her works have not been scanned. A Lost Lady is a novel for which there is no scan available in IA. --EncycloPetey (talk) 22:33, 14 June 2018 (UTC)
@EncycloPetey: Oh yes, it is a huge deal in the States. I'm kind of surprised Disney didn't swoop in and buy some legislators yet to extend it, tho we're trying with the century+ copyrites on music proposed. —Justin (koavf)TCM 23:04, 14 June 2018 (UTC)
A Lost Lady is available in Gutenberg (1) and HathiTrust (2, 3, 4), although the scans are currently locked. Hrishikes (talk) 01:49, 15 June 2018 (UTC)
We'll have to wait until sometime next year to see whether the scans at Hathi are of good quality, and to determine which edition they are. Gutenburg texts too often have editorial issues for me to trust them anymore. I'd rather see a high-quality scan made fresh from a first edition, if we can get one. --EncycloPetey (talk) 02:41, 15 June 2018 (UTC)

Author:Sylvanus Urban, he was and he wasn't; disambiguate? portal?[edit]

Sylvanus Urban was for 100+ years the editor/publisher/writer of The Gentleman's Magazine. We are right that it was initially Author:Edward Cave though as he died mid 18th century, it is doubtful that he was still writing "Table Talk" in The Gentleman's Magazine/Volume 271. As it became an eponymous for the editor, we can disambiguate it and point to all the editors by years, or we can convert it to a portal. I am favouring the disambiguation, though think that a collective opinion may be better. — billinghurst sDrewth 13:58, 16 June 2018 (UTC)

EnWS should unlock Mein Kampf and My Struggle.[edit]

"Existing translation identified as being copyright until 2039 in United States." does not justify this protection. Everyone in Wikimedian could translate Mein Kampf. Moreover, It's dubious that Muphy's translation is copyrighed in United States. —Preceding unsigned comment added by 2001:2d8:e070:a11d::9ee:90a5 (talk)

Please see Wikisource:Translations, which states our policy regarding Wikisource created translations. One requirement is that "A scan supported original language work must be present on the appropriate language wiki, where the original language version is complete at least as far as the English translation". Since there is no German-language original backed by a scan on the German WS, a user-created translation is not currently within our scope. --EncycloPetey (talk) 18:08, 16 June 2018 (UTC)
It's noexitence in German wikisource is due to cencorship law of Germany. Wikimedia oppose censorship. THERES A PDF VERSION OF GERMAN LANGUAGE VERSION OF MEIN KAMPF.—Preceding unsigned comment added by 2001:2d8:e070:a11d::9ee:90a5 (talk)
I don't see any reason why Murphy's translation would be out of copyright in the US. I'm not really sure what the copyright status of Mein Kampf is in the US; it has a renewal, though questionably timely, and whether or not Houghton Mifflin had the right to file for renewal? It will be moot in a few years, as a work published in 1925/1926. If agreed to be PD and published on wikisource.org, which will publish US PD works the German Wikisource won't, we could start a translation here. But translations aren't nearly as trivial as you suggest, and I don't know of a successful Wikisource translation of a work this long, and this one looks to be a mess.--Prosfilaes (talk) 22:28, 16 June 2018 (UTC)

Excerpting stories from long subpages[edit]

I'm working on Italian Popular Tales, a project that had been mostly stalled since 2012. The bulk of the work is translations of folktales, interspersed with commentary, followed by endnotes (some of which are very long, including one or more numbered tales themselves). There seems to be about a dozen of these tales that have articles devoted to them on Wikipedia, on one of which I've placed a link back to the text here: w:Thirteenth (fairy tale). As you can see the link is to an anchor in the middle of a very long subpage. My question is, would it be advisable to make supplementary transclusions for individual tales that would be easier to link to from Wikipedia and could be entered into Wikidata? Or should the long subpages simply be broken up? Or should translations pages or redirects be used? I would greatly appreciate any advice. — Mudbringer (talk) 05:10, 18 June 2018 (UTC)