From Wikisource
Jump to navigation Jump to search
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 370 active users here.


3000 Validated Works[edit]

Late on Thursday 17 January 2019 (UTC) validation of Amazing Stories/Volume 01/Number 02 was completed. This was our 3000th work to reach this status. To see a list of the previous milestone works go to Portal:Proofreading milestones. Beeswaxcandle (talk) 17:59, 18 January 2019 (UTC)

Well done to all the editors involved. Your work is very much appreciated. —Beleg Tâl (talk) 18:51, 18 January 2019 (UTC)
Yes, very well done! But it occurs to me… Shouldn't these numbers be displayed prominently on the Main Page? We currently have 3,059 validated works, 1,995 proofread works, just under a million proofread pages (according to Slowking above), etc. Some stats are displayed on the Community Portal but that's centred on pages and maintenance: we should have some bragging numbers on the front page for visitors! enwp brags about its 5,801,659 articles at the very top of their w:Main Page, but Wikisource's numbers are even more impressive considering the far smaller number of editors that have achieved them! --Xover (talk) 08:53, 10 February 2019 (UTC)


Bot approval requests[edit]

Repairs (and moves)[edit]

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

Pictures in Rhymes[edit]

Happy New Year.
Can this work be uploaded without the watermarks? Meaning can it be? And can someone do it? Thank you.
Pictures In Rhyme by Kennedy, Arthur Clark; Greiffenhagen, Maurice, 1862-1931

Publication date 1891
Usage Public Domain Mark 1.0
Topics Poetry
Collection folkscanomy; additional_collections
Language English
--Level C (talk) 16:07, 2 January 2019 (UTC)

Books aren't "uploaded" to Wikisource. Books this old, which are in public domain in their home country, are uploaded to Commons. And no, the watermarks cannot be stripped from the images. However, a Wikisource copy built from this scan would not transcribe the watermarks. --16:50, 2 January 2019 (UTC)
Thanks for the info! --Level C (talk) 23:49, 22 January 2019 (UTC)
ok here you go, i will fix up the index tomorrow. c:File:Pictures In Rhyme.djvu; Index:Pictures In Rhyme.djvu. -- user:slowking4 16:01, 17 January 2019 (UTC)
Thank you for your work. This is awesome. --Level C (talk) 23:49, 22 January 2019 (UTC)

Index:A Naturalist on the Prowl.djvu[edit]

Misaligned text layer, with resepct to the scans. I will categorise any more of these I find in Category:Scans with misaligned text layer if anyone wants to make repairs..ShakespeareFan00 (talk) 16:28, 24 January 2019 (UTC)

Done.— Mpaa (talk) 21:50, 6 February 2019 (UTC)


Missing image scans. can some insert placeholder so that the text can be proofread, and the other images used? ShakespeareFan00 (talk) 14:39, 28 January 2019 (UTC)

Done.— Mpaa (talk) 22:55, 8 February 2019 (UTC)

Other discussions[edit]

Wikisource Community User Group representative vote[edit]

Dear all,

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

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

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

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

Thank you!

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

Sub-disambig pages by author[edit]

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

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

Yes, I object. Some of those are versions pages, not disambiguation. However, if they are indeed different works that merely share the same title and author, then I agree. --EncycloPetey (talk) 16:59, 18 December 2018 (UTC)
I am not talking about versions pages, those are completely different and have nothing to do with this. I am talking about separate disambig pages that are created to disambiguate between different works with the same title, but which for some reason have been split off into separate pages by author. —Beleg Tâl (talk) 17:27, 18 December 2018 (UTC)
I am also not talking about editions pages like Song (Aldington) or redirects like Song (Le Gallienne), for the record. —Beleg Tâl (talk) 17:29, 18 December 2018 (UTC)
@Beleg Tâl: your work with the music here has appeared in my watchlist, and is fairly wonderful. I must confess, however, that I find the list of works at Song to be confusing, even with the first lines. Also, I learned here that I am using the word disambiguate wrongly in my summaries. So, a thanks, an apology for being easily confused and another for being confusing.--RaboKarbakian (talk) 18:28, 18 December 2018 (UTC)

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

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

@Londonjackbooks: yes, Song (Coates) is one example, as are the others listed in my original comment. Here are some of my reasons:
  • Main reason: all of the works listed at Song (Coates) are works entitled "Song". All works entitled "Song" should be listed at Song, because Song is supposed to be a list of all works entitled "Song". Therefore, all works listed at Song (Coates) should also be listed at Song. Once all these works are listed at Song, then Song (Coates) will contain only information already available at Song. Therefore Song (Coates) is redundant, and is therefore a candidate for speedy deletion.
  • Additional reason: A page that disambiguates works called "Song" but only if they are by Coates, is not in keeping with the Manual of Style or current practice.
  • Additional reason: Song (Coates) is, by force of our standards for disambiguation, a list of works called "Song (Coates)". None of the works at Song (Coates) are actually called "Song (Coates)", as all of them are called only "Song". We have no works on Wikisource entitled "Song (Coates)". Therefore there is no need for a list of works entitled "Song (Coates)".
