Wikisource:Scriptorium/Archives/2018-05

Copyright question

Hi, I found the text for a novel published in 1863. The author died more than 100 years ago, but the edition of the book I found was published way later. The prologue is obviously copyrighted, because it was written for the new edition. However, the text of the novel itself is in the public domain. Can this edition be used as a source (only for the text of the novel, of course)? As I said, the novel was originally published in 1863 and the author died in 1905. --Freddy eduardo (talk) 14:48, 4 May 2018 (UTC)

Have you looked on the Internet Archive for a scan of an earlier edition? Or the Hathi Trust? Wikisource prefers to have copies of works backed by a scan. I would offer to help, but I do not know the title or author, as you did not provide the details. --EncycloPetey (talk) 16:29, 4 May 2018 (UTC)

@EncycloPetey: Here is the edition I found: [1] (hosted at archive.org). As you can see, that edition is from 1974, so the prologue is copyrighted. I searched for a scan of the original 1863 edition but I couldn't find it anywhere (the novel is in Spanish, I plan to upload it to the Spanish Wikisource, but there are not many active users nowadays over there so that's why I'm asking here). Can I upload the text of the novel and link to that edition as a source? Thanks for the help--Freddy eduardo (talk) 19:28, 4 May 2018 (UTC)

@Freddy eduardo:, I don't think there would be a problem with Wikisource policy in transcribing the text as you describe (leaving out the prologue). But the potential problem would be in the upload of the PDF file. You may wish to bring this up at commons:Commons:Village pump/Copyright. One possibility would be to create a new PDF file leaving out the copyrighted pages, but you might need specialized PDF software to do that. Hope this helps. -Pete (talk) 19:50, 4 May 2018 (UTC)

HathiTrusts works by that author are all recent and not viewable. You can take this edited version; I don't read Spanish, so I may have overcut or undercut. (That's a temporary link, so copy it if it's useful.)--Prosfilaes (talk) 21:40, 5 May 2018 (UTC)

did not find first edition on worldcat, so finding it to scan it would be hard. maybe a query at national library. Slowking4 ‽ SvG's revenge 23:56, 5 May 2018 (UTC)

Centralised hacking attempts

A centralised hacking attempt, targeting wiki user accounts is going on, WMF is also aware, see here. Many of my colleagues in Indic projects, including myself, have been targeted. Same may be the experience with many users here. Targeted users will receive failed log-in attempt alert from English Wikipedia (mainly) and also email. Better to secure your accounts by strengthening the password and also going for 2-Factor-Authentication (2FA). Admins (in at least one wiki site) can enable 2FA for themselves. Non-admins can request at m:Steward requests/Global permissions. Hrishikes (talk) 03:00, 4 May 2018 (UTC)

Me as well, earlier this morning. Several attempts. I left a message at my WP user page for 'whomever'. Wondered if it affected anyone else as well. Londonjackbooks (talk) 03:07, 4 May 2018 (UTC)

Likewise, but I had only one attempt this morning. --EncycloPetey (talk) 03:39, 4 May 2018 (UTC)

Me too: around 21:00 UTC on 3 May (or 00:00 on 4 May if of Moscow Time) I also got message from English Wikipedia about one failed attempt to log in to my account. So it seems to be that it was a true mass attack to indiscriminately random users, if even I, who doesn't belong to English-speaking world, also was attempted to be attacked in English Wikipedia. --Nigmont (talk) 22:02, 4 May 2018 (UTC)

Looks like Wikipedia underwent another mass attack. --EncycloPetey (talk) 14:44, 7 May 2018 (UTC)

AdvancedSearch

From May 8, AdvancedSearch will be available as a beta feature in your wiki. The feature enhances the search page through an advanced parameters form and aims to make existing search options more visible and accessible for everyone. AdvancedSearch is a project by WMDE Technical Wishes. Everyone is invited to test the feature and we hope that it will serve you well in your work!

Birgit Müller (WMDE) 14:45, 7 May 2018 (UTC)

Advanced search form now available through beta preferences. — billinghurst sDrewth 14:12, 8 May 2018 (UTC)

Tech News: 2018-19

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

Recent changes

• The Wikimedia Commons mobile app has a new version. It is now easier to find nearby places that need pictures. It helps you with direct uploads and title and category suggestions. The app only works on Android phones. [2]

Problems

• The abuse filters had a problem with blocks where you had changed how long they last. It used the default length everywhere. This was in late April. Abuse filter users should make sure the right block length is used and change them if needed. This is only for filters where how long blocks last had been changed. [3]

Changes later this week

• The advanced search function beta feature will be on all Wikimedia wikis. It makes it easier to use some of the special search functions that most editors don't know exist. [4]
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 8 May. It will be on non-Wikipedia wikis and some Wikipedias from 9 May. It will be on all wikis from 10 May (calendar).

Meetings

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

Future changes

