Wikisource:Scriptorium

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

Contents

Announcements[edit]

Added gadget to sort Special: pages output[edit]

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

The Popular Science Monthly Project[edit]

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

PSM project home page

Some statistics:

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

Proposals[edit]

Bot approval requests[edit]

Repairs (and moves)[edit]

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

Strip google notices[edit]

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

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

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

Comic History of England[edit]

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

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

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

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

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

Statutes at large Missing pages[edit]

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

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

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

Index:Coloured Figures of English Fungi or Mushrooms.djvu[edit]

Can someone swap the scans for Page:Coloured Figures of English Fungi or Mushrooms.djvu/1102 and Page:Coloured Figures of English Fungi or Mushrooms.djvu/1101 which seem to be in the wrong order? and swap the transcription on those pages as well? Thanks. ShakespeareFan00 (talk) 21:56, 20 June 2018 (UTC)

Other discussions[edit]

Page images errors - FIXED![edit]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tech News: 2018-20[edit]

22:22, 14 May 2018 (UTC)

LIFE magazine[edit]

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

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

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

Mark proofread gadget[edit]

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

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

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

Noun Project author icon 1642368 cc.svg

Dear all

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

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

Thanks very much

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

Lint fsx[edit]

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

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

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

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

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

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

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

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

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

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

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

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

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

Sorted through gadgets[edit]

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

Tech News: 2018-21[edit]

17:33, 21 May 2018 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

Tech News: 2018-22[edit]

12:40, 29 May 2018 (UTC)

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

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

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

Introducing Toolhub[edit]

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

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

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

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

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

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

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

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

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

{{double link}} across pages[edit]

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

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

Tech News: 2018-23[edit]

21:54, 4 June 2018 (UTC)

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

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

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

Image problems when editing[edit]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Lillypond scoring[edit]

Statutes of the Realm[edit]

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

&aelig;[edit]

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

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

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

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

Problem with page display[edit]

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

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

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

Broadcasting Act 1981 (United Kingdom)/Schedule7

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

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

Formatting UK legislation..[edit]

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

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

Page status buttons[edit]

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

{{Rule}} not centering?[edit]

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

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

Tech News: 2018-24[edit]

21:55, 11 June 2018 (UTC)

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

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

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

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

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

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

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

Update on page issues on mobile web[edit]

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

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

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

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

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

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

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

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

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

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

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

A Lost Lady[edit]

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

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

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

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

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

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

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

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

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

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

Excerpting stories from long subpages[edit]

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

I would not make supplementary transclusions. I would either use anchors as currently used, or break up the subpages into sub-subpages, using {{AuxTOC}} as necessary (example). If each tale can be considered a work per se, and it seems like they can be in this case, then I would encourage creating translation pages or redirects regardless. —Beleg Tâl (talk) 10:37, 18 June 2018 (UTC)
@Beleg Tâl: thanks for the suggestions. Splitting into sub-subpages would be of limited usefulness since many of the stories are in the endnotes, sometimes more than one story in a single endnote. I've made a translations page for Thirteenth and recorded that in Wikidata. So now I'd like to ask, should links from the Author page (in this case Author:Giuseppe Pitrè) and the Wikipedia pages preferably go to this translations page, or straight to the location on the book's subpage? Also, I linked the title of the tale on the book's subpage to the translations page, which seemed to be the most obvious pathway to the related Wikipedia and Author pages. I'll need to put a note in the header explaining what the links are for. — Mudbringer (talk) 12:01, 18 June 2018 (UTC)
A {{translations}} page has typically been to disambiguate multiple works, so historically we would not have created such a page and listed one item. [That said that practice/approach eventuated prior to WD when we have coordinated interwikis, and to where we would indeed place the interwiki for the conceptual item.] In the examples that you provide, if we are not going to separate transclusions, I think that this methodology is the means to find the balance. — billinghurst sDrewth 22:22, 18 June 2018 (UTC)

Tech News: 2018-25[edit]

21:47, 18 June 2018 (UTC)

Template:Plain sister and bibliowiki[edit]

I have updated Wikilivres visual presentation through {{plain sister}} (template and module) to now be Bibliowiki. I think that I got it working fine, please report any problems back here and ping me. Thanks. I think that completes the presentation space. There are still mentions in templates, and editors should feel comfortable in changing parameters to use bibliowiki, and again if any problems, please report back here. — billinghurst sDrewth 03:22, 19 June 2018 (UTC)

Lint filter fix for float right, somewhat counter-intuitive—others check/replicate?[edit]

I think that I have found the solution to {{float right}} pages showing up in the lint filter. Starting the span containing "float right" at the start of the paragraph, before all the text to which it will float, and it seems to resolve from my couple of trials. If others confirm that is the case, then we can have another tick for our resolution processes. — billinghurst sDrewth 10:55, 19 June 2018 (UTC)