I therefore propose that yes, all the contents of Song (Coates) (and Song (Anne Brontë) and Song (Burns) and all the other such pages) be transferred directly into Song, and that the same occur with sub-disambig pages for other titles whenever I encounter them. However, rather than delete Song (Coates) I would redirect it to Song, because it is likely that users will link or search for Song (Coates) to find a song called "Song" and written by Coates. If we are feeling generous, we can use an anchor or section header to redirect Song (Coates) to the specific location at Song that lists works by Coates with this title.
I also want to point out that the only contrary argument I can think of, is that Song is a massive list and merging will make it even more massive. My response to this is: firstly, it doesn't matter that Song is massive so long as it is functional; secondly, we have better, more standard methods for dealing with massive lists (such as {{TOC}} and alphabetical sections, for example; or in simpler situations a simple nested list) which are more in keeping with existing practices and expectations of readers; thirdly, we have lots of massive lists on Wikisource that are perfectly acceptable both from a user experience perspective and from a policy and consensus perspective; I am sure I could come up with more if I had time.
All of which is to say: Song (Coates) is an anomaly in our practices; consolidating all this on Song and redirecting Song (Coates) to Song is how it should be done in order to match with our practices and expectations. —Beleg Tâl (talk) 22:33, 21 December 2018 (UTC)
Makes sense to me, including the suggestion to make the long list more accessible by dividing it into alphabetical sections. --Jan Kameníček (talk) 23:35, 21 December 2018 (UTC)
Thank you for spelling things out. I understand some of your reasoning, and am trying to think through the logic in baby steps. So, if someone is viewing one of Coates' poems entitled "Song" at WS, they would currently see (via the use of the {{similar}} tag) that there are other works available here by the same title—not only by different authors, but also by the same author. That would not be the case were we to be rid of Song (Coates), and I am trying to get over my obtuseness and stubbornness to understand why having such a disambiguation would not be useful in the interest of research. Why is such a redundancy (in certain cases) necessarily a bad thing? And I can't find at the dab help pages exactly where it specifically goes against guidelines. More questions are in my head, but I'll leave it at this for now. Londonjackbooks (talk) 06:11, 22 December 2018 (UTC)
@Londonjackbooks: For an example of what I am proposing, see Song: "Lordly gallants!" by George Wither. You will notice that the hatnote says "For works with similar titles, see Song." Users that click on the link will see a list of works called "Song", some of which might be by Wither, and some of which might not be by Wither; which is exactly what users expect when they click on that link. More generally, I do not deny that pages like Song (Coates) are useful in the interests of research; I only deny that Wikisource is the place for them. We should not maintain lists of works called "Song" by Coates for the same reason that we should not maintain lists of works called "Song" published in the USA, lists of works called "Song" written in 1896, or for that matter, works called "Song" written by Coates in 1896 and published in the USA. Structured queries like this are better handled by Wikidata, which is designed explicitly for this purpose. On Wikisource, users already have two ways to find works by Coates called "Song": 1) search for "Song" at Author:Florence Earle Coates; or 2) search for "Coates" at Song. —Beleg Tâl (talk) 14:33, 29 December 2018 (UTC)
@Beleg Tâl: "We should not maintain lists of ... for the same reason that..." Thank you. I can wrap my head around that reasoning :) I only ask that I be permitted, if your proposal is agreed upon, to do the cleanup for Coates' works myself. Obviously, this request can't necessarily be regulated, but I'm at least putting it out there. Thanks :) Londonjackbooks (talk) 05:09, 30 December 2018 (UTC)
@Londonjackbooks: That works for me. Song would be the first one for me to tackle but I'll hold off until you take care of the ones by Coates. —Beleg Tâl (talk) 18:58, 2 January 2019 (UTC)
Will do. Thanks. I've not been very active here recently, but will make an effort. It may be after January's end. Should I wait until a general consensus is reached on the proposal? Londonjackbooks (talk) 20:26, 2 January 2019 (UTC)
I think we have sufficient consensus to proceed. I'll begin work on Song but I'll leave the Coates part for you. —Beleg Tâl (talk) 16:25, 11 January 2019 (UTC)
@Esme Shepherd: you've made a few of these for Landon, do you have any thoughts on this proposal? —Beleg Tâl (talk) 18:56, 2 January 2019 (UTC)
Esme Shepherd (talk) 20:56, 2 January 2019 (UTC) I did make such a page for 'Change' because I knew Landon had written six poems with that title. These were moved into the main disambiguation page, which didn't bother me although the result is a little confusing because Change (L. E. L.) still also exists as does Change (And this is what is left of youth!), which is for versions of the same poem.
I do have reservations with regard to "Song" because Song (L. E. L.) contains 92 poem entries and I cannot see any advantage in amalgamating these into one disambiguation page with all the other 'Songs'. Surely these pages are to make finding works easier for the user, not more difficult. On the other hand, maybe listing them both ways would be even better - catalogued by the first line, as well as by the poet.
@Esme Shepherd: I am not worried about versions pages at the moment, although I agree that Change (L. E. L.) is a confusing name for a versions page. I understand that merging Song (Letitia Elizabeth Landon) into Song will be very long, but I also intend to make the page easier to navigate as well, so I think it will work out in the end. —Beleg Tâl (talk) 21:15, 2 January 2019 (UTC)
Esme Shepherd (talk) 22:08, 2 January 2019 (UTC) Okay, ease of navigation is the main issue. I would like retention of first lines, as they are the principal identifier. The problem as far as I can see is that someone looking at a Landon song wishing to see other poems with a similar title will be redirected into Songs in general rather than specifically Landon songs. How are they to reach that specific subset if it is lost in a very long list?
Esme Shepherd (talk) 17:09, 30 January 2019 (UTC) Very good. I like what you have done.

Issue with the FI Template display.[edit]

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

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

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

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

Could someone confirm if this a site issue?

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

yes, it looks like another side effect of this change. Zdzislaw (talk) 20:03, 20 December 2018 (UTC)
FWIW {{img float}} is still working. --EncycloPetey (talk) 22:06, 20 December 2018 (UTC)
Only inside a single paragraph, not across paragraphs. See eg. here. Ankry (talk) 00:43, 21 December 2018 (UTC)
@Ankry: Thanks for the phabricator link. They should probably be made aware as well (explicitly) of the issues with image placement and unwanted paragraph separation. We have also noted (above) that padding on the left and right margins in the Page namespace has gone to zero, which is not desirable. Until now the focus has been on the window resizing, and not the other issues that are now surfacing. --EncycloPetey (talk) 00:53, 21 December 2018 (UTC)

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

This last, at least is readily fixable. Simply replace
width: {{{width|{{{1|auto}}}}}};
in {{rule}} with flex-compatible
width: {{{width|{{{1|100%}}}}}};
I would do it myself except for it being protected114.74.46.230 05:22, 22 December 2018 (UTC)
  • there is no need to make any changes. {{rule}} (and many other) will be visible again after reverting the changes - see: phab:T209939#4840870. Zdzislaw (talk) 23:34, 22 December 2018 (UTC)
@Zdzislaw: Agreed. In fact I have some sympathy for the frustration of TheDJ over this change… but the fact he has not edited here for over four years implies the :flex proposal was based more on a theoretic basis than actually thought out and tested?
And while on the topic of untested alterations, have you (O.K. not you—no insult intended—more precisely somebody with editsitecss rights would be needed!) considered putting in place something like{display:block;}
into (maybe)MediaWiki:Common.css as a stop-gap until such time as the Phabricator patch is backed-out or sensibly resolved? 04:38, 23 December 2018 (UTC)

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

That is really strange: I have copied the code out of the page namespace to my Sandbox, where it is displayed correctly... --Jan Kameníček (talk) 18:54, 26 December 2018 (UTC)
Indeed. When the same content is placed in a different namespace, or transcluded to another namespace, it's fine. All of the issues appear to stem from use in the Page namespace when items are displayed side-by-side. --EncycloPetey (talk) 18:58, 26 December 2018 (UTC)

Related spacing issue?[edit]

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

Most probably not related. It gets worse though: note just above Choëphoroe_(Murray_1923)/Text#19 the necessary blank line between stanzas is missing. Two thoughts: should <poem> have been utilised; and/or should each stanza have been forced into its own, individual, paragraph <p>/</p>? 00:30, 2 January 2019 (UTC)
The <poem> tag is notoriously unreliable and fussy, especially across page breaks. I stopped using it ages ago. --EncycloPetey (talk) 00:37, 2 January 2019 (UTC)
I've frequently seen the parser put the last line of a page in a separate paragraph, long before the above issues started. It doesn't happen when it gets transcluded so I've just ignored it. —Beleg Tâl (talk) 00:35, 2 January 2019 (UTC)
When I first began I was encouraged to always check preview before saving. Recently however I note that every time one previews, a blank line is added to the bottom of the page (yes, three previews equals three blank lines!). As I know about this, I always make sure to delete before saving. There may be some who have not noticed this. Esme Shepherd (talk) 10:49, 5 January 2019 (UTC)

Greek and polytonic templates[edit]

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

Not the same issue. Looks like the TemplateStyles plugin is causing the parser to split the paragraph in two. —Beleg Tâl (talk) 13:15, 4 January 2019 (UTC)
I found this problem affected not only in this wiki but also in Wikipedia. In w:Zhang-Zhung language I saw this problem also occur in main namespace. So I think TemplateStyles plugin has a regression. --Great Brightstar (talk) 16:10, 9 January 2019 (UTC)
I found <indicator> tag can be used to avoid this behavior, and the problem is fixed. --Great Brightstar (talk) 09:45, 24 January 2019 (UTC)
I found Wikipedia put an icon at the right top corner of the help desk while I saw it on my phone, I will see how they did it, and is it possible to make use of that. --Great Brightstar (talk) 13:21, 13 February 2019 (UTC)
Oh that is not so suitable than <indicator> tag which can inject an element only once, don't use that. --Great Brightstar (talk) 13:54, 13 February 2019 (UTC)


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

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


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