• All wikis with fewer than 100 high-priority linter errors in the main namespace will switch to use the Remex parsing library. This is to replace Tidy. It will happen on 16 May. Other wikis will switch soon when they have fixed the errors that must be fixed. Tidy will be removed on all wikis before July 2018. [5][6]

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

16:27, 7 May 2018 (UTC)

Comment

• Special:LintErrors as of 20180507

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).

 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? [7] -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?

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

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

Recent changes

• Dynamic maps are now available on most Wikipedias. Labels on maps can also be in different languages.
• The new Advanced Search interface is now available as a Beta Feature on all wikis. This makes it easier to learn about and to use many of the powerful options in our search. Feedback is appreciated. [8]

Changes later this week

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

Meetings

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

Future changes

• In the mobile view, warnings for when something is wrong with a page are not as clear as they should be. The developers are working on this. You can give feedback and suggestions.
• The developers are working on making the Wikipedia Android app available in more languages. You can give feedback, suggestions and help test it. Read more on mediawiki.org [9]

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

22:22, 14 May 2018 (UTC)

LIFE magazine

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.

Links to issues in question

• v16n01
• v16n02
• v16n03
• v16n04
• v16n05
• v16n06
• v16n07
• v16n08
• v16n09
• v16n10
• v16n11
• v16n12
• v16n13
• v16n14
• v16n15
• v16n16
• v16n17
• v16n18
• v16n19
• v16n20
• v16n21
• v16n22
• v16n23
• v16n24
• v16n25
• v16n26
• v17n01
• v17n02
• v17n03
• v17n04
• v17n05
• v17n06
• v17n07
• v17n08
• v17n09
• v17n10
• v17n11
• v17n12
• v17n13
• v17n14
• v17n15
• v17n16
• v17n17
• v17n18
• v17n19
• v17n20
• v17n21
• v17n22
• v17n23
• v17n24
• v17n25
• v17n26

-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)

Comic History of England

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)

Done and dab created. Beeswaxcandle (talk) 07:25, 16 May 2018 (UTC)

Mark proofread gadget

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?

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

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.

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)

Added gadget to sort Special: pages output

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)

Page number corrections in {{dotted TOC line}} template.

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

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

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

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

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 22 May. It will be on non-Wikipedia wikis and some Wikipedias from 23 May. It will be on all wikis from 24 May (calendar).

Meetings

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

Future changes

• It could become easier to reference different pages of a book in an article. You can give feedback. The last day for feedback is 27 May.

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

17:33, 21 May 2018 (UTC)

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

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)

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

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. [10] -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

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)

The Popular Science Monthly Project

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

Requesting input on the main namespace titles with Roman numerals

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

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

Recent changes

• You can now use global preferences on most wikis. This means you can set preferences for all wikis at the same time. Before this you had to change them on each individual wiki. Global preferences will come to the Wikipedias later this week. [11][12]
• It is now easier for blocked mobile users to see why they were blocked. [13]
• Wikidata now supports lexicographical data. This helps describe words.
• There is now a checkbox on Special:ListUsers to let you see only users in temporary user groups. [14]
• Some rare invisible Unicode characters have recently been banned from page titles. This includes soft hyphens (U+00AD) and left-to-right (U+2066) and right-to-left (U+2067) isolate markers. Existing pages with these characters will soon be moved by a script. [15]
• There's a new Wikimedia Foundation team to support the Wikimedia technical communities. It's called the Technical Engagement team. Most of the team members did similar work in other teams before this. [16]

Problems

• Some translatable pages are showing old translations instead of latest ones. The cause of this issue has been fixed. We will update all pages automatically to show the latest translations. [17]

Changes later this week

• There will be a new special page named PasswordPolicies. This page gives information about the password rules for each user group on that wiki. [18]
• A new way to see moved paragraphs in diffs is coming to most wikis. This is to make it easier to find the moved paragraphs and the changes in them. [19]
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 29 May. It will be on non-Wikipedia wikis and some Wikipedias from 30 May. It will be on all wikis from 31 May (calendar).
• Wikis can enable Citoid to provide automatic reference look-up in the visual editor and the 2017 wikitext editor. This is complex. The tool will now disable itself if the configuration isn't correct. It has warned about this in the JavaScript console since February. Check that your wiki is configured correctly. You can ask for help if you need it. [20]

Meetings

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

Future changes

• Content Translation drafts which have not been updated in over a year will be removed. This allows other users to translate those articles. [21]
• A survey is collecting information on what users think about how Wikimedia wiki pages are loaded. This information could be used in future development. [22]
• Some wikis will switch to use the Remex parsing library. This is to replace Tidy. It will happen on 30 May and 13 June. Wikis with fewer than 100 linter issues in the main namespace in all high-priority linter categories will switch. This includes Wikidata. Tidy will probably be removed on all wikis in the first week of July. [23][24]

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

12:40, 29 May 2018 (UTC)

Text of the new Swedish "negligent rape" law

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)