@Billinghurst: Could you provide some specific examples of what you're describing. I don't follow what you're saying, and believe it might be at odds with situations where float right needs to be at the end of a paragraph for dramatic works. --EncycloPetey (talk) 15:24, 19 June 2018 (UTC)

"New texts" -- reasons[edit]

I think there's a great deal of thought that goes into the decisions we make about what works to transcribe, but it's largely invisible, both to us Wikisource editors and to the world at large. I imagine that reasons might vary from "my dad loved this book, and I always wondered why" to "I think it's important to civilization that more people read this essay" to "this poet's style is mostly forgotten" to "this is a horrible and misunderstood piece of propaganda, and I think everybody should have the chance to evaluate it themselves."

I'm curious if others might like to see a few words -- or perhaps a field for a link to a page in user space -- under the "new texts" section. Perhaps an optional field.

Do others share this curiosity about our fellow editors' reasoning? Are there other ways we could make it more apparent to our readers or one another? Apart from technical requirements or layout considerations, what do you all think of finding a way to make this more visible? -Pete (talk) 22:21, 19 June 2018 (UTC)

This sounds to me more like something to be printed in a newsletter than something to be linked in the New Texts. --EncycloPetey (talk) 00:49, 20 June 2018 (UTC)
There appears to be some form of discussion at Template talk:New texts. I think OP was pointing towards something more akin to the kind of process used on the WP main page, for example the Did you know section. Whether we should copy that (or do something even remotely similar) is of course debatable, but that particular example is in itself a "rough starting point", since the purpose of both pages/templates seems to be "To showcase new and improved content, illustrating to readers the continuous improvement and expansion of Wikipedia's [or in our case, Wikisource's] corpus of articles [...];". 198.84.253.202 03:24, 20 June 2018 (UTC)

Edit size/'wrong diffs"?[edit]