Wow that template is massively complex. What I've determined so far:
  • In between the two "separate" diagrams are hidden empty elements
  • The hidden empty elements are tagged as class=mw-empty-elt
  • The class mw-empty-elt is added by the parser to all empty elements in order to resolve some issues from when Tidy was retired [1]
  • The class mw-empty-elt is set to display:none, see phab:T129375, phab:T150742, phab:T172896, phab:T49673
  • When you disable the display:none rule, the chart displays properly.
Beleg Tâl (talk) 23:35, 5 January 2019 (UTC)
With that information, despite having no idea what's going on, I seem to have fixed it. —Beleg Tâl (talk) 23:48, 5 January 2019 (UTC)
Thanks. The really frustrating part was that the example on the Template consistently worked, but every other instance I located or tried myself wouldn't work. Glad it has been corrected. --EncycloPetey (talk) 00:22, 6 January 2019 (UTC)

Possible fix coming[edit]

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

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

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

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

Based on phab:T208901, the devs are still debating how to address the paragraph-splitting issues with templatestyles. —Beleg Tâl (talk) 13:28, 9 January 2019 (UTC)
The 1.33/wmf.12 version of MediaWiki is now live here, and based on a quick check it fixes the missing horizontal rule issue, returns the header and footer fields to a reasonable size, and makes them resizable again. It would be a good idea for anyone who have experienced problems suspected to be related to this issue to test whether their problem is now resolved. Re-pinging previous list: Sp1nd01, Zdzislaw, EncycloPetey, Ankry, Jan Kameníček, Beleg Tâl, Esme Shepherd, Narky Blert. --Xover (talk) 20:54, 9 January 2019 (UTC)
I can now see and (I trust) edit the header and footer boxes in English WS in both PaleMoon and WaterFox, which I could not before. They are still absent from multilingual WS; but that's a lesser problem, and it's always possible that the fix will percolate through slowly. Narky Blert (talk) 21:28, 9 January 2019 (UTC)
Grrr. Problem solved. Preferences/Editing "Show header and footer fields when editing in the Page namespace" is disabled by default in multilingual WS. I've enabled it, and can now see and edit the header and footer boxes. Narky Blert (talk) 08:01, 11 January 2019 (UTC)
To confirm that I see the images are now floating left and right as expected, thanks. One other issue that I spotted on a random page proofread was that the blackletter font wasn't displaying, I thought it may have been related to this issue, but on just rechecking the page blackletter is still not displaying. i.e. Page:Vaccination a delusion.djvu/7 Sp1nd01 (talk) 22:03, 9 January 2019 (UTC)
@Sp1nd01: I can see the blackletter font from the computer I am currently using, so it may be a browser, OS, or personal skin issue, or something similar. Try a different browser or computer, I you can, and see if the problem persists. --EncycloPetey (talk) 22:56, 9 January 2019 (UTC)
Thanks for the suggestion, I should have thought of trying that before! I confirm that if I use the Edge browser it does show the blackletter fonts fine, but my default Firefox browser still does not. I'm 100% certain that it used to display fine, maybe its caused by a recent update either to the browser or OS. Sorry for the false alarm. Sp1nd01 (talk) 23:20, 9 January 2019 (UTC)
The blackletter font renders for me in both PM and WF. Oddly, in both browsers the blackletter line, unlike the other formatting, initially appeared in a plain font and only turned into blackletter at the very end of page loading. That suggests a coding issue of some sort. Narky Blert (talk) 04:53, 10 January 2019 (UTC)
Thank you. Now I can edit headers and footers again at my own desk - that's great! Esme Shepherd (talk) 22:33, 9 January 2019 (UTC)

Changes to {{Lang}}[edit]

With reference to Wikisource:Scriptorium#Language_tagging, I made an attempt to modify {{Lang}}, adding inline=yes as default option for <span></span> template, and inline=no to generate a <div></div> template.
I would appreciate very much opinions on the choice on names and proposed coding, and a review from someone expert in templates and community in general. Thanks— Mpaa (talk) 21:35, 14 January 2019 (UTC)

Better have the discussion at the template talk page maybe. I posted here the news for visibility.— Mpaa (talk) 21:52, 14 January 2019 (UTC)
It might be simpler to have two templates, like we have for all other similar situations: {lang} for inline (span) and {lang block} for (div). This way the template won't require an extra parameter or template burden in lengthy documents. This is what we already do with {{smaller}} and {{smaller block}}, for example. --EncycloPetey (talk) 22:40, 14 January 2019 (UTC)
Someone in previous thread preferred one single template. I am more inclined to your approach. Let's see a few more comments.— Mpaa (talk) 23:16, 15 January 2019 (UTC)
I also am inclined to {{lang}} and {{lang block}} as separate templates. They can both share common inner workings if desired. —Beleg Tâl (talk) 00:46, 16 January 2019 (UTC)
@Mpaa:I agree with two separate templates as well. --Jan Kameníček (talk) 13:02, 17 January 2019 (UTC)
Separate templates, Would it be possible to apply something like this to the iwtrans templates as well? ShakespeareFan00 (talk) 14:48, 17 January 2019 (UTC)
@Mpaa: Provided you mean Andy's comment in the thread above, and provided I understood them correctly, the objection was to duplicating code in two separate templates: having one template that supports both modes, and a lightweight wrapper template that just invokes the full template with the right parameter(s) set, is wholly in agreement with that stance. From a end user perspective it's two different templates; but there's only one set of template code to maintain. I do not believe anyone has actually objected to having separate templates in the end-user sense. --Xover (talk) 14:55, 17 January 2019 (UTC)
But having one template that calls another template. . . isn't that increasing template burden again? This is a template that has the potential to be transclusion thousands of times in a single work, or even in a single Mainspace page. Template burden is a real concern in that sort of situation. We already have some ToC templates that break in large tables of contents. --EncycloPetey (talk) 15:10, 17 January 2019 (UTC)
In that edge case, use the primary template, with the parameter, not the wrapper. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:25, 17 January 2019 (UTC)
When this template is used, it will be used heavily. We have several current projects that are bilingual dictionaries, glossaries, and the like. I did a work that was a thesis on additions to the standard Greek lexicon, and we have several reference works which include multiple non-English words throughout. So what makes you think that this is an "edge case"? Isn't your proposal effectively to complicate the most complex uses of this template? --EncycloPetey (talk) 19:28, 17 January 2019 (UTC)
@EncycloPetey: So far as I am aware, the two big technical limitations with templates is the recursion limit and the total expanded size, with total number of transclusions on a single page a distant but not insignificant third. I'm not sure what you mean by "template burden", but a template calling a single other template is unlikely to be much different from just simply calling a single template. If there is some issue there that I'm not aware of (absolutely a possibility), I'm sure we can investigate moving the common code into a Lua module that both templates call. Last I heard, the WMF guidance was that performance should never be a consideration for any community discussion: resource limits can be raised, more hardware added, or infrastructure code made more efficient. --Xover (talk) 19:17, 18 January 2019 (UTC)
The WMF guidance you speak of is WP and Commons guidance. Projects like WS and WT are very, very different from the "expected" model based on what happens at WP and Commons. So much so that the usual guidance doesn't apply. --EncycloPetey (talk) 20:59, 18 January 2019 (UTC)
Fair point. But still, based on my (necessarily limited) understanding, I don't see any big problem looming as a result of one template invoking another. The parser and caching should effectively take care of that, and we can always move the common logic to Lua if necessary (I'd say preferably, but I'm not sure everyone here agrees with that). --Xover (talk) 07:24, 19 January 2019 (UTC)
I have added {{lang block}}, which internally calls {{lang}}. If this turns out to be too heavy, it can be refactored appropriately.— Mpaa (talk) 20:16, 20 January 2019 (UTC)
I would really appreciate if someone could make the backend logic in Lua (or solve the following issue). Linter on {{lang}} gives an error due to fact that the {{#ifeq:{{{inline|yes}}}|yes|<span|<div}} does not really create a span tag as the closing ">" arrives only later. It is nothing that generates errors when used or functional issues but it is annoying as it might give such impression. Thanks.— Mpaa (talk) 21:20, 20 January 2019 (UTC)
@Mpaa: Where are you seeing this linter error? --Xover (talk) 09:33, 21 January 2019 (UTC)
On the template page itself. I know it has no effect but when trying to understand where a lint error comes from, it is good to have them clean.— Mpaa (talk) 20:14, 22 January 2019 (UTC)
I'm sorry for being dense, but where exactly on the page? I'm not seeing it anywhere on Template:lang, nor when I preview an edit to it. --Xover (talk) 20:36, 22 January 2019 (UTC)
You need to enable the linter checker gadget.— Mpaa (talk) 20:53, 22 January 2019 (UTC)
In terms of terminology, a "Gadget" is something you can go enable in the preferences with a simple checkbox. Based on a little detective work, what you're using is the "user script" w:User:PerfektesChaos/js/lintHint with a little custom configuration (see the "Configuration by JavaScript" section and enable all namespaces).
In any case, I can't really see why the linter is complaining here. While the source of the template is indeed apt to confuse any parser, the linter really shouldn't see it until after it's been preprocessed sufficiently that what it sees is a complete tag pair. Note also that what it's complaining about is the end tag, because it thinks it hasn't seen a matching start tag, and not the start tag itself. Which, unless there's an actual bug in the code that I'm not seeing, is pretty weird behaviour.
As you say, it doesn't show up when transcluded, so I don't think it's something we should worry overmuch about. However, if someone with the right permission bits can import some dependencies and supporting templates/modules from enwp, I can take a stab at reimplementing the common stuff in Lua to avoid the problem. --Xover (talk) 15:32, 23 January 2019 (UTC)
I forgot how I enabed it. When I try to understand what gives an error, spurious messages just confuse. Sometimes it is already hard enough to tame divs and span ...— Mpaa (talk) 20:38, 23 January 2019 (UTC)

Plan S for free content: feedback request[edit]

The Plan S open-access initiative aims to make modern academic articles free content. It is requesting feedback about itself on these questions:

  1. Is there anything unclear or are there any issues that have not been addressed by the [Plan S] guidance document?
  2. Are there other mechanisms or requirements funders should consider to foster full and immediate Open Access of research outputs?

It seems to me as though people here may have useful answers. Feedback is open until the 8th of February.

The plan launched in September and has a large proportion of European research funders and a couple of US ones onside; if you are affiliated with a research funder, they might want to look into it. The best comment on Plan S I've heard so far comes from Elsevier (which doesn't really like the financial transparency provisions, for starters). An Elsevier spokesman said "If you think that information should be free of charge, go to Wikipedia" ("Als je vindt dat informatie gratis moet zijn: ga naar Wikipedia"). I'm not sure if he knew about the journals published here.

Is there a good place to point academics who want to ga-naar-Wikipedia? I'm thinking of a how-to for people unfamiliar with wiki authoring who want to, say, post a post-print to Wikisource. Our metadata could make that last very findable, if properly formatted with something like Wikiversity:Template:Article info. HLHJ (talk) 00:32, 21 January 2019 (UTC)

User:Daniel Mietchen? see also m:WikiCite -- Slowking4SvG's revenge 01:18, 22 January 2019 (UTC)
Thanks, Slowking4. A comment is being drafted at Wikiversity:Talk:WikiJournal User Group#Plan S RfC, contribs welcome. HLHJ (talk) 05:48, 27 January 2019 (UTC)

Tech News: 2019-04[edit]

20:33, 21 January 2019 (UTC)

Google Cloud Vision + books[edit]

>Google is also providing Wikipedia free access to its ... Cloud Vision API, which will ... let editors automatically digitize books so they can be used to support Wikipedia articles too.
Google Gives Wikimedia Millions—Plus Machine Learning Tools. Wired. 2019-01-22.

Anyone know where I can read more about the WMF/Wikisource's plans with this? czar 12:43, 23 January 2019 (UTC)


-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:52, 23 January 2019 (UTC)

Wikisourcers already have access to two OCR systems of Google: Google Cloud Vision OCR and Google Drive OCR. The Drive ocr is better. Users can include both on their edit toolbar by customising gadget preference or own common/global.js. Hrishikes (talk) 14:03, 23 January 2019 (UTC)
yes, this was a big event for the Indic languages, less so for english, although works well for marginal pages. you could develop a google books to commons tool, but we currently upload to commons via internet archive. Slowking4SvG's revenge 18:12, 23 January 2019 (UTC)
At present, three ocr systems can be used in English Wikisource: Tesseract 3, Google Cloud Vision, Google Drive. I have all three in my edit toolbar, but the Drive ocr gives the best output. Tesseract 4 has been developed (I have it for offline use), but onsite, it has not been updated. Secondly, books from Google Books can be transferred directly to Commons using url2commons, e.g. this file. Hrishikes (talk) 02:02, 24 January 2019 (UTC)
and you should change to c:Template:Book which has the right metadata fields. information template is limited. Slowking4SvG's revenge 13:58, 27 January 2019 (UTC)
Is there a limit in usage of Google Drive OCR in case one would like to automate the task?— Mpaa (talk) 20:26, 24 January 2019 (UTC)
Yes, some limit is there, but usually that limit is difficult to reach. The OCR4wikisource tool uses Google Drive OCR for automating the task. Thousands of books in various Indic wikisources have been ocr-ed using this tool. Hrishikes (talk) 04:47, 25 January 2019 (UTC)
If WMF are in touch with Google, is there a process where feedback can be sent about incomplete or unintentionally degraded scans present in Google Books, or through which suggested improvements of the OCR process could be suggested? ShakespeareFan00 (talk) 09:13, 27 January 2019 (UTC)

Page:Baron Trump's marvellous underground journey.pdf/22 and others...[edit]

The PDF handler has again failed here, and produces a blank page image. I know the pages is there because I CAN see it if I grab the PDF directly. Can someone please produce, a list of what PDF formats Mediawiki DOES actually support, so these semi-random page display failures can be removed, by down converting files if needed. ShakespeareFan00 (talk) 13:32, 26 January 2019 (UTC)

Have you reported this on Phabricator? —Beleg Tâl (talk) 14:05, 27 January 2019 (UTC)
I haven't because it's usually the file that needs repair not the handler .. My request for a list of "supported" PDF formats stands. ShakespeareFan00 (talk) 14:09, 27 January 2019 (UTC)
Phab might be able to give you a list of supported formats as well. Idk if anyone here knows that level of detail about mediawiki file support. I sure don't. —Beleg Tâl (talk) 15:27, 27 January 2019 (UTC)

Replacing a work -[edit]

I've noted some missing scans, and low image qualiity in : Index:Travel Pictures The Record of a European Tour.pdf

There's a version that has the missing pages here:-

and being on most likely also has a text layer, which the current scans don't.

Can someone advise on this further? ShakespeareFan00 (talk) 12:18, 27 January 2019 (UTC)

Since the bad scan has very little proofreading done so far, I would just import the better scan and start working on it. Make sure to coordinate with User:Wikilover90 who started that transcription project. You can put the bad index on WS:PD when it's fully abandoned in favour of the better scan. —Beleg Tâl (talk) 14:02, 27 January 2019 (UTC)
Agreed. And in case anybody reading this discussion is unaware, I highly recommend the IAupload tool for importing Internet Archive texts. Just log in with Wikimedia credentials, paste the IA identifier (in this case, travelpicturesre00bhav), and upload. -Pete (talk) 22:05, 30 January 2019 (UTC)

Page numbering fails when defining custom strings in Index page list..[edit]

s:Things_Mother_Used_to_Make/Pickles failed to display page numbers displayed unless a very specifc format is used when defining the page numbers on the relevant Index: page. Suggestions are welcome? ShakespeareFan00 (talk) 14:16, 27 January 2019 (UTC)

Okay for whatever reason the page-numbering scripting can't apparently cope with simple brackets. What a shame :( ShakespeareFan00 (talk) 14:21, 27 January 2019 (UTC)
"43*" works as a page number "43(*)" doesn't.. Why? ShakespeareFan00 (talk) 14:22, 27 January 2019 (UTC)
Also if this is indeed a limitation, there's NO warning given when trying to update the Index page concerned..ShakespeareFan00 (talk) 14:23, 27 January 2019 (UTC)

Another example : - The Return of Sherlock Holmes, 1905 edition/Chapter 1, page numbers display up to where a page number with a bracket for an image plate appears. and then they do not. 14:38, 27 January 2019 (UTC)

I presume the numbering system was not designed to function with asterisks or parentheses in page numbers, since those characters are neither numerical, nor are they normally included as part of a page number. Change the "(8)" to "Img" or something else that does not use parentheses. --EncycloPetey (talk) 14:42, 27 January 2019 (UTC)
Right- Thats what I was thinking as well, Do you happen to have a list of Index pages that uses paranthesis inside a <pagelist /> tag? Would it be possible to generate one? ShakespeareFan00 (talk) 14:46, 27 January 2019 (UTC)
It's still broken - The_Return_of_Sherlock_Holmes,_1905_edition/Chapter_1 it picks up the Img tag for Djvu page 21, and the blank for page 22, and then fails to pick up the number for page 23. The script needs to be overhauled. ShakespeareFan00 (talk) 14:53, 27 January 2019 (UTC)
Mentioned at Phabricator - (talk) 15:08, 27 January 2019 (UTC)
The work-arounds suggested by @Billinghurst: and others in the now closed ticket, appear to resolve the issue. However I'd like a clear indication that these work arounds are the correct one, and likely to remain stable in the long-term, before deploying it over the 5000 or more affected pages. A concern that was noted previously by others was the deployment of "fixes" that hadn't been fully debated. ShakespeareFan00 (talk) 12:28, 28 January 2019 (UTC)
I'm still however puzzled given that Mrs. Beeton's Book of Household Management/Chapter I had the same situation of a blank page within the transclusion, but no page numbering display error... Perhpas others can assist in figuring out the more precise circumstances of when the glitch happens?

ShakespeareFan00 (talk) 12:40, 28 January 2019 (UTC)

Well it should all display nicely - updated all the non blank pages to have unique id. ShakespeareFan00 (talk) 13:02, 28 January 2019 (UTC)

Page:Gurney - Things Mother Used to Make.djvu/24[edit]

I'd like a second view, Here the recipes are currently formatted such that there's no breaks. the {{Center}} heading being used as such between recipes.

Is this ideal, or would it be better to put new lines in to separate individual recipes? ShakespeareFan00 (talk) 01:40, 28 January 2019 (UTC)

ShakespeareFan00 (talkcontribs), here is how I would organize it. Feel free to revert, however. ―Matthew J. Long -Talk- 04:00, 31 January 2019 (UTC)

Work by Communist Party of China[edit]

Since it has been long unclear to many if the works by Communist Party of China is copyrightable, I find it necessary to seek clarification and establish consensus. While CPC may hold copyright to some of its works, those should not include orders, and any document released by CPC that is of severe public interest. Under US copyright law, do we consider Edict of CPC as Edict of Government given the status quo of Chinese politics? Considering article 5 of Copyright Law of PRC, do we consider some works by CPC as "other documents of legislative, administrative or judicial nature;"? After the 2018 constitution amendment, the party leadership is written in, does that mean to copyright works by CPC would be unconstitutional in its nature?Viztor (talk) 19:47, 25 January 2019 (UTC)

Your question would be better directed at a forum on Commons. We have very few editors here who work in Chinese, so the issue of CPC copyright seldom comes up. --EncycloPetey (talk) 02:22, 28 January 2019 (UTC)
Many Chinese Wikisourcers consider works by Communist Party of China possibly copyrightable, being discussed at their scriptorium. If in doubt, leave it out.--Jusjih (talk) 04:26, 28 January 2019 (UTC) (your East Asian cultural bridge)
Chinese Wikisource has zh:Wikisource:English Scriptorium.--Jusjih (talk) 00:15, 29 January 2019 (UTC)

Tech News: 2019-05[edit]

18:15, 28 January 2019 (UTC)

When Father Carves the Duck[edit]

There are odd characters appearing in this text. Can anyone identify them and determine why they might have ended up in the text? --EncycloPetey (talk) 18:39, 28 January 2019 (UTC)

@EncycloPetey: Are you sure you have the correct text? This is just standard-issue ASCII to me... —Justin (koavf)TCM 19:57, 28 January 2019 (UTC)
On my Mac it looks like basic ASCII, but on the PC, it has odd-looking characters in almost every line of text. --EncycloPetey (talk) 20:54, 28 January 2019 (UTC)
Yeah, cannot reproduce this. Anybody else? —Justin (koavf)TCM 21:28, 28 January 2019 (UTC)
It's U+2028, see Stackoverflow. I see it on Chrome on PC (the browser is going to be important here.) It's the Unicode specific line separator, but since good old ASCII line breaks stuck around, it doesn't seem to be handled right. I don't know the exact source, but it doesn't smell of attack or corruption (as long as all the line breaks that should be there are), so they can just be deleted.--Prosfilaes (talk) 23:54, 28 January 2019 (UTC)
For anyone who is not seeing this, are you seeing blank lines between every lines? It seems wrong for a system to just ignore them, but that's what I'm getting from EncycloPetey's comment about the differences between Mac and PC.--Prosfilaes (talk) 23:57, 28 January 2019 (UTC)
Ooooooh. Shows in Chromium as well. Removed them. Thanks! —Justin (koavf)TCM 23:58, 28 January 2019 (UTC)

License text[edit]

Many publishers are negligent or deliberately deceptive in reporting to their users the copyright status of materials in the public domain, or under a free license. One of the ways Wikimedia sets itself apart, in general, is by giving readers (and potential reusers) clear information about licensing. But in one respect, I think we fall short. At the bottom of every Wikisource page is the following text:

"Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply."

On Wikisource, this claim is almost always inaccurate. Most of the material here is in the public domain; other material may have any of several free licenses.

Changing this text would require close consultation with the WMF legal department. But before reaching out to them, I'd like to know: what do Wikisource users think would be the ideal resolution? -Pete (talk) 20:33, 28 January 2019 (UTC)

Most websites that I've seen have handled this by saying "unless otherwise specified, text is available &c." —Beleg Tâl (talk) 02:26, 29 January 2019 (UTC)
Yes, that phrasing is common; but I don't think it's a good fit for Wikisource, since Wikisource is not a place for original composition by project members. If a main space page does not specify otherwise, I would guess that in most cases, it's either (a) public domain without a banner, or (b) a copyright violation that hasn't been caught. I'd guess (though I'm not sure how to measure) that the number of cases in which an unmarked main space page is CC BY-SA are vanishingly rare. -Pete (talk) 01:11, 30 January 2019 (UTC)
I think it's still a good fit for Wikisource, you just need to flip your thinking around. Every hosted text requires a license tag; every item of content on this site that isn't a hosted text is CC BY-SA, so a fully accurate statement would be "Unless otherwise indicated, or unless someone screwed up, all text is CC-BY-SA" - but I think "unless someone screwed up" can be safely taken as given. —Beleg Tâl (talk) 03:46, 30 January 2019 (UTC)
I think the discussed text should not appear in the main namespace at all. The license should be made clear by a license tag only. It is misleading if the license tag states it is in public domain and at the same time the text below states it is licensed under CC-BY-SA + some unspecified additional terms. The license tag makes the statement below redundant. --Jan Kameníček (talk) 09:41, 30 January 2019 (UTC)
I strongly disagree with this. There is lots of meta text in mainspace: headers, notes in headers, license tags, banner text, interface text, &c all of which is CC-BY-SA unless otherwise noted. —Beleg Tâl (talk) 23:56, 1 February 2019 (UTC)
A lot of that is too short to attract a copyright anyway. "This work was published before January 1, 1924, and is in the public domain worldwide because the author died at least 100 years ago." is not at all copyrightable. Notes should not generally be long enough to be copyrightable. I suppose much of the stuff is outside our control, but we should be clear where the CC-BY-SA applies.--Prosfilaes (talk) 00:32, 2 February 2019 (UTC)
I agree with Beleg Tâl. The text isn't optimal outside the Wikipedias (where most text really is CC-BY-SA), but it's still a good default for all the text on enWS that isn't tagged with an explicit license. To wit, this text here is, by way of the terms displayed in the edit field, "irrevocably agree to release your contribution under the CC BY-SA 3.0 License and the GFDL". What's missing is really the "Unless otherwise specified" part to make it clear that public domain works have not magically become subject to new copyright by virtue of us transcribing them.
I also agree with Peteforsyth insofar as it being worthwhile to address the issue. It is a minor issue, but not an entirely insignificant one.
I also think the boilerplate at the bottom there is technically somewhat in the local project's control (i.e. I'm pretty sure it's configured text, not hardcoded) so provided WMF Legal has no actual objection to whatever we decide, it should be realistically possible to get it changed in our lifetimes. --Xover (talk) 06:26, 31 January 2019 (UTC)
Ah, I see I was not as explicit as I could have been. I'm talking specifically about main space, which I think is by far the most important. (I realize it's probably not currently easy to have the text vary based on namespace, but I'd imagine that's something that could be changed if a need is demonstrated.)
With that in mind, I suppose the header info, which occasionally includes extensive "notes", might indeed include text that is CC BY-SA. So maybe the footer message should take that into account. -Pete (talk) 00:21, 1 February 2019 (UTC)
As a purely technical matter, and provided my quick leafing through the docs didn't lead me astray, the text in question is configured using the variable $wgRightsText. This is a global configuration that affects all pages in all namespaces on a given wiki. It is also not, that I have found, changeable by the local community (you need to request the change from the WMF). However, there exists an extension named PerPageLicense that claims to let you specify a license on a per-namespace or even per-page basis. The extension is not installed on enWS, and cannot be installed by the local community (must be requested from WMF; who are likely to ask pointed questions, drag their heels, and involve WMF Legal first). But that being said, there's no obvious technical reason why it can't be installed. Which means—and again I'm speaking from a purely technical perspective here—we could request the sort of change you're envisioning provided there's a strong enough consensus in favour of 1) changing the status quo at all, and 2) what that change should be. --Xover (talk) 06:46, 1 February 2019 (UTC)
Correction: Thanks to an exceedingly helpful gentleperson answering questions elsewhere, I've found that the license boilerplate is actually stored in MediaWiki:Wikimedia-copyright and is actually editable (in the technical sense) by Administrators and Interface Administrators on WMF wikis (for non-WMF MediaWiki installations the previous description holds true). We would still, I think, have to run any change by WMF Legal, but Wikinews and Wikidata have custom license text there already so it's not unheard of. For per-namespace configuration the previous is still correct, except that there's a decided risk the mentioned extension will not work with the special WMF setup. If that's the case we would need to have actual development work done to adapt it (or reimplement the functionality in MW directly), which sounds like it might take a long time and be hard to get bumped up the priority list. --Xover (talk) 08:08, 1 February 2019 (UTC)