Can anybody explain what this is? The only change I actually did was add the </poem> tag which was missing at the end. Yet, for some reason, the page history shows a change of -114 bytes, and the diff of course shows the addition of quotation marks (") around the section begin and section end tags, which oddly enough are not even on the page, there's simply a ## hymnal85 ## at the top. 198.84.253.202 03:13, 20 June 2018 (UTC)

The hashtags are the "wiki-friendly" display form for a section start. The sudden drop in page size may reflect some hiccup from the last time the page was edited. From time to time the system seems to vastly overestimate the size of a page, and a subsequent edit returns the size to its correct value. --EncycloPetey (talk) 03:39, 20 June 2018 (UTC)
My guess is that the website back end software (MediaWiki) changed how they calculate the length of pages since 2013, and editing old pages that uses the header/body/footer format will cause the incorrect size difference. And the additional quotes is probably how MediaWiki wants to represent the section tags now which isn't visible on the edit page except through the hashtags. So 198.84.253.202, it's nothing to worry about, you didn't remove any text. --Riley AJ (talk) 04:09, 20 June 2018 (UTC)
I wasn't worried, just curious. By my (short) investigation, the earliest edit which I can confirm beyond all doubt has this kind of page size change is from December 2013 (-116 bytes), while the latest edits I can find which don't have it are from September 2013 (+82 bytes). Of course, that is from a very small sample (with only sporadic activity). I haven't bothered to check further to see if the date can be pinpointed more accurately. A browse through the archives looking for "size" does not yield anything about this between October and December of that year. Overall, a minor change which seems to have been mostly unnoticed. 198.84.253.202 05:02, 20 June 2018 (UTC)
Changes in how proofread page operates means that some code that was there is redundant and was removed with that edit. — billinghurst sDrewth 07:56, 20 June 2018 (UTC)

OCR for Persian[edit]

Hey librarians! I know that it is not the right place to ask this but I’m not sure I could find an answer in another place. Is it possible someone could turn on Google OCR for the Persian wikisource (fa.wikisource.org)? We are in desperate need of that. Now the users are taking pictures of the pages and upload them to their Google Docs. Then import the pages into a Google document, and then Google OCRs the picture. The precision is so good that it's worth the hurdle. But the process is long. Can anyone help? --Yousef (talk) 05:50, 21 June 2018 (UTC)

@Yoosef Pooranvary: Add this line in your Mediawiki:Common.js:
mw.loader.load('//wikisource.org/w/index.php?title=MediaWiki:GoogleOCR.js&action=raw&ctype=text/javascript');
--Hrishikes (talk) 17:23, 21 June 2018 (UTC)
@Hrishikes: is there a proper way to use it on two columns documents ? like Index:An Ainu-English-Japanese dictionary (including a grammar of the Ainu language).djvu ? Assassas77 (talk) 08:57, 23 June 2018 (UTC)
@Assassas77: See Google ocr result on this page. -- Hrishikes (talk) 09:12, 23 June 2018 (UTC)
Hmmm, the OCR does help a bit but the result must be edited to be split in two column then. Okay ! Assassas77 (talk) 09:15, 23 June 2018 (UTC)

Abbreviations in reference works[edit]

Is it acceptable to expand abbreviations when transcribing reference works such as dictionaries? I know that ideally we would try to be faithful to the source material, but some entries have so many abbreviations as to be unintelligible out of context (see diff).--Underlying lk (talk) 15:41, 21 June 2018 (UTC)

No. We strive to present works as they were published. Mass altering of text would not be desirable. However, once the original text exists here in a scan-backed form, it is reasonable to then add a separate copy of the work which has been "annotated", such as by expanding the abbreviations. Draft policy of this can be found at Help:Annotating, but there isn't much there. The key points to note are (1) there should be an original, unannotated copy here first, and (2) that the annotated version should make it clear that the text is annotated. For example, calling it "My Book (annotated)" or "The Annotated My Book" (where 'My Book' is the title of the original. --EncycloPetey (talk) 15:47, 21 June 2018 (UTC)
@Underlying lk: As EP said, no, we wouldn't; it doesn't represent the work as published, AND it just makes it harder to accurately proofread. That doesn't stop us from doing a couple of things. 1) If there are not very many, we can transclude them into the notes section. 2) If they are expressed on a list on a page, putting a wikilink into the notes section that points to the abbreviations. — billinghurst sDrewth 01:34, 22 June 2018 (UTC)
Follow-up. I see that we have Page:An Etymological Dictionary of the German Language.djvu/21 and Page:An Etymological Dictionary of the German Language.djvu/22 pages that would we would transclude to "name of work/List of Abbreviations]]" probably as a separate page, so typically when we build the transcluded pages we would have a header note "see [[../List of Abbreviations/]]" as this sort of relative link that is such a pointer. — billinghurst sDrewth 01:42, 22 June 2018 (UTC)
Good idea, adding a link to the abbreviations surely can't do harm.--Underlying lk (talk) 02:06, 22 June 2018 (UTC)
I've been thinking about this for some time. How about adding the expanded word in tooltip form, as {{SIC}} is used for example, we could have the best of both worlds. When you hover over the world it will give you the full word.Jpez (talk) 08:57, 23 June 2018 (UTC)

Lippincott pdf files[edit]

I have downloaded several pdf's directly from google. I would like to begin uploading them but was encouraged to come here to check on protocol and first pages and the like.--RaboKarbakian (talk) 16:40, 21 June 2018 (UTC)

@RaboKarbakian: pdf files are not as obedient as djvu files when it comes to transcription, and Google has a shocker of an additional front page (and one that troubles Commons-netizens); which is why we initially and normally push files to InternetArchive then use toolforge:ia-upload to bring in a djvu without the horrid front page. — billinghurst sDrewth 01:53, 22 June 2018 (UTC)
@Billinghurst: I don't think they are there, with the exception of one of them. The tool to strip the first page is ia-upload, isn't it?--RaboKarbakian (talk) 01:55, 22 June 2018 (UTC)
@Billinghurst: If you can point me to where the netizens have complained, I might be able to handle their complaints when they come for me.--RaboKarbakian (talk) 04:09, 22 June 2018 (UTC)
This is not about winning the argument, as we have beaten it to a standstill, and currently looking for a tool to resolve, so it is preventing the further occurrences of the problem, preferably. Yes, IA-upload is the upload tool that enables the removal at the upload phase. PDFs can be problematic, greatly more so than djvus. We developed the process to this solution as it worked better. Lived and learned experience. — billinghurst sDrewth 08:47, 22 June 2018 (UTC)
One half (that is a guess, not calculated -- it might be closer to one third) of the djvu I have gotten from ia have ocr pages missing or are off by one or two or more pages. I try to be as picky as possible about raw materials, but am hesitant to put the documents through another electronic sieve. I truly would like to read a or the discussion which is one of the advantages of 1) a wiki and 2) people working together. To increase my own knowledge and understanding and also to know the user names of the people who find this important enough to discuss.--RaboKarbakian (talk) 13:48, 22 June 2018 (UTC)
DjVu is a free and open format, produces small files optimised for text, and works with the software. Any problems with a djvu file probably results from poor scans, like the 'needs more jpeg' google file conversions out there. There is an essay Wikisource:DjVu vs. PDF, and some of the related discussion in links to that page, but sooner or later users come to the same conclusion. CYGNIS INSIGNIS 19:24, 22 June 2018 (UTC)
This discussion is about files that are just not worth converting. Very few images. The OCR is fine enough. I am not going to argue ever for pdf over djvu. The extra step to convert pdf into djvu because djvu is a more preferred format is a different matter.
Instead of this, cygnis who used to have that annoying statue on your page, we should be discussing Lang.--RaboKarbakian (talk) 20:44, 22 June 2018 (UTC)