Blank page transclusion, and page number suppression...[edit]

In this edit for :

The inclusion in the transcluded sequence of a blank page, means that the page number for the content page subsquent to the blank page with no content is suppressed, this is I've been informed as designed (although disappointing) behaviour.

This was repaired as -

However, it is felt that this is confusing for potential readers (and contributors) that might not be aware of the technical minutiae of how the numbering script works locally, and the need to explicitly exclude specifc blank DJVU pages directly.

Would it be possible for someone technically minded to write scripts that:

  1. Generates a list of article pages, which transcluded sequences which transclude blank pages, so that appropriate so that the "exclude" parameter can be used, which is the solution suggested previously.
  2. Use the list generated, to amend transcluded sequences (typically a <pages /> tag) to explicitly mark using the "exclude=" parameter, pages that are marked as having no content, and which do not contain any wikitext?

Alternatively, the page numbering script could be amended, to cope with this.

Given the repetitive and repeatable nature of the edits required, I feel this task should ideally be done by a bot, like certain other routine maintenance tasks. 11:33, 30 January 2019 (UTC)

A bot sounds feasible for this, but I don't know who operates bots on enWS these days.
I have a long term ambition to attack MediaWiki:PageNumbers.js with an eye to splitting the page numbering bits away from the layouts bits, fixing various issues related to page numbering (see a previous thread on here), and generally tidying up (making it easier to maintain, hopefully). However, that job has to start with turning it into a Gadget so it can be disabled from the preferences. Right now it gets loaded unconditionally for everyone so if you tried to make a new version the two would always be fighting over which one does what to the page numbers and layouts. And since I can claim very little expertise in programming for a MediaWiki environment, I would need the assistance and support of more experienced users (preferably with the +sysop and +interfaceadmin bits, since only admins can edit most of the relevant files).
If anyone is interested in that please do let me know! I make no promises regarding timeframes or results, but it's a personal itch I'm willing to put some effort into scratching. --Xover (talk) 07:15, 31 January 2019 (UTC)

Category:National portals are inconsistent[edit]

We have Portal:Côte d’Ivoire but not Portal:Ivory Coast. For some reason, we have Portal:Cape Verde rather than Portal:Cabo Verde, Portal:Swaziland rather than Portal:eSwatini, and Portal:East Timor rather than Portal:Timor-Leste. I recommend moving all the latter three. Also, Portal:Sao Tome and Principe instead of Portal:São Tomé and Príncipe.Justin (koavf)TCM 21:41, 30 January 2019 (UTC)

Those all seem to be the officially declared names in English, with one exception. I find it weird to have w:Ivory Coast but w:Eswatini, but that's Wikipedia's problem. However, I would go with Eswatini, for consistency with Wikipedia and because the capitalization standard is inconsistent and capitals at the front is better English.--Prosfilaes (talk) 05:18, 31 January 2019 (UTC)
@Prosfilaes: With one exception...? —Justin (koavf)TCM 06:32, 31 January 2019 (UTC)
Eswatini instead of eSwatini. Rather, that's at least ambiguous.--Prosfilaes (talk) 07:28, 31 January 2019 (UTC)
Support moving them, but make sure you leave a redirect. Regarding the Eswatini vs eSwatini, see w:Talk:Eswatini#eSwatini vs. Eswatini, where it is noted that Eswatini is the official name in English (eSwatini is the official name in Swazi) while common usage is apparently evenly split between the two, and Eswatini is more in line with normal English orthography. —Beleg Tâl (talk) 12:04, 31 January 2019 (UTC)

Is this a cache issue?[edit]

The reference images at Index:The Living Flora of West Virginia and The Fossil Flora of West Virginia.pdf all seem to be off by one page since I deleted the Google scan title page from the beginning of the PDF. I'm assuming the index is drawing from a cache of the old pages but even after clearing my caches both here and at commons I still have the misalignment problem. Can anyone help? Abyssal (talk) 15:42, 31 January 2019 (UTC)

Deleting a page will automatically shift everything in the scan by one page. Is this what you mean? If not, could you be more specific about what you're seeing? --EncycloPetey (talk) 20:38, 31 January 2019 (UTC)
I'm pretty sure EncycloPetey's explanation is correct; deleting page one will shift all other pages. The better approach is to *replace* page one with a blank page, which you could do by duplicating an existing blank page. (On Linux, I use PDF Shuffler for this, but I don't know what operating system you're using; there are probably free software options for any OS.) You can still do that, and re-upload; I think this is your best bet.
However, there also seem to be major cacheing issues around this stuff, so your initial instinct is not unfounded. I've found it takes several days for caches to catch up, and purging all relevant pages through the MediaWiki software doesn't help. It'll even go back and forth from "incorrect" to "correct" in the process...see this report. What I didn't mention there is, since it "fixed itself," it also screwed itself up again, and now is working properly again. So you might re-upload, and then wait a week, to save yourself a possible headache :) -Pete (talk) 21:41, 31 January 2019 (UTC)
I am seeing no misalignment, after random checking, in the file mentioned by @Abyssal:. Hrishikes (talk) 02:09, 1 February 2019 (UTC)
The places where I (still) see incorrect OCR, @Hrishikes: pages 24 and 25 (DJVU) and perhaps others. It may not be a big deal, if it's just a few pages, as they can just be OCR'd or transcribed "manually." Still, it would be nice to have a clearer sense what goes on in cases like these. (Also, I was incorrect about my example -- it has not "fixed itself" after all. I may have been looking at the wrong page when I wrote that.) I'm inclined to start a phabricator task, but I'm not sure I even understand the problem well enough to describe it accurately. -Pete (talk) 20:29, 7 February 2019 (UTC)
@Peteforsyth: -- In case of misalignment of ocr, it can be done locally, there are multiple options at present. I have done some; please check the quality. Hrishikes (talk) 06:14, 8 February 2019 (UTC)
We typically have Proofread Page Extension issues with PDFs, which is one reason why DjVu files are preferred. If a correct DjVu file of this text can be uploaded, and the work done thus far transferred over to an Index page for the DjVu file, the whole process will likely proceed more smoothly. --EncycloPetey (talk) 20:34, 7 February 2019 (UTC)

Changes to page numbering[edit]

Page numbering in the ProofreadPage extension appears to have been modified, in particular now appearing within the flow of text instead of in the left margin. Does anyone know where this change came from? —Beleg Tâl (talk) 03:00, 4 February 2019 (UTC)

It still appears in the margin for me, at least in the works I checked. Where are you seeing this behavior? --EncycloPetey (talk) 04:42, 4 February 2019 (UTC)
Are you aware that this is a display option in the sidebar? Perhaps you accidentally bumped it.... Hesperian 10:58, 4 February 2019 (UTC)
I was not aware, but I am now! Thanks. —Beleg Tâl (talk) 14:42, 4 February 2019 (UTC)

Tech News: 2019-06[edit]

17:12, 4 February 2019 (UTC)

Resolution of the CharInsert problem[edit]

Would anyone know how to update the MediaWiki:Gadgets-definition for CharInsert? This is the instruction I got from w:Wikipedia:Village pump (technical). Since the code is a copy of the WP CharInsert.

Our updated/upgraded script of Charinsert is not fully functional. The problem is that the update is not writing the user's Charinsert row selection to a cookie as it used to. The code change is that the script now writes to the LocalStorage and not a cookie.Ineuw talk 20:27, 4 February 2019 (UTC)

A bureaucrat can do it, or give you access to do it -- @Hesperian, @Mpaa, @Zhaladshar:Beleg Tâl (talk) 22:45, 4 February 2019 (UTC)
Thanks for the reply. Unfortunately I have no clue what to do.— Ineuw talk 01:05, 5 February 2019 (UTC)
However, I found more information on this Mediawiki page.— Ineuw talk 13:38, 5 February 2019 (UTC)

Is this standard procedure?[edit]

I was validating this page and noticed the proofreader re-arranged it so that the image doesn't divide the paragraph as in the original source document. Sounds reasonable, but I thought I'd run it by you guys to make sure this is the correct procedure. Abyssal (talk) 20:10, 7 February 2019 (UTC)

It varies by text; there is no uniform standard for this. In this work, there is high density of images, and thus a danger of placing images on consecutive pages together in ways that break the formatting. The original places images in the vertical center of pages (regardless of section or paragraph breaks), which is a feature that cannot be replicated in an electronic format, and which is not desirable when this results in the apparent random breakage of paragraphs. The two of us who worked on the initial text agreed that repositioning some of the images was a good compromise, and would better preserve the integrity of the text. --EncycloPetey (talk) 20:16, 7 February 2019 (UTC)
@EncycloPetey:Makes sense. On this specific page, though, I am kind of concerned that the image isn't listed under the section that discusses it. Am I making too big a deal of things? Abyssal (talk) 01:44, 8 February 2019 (UTC)
More than a few of the images, as published, were not in the section that discusses them. All images are referenced by number from the text, and this image comes immediately before the text that makes reference to it. The alternative would be to move the image and thereby to break the opening paragraph of that section into two separate paragraphs. --EncycloPetey (talk) 02:13, 8 February 2019 (UTC)
@EncycloPetey:What about placing it under the section heading but before the text? Abyssal (talk) 03:10, 8 February 2019 (UTC)
That would look really, really odd. The section heading would look like an image caption instead of a section heading. There's a reason that publishers avoid doing that. --EncycloPetey (talk) 03:23, 8 February 2019 (UTC)
@EncycloPetey:Alright. I'll defer to your judgement and just validate that page and similarly formatted pages. Abyssal (talk) 05:19, 8 February 2019 (UTC)

template improvements needed? Auxiliary Table of Contents[edit]

Anyone who knows about template programming, please take a look at this. As you can see, when you use {{TOC line}} and {{Dotted TOC line}} in {{Auxiliary Table of Contents}}, the background color doesn't match. Can this be fixed? Thanks Levana Taylor (talk) 20:42, 9 February 2019 (UTC)

Is there some reason that the illustrators need to be listed as a separate column in an Auxiliary ToC? --EncycloPetey (talk) 22:30, 9 February 2019 (UTC)
I discussed that in the first post of this thread. The reason is that I am exactly imitating the format the magazine used to announce their contents in their advertisements (though the advertisement contents can't be used as a substitute TOC because they're not complete and in order). True, it's not necessary ...
Even if I wasn't using two columns I would still need {{TOC line}} in order for hanging indents to work properly. Plus, other people have combined these templates. Levana Taylor (talk) 22:54, 9 February 2019 (UTC)
I think I solved the clolour problem with TOC line by setting the background for transparent instead of white. It seems more difficult with the Dotted TOC line, as the dots would become visible through the text too. The only solution I have is to add another parameter that would enable to change the background colour if the template is used within the Auxiliary TOC, see my experiment at Dotted TOC line/sandbox. --Jan Kameníček (talk) 08:59, 10 February 2019 (UTC)
It was never intended that the TOC templates as used in the Page: namespace would be used in the AuxTOC template, which is why combining them is being problematic. For the hanging indent spacing problem, you'll need to use a single {{hi}} for all the lines, not just the ones that are longer. For the dotted TOC lines, I suggest that you'll need to consider a different format. Remember that AuxTOC is a construct by us to make a work more easily navigble in the absence of a printed TOC, so it's OK to do things in a pragmatic way that works within the confines of what it's capable of. Beeswaxcandle (talk) 09:17, 10 February 2019 (UTC)
The problem is that Dotted TOC Line depends on the z-index property and a solid background to hide the extraneous dots behind the text; and in CSS backgrounds are not inherited. To fix this you would need to ensure that every single HTML element between the green background and the div that's currently set to white had an explicit "inherit" value. It would probably be better to simply reimplement the dotting functionality into AuxTOC directly. But caveat, I haven't actually looked at how the dotted toc line template actually achieves its effect so that may be a tall order. --Xover (talk) 09:43, 10 February 2019 (UTC)
@Beeswaxcandle:: You're absolutely right, the TOC looks vastly better if I don't use AuxTOC but instead recreate a similar effect using {{border}} with a white background. Levana Taylor (talk) 11:28, 10 February 2019 (UTC)

TemplateScript for Greek beta code[edit]

I created a TemplateScript tool for entering Greek text using w:Beta Code. If anyone wants to use or improve it, it's at User:Beleg Tâl/Beta.jsBeleg Tâl (talk) 03:23, 11 February 2019 (UTC)

Tech News: 2019-07[edit]

18:45, 11 February 2019 (UTC)

Wikidata Edit section on the sidebar[edit]

On the sidebar, I would like to either place the Wikidata Edit section below the Tools section, or hide it? Would someone have a script which I could copy? Thanks in advance. — Ineuw talk 00:10, 14 February 2019 (UTC)

pst, you could also try out timeless skin, which moves sidebar menu to the top (as you zoom in), and puts edit in upper right. yrmv. Slowking4SvG's revenge 00:10, 18 February 2019 (UTC)

Dynamic layouts...[edit]

Is there someone dedicated that could write an explanation of how the page numbering script interacts with LST and proofread page?

I'm asking because I wanted to make a suggestion on how to possibly solve certain problems, but needed to know a little bit more about the internals to do it, to be sure if the fix was an appropriate one. ShakespeareFan00 (talk) 20:03, 14 February 2019 (UTC)

The relevant portion of the page numbering java-script makes reference to a number of CSS classes. ( or overrides), that are defined upon various aspects of page display. Is there a diagram explaining the Hireachy of what gets generated for each layout? ( There are references made to page and region container classes for example?)

ShakespeareFan00 (talk) 20:18, 14 February 2019 (UTC)

Cleaning up Once a Week namespace[edit]

Right now the namespaces for Once a Week are chaotic, because in the past some of the articles were created stating the volume number in Roman numerals and some in Arabic numerals (the existing parts of Volume IV are half-and-half). I think they should all be Roman numerals, since that is how the magazine itself does it. I started trying to clean it up but I was just making myself confused and introducing errors; so can a bot fix this? Change all pagenames and links using an Arabic-numbered volume to Roman-numbered? (Or vice versa, even, it just ought to be consistent.) Levana Taylor (talk) 03:19, 17 February 2019 (UTC)

The preference on Wikisource is usually for Arabic numbering, unless there is some reason to do otherwise. Arabic numbering will sort properly, and be more easily handled with linking. Roman numerals have the disadvantage that they sort alphabetically, not numerically, so for large works with many parts or sections, Arabic numbering is probably the better way to go. --EncycloPetey (talk) 04:26, 17 February 2019 (UTC)
I agree that it would make the pagenames easier to handle if they were numbered in Arabic numerals. What is needed in that case is for someone (a bot?) to find and fix pagenames and links that currently use Roman numerals. Some of those I created myself (sorry) but some were there before me.
Nonetheless, all the existing headers (whatever the numbering in the pagename) are piped to display Roman numerals for the volumes. I think this makes sense.
The only remaining thing needed, in that case, is a modification of {{Once a Week link}}. It should display volume numbers as Roman numerals even though they would be entered as Arabic numerals. (Plus, unrelatedly, that template needs to be modified to allow displaying the "article" parameter as the visible title rather than having "link" override "article" the way it does now.) Levana Taylor (talk) 05:14, 17 February 2019 (UTC)
Can I offer a time swap? If someone will take care of finding and correcting all Roman numerals in Once a Week, I'll spend a few hours on some tedious task you don't want to do. Levana Taylor (talk) 16:03, 18 February 2019 (UTC)
The best place to seek Bot help is to post at Wikisource:Bot requests, because that it where people expect to see requests for help that requires a Bot. --EncycloPetey (talk) 16:12, 18 February 2019 (UTC)
Also check the sandbox for {{Article link/sandbox}} , I put something there that may be of interest. ShakespeareFan00 (talk) 16:35, 18 February 2019 (UTC)
@EncycloPetey:: Thanks, will x-post.
@ShakespeareFan00:: Is that intended to display the volume as a Roman numeral? It doesn't seem to be working. Levana Taylor (talk) 21:22, 18 February 2019 (UTC)
Did you specify the additional option? ShakespeareFan00 (talk) 21:23, 18 February 2019 (UTC)
Thanks - Template:Article_link/testcases#Volume/issue ShakespeareFan00 (talk) 21:26, 18 February 2019 (UTC)
The "roman_vol" parameter is great! (Just what I was thinking of.) Did you intend to change the quotes around the title to curly, though? Levana Taylor (talk) 23:20, 18 February 2019 (UTC)
The template code changes are in the sandbox because it would need an interface admin to review and update the main template. did you want roman_iss function as well?ShakespeareFan00 (talk) 12:45, 19 February 2019 (UTC)
That'd probably be a good idea, although it's very rarely used. I can think of just one magazine offhand that didn't have volumes but did number its issues I, II, etc.Levana Taylor (talk) 18:26, 19 February 2019 (UTC)

OCR button is non functional...[edit]

Was attempting to use the OCR button , to get the OCR text for a page - It generated the following error - "ws_ocr_daemon robot is not running. Please try again later."

Can someone reboot the bot responsible? Thanks. ShakespeareFan00 (talk) 11:18, 17 February 2019 (UTC)

Tech News: 2019-08[edit]

23:14, 18 February 2019 (UTC)