Wikisource:Scriptorium/Archives/2018-09

Please do not post any new comments on this page. This is a discussion archive first created in September 2018, although the comments contained were likely posted before and after this date. See current discussion or the archives index.

Announcements

Initiative for coordinating documentation, practices and solutions of misc. Wikisource versions

Hello, everybody is invited to participate in the project of coordinating documentation, practices and solutions of misc. Wikisource versions. Although the page itself is only in English so far, all comments in any language are welcome in the talk page and will integrated in the page thereafter. It will also be internationalized once enough attention will have been dedicated to it. Thank you in advance for all your contributions, and please be bold to spread the word everywhere you feel apropriate. Cheers, Psychoslave (talk) 03:20, 14 August 2018 (UTC)

Growth team is looking for your feedback and ideas

Hello!

Have you heard about Growth team?

The Growth Team's objective is to work on software changes that help retain new contributors in mid-size Wikimedia projects. We will be starting with Wikipedias, but we hope these changes will benefit every community.

We are contacting your project today, because you may be interested by what we work on.

8 ideas we consider: tell us what you think about them!

We are considering new features to build, that could retain new editors in mid-size Wikipedias. We will be testing new ideas in Czech and Korean Wikipedias, and then we'll talk to more communities (yours!) about adopting the ideas that work well.

We have posted the 8 ideas we are considering. We would really appreciate your thoughts and the thoughts from your community. Please share the ideas, and tell us what do you and your community think of those ideas before September 9.

Share your experiences with newcomers

We want to hear about what is working and what is not working for new contributors in your wiki. We also want to hear any reactions, questions, or opinions on our work. Please post on the team’s talk page, in any language!

Learn more about us

You can visit our team page to find out why our team was formed and how we are thinking about new editors, and our project page for detailed updates on the first project we'll work on.

Get updates on your project page

The Growth team's newsletter will provide updates regularly. You can subscribe to it.

On behalf of the Growth team, Trizek (WMF) (talk) 17:41, 27 August 2018 (UTC)

Repairs (and moves)

Index:Her Benny - Silas K Hocking.djvu and pages

It's been moved to File:Her Benny - Silas K Hocking (Warne, 1890).djvu. Prosody (talk) 23:12, 1 September 2018 (UTC)

What needs to be done (and why isn't it handled automatically)? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:03, 2 September 2018 (UTC)

Since the work was proofread before the file was moved, all of the pages exist using the name of the original file. Someone needs to do a bulk page move to shift the pages to the correctly named file. This is why we try to do all work "fixing" the underlying file before the pagelist is added and the work is listed as 'ready for proofreading'. --Mukkakukaku (talk) 18:23, 2 September 2018 (UTC)

Other discussions

N-like character

What is the penultimate character, in "BRÂHMANA" / "Brâhmanas", in Page:Sacred Books of the East - Volume 12.djvu/11 and oher pages of that work? en.Wikipedia renders the word as "Brāhmaṇa". Note also "ā" vs. "â". Which should we use? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:42, 24 August 2018 (UTC)

It's just an italic N. The author's choice of notation should be followed, so Brâhmana is the preferred option here. —Beleg Tâl (talk) 22:05, 24 August 2018 (UTC)

The initial "s" in SATAPATHA is also italicized. --EncycloPetey (talk) 00:02, 25 August 2018 (UTC)

Link spans two DjVu pages

The last words at the end of Page:The Cambridge History of American Literature, v4.djvu/18 and the first word of Page:The Cambridge History of American Literature, v4.djvu/19, taken together, are the title of a work, which should form a single HTML link in the final rendered page. How is this to be achieved? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:43, 25 August 2018 (UTC)

The templates to use are {{linkable phrase start}} and {{linkable phrase end}}. —Beleg Tâl (talk) 11:56, 25 August 2018 (UTC)

Or utilise the footer on the first page to put the text to be melded, then judicious use of <includeonly> with the respective text, on the second page. — billinghurst sDrewth 01:26, 27 August 2018 (UTC)

Using gadget to create an index page

I have uploaded a DjVu file to Commons, and am trying to create the corresponding index page here. I have enabled the "gadget to auto-populate fields from the File: at Commons", but cannot see how to use that gadget when I'm on the Index creation page. Should it activate automatically? (If so, why is it not?), or should there be a button or link to invoke it? (If so, where?). I have checked all the relevant help pages, but could not find anything on this. I have also double-checked my spelling of the file name. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:32, 25 August 2018 (UTC)

I use the link provided from the book template on the djvu file at commons and open the source index page. Then I get this daunting page that feels like failure (about how the page doesn't exist, blah blah blah). I use the "Create" or "Create this page" link located at the upper portion of the failure page and if I could spell walah.... The index page that occurs will need some help, but it is pretty cool how the gadget works.--RaboKarbakian (talk) 15:07, 25 August 2018 (UTC)

If you have the {{book}} (preferable) or {{information}} template completed at Commons, when you create (action on your part) the Index page will be populated with the appropriate corresponding data fields. — billinghurst sDrewth 06:55, 26 August 2018 (UTC)

I have done a little text edit to the gadget description to (hopefully) clarify the process. — billinghurst sDrewth 06:58, 26 August 2018 (UTC)

Editing of sitewide CSS/JS is only possible for interface administrators from now

(Please help translate to your language)

Hi all,

as announced previously, permission handling for CSS/JS pages has changed: only members of the interface-admin (Interface administrators) group, and a few highly privileged global groups such as stewards, can edit CSS/JS pages that they do not own (that is, any page ending with .css or .js that is either in the MediaWiki: namespace or is another user's user subpage). This is done to improve the security of readers and editors of Wikimedia projects. More information is available at Creation of separate user group for editing sitewide CSS/JS. If you encounter any unexpected problems, please contact me or file a bug.

Thanks!
Tgr (talk) 12:39, 27 August 2018 (UTC) (via global message delivery)

Tech News: 2018-35

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 see moved paragraphs in diffs in the mobile view. It also works on all languages in the desktop view. [1]
• Bureaucrats on all Wikimedia wikis can now remove the interface admin user right. [2]

Problems

• Some diffs show lines in the wrong order. The developers are working on fixing it. [3]

Changes later this week

• The message you see when you thank a user will change. This is to make it easier to understand. [4]
• AWB will stop adding using AWB in the edit summary. Instead it will add a tag that says AWB. [5]
• Some abuse filter variables have changed. They are now easier to understand for non-experts. The old variables will still work but filter editors are encouraged to replace them with the new ones. You can find the list of changed variables on mediawiki.org. They have a note which says Deprecated. Use ... instead. An example is article_text which is now page_title. [6]
• Abuse filters can now use how old a page is. The variable is page_age. [7]
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 28 August. It will be on non-Wikipedia wikis and some Wikipedias from 29 August. It will be on all wikis from 30 August (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 28 August 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 29 August at 15:00 (UTC). See how to join.

Future changes

• Because of a data centre test you will be able to read but not edit the wikis for up to an hour on 12 September and 10 October. This will start at 14:00 (UTC). You might lose edits if you try to save during this time. The time when you can't edit might be shorter than an hour. You can read more about this.

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

16:16, 27 August 2018 (UTC)

em-dash at page end

How do we deal with an em-dash at the end of a page, as on Page:Her Benny - Silas K Hocking.djvu/293? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 07:46, 28 August 2018 (UTC)

@Pigsonthewing: Reckon {{nop}} would work. Try transcluding this page and the next one in your sandbox and see how it looks. —Justin (koavf)❤T☮C☺M☯ 08:05, 28 August 2018 (UTC)

I understand that we want the text to render one one line, as "foo—bar"; surely {{nop}} would break that onto two lines? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:04, 28 August 2018 (UTC)

It is a new paragraph on the next page, so NOP it and reproduce as set—separate paragraphs. — billinghurst sDrewth 11:33, 28 August 2018 (UTC)

Ah so it is, in that case. But were it not? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:19, 28 August 2018 (UTC)

This is one of the times that the software ought not to render a space but does so anyway. Some people use {{linkable phrase start}} and {{linkable phrase end}}, but I think it would be better to have the software recognize what's happening and render it correctly. --EncycloPetey (talk) 13:58, 28 August 2018 (UTC)

@Pigsonthewing: If there is an em-dash at page end and next line on next page is to be continuous, say A—B, then do this: on first page: {{hws|A—|A—B|hyph=}}; on next page: {{hwe|B|A—B}}. That would work. Hrishikes (talk) 17:04, 28 August 2018 (UTC)

OR just put A— in the footer, and on the next page put either <includeonly>A—</includeonly>B or use {{hwe}}, all just system tricks. We have the templates to help explain the process to newbies, though in terms of output, it is a more systematically complicated way, for experienced mediawiki users it is fine to use the tools available.

Are pages that "do not need to be proofread" transcluded now?

Hi to all! Recently I discovered, that pages for which the proofread status has been set as "This page does not need to be proofread.", seemingly are transcluded if they get into transclusion range set by expression <pages index="..." from= to= />. For example, this page: Domestic Encyclopædia (1802)/Potatoe: after page 434 (458 in the source file) — seemingly the next page is displayed (marked with sign [-] on the left side) though it has status "This page does not need to be proofread." As I remember from the past experience, some time ago such pages were not transcluded, they were simply ignored even if they got into transclusion range. And it looked reasonable because such pages, by the sense of this status, are not expected to have valid content which might be intended to be displayed. Why are such pages transcluded and displayed now? Is now the proofread software designed to work so? Or this is just a bug and will be fixed soon? --Nigmont (talk) 22:21, 29 August 2018 (UTC)

If a page is inlcuded in the <pages> it is transcluded. If it is an empty page then it will not display as it is empty and the page number will be hidden; if it has content, eg. an image or some other proofread text, then it will be display. — billinghurst sDrewth 12:56, 2 September 2018 (UTC)

The image (figure 1) is referenced in the article, why would you wish to exclude it? It would be proofread as normal, it simply lacks a page number. The page number is just our labelling, and has nothing to do with a page is transcluded or not — billinghurst sDrewth 12:59, 2 September 2018 (UTC)

Oh, I see the issue. The page numbering script excludes page numbers where they are squished out, and typically that is the first page that contains text or image, and the second is blank, here the blank page has the label, and the second has its label squished. In this case, simply use exclude= nnn to ignore the blank page and you will see that it will display fine. — billinghurst sDrewth 13:05, 2 September 2018 (UTC)

Errata listed in original document

Page:A Treatise of the Mechanical Powers - Motte - 1733.djvu/240 lists errata for the work of which that page is a part. I presume we do not correct the original text, but can we add footnotes or similar, so that the errors do not affect readers? Is there a guide, or an example, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:07, 2 September 2018 (UTC)

Correct that we don't emend it. We have used various means with regard to errata. DNB we have transcluded the errata to the bottom of the respective biographies. We have added links to errata, we have transcluded the errata into the notes field, often labelling the error with {{SIC}}. There is no exact right way. Examples, umm, digging them out from my edit pool is a challenge, often they are just part of doing the work. I would suggest a search for ERRATA in the main ns to see what you find. — billinghurst sDrewth 12:51, 2 September 2018 (UTC)

I did Highways and Byways in Sussex/Errata forever ago. — billinghurst sDrewth 12:52, 2 September 2018 (UTC)

for DNB there is a Template:DNB errata to transclude the errata section as a footer, i.e. Atkins,_William_(DNB00) see also Template:Errata -- Slowking4 ‽ SvG's revenge 21:44, 2 September 2018 (UTC)

Word order jumbled

The print quality in Page:Bird Haunts and Nature Memories - Thomas Coward (Warne, 1922).pdf/21 and others from that work is better than others I've worked on, yet the OCR results have words out of order. Is there anything that can be done to remedy this? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:17, 2 September 2018 (UTC)

@Pigsonthewing: Looks like a problem with the text layer in the source PDF (the text you see isn't usually OCR done on the fly; it comes from the original file, usually done at the time of scanning the paper book). If you use the "OCR" gadget in the toolbar (you may need to enable it first, I can't recall atm) you'll get much better results on that page. Not sure what backend it's using, but it redoes the OCR and replaces whatever text layer was in the original. --Xover (talk) 20:42, 2 September 2018 (UTC)

Yes, much better. Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:02, 2 September 2018 (UTC)

Bengali Wikisource Awareness Campaign videos

Hi, I am happy to announce that, three Bengali Wikisource Awareness Campaign videos have been released in Youtube channel of West Bengal Wikimedians User Group. This campaign was first such initiative to promote Wikisource among new readers.

The project was first placed in IdeaLab as part of Inspire Campaign and was later funded by Wikimedia Foundation rapid grant. The details can be found here.

Please do watch the videos. The English and Bengali subtitles are already there in Youtube and Commons.

Enjoy! -- Bodhisattwa (disc.) -- Bodhisattwa (disc.) 06:53, 1 ott 2018 (CEST)

• What just happened
• Watchful eyes
• World at your doorstep

Tech News: 2018-36

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

• There is a new user right for users who can edit CSS and JavaScript for the entire wiki. Before this all admins could edit CSS and JavaScript. This was a security risk. This group is called interface administrators. Administrators can delete user CSS and JavaScript pages. [8][9]
• There will be an A/B test on the Wikipedia mobile website. It starts this week. It tests how we show templates that show information about an article. The test will last two weeks. [10][11]
• You can now use different CSS rules for different skins when you edit templates. This is because of TemplateStyles. [12]
• wp10 in ORES is now called articlequality. [13]
• When you get a new message on your talk page you get a yellow message in the toolbar. The preference to show or not show this has been removed. [14]

Problems

• UploadWizard had problems with campaigns. Users could not upload files. This has now been fixed. [15]
• You can get a notification when a link is made to a page you created. This has not worked since June. It was fixed last week. [16]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 4 September. It will be on non-Wikipedia wikis and some Wikipedias from 5 September. It will be on all wikis from 6 September (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 5 September at 15:00 (UTC). See how to join.

Future changes

• The Wikimedia Foundation Readers department will work on advanced mobile editing. You can read more about this and other things they plan to work on over the next year. You can also see the presentation.
• The RelatedSites extension will be removed from Wikivoyage.
• Unused projects on the Wikimedia Cloud virtual private server will be removed. This will happen in October. Projects can be marked if they are being used. [17]

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

16:47, 3 September 2018 (UTC)

https://en.wikisource.org/wiki/Page:Black%27s_Law_Dictionary_(Second_Edition).djvu/1179

This page says that it needs proofreading. I did. Who do I send it to?? Lemme Noe!! Jim Graves e-mail addy:(snipped)

—Preceding unsigned comment added by 104.0.181.123 (talk)

Please see Help:Beginner's guide to proofreading for information on proofreading pages. —Beleg Tâl (talk) 20:48, 3 September 2018 (UTC)

In short, click "edit" on the page, and make the corrections in situ, then click the "publish" button on the page. — billinghurst sDrewth 00:17, 4 September 2018 (UTC)

Read-only mode for up to an hour on 12 September and 10 October

Read this message in another language • Please help translate to your language

The Wikimedia Foundation will be testing its secondary data centre. This will make sure that Wikipedia and the other Wikimedia wikis can stay online even after a disaster. To make sure everything is working, the Wikimedia Technology department needs to do a planned test. This test will show if they can reliably switch from one data centre to the other. It requires many teams to prepare for the test and to be available to fix any unexpected problems.

They will switch all traffic to the secondary data center on Wednesday, 12 September 2018. On Wednesday, 10 October 2018, they will switch back to the primary data center.

Unfortunately, because of some limitations in MediaWiki, all editing must stop when we switch. We apologize for this disruption, and we are working to minimize it in the future.

You will be able to read, but not edit, all wikis for a short period of time.

• You will not be able to edit for up to an hour on Wednesday, 12 September and Wednesday, 10 October. The test will start at 14:00 UTC (15:00 BST, 16:00 CEST, 10:00 EDT, 07:00 PDT, 23:00 JST, and in New Zealand at 02:00 NZST on Thursday 13 September and Thursday 11 October).
• If you try to edit or save during these times, you will see an error message. We hope that no edits will be lost during these minutes, but we can't guarantee it. If you see the error message, then please wait until everything is back to normal. Then you should be able to save your edit. But, we recommend that you make a copy of your changes first, just in case.

Other effects:

• Background jobs will be slower and some may be dropped. Red links might not be updated as quickly as normal. If you create an article that is already linked somewhere else, the link will stay red longer than usual. Some long-running scripts will have to be stopped.
• There will be code freezes for the weeks of 10 September 2018 and 8 October 2018. Non-essential code deployments will not happen.

This project may be postponed if necessary. You can read the schedule at wikitech.wikimedia.org. Any changes will be announced in the schedule. There will be more notifications about this. Please share this information with your community. /User:Johan(WMF) (talk)

13:33, 6 September 2018 (UTC)

CC-BY 4.0 as default license in upload forms

I suggest that CC-BY 4.0 should be the default suggested licensing when using the upload forms in Wikimedia projects for own works, instead of the current CC BY-SA 4.0 license (example at Commons), sometimes with dual GFDL licensing (example here at Wikisource). The main difference would be that derivatives are not required to have the same license. Reasons for changing to CC-BY 4.0 are:

• It is a more permissive license.

• It makes it much easier to combine and mix works. The combination of the two images at right, for example, would not have been possible at all if the images were licensed under let's say CC BY-SA 4.0 for the first one and CC BY-NC 2.0 for the other. However, if either was CC-BY 4.0 it would have been permitted. See WP:Adaptation for further information in this regard.
• CC-BY is by far the most popular licensing for open access journals (see Directory of Open Access Journals - Journal license tab), and is similarly popular in databases (see CC: Data and CC licenses). CC BY-SA is therefore not compatible for inclusion in most open access journals, denying them free access to the sum of Wikimedia knowledge.
• Most uploaders may very well be as willing to upload under CC-BY, but may not be familiar with the differences between having SA or not. The current upload form layouts thus make lots of works receiving a more restrictive licensing than necessary. Just because uploaders can upload under the most restrictive license Wikimedia has to offer doesn't mean they need to be presented with that option by default. Those who still want to put the additional SA restriction would still be able to actively choose so.
• The currently suggested dual licensing with CC BY-SA 4.0 with GFDL such as here in Wikisource (link to form) is actually incompatible in a strict sense (see Wikipedia section on this matter, and is also a lot of extra read for those who want to know what GFDL means, since it doesn't provide the short presentation as given in Creative Commons licenses (compare GFDL license page to the CC BY-SA 4.0 page. It would therefore be both easier for uploaders and more legally correct if we simply dropped GFDL from the default license suggestion. Again, those who do want to choose dual licensing for some reason would still be able to actively choose so.

I want to know if you agree with this suggestion, and we can then bring it to Wikimedia's legal team for review before implementation. I know the change is technically not that hard, since we only need to change the upload form layouts, not the licenses of any already uploaded works, nor the overall licensing of any wiki. I've started a vote on this issue in Wikimedia Commons. Please go to that page to join:

• Commons:Commons:Village_pump/Proposals#CC-BY 4.0 as default license in upload forms

Mikael Häggström (talk) 20:57, 10 September 2018 (UTC)

trashy

Has any one else noticed how trashy the page looks when the header is pushed down by the misleading status bar, any hat notes, and the snail trail [<title<subtitle] that repeats the information in the aforementioned header (repeated in the page it atops). The float overlays the page numbers, though I could switch them off I suppose, and it looks like a dingo's canine's breakfast. The italic AUTHOR and unitalic TITLE is also setting off the whole impression.

I have, for a number of years, but not prepared to say it is useless—beyond average—because it scares off people who might take the site seriously :-) Good night — CYGNIS INSIGNIS 14:24, 4 September 2018 (UTC)

@Cygnis insignis: No clue what you're talking about. Can you link to an example? —Justin (koavf)❤T☮C☺M☯ 18:47, 4 September 2018 (UTC)

The {{header}} style dates back to about 2008 or 2009, and also contains our attempts at metadata, at which we probably still suck. I would presume that discussion was here (now within WS:Scriptorium/Archives) and at Template talk:header. The periphery components have had discussions afterwards. We tried the notes at the bottom, and that didn't work either as they were unseen. It should never be an issue to have a productive conversation about the components of the headers, and the layouts of the pages. Things evolve (front and back end; desktop and mobile), and there is occasional design creep, so sounds reasonable discuss components that are problematic. We can lack good skills in css in our populace, or maybe that is those willing and able in css. Also to note that with the new mw:Extension:TemplateStyles there is scope for us to pull elements out of the Template:Header and modules to separate/simplify components. I suppose that we want to break the conversation down to reasonable bite size pieces, as mega conversations often go unresolved here. — billinghurst sDrewth 22:11, 4 September 2018 (UTC)

Addendum, back then it would have been discussion about "header2", as it was then. — billinghurst sDrewth 22:17, 4 September 2018 (UTC)

@Koavf: An example can be found at https://en.wikisource.org/wiki/Special:RandomRootpage/Main. Begin reading from the very top, left to right, and imagine you are seeing it for the first time. As you move down the page, note things like the header object overlapping the first page number (the link to the transcluded page). Would you like me to screenshot what is visible to everyone? Billinghurst wanted the author in italic and the title not italic, so that is characterised as a 'meta discussion' and therefore never to be fixed. CYGNIS INSIGNIS 02:37, 5 September 2018 (UTC)

Mate, stop picking fights, it advances nothing, and turns things difficult. I neither designed nor developed the header, anything that was chosen at the time would have been community consensus. — billinghurst sDrewth 11:42, 5 September 2018 (UTC)

no ur Is this the 'consensus' you recall: User_talk:Billinghurst/Archives/2009#bot_bug. Do I need to find where you obstructed the simple fix of the italic issue? Pull your head in, and don't call me 'mate'. —CYGNIS INSIGNIS 20:11, 5 September 2018 (UTC)

@Cygnis insignis: What you linked to went to Richard de Abyndon (DNB00) for me. I'm using Firefox and not seeing overlapping. Yes, if you need to screenshot, please do. —Justin (koavf)❤T☮C☺M☯ 02:39, 5 September 2018 (UTC)

I too don't see any problem -- for me the random page picked was Speeches of Carl Schurz which does not have a source file, and thus no page numbers. But I also have set Layout 2 as my preferred default so I generally do not have a problem with things like overlapping page numbers. A screenshot would be helpful to show what you're having issues with, I think, so we're all at least on the same page. (I'm in Chrome, FWIW.) --Mukkakukaku (talk) 05:39, 5 September 2018 (UTC)

Header page overlap.png

Thank you both for the response, the statement was prompted by Essays on Political Economy, complaining about the header was easier than wading through that again. The capture at right shows the problem I have always seen on my platform (antique Mac, FF, default layout.) — CYGNIS INSIGNIS

I can confirm that overlap is still present in Firefox 62 on macOS 10.13.6 (latest release version). It's not present in ditto Chrome or Safari. It's probably just a too tight default margin or something that's fixable if someone digs a bit. --Xover (talk) 08:22, 6 September 2018 (UTC)

Oh, interesting. It actually looks like this might be another .offsetTop bug, along the lines of the Webkit one I've detailed in another thread, only in Firefox this time. In Chrome and Safari the <span> that marks the first page has a (correct) .offsetTop value of 0. In Firefox, though, its value is -11. When the PageNumbers.js script creates the page number links in the left margin, it uses the .offsetTop value reported by the browser for the page marker as the position for the page number. And with a -11 the page number ends up encroaching on the layout box for the header. Since I can't tell what triggers it I don't see how we could make enough of a test case to be able to report this to Mozilla and have any chance of getting it fixed. But it's possible we could work around it in PageNumbers.js by simply ignoring negative .offsetTop values: for our use case these will always be incorrect. --Xover (talk) 15:54, 6 September 2018 (UTC)

I'm unsure of some of what Cygnis insignis is referring to, but I too have long thought that we have become blind to the awfulness of our layout, and need to see it with fresh eyes. Consider The Collected Works of Dugald Stewart/Volume 1/Part 1/Chapter 1:

Firstly, no self-respecting website should be entitling its pages with slashes like this. Sure, that's our subpage structure, and sure, we editors need to know about it. But it just looks weird and stupid to our readers.

Secondly, follow Cygnis's advice and read it sequentially from the header, with fresh eyes. You get:

• The Collected Works of Dugald Stewart/Volume 1/Part 1/Chapter 1
  
• < The Collected Works of Dugald Stewart‎ | Volume 1
  
• The Collected Works of Dugald Stewart (Volume 1) by Dugald Stewart
  
• Part 1: Chapter 1

That's an awful lot of pointless repetition.

Hesperian 07:46, 5 September 2018 (UTC)

templates do not work well in small screens / mobile. we could use a refresh. but that would require some coding, and consensus building for a redesign. Slowking4 ‽ SvG's revenge 12:24, 5 September 2018 (UTC)

Hesperian.

1. Example one is a mediawiki construct, what are you suggesting instead? What other configurations are available through mediawiki, and how else would you wish to work the issues around subpages and their linking?
2. Example 2, is similarly a mediawiki construct, though it seems to be able to be controlled by class="firstHeading". It is an interesting breadcrumb, and only appears when we have subpages. I have no idea of its malleability otherwise. It does allow quick flicking to layers of works, or to a rootpage of a work. It also only appears when the subpage layer is created. Not visible at Koafv's example. If you are in a journal, or newspaper, like The Times/1937/Obituary/Mr. Alan Butterworth it gives the root, it gives the year, and omits the non-existent obituary. Those active sublinks can be useful for navigation in certain circumstances. Also in my last example, there is less other repetition, and the subpage structure allows an automated collation at 1937, though it is still the ugly output, we haven't yet managed to get {{SUBPAGENAME}} display.
3. Example three display is choice of the contributor, and I would have said less typical, as usually it is simple a manufactured hyperlink to the rootpage. There is clear variation in user generated output
4. Example four display is also a choice of the contributor

What would your preference be? Which of those are you suggesting that we remove? What is the equivalent mobile output like? — billinghurst sDrewth 12:29, 5 September 2018 (UTC)

These are all excellent questions, and the reason I've not raised these issues before now is I've had no answers/solutions to offer. Hesperian 07:44, 6 September 2018 (UTC)

If we set $wgRestrictDisplayTitle to false, we can use the magic word {{DISPLAYTITLE: …}} to set the page title ("Example one", I think) to something else. Whether that's wise or would even be an improvement, and what to set it to, I'll leave for wiser minds than mine to figure out. My immediate opinion is that the bits that matter are in the hands of the WMF developers (i.e. outside the hands of the community), and the rest isn't in any immediate need of changing. I might have picked a different background colour for {{header}} myself, but that's about it. --Xover (talk) 17:34, 5 September 2018 (UTC)

as we see with mw:Winter or mw:Skin:Timeless, it is a herculean task to upgrade the look and feel of the reading experience. maybe we need to add it to wishlist, or recruit an Isarra to push the consensus. (they did listen to us a little) Slowking4 ‽ SvG's revenge 23:54, 5 September 2018 (UTC)

It is my memory, (and it could be flawed as it was a long time ago) that there was lots of discussions and trials of background colours, and in among earlier colour palettes of skins. We did what we could with the skills to hand, and the css/css2 restrictions of the browsers at the times, and prior to much in mobile. GOIII did lots of work in the area, though generally his edits are ever-present though undocumented in edit summaries. I am sure that things can do things better, and it will be the balance between doable, reliable, extensible and consensual. I can see that WSes may be able to get it into the annual FIXME cycle if we get enough votes, or can clearly demonstrate value. — billinghurst sDrewth 07:30, 6 September 2018 (UTC)

or we can just get rid of the title of the page we're talking about altogether. All the information should be in the header anyway and if an editor needs to know where they're at they can just look at their browsers address bar.Jpez (talk) 04:20, 6 September 2018 (UTC)

That is also a rationale for disposing of the header and keeping the title page, replacing the title page is what happened in the days before scans made text integrity verifiable. It was invented to rebadge Gutenberg texts and throw away front matter that someone decided we don't need to see, and shape any text as a meta version of a work, novel, poem, essay, at least I assume so as that is why I never bothered reading texts here. — CYGNIS INSIGNIS 08:18, 6 September 2018 (UTC)

If you don't like the header, you can use Layout 3 -- though sadly these layouts seems to only work for transcluded works. The header contains useful information, though; how are you supposed to navigate a multi-chapter work without it? Go back to the front matter, scroll to the TOC or index, figure out where you were and click the subsequent link? Now that seems like extraneous work. --Mukkakukaku (talk) 03:16, 8 September 2018 (UTC)

@Mukkakukaku: What I like is solutions. I do not favour the layout options as a solution to anything but an imagined problem, and the header is a historical legacy that no amount of tweaks and workarounds will fix. I have a solution, but proposing may be futile; it is certain to be resisted because other users already have a substantial investment in the header's problems. — CYGNIS INSIGNIS 02:36, 10 September 2018 (UTC)

Well, sure, solutions are good. But I have yet to understand what the actual problem is. I mean, Hesperian did a good job explaining the redundancy concern with the page title/hierarchical display (that shows when you have subpages) -- and I agree that it's redundant and needs to be addressed. But I have no idea what the problem is with the rest of the header. Frankly, in my experience it solves more problems than it creates: it provides a standardized format to display the current work's title, author, year of publication, section title, contributor title, etc., plus navigational options for "next" and "previous" chapters. I don't have a lot invested in the design, but I do have a lot invested in the functionality, and little interest in fixing what ain't broke, as they say. (And as I mentioned, I haven't heard what's broke about it yet.) That being said, this discussion has become somewhat nonlinear, which is a pity. Feel free to ignore this tangent. --Mukkakukaku (talk) 02:55, 10 September 2018 (UTC)

Haha. "Well", I'm taken aback when people start their sentences that way, but Reagan was a great public speaker :) I'm not good at describing problems, but here goes: The header, as I describe above, was created to replace title pages and provide navigation; this distinguished a text from other hosting sites. Creating these 'points of difference' is a legacy of when wikisource was trying to justify its existence. The solution is to dispose of the faux title display on which the header is based, and replace it with a box of labelled data and links, left aligned, using bibliographic styles. This could do what the header is supposed to do, the items you mentioned, and much more besides. The headers only solves the 'problem' of forcing constraints on how data is displayed, not how it can be more useful. A basic application of a data box is output, like a citation for the page being viewed, or for WD bots to extract metadata from works or their subpages. I contend that people have been unknowingly viewing this the wrong way round, value is found in the text and its metadata, not in controlling its display. The situation is similar to the assemblage of sister link boxes, some newer users streamlined and improved them and it was incorporated into the header; the header object could never effectively work for open access to data when it is designed to work against that principle. — CYGNIS INSIGNIS 05:13, 10 September 2018 (UTC)

page style looks terrible on page

I am obeying some style page suggestions I was spanked for not using, and it looks over-done and with distracting bling.

Glorious Roll of the American Drum

Is there a way to fix this in which I will not be harrased? --RaboKarbakian (talk) 15:33, 7 September 2018 (UTC)

Probably not with that attitude, no. And if you want help with something you'll have to explain in more detail what you perceive to be the problem. --Xover (talk) 16:13, 7 September 2018 (UTC)

I am sorry for the attitude, well, more like slang. "Bling" is fancy things which have no purpose, in this case, the hover highlighting of the text of the page. It is a useful thing (and not bling) when found on a document which contains more than one page.

The word spank is being used inappropriately here, but it was a shorthand that I was using to remind myself "be careful as you are editing in a public space and have had experiences in which seemed jarring or shaken out of a pleasant workflow". My nice looking documents were changed from the second transclusion method described at wikimedia into these lovely looking page highlighted somewhat more natural language hashed templates that are too much for the single item document I just made.

I came here because I would like to go back to the "non-deprecated" method I was using before only this time, without the changes and without reprecussions for using it. (There was an ongoing discussion of the use of the word deprecated also, as from a software point of view, the "deprecated thing" was server side includes.)

I don't care about the language I use here. It's all wrong. Sorry?--RaboKarbakian (talk) 17:47, 7 September 2018 (UTC)

The highlighting when you hover your mouse cursor over the page number in the margin is something all works on Wikisource get. However, if you dislike it you can disable it using the "Page links displayed" link under the "Display options" in the sidebar. In the sense you're intending here, there is only one way to transclude works from the Page: namespace to a main namespace page (there are some variations surrounding use of sub-pages for chapters and such). The syntactical variants you've found are mere technical artefacts: think of them as bugs, in software development terms.

You might also want to take a moment to look into what the purpose of Wikisource is. We reproduce the original work faithfully (within reason, and there are unsettled gray areas), rather than make new editions. If your aims are different from Wikisource's aims, then you are bound to be endlessly frustrated here.

Finally, for any given method or bit of "bling", you may safely assume that it is the way it is based on the consensus of the community here that that is how it should be. Some things are certainly better debated than others, but if it is a certain way there's a good chance it's because it has at least de facto consensus. All such consensus is subject to change (within technical and legal limits), of course, but that requires good arguments that change is needed and persuading a majority of the community that your alternative is better. On the way to transclude works I don't like your chances; on other issues you might have better luck.

Of course, that would probably necessitate taking some care with the language you use… --Xover (talk) 18:23, 7 September 2018 (UTC)

Maybe it's just my browser glitching, but I don't see neither a page number, nor a "page links displayed" option under the 'display options' sidebar section. Or maybe it's because the last edit to this work swapped out the pages tag for a ... I have no idea what that is being used to transclude but it's weird.

What is kind of distracting is the wikidata authority control footer at the bottom of this work. I've never actually seen one of those outside of the Author namespace. That and the weird "follows and followed by at wikidata" note in the notes field are the only blatantly out-of-place things I can see with the work. I mean, I guess the redlinked "Unknown" contributor instead of using an override parameter, too, but that's a minor tweak to fix. --Mukkakukaku (talk) 03:13, 8 September 2018 (UTC)

And there you go!! a recent diff I put the note that the follows and followed by can be accessed at wikidata. I thought it might be a good experience in making templates for me or someone else.

Extremely brief discussion, apparently with the "concensus" about it, but the consensus has a user name.--RaboKarbakian (talk) 09:57, 8 September 2018 (UTC)

Every consensus has a user name attached to it, or it wouldn't be part of a consensus, now would it? We don't include those kinds of "educational notes" on the pages of works. Procedural notes ought to be in the Help: namespace or a Talk: page, not in the work itself. And let's be frank here: You're not following community norms, and when you get called on it, you deliberately ignore what you're told, and then go do your own thing anyway. So don't try to play the "poor little me" act when you've set yourself up for this by ignoring most of the advice you've been given and flouting established style at every turn. If you're going to refuse to follow convention, then at least be honest about what you're doing. --EncycloPetey (talk) 15:48, 8 September 2018 (UTC)

@RaboKarbakian: I made this diff to give you another spanking. If you ever use multicol for that situation, the printer saving paper, your buttock will be toasting crumpets for the senior boys. CYGNIS INSIGNIS 02:45, 12 September 2018 (UTC)

<html5> is great. Pasting <br /> after everything is not so great. <poem> is real handy, especially when I know what crap html {{dhr}} is probably making.--RaboKarbakian (talk) 02:55, 12 September 2018 (UTC)

@Cygnis insignis: You didn't need to revert this. <poem> doesn't play well with the block templates /s /e. I have been using <br /> there. It is more choicey of the two formats.--RaboKarbakian (talk) 12:55, 12 September 2018 (UTC)

Pasting it! what a good idea, I had been typing it out each time ;) I'm not aware of a problem with the start and end templates, has someone been recoding it? — CYGNIS INSIGNIS 13:40, 12 September 2018 (UTC)

Constitution of Angola

The page named Constitution of Angola (1975) actually contains the 1992 version of the constitution. Since this is my first time editing WikiSource, I could use some help or advice on this. Is it fine for me to rename the page to "Constitution of Angola (1992)"? Here are the relevant sources I'm aware of. Krubo (talk) 04:06, 12 September 2018 (UTC)

Done Thanks for pointing that out. — billinghurst sDrewth 04:36, 12 September 2018 (UTC)

Thanks! Krubo (talk) 17:23, 12 September 2018 (UTC)

Living authors category

It seems that authors with the date of the death missing in Wikidata are categorized as "living authors" in Wikisource. As a result authors whose date of death is unknown, such as Author:Chval Dubánek, are categorized as "living" as well. Can it be fixed in some way, please? --Jan Kameníček (talk) 18:51, 11 September 2018 (UTC)

The problem is probably in the module:Author, particularly in the lines:

if type == 'death' and isHuman then

-- If no statements about death, assume to be alive.

addCategory( 'Living authors' )

It really looks weird if we assume that people working centuries or even millenia ago (such as Author:Zeuxippus are still living. For this reason I suggest that people over 90 should not be categorized based just on the fact that Wikidata do not have any record of their death. However, they might be categorized here manually. --Jan Kameníček (talk) 20:20, 12 September 2018 (UTC)

Less of us play in the module: ns for fear of breaking things. I would suggest leaving a note on Template talk:Author and applying a ping for "Samwilson". — billinghurst sDrewth 01:08, 13 September 2018 (UTC)

handled at template talk:Author — billinghurst sDrewth 21:53, 13 September 2018 (UTC)

Tech News: 2018-37

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

• When you added or edited a template with the visual editor the input boxes were very big. This has been fixed. The input boxes will now be smaller until you click on them. Then they will change size to fit the text. [18]

Problems

• Some diffs showed lines in the wrong order. This was fixed last week. [19]
• Marking a cross-wiki notification as read didn't work every time. The other wiki was not updated. This has now been fixed. [20]
• <maplink> did not work for a few days. This was because of a bug. This has now been fixed. [21]
• {{subst:REVISIONUSER}} is used by some templates. For a period edits saved with {{subst:REVISIONUSER}} would save the previous user's name and not your username. This is now fixed. Edits made before the bug was fixed will still be wrong and need to be corrected. [22]
• When you move a page the title still shows the old page name. The developers are working on fixing this. [23]

Changes later this week

• Because of a data centre test you will be able to read but not edit the wikis for up to an hour on 12 September and 10 October. This will start at 14:00 (UTC). You might lose edits if you try to save during this time. The time when you can't edit might be shorter than an hour. You can read more about this.
• Because of the data centre test there will be no new version of MediaWiki this week. Changes for this week will come next week instead.

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 11 Septmber 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 12 September at 15:00 (UTC). See how to join.

Future changes

• The developers work on making the wikis work better on mobile phones. There is a list of common problems when making content easier to read in the mobile view. You can add things to the page and ask others to help.

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

22:35, 10 September 2018 (UTC)

Comment

The above discussion at mediawiki that relates to mobile configuration seems particularly problematic and antithetical to production of a literary work, and to how we have structured our pages. It would seem that we need to be involved with the conversation, and it highlights how we do produce components and probably need guidance from the Reading team about what we are doing. — billinghurst sDrewth 04:17, 11 September 2018 (UTC)

I don't see how it affects producing transcripts, only where the 'page structure' (and layout) is non-compliant. Which components need attention? — CYGNIS INSIGNIS 08:05, 11 September 2018 (UTC)

Well it's because these days we don't produce transcripts (eg. just the content). We try to preserve the work in its entirety, including the original print layout as best we can.

Most of our layouts are non-compliant, really. Any place where people set an explicit width in pixels -- for example, on an image. Anything that relies on hovering -- the {{SIC}} and {{redact}} templates come to mind -- aren't compliant. Heck, the argument I accidentally started a few sections ago about the auxiliary tables of contents is about a non-compliant template.

There's just not enough horizontal real-estate on a mobile device to support our layouts because we attempt to mimic and preserve the printed page. Sidenotes? no room for that -- but what can we do as an alternative?

It almost seems like we'll want to have our templates and layouts degrade gracefully into something that looks more like what Gutenberg produces (just puking the content onto the screen; come back to desktop to see the work as it was intended to be consumed.) --Mukkakukaku (talk) 01:06, 13 September 2018 (UTC)

What are the problems with SIC and redact? [So much to have to know that takes away from transcribing] — billinghurst sDrewth 01:57, 13 September 2018 (UTC)

The list from that cited page

1. Use common class language for components in templates across projects
2. Don't put infoboxes or images at the top of the wikitext
3. Meta data (including coordinates) should be positioned at the bottom of the article
4. Use consistent ordering for hatnotes and ambox templates
5. Inline styles should not use properties that impact sizing and positioning
6. Avoid tables for anything except data
7. Make sure your main page is mobile friendly
8. Templates should use a single root element with a sensible CSS class
9. Collapse issues with a multiple issues template
10. Do not assume positions of images, infoboxes, tables in text

and some thoughts.

We try to do 1) though we don't do it effectively. Header templates is an example of 2), and some of the other aspects of featured works similarly sit there per 3). We use inline styling a lot to replicate the work per 5). We do large amounts in tables, often to replicate a work, though also with {{block center}} as other means has failed us per 6). We don't container multiple issues per 9).

Probably other components in the others. I am time-poor and not suitably knowledgeable to be authoritative. I started a topic on the respective talk page, and am endeavouring to add to it, though not the quality time to be lucid and extrapolative. — billinghurst sDrewth 01:54, 13 September 2018 (UTC)

Re: SIC and redact -- They rely on hover to indicate content. How does one hover with a touch screen? The SIC template moreso in this regard because the corrected spelling is indicated in hover, whilst the redact template uses the hover to indicate why the data was redacted as a result of a FOIA request. The redact template's other issue is that it uses a specified fixed width, usually determined by the proofreader to be somehow related to the redacted content length in the original text. This would be number 5 in the above list.

I'm actually extremely surprised they didn't mention hover explicitly since that's one of the first things that have been brought up as an issue I've had to deal with when adapting desktop-first websites to mobile/tablet. But perhaps in a Wikipedia-centric world that's a much less used paradigm.

As someone who actually does occasionally read works on their phone, I actually find the header's consistency rather useful in the mobile view -- I'll know I can find the title, author, year of publication, portal/wikidata/wikipedia links all in the same consistent place. Moving them to the bottom where they suggest moving the "metadata" would actually be really really unhelpful in my opinion.

Also we have a lot of tables. The older experimental TOC templates do not degrade gracefully for the mobile view. Even things that should never have had tables for layout -- like {{Auxiliary Table of Contents}} in the argument above -- has a table based layout which it simply doesn't need. --Mukkakukaku (talk) 02:25, 13 September 2018 (UTC)

From memory it harks back to the issue that we had with centre blocking (see Template talk:Block center) where it didn't work unless it was a table, and was why {{block center}} was a table (and I hadn't noticed that it had stopped being so.) So the issue is that we haven't kept up well with the progression of html/css and retirement of browsers. I would think that {{AuxTOC}} needs that same treatment as "block center", and if we could even better apply template styles to each of them, that may be better again. — billinghurst sDrewth 04:42, 13 September 2018 (UTC)

•  Comment Looks like we need a formatting and template repair and review space, so where we identify old/recalcitrant formatting, and its use in templates, that we can methodically fix things in an informed way. It might also serve as a place where we can report forthcoming known coding issues and then hunt for those problems on our site. If we did, we could do and fix somewhere within Wikisource:Maintenance of the Month (which should also be renamed Wikisource:Maintenance). — billinghurst sDrewth 05:01, 13 September 2018 (UTC)

(edit conflict) Right. Tables for layouts was something that kind of went out with IE6 and the browsers wars. (And even over at phabricator they make a point of not supporting anything older than the current release of a given browser.) These days the preferred method to do a centering would be to use a div or other block-level element with a style of margin:0 auto;. But truthfully even that is problematic from a mobile design standpoint. In order for something to be centered, you need to have a width that is less than the maximum; in mobile you're severely limited in horizontal real-estate anyway, so there's nearly never a reason to use the 'center block' concept because you're artificially forcing a user to scroll by squishing content into a fraction of an already limited area. (The centered text concept is different; alignment is still relevant.)

What we might want to consider is using CSS media queries to have our styling specific target different widths of screen. That way we could specify how a view looks at mobile (or other extra-small interfaces), versus tablets (small), small computer screens (eg. 1024x768; medium), then desktop (larger). The problem is that -- to my knowledge -- you can do media queries at the element level and instead have to declare them at the global level. (As an example, look at this website and shrink your browser window. There's a lot more examples like this in the modern web.)

That would involve a consistent effort across-the-board to figure out what the user experience in mobile (vs tablet vs desktop) should be so as to get the global styles in places. But then templates could just inherit those base styles (via classes) and then adjust using as needed based on the needs of the template itself.

As far as I can tell, this push to be more mobile friendly didn't come with any software based tools to make this easier to do. Just watch they'll ask us to be more screen reader friendly next. Mukkakukaku (talk) 05:05, 13 September 2018 (UTC)

I wonder whether we should be seeking a grant for a project to get someone to investigate the css needs of the WSes, and fix the framework. — billinghurst sDrewth 21:45, 13 September 2018 (UTC)

And maybe it is ultimately, for mobile devices do we really want to throw in the formatting that the book had? Is this a case of KISS? — billinghurst sDrewth 21:52, 13 September 2018 (UTC)

I think we're going to find that we can't reproduce the book layout faithfully due to the limitations of the medium. There just isn't enough horizontal room on the phone screen to render, say, two side notes plus content. Or a larger detailed image (eg. a map from an aviation accident report). We might need to consider making it policy that in mobile you'll get the content, but if you want to experience the work in the way the publisher intended originally you'll need to switch to a larger format. But that would be a decision that we'd have to make as a community. --Mukkakukaku (talk) 00:26, 14 September 2018 (UTC)

•  Question Would it possibly be useful to create a WikiProject to direct an effort to systematically update our templates and other pages to make them more mobile friendly? --Mukkakukaku (talk) 23:37, 14 September 2018 (UTC)

Main page

There is guidance for main page design that we should read at mw:Mobile Gateway/Mobile homepage formatting — billinghurst sDrewth 04:26, 11 September 2018 (UTC)

Aux TOS now full-width?

Did we at some point recently discuss having the auxiliary TOC templates now be full-width? Can someone point me at that? Because all of the aviation accident reports I've been working on, which rely on these auxiliary TOC templates to link attachments (since they have no formal tables of contents) now have this garish full-width green green box, with the content floating sadly in the middle at the specified width.

Cf: Aviation Accident Report: American Airlines Flight 320

I'd really rather not have to go back and swap out templates on all the completed reports. --Mukkakukaku (talk) 03:57, 10 September 2018 (UTC)

@Mukkakukaku: The change was made by Esponenziale in this edit on 7 September. The preceding discussion was here (the thread above it from 2016 is also relevant: pinging Hesperian). Because this change was insufficiently discussed, affects a large number of works, and has been objected to here, I have reverted it for now. In my opinion such changes should be discussed (pro—con, details, needed remedial action, etc.) thoroughly here first, and sit a reasonably long while up in #Proposals to make sure everyone has a chance to see it and raise concerns before it is implemented. Other than that I currently have no opinion on this change (but the discussion here might induce me to develop one). --Xover (talk) 04:42, 10 September 2018 (UTC)

@Mukkakukaku, @Xover: I've better detailed my reasons in Template_talk:Auxiliary_Table_of_Contents#Responsive_design, I'd rather move any further discussion there if you like —Esponenziale (talk) 14:08, 10 September 2018 (UTC)

@Esponenziale: This affects a lot of works across the project and not very many editors watch the template's talk page. I think it's best to keep the discussion here. That being said, I don't think it's a good tradeoff to make changes to the formatting that impacts the website (which is the primary interface) to benefit one of the possible export formats (ePub). Particularly as CSS is explicitly designed to allow different styling of the same content for different media (webpage + book was one of the combinations specifically designed for). Thus, any change whose goal is to affect the ePub needs to start with the requirement not to affect the master web version. The web version can, of course, also be changed iff it benefits the web version. And if a change is good for both, then so much the better. But that needs to be thoroughly discussed beforehand; and that starts with clearly articulating the problem and a proposed solution that takes into account the different interests. --Xover (talk) 14:54, 10 September 2018 (UTC)

A part for design responsiveness, which was the real objective of my edit, the appearance was only slighted modified (green background enlarged to full width also when viewport is large) mainly because it allowed to simplify the template (see explanation at Template_talk:Auxiliary_Table_of_Contents#Responsive_design), but also because the other green boxes used for navigation between subpages are 100% large, and in my opinion they're better off all equally large.

To sum up, I think this tweak to appearance was good for ePub, web and template code. But it was't of much relevance, if @Mukkakukaku: doesn't like it, I'll find a solution (suboptimal, at least to me) in order to satisfy his preference. —Esponenziale (talk) 23:24, 10 September 2018 (UTC)

The issue isn't whether Mukkakukaku likes it or not (and it's a bit unfair of you to cast the issue that way). The issue is that this change, whether good or bad, affects a very large number of works across the whole project, and so it should be discussed before implemented. Try changing the page background to pink on all 5 million articles on English Wikipedia without gaining a solid consensus first, and see what the response of the c. 30k active monthly editors there will be (well, actually, you can't do that because enwp has added protection on all the relevant bits for this very reason). Wikisource is a much smaller project, but the same principle applies. It's actually even worse here, in some ways, because the specific visual display of a work is a much bigger factor here than at the Wikipedias.

And in light of the bigger issues flagged below, it seems that discussion properly belongs as part of a larger discussion of how we deal with the needs of the mobile frontend. --Xover (talk) 08:05, 11 September 2018 (UTC)

@Esponenziale:, the fact that you thought this edit was better is not sufficient reason to impose your opinion on everyone. I do not agree with the reasons you have given and do not support the change. Making a ToC template look more like a Header template is more likely to confuse readers than assist them. --EncycloPetey (talk) 14:02, 11 September 2018 (UTC)

Yet another thing jostling with the header, easily merged to a template with labelled display of data. I am looking for a seconder for a proposal to replace the header template, so talking it up at every opportunity. CYGNIS INSIGNIS 17:47, 11 September 2018 (UTC)

An Auxiliary ToC has nothing to do with the Header and shouldn't do. If you thought I said otherwise, you misunderstood what I was saying. --EncycloPetey (talk) 00:29, 12 September 2018 (UTC)

Oh, hi :| It was not intended as a reply to your comment on our central discussion page, it is about sowing a seed of change; I tried to make it clear that I was shamelessly using the example of that ToC to demonstrate the merit of my proposal to dispose of the header. I believe I understood what you were saying, agreeing that it is a confusing fix, and already assume you are firmly opposed to any solution I might present. — CYGNIS INSIGNIS 02:00, 12 September 2018 (UTC)

@EncycloPetey, @Xover: I see that there's no consensus about the change to full width. What about responsiveness?

P.S.: I'm quite surprised by your reactions, I've made this edit without bothering anybody here (I wrote in advance only on the template talk page) because in my opinion, as I've already pointed out, the change in appearance was minor and didn't necessarily need discussion. I've no problem in discussing it now and I've no problem if someone find it more relevant than I do. But there's really no need to waste time explaining why I can't be the dictator of Wikisource...—Esponenziale (talk) 09:54, 12 September 2018 (UTC)

@Esponenziale: Ah, I see now from whence the confusion stems. No, the visual layout change was not a minor one. I'm also quite surprised you could conclude it was: are you certain you've not let yourself be misled by, say, only looking at the ePub output (or mobile or…) rather than how it's actually used in different works on the desktop website? I'll repeat that I'm not particularly a fan of the status quo, but even a cursory inspection suggests to me that making it full-width would be a dramatic change for which consensus must be sought first.

Whether or not to make it responsive is an orthogonal issue: responsive design is a fine and laudable general principle, but the devil is in the details. What are the downsides and tradeoffs? What is the implementation cost? What, specifically, will it gain us for this particular interface element? And in any case, that process starts by making it responsive while preserving its current visual appearance.

Personally I think its biggest problems are its relative paucity of functionality (e.g. I would prefer to float it to the side, and perhaps some more automated linking for convenience) and a certain distaste for its visual design (but it matches the house style, so that's not this template's fault). Making it responsive is waaay down on my list of priorities. --Xover (talk) 11:13, 12 September 2018 (UTC)

Appearance can be left unchanged on big viewport, but some very slight differences in appearance allow to obtain some minor benefits. Would the following rendering be ok with you? –Esponenziale (talk) 13:39, 12 September 2018 (UTC)

Chapters (not individually listed)

1. Chapter I
2. Chapter II
3. Chapter III

What are you asking with regard to? In asking approval for "the following", do you mean as new code for the template? Do you mean as an alternative non-template use? You'll have to spell out what it is you are asking, so that people here can judge the proposal. --EncycloPetey (talk) 13:55, 12 September 2018 (UTC)

We were discussing a change to the template to make it responsive, without enlarging it to full width. That is the output of the template once modified. –Esponenziale (talk) 14:40, 12 September 2018 (UTC)

The template intentionally takes a width parameter. I'm not sure what you're doing there, setting width to 100% and then max-width to 400px. ;)

That being said, swapping out the table-based layout for a div-based layout is a fine improvement, since tables are slow to render anyway and this particular thing doesn't have any tabular data. Using style margin:0 auto; padding:0 6px; width:400px seems more appropriate. (The current version of the template uses 400px as the fallback width.) You can also use a flex layout to get the '(not individually listed)' positioned properly like so:

Chapters(not individually listed)

1. Chapter I
2. Chapter II
3. Chapter III

It could help if it was made clear what is meant by "responsive" because my understanding of the word was that it is displayed appropriately in all size formats including mobile, tablet, and desktop -- which as far as I knew this version already did. The optimal solution would be for it to be treated more like a full-width secondary header in the mobile view since that matches most mobile design paradigms, but the only way I know of doing this involves CSS media queries which are (as far as I know) not supported in templates. --Mukkakukaku (talk) 00:47, 13 September 2018 (UTC)

Your understanding of the word responsive is correct. And if the width is defined as you did, then the layout isn't responsive: when the viewport width is smaller than div, it is either scaled or only partially displayed (see screenshot here). Setting the width to 100% and max-width to 400px (or, equivalently, setting the width to 400px and max-width to 100%) solves this problem without the need for media queries.

I'm not very accustomed with flexbox. In my opinion it would represent a small complication because it should fallback nicely (it's currently not supported by 5% of browsers and probabily far more e-readers). Note also that your current implementation lacks any padding between the two texts (they touch together when the width is small or they're long).–Esponenziale (talk) 09:26, 13 September 2018 (UTC)

Re: flexbox -- The wikimedia folks seem to only care about supporting the latest release of each browser. It degrades into what your version looks like anyway, so it doesn't matter in the long run. I don't know what you mean by "padding between two texts", either. Paragraph tags have native bottom margin as part of the browser default styling, which is what I leveraged. You can always put a margin-bottom:6px or whatever on the paragraph tag. If that's not what you mean, then I have no idea what you're talking about. Slap a max-width:100% on the parent container if you don't want it to overflow its parent, I guess. --Mukkakukaku (talk) 00:22, 14 September 2018 (UTC)

Done: I've updated the template just now, using flexbox to keep the comment on the right corner, as you suggested. Top and bottom paddings and margins are not defined in order to be inherited from the subheadertemplate class. Padding between title and comment (the two texts I was mentioning before) is guaranteed by imposing a min-width of 1em on the span between the two. –Esponenziale (talk) 14:20, 14 September 2018 (UTC)

@Mukkakukaku: in Aviation_Accident_Report:_American_Airlines_Flight_320 the template has 100% width because you defined the width as 250px instead of 250 (without px) as the documentation requires. –Esponenziale (talk) 14:26, 14 September 2018 (UTC)

We had been trying to not embed units in any of our applied widths. I would think that we may be better to look to update the template so that it is unitless. There are about 900 uses, we could bot replace those with px where we have applied a custom width. — billinghurst sDrewth 15:21, 14 September 2018 (UTC)

Ok I see now that the previous actual implementation of the template was unitless since 2015, but the documentation wasn't up to date and was saying that the unit of measure shouldn't be entered. Today I updated the template in compliance with the latter. Now I've just made the template unitless, as you asked, and I've updated the documentation to reflect that. –Esponenziale (talk) 21:30, 14 September 2018 (UTC)

Now I'm confused since that particular page clearly sets width=250px (with unit) on the Aux TOC template, and it looks correct (since the initial change was reverted in the template itself). Prior to the template revert it was a 100% wide green rectangle, with the actual TOC content (the links) at 250px floated in the center. Either way, I officially have no idea what we're talking about anymore. :) Either of those two last proposed templates is fine in my opinion (the one I proposed or the one Esponenziale proposed). They both seem to accomplish the desired affect -- the box is green, limited to the size of the content/requested width, doesn't grow scrollbars at smaller resolutions, and is not based on the HTML table tags. --Mukkakukaku (talk) 23:26, 14 September 2018 (UTC)

Oh. I see. Yes, when things don't work as the documentation says, I go and make them work anyway which is why I used the units when declaring the width because that's what made it work. Less confused now. I've been using this template like this forever and didn't realize the documentation had gotten out of sync. But still. We should be ok now, yes? --Mukkakukaku (talk) 23:28, 14 September 2018 (UTC)

Yes! –Esponenziale (talk) 09:32, 15 September 2018 (UTC)

Table of images

What's the best template for the list of images on Page:Bird Haunts and Nature Memories - Thomas Coward (Warne, 1922).pdf/15, where the photographer credits are right aligned in the column before the page number? I've tried {{Dotted TOC line}}, with |dotend=, but that didn't do what I'd hoped (its documentation is less than clear). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:07, 15 September 2018 (UTC)

{{TOC row 1-1-1}} might do it. Those templates are kind of finicky though, though there's a decent amount of choice if that one doesn't work. --Mukkakukaku (talk) 22:10, 15 September 2018 (UTC)

Or possibly {{TOC row 2-1-1}}. That one seems more likely to be what you need. If all else fails you can just do a regular table. --Mukkakukaku (talk) 22:12, 15 September 2018 (UTC)

Thank you. I found that {{dotted TOC page listing}} gave the closest approximation to the source. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:53, 15 September 2018 (UTC)

Do you have small tasks for new contributors? It's Google Code-in time again

Hi everybody! Google Code-in (GCI) will soon take place again - a seven week long contest for 13-17 year old students to contribute to free software projects. Tasks should take an experienced contributed about two-three hours and can be of the categories Code, Documentation/Training, Outreach/Research, Quality Assurance, and User Interface/Design. Do you have an idea for a task and could you imagine mentoring that task? For example, do you have something on mind that needs documentation, research, some gadget or template issues on your "To do" list but you never had the time, and can imagine enjoying mentoring such a task to help a new contributor? If yes, please check out mw:Google Code-in/2018 and become a mentor! Thanks in advance! --AKlapper (WMF) (talk) 13:51, 9 September 2018 (UTC)

Would fixing the edit page tool bars be a suitable task? There are things that are there that shouldn’t be and things that should be that aren’t e.g. the maths characters are up the wop and ff isn’t on the ligatures and the User choice is at the bottom of the pull-down list, it would be best at the top. Zoeannl (talk) 23:56, 16 September 2018 (UTC)

My first index

I'm abut to transcribe my first book index, starting at Page:Bird Haunts and Nature Memories - Thomas Coward (Warne, 1922).pdf/273. Does anyone have any tips, good examples or recommended templates, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:16, 15 September 2018 (UTC)

I generally proof them like extended tables of contents. (I also don't preserve the two-column layout unless there is a good reason for it.) Page numbers can be linked using {{DJVU page link}} if you think it's worthwhile, otherwise they're transcribed as-is. If you run into any ditto marks, there's a template for that.

I like to link topics as close to where they are in the work as is possible. If there's a proper section heading with an anchor, they can be linked to that, otherwise just to the chapter. (Thus it's sometimes useful to have already figure out the TOC/how the work will be organized in the main namespace.)

It's really just like proofreading/transcribing a set of highly ordered pages (eg. standardized layout.) It can get tedious. For complex indices I sometimes copy the content into a text editor which supports useful things like regex find/replace, column editing, etc. --Mukkakukaku (talk) 01:53, 16 September 2018 (UTC)

Thank you. Is there a template that will make each line in the source code appear as a new line in the rendered result, as <poem> does, rather than putting <br> at the end of each line? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:18, 16 September 2018 (UTC)

•  Comment Index pages are always a little 'urk', and there is no one way to do them, as it depends on how they are indexed. Please don't retain columns as they don't stitch together well. Add {{anchor}}s at each section and when transcluding put {{compactTOCalpha}} into the notes. Generally with spacing I have just put one empty line between each line, and two empty lines b/w each letter. If you need to centre the Index label, I "noinclude" the formatting as it transcludes poorly. I will also often {{block center}} the entire transcluded set as a left aligned column can look "urk". If you are looking for examples, I have had parked quite a few at user talk:Phe over the years. — billinghurst sDrewth 13:34, 16 September 2018 (UTC)

On the other hand, I never block center/center block indices because I use Layout 2 by default and it looks "urk". ;) But to each, his own.

I sometimes use the {{dhr}} template to guarantee the explicit "blank line" between sections (the software collapses whitespace for you otherwise.) I also find {{plainlist}} to come in useful, though I tend to use it more for ingredient lists in cookbooks than for indices. --Mukkakukaku (talk) 18:05, 16 September 2018 (UTC)

Tech News: 2018-38

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. Images uploaded using Nearby are now automatically added to the associated Wikidata item. You can browse other images on Commons. You can see your achievements and your upload statistics. It has also fixed some bugs. [24]
• MediaWiki web requests now have a time limit of 60 seconds for GET requests and 200 seconds for POST requests. [25]

Problems

• You could not see the menu on the notifications page on the mobile version. This has now been fixed. [26]

Changes later this week

• Special:AncientPages can hide disambiguation pages. [27]
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 18 September. It will be on non-Wikipedia wikis and some Wikipedias from 19 September. It will be on all wikis from 20 September (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 19 September at 15:00 (UTC). See how to join.

Future changes

• The developers are testing new mobile web navigation. You can use it and give feedback.

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

21:58, 17 September 2018 (UTC)

The GFDL license on Commons

This has been posted here because your wiki allows local file uploads. Please help translate to your language.

Commons will no longer allow uploads of photos, paintings, drawings, audio and video that use the GFDL license and no other license. This starts after 14 October. Textbooks, manuals and logos, diagrams and screenshots from GFDL software manuals that only use the GFDL license are still allowed. Files licensed with both GFDL and an accepted license like Creative Commons BY-SA are still allowed.

There is no time limit to move files from other projects to Commons. The licensing date is all that counts. It doesn't matter when the file was uploaded or created. Every wiki that allows local uploads should check if bots, scripts and templates that are used to move files to Commons need to be updated. Also update your local policy documentation if needed.

The decision to allow files that only have a GFDL license, or not allow them, is a decision all wikis can make for themselves. Your wiki can decide to continue allowing the files that Commons will no longer allow after 14 October. If your wiki decides to continue to allow files after 14 October that Commons will no longer allow those files should not be moved to Commons. — Alexis Jazz, distributed by Johan using MassMessage

18:11, 20 September 2018 (UTC)

WEF framework / Wikidata gadget — confirm that it is again working

The WEF framework gadget has been reconfigured, so it broke here. I have played with the mediawiki configuration, and I believe that it is functional again. I would appreciate if someone can please confirm that it is working. Thanks. — billinghurst sDrewth 23:37, 20 September 2018 (UTC)

Vulgate

An editor has proposed at w:Wikipedia:Village pump (miscellaneous)#Vulgate that we need a better and more complete Vulgate here (presumably an English translation). BD2412 T 02:30, 19 September 2018 (UTC)

It wasn't clear to me from the query whether it was a request for the Latin Vulgate or an English translation. The standard English translations of the Vulgate are the Bible (Douay-Rheims) translations. As with many translations into English, there are multiple editions extant. --EncycloPetey (talk) 03:15, 19 September 2018 (UTC)

The main Bible focus here at present is getting the KJV scan-backed. I doubt the current group of enWikisourcerors have the capacity to work on another version/translation right now. Beeswaxcandle (talk) 03:30, 19 September 2018 (UTC)

yeah, if User:Temerarius wants to show up, and get started, i would help him. here is an 1844 edition [28], and a 1852 [29] but i am past patience with the aspirational directive form of collaboration. too many other backlogs on my to do list. Slowking4 ‽ SvG's revenge 17:29, 19 September 2018 (UTC)

If it is something we should eventually have, then it can't hurt to set up the project. If others want to follow through, that's on them. BD2412 T 22:31, 19 September 2018 (UTC)

Without a lack of clarity of what is needed, I am not certain that we can give specific advice. We can give general advice of 1) Straight transcription belongs at laWS. 2) If scans exist then they can be translated in our Page: ns. 3) If you want it done, it is our experience it will require a team of interested and committed people and a project is the best means to coordinate such. — billinghurst sDrewth 22:36, 19 September 2018 (UTC)

I'm sorry I wasn't clear: I was inquiring about the Latin text. There are a number linked at https://en.wikipedia.org/wiki/Vulgate, to which presumably no copyright restrictions apply. Temerarius (talk) 15:40, 22 September 2018 (UTC)

@Temerarius:The Latin text would need to be uploaded to the Latin Wikisource. And some of the Latin editions do have copyright restrictions. The Latin text is itself a translation from the Greek, attributed to Jerome, but the most recent revision was issued in the middle of the 20th century. That edition would still be protected by copyright. --EncycloPetey (talk) 17:28, 22 September 2018 (UTC)

Template to mark works ineligible for copyright due to lack of human authorship

I propose either creating a new template (perhaps {{PD-machine}}), or altering our current {{PD-ineligible}}, to account for works that are in the public domain due to the absence of human creative expression. This template would make clear, for example, that machine translations of non-English works may be freely hosted here (so long as the foreign-language original works are also eligible).

The question whether machine translations may be hosted here has been discussed at meta: Wikilegal/Copyright for Google Translations, which concludes that such Google holds no U.S. copyright in the automatic translations produced by its software.

Guidance from the U.S. Copyright Office also supports this conclusion. Section 306 of the current (2017) Compendium of U.S. Copyright Office Practices states:

The U.S. Copyright Office will register an original work of authorship, provided that the work was created by a human being.

The copyright law only protects “the fruits of intellectual labor” that “are founded in the creative powers of the mind.” Trade-Mark Cases, 100 U.S. 82, 94 (1879). Because copyright law is limited to “original intellectual conceptions of the author,” the Office will refuse to register a claim if it determines that a human being did not create the work. Burrow-Giles Lithographic Co. v. Sarony, 111 U.S. 53, 58 (1884). For representative examples of works that do not satisfy this requirement, see Section 313.2 below.

The cross-referenced Section 313.2 does not expressly mention translations, but it does provide, in part, that “the Office will not register works produced by a machine or mere mechanical process that operates randomly or automatically without any creative input or intervention from a human author.” This further supports the principle that machine translations contain insufficient human expression to qualify for their own copyright protection.

At present, none of our Category:License templates address the human authorship requirement directly. The closest analog is {{PD-ineligible}}, which addresses works that “consist[ ] entirely of information that is common property and contain[ ] no original authorship.” All the works marked with the present version of {{PD-ineligible}}, however, appear to be the product of human authorship (or at least human transcription), and the {{PD-ineligible}} tag does not appear to address the ineligibility of non-human-originated works as discussed in the above-quoted language from the Compendium.

Because {{PD-ineligible}} in its present form does not quite fit the scenario of works created by machine, I suggest creating a new template that would expressly note that the lack of human authorship disqualifies such works from copyright protection in the United States. Tarmstro99 14:45, 8 September 2018 (UTC)

Even if Google holds no U.S. copyright in the automatic translations produced by its software, how about adding quick links from Wikisource? Perhaps machine translations will be improved, thus evolving.--Jusjih (talk) 01:52, 25 September 2018 (UTC)

Tech News: 2018-39

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 preferences form will change to use the standard look. If you see any problems please report them on Phabricator. [30]
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 25 September. It will be on non-Wikipedia wikis and some Wikipedias from 26 September. It will be on all wikis from 27 September (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 26 September at 15:00 (UTC). See how to join.

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

15:23, 24 September 2018 (UTC)

Infoboxes on categories?

At Commons they have infoboxes that pull Wikidata, similarly to how we pull data for our headers; {{wikidata infobox}} and an example of use at c:Category:Alfred Odgers. We have been less than active with our labelling of categories, and while some have the use of {{plain sister}}, others have nothing. In a Commons's conversation it was asked whether it was of interest to us to utilise their schema for infoboxes. I am not adverse to its use

Notes:

• The modules that are utilised have some similar functionality with some of our existing modules
• Commons coding fraternity is reasonably active, so there is opportunity for access to more lua coders skilled at pulling Wikidata
• We are not the best categorisers, and generally don't do people categories

Thoughts? — billinghurst sDrewth 23:15, 24 September 2018 (UTC)

Commons has a preference setting that puts the categories at the top. It is easier to have an opinion if you can see what you are making the opinion on.--RaboKarbakian (talk) 00:26, 25 September 2018 (UTC)

Not sure what to do with that comment. Any preference that Commons has, we have. Any gadget that Commons has, we can have, or individually one can run using a configuration line in your Special:mypage/common.js. — billinghurst sDrewth 02:13, 25 September 2018 (UTC)

Our category naming and structure differ significantly from that used on Commons and the Wikipedias. --EncycloPetey (talk) 00:32, 25 September 2018 (UTC)

As with our author and portal namespace, local naming and structure is not particularly pertinent. All this would do is put the data boxes into place, and display Wikidata with matching data as we do in main, author, and portal nss. Presumably (though we should check) if a category is not connected to Wikidata, then its display would be 'hide'. — billinghurst sDrewth 02:13, 25 September 2018 (UTC)

I disagree. Category naming and structure here is vastly different from other projects, and the names in the infobox will match the Wikipedia/Commons model. With the Author namespace, we are dealing with the name of the author and relevant dates. There is no major disconnect in that case. But pulling the names of Categories from Wikidata will more likely confuse users than help, and will encourage the creation of parallel category structures here to match Wikipedia and Commons. Both are strong negative points for me. --EncycloPetey (talk) 02:33, 25 September 2018 (UTC)

I have copied it (and the required modules and their required modules (ad nauseaum)) on User:Einstein95/sandbox. I particularly find the "Notable Work" field quite interesting, it might lead people to start adding texts that we don't have if they're fans of authors or genres. -Einstein95 (talk) 06:09, 25 September 2018 (UTC)

commons has a structured data on commons, and much work, standardizing metadata in templates.

we could increase links from wikisource to wikidata; could create items: "Wikisource author page" and "wikisource work" page, they have an index page item [31], with status [32], and wikisource links at footer.

we could increase our use of wikidata at author and work header pages. (will have to relax edition specification) we could modify author and header template to pull from wikidata. Slowking4 ‽ SvG's revenge 20:28, 25 September 2018 (UTC)

Just a couple of brief comments (background: I wrote and maintain the infobox). It doesn't have to be used in categories - it should work equally well in other namespaces. It currently follows d:Property:P301 to go from category to topic items - if it would make sense to follow a different link to fetch the topic information then that should be possible. The infobox is built on modular code (Module:WikidataIB), so pieces of it (row lines, auto-categorisation, etc.) could be reused in e.g. {{Author}} (if that isn't the case already). I'm happy to provide help with using the infobox and WikidataIB if that's useful (on the parser function and bot editing sides - I don't know Lua). Thanks. Mike Peel (talk) 21:08, 25 September 2018 (UTC)

 Comment On WP they use infoboxes in articles much like we use headers. Would it perhaps be more in keeping with the rest of WS if instead of category infoboxes we introduce category headers that perform similar function? —Beleg Tâl (talk) 23:38, 25 September 2018 (UTC)

I'd be mildly opposed to making our categories look like Author, Portal, and Work pages. Also, anyone who uses other projects will arrive with a certain expectation of what categories will look like, and doing something to violate that expectation seems a bad idea to me. --EncycloPetey (talk) 00:53, 26 September 2018 (UTC)

I strongly support this proposal, which will add semantic richness to our category pages. The templates work well, with overwhelming popular support, on Commons. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 05:30, 26 September 2018 (UTC)

What is the correct date?

We have had a contributor newly add:

Declaration of education The announcement of Fifty Industrial Community College on 18 June 1997

which appears to be a Google-translated copy of the same work as

Declaration of education The announcement of Fifty Industrial Community College on 18 June 1996

Can we determine the correct date so as to effect a merger? --EncycloPetey (talk) 01:01, 26 September 2018 (UTC)

According to File:ฯพณฯสุขวิช รังสิตพล รัฐมนตรีว่าการกระทรวงศึกษาธิการประกาศจัดตั้งวิทยาลัยการอาชีพ.jpg, it gives the year as B.E. 2540, which corresponds to 1997 C.E. -Einstein95 (talk) 04:50, 26 September 2018 (UTC)

This is also shown on the Thai Wikipedia article :

พ.ศ. 2540 (ค.ศ.1997) - นายสุขวิช รังสิตพลประกาศจัดตั้งวิทยาลัยการอาชีพ 51 แห่ง

-Einstein95 (talk) 04:54, 26 September 2018 (UTC)

Document itself says 1997. I have moved the first added to the 1997 space, though I think that it needs to be moved to the translation namespace, and we need to correct the case and grammar of the title. — billinghurst sDrewth 06:10, 26 September 2018 (UTC)

New Wikidata templates

The templates {{Reasonator}} and {{Scholia}} are available, for linking from Wikisource pages to representations of Wikidata items, where no suitable Wikipedia page is available as a target. They are modelled on {{WikiDark}}, with the same low-contrast links. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 05:26, 26 September 2018 (UTC)

Wikiscan Statistics

For general information. A statistics of this site is available here, maintained by Wikimedia France. Hrishikes (talk) 03:31, 27 September 2018 (UTC)

thank you. here are some old format, continuously updated stats https://tools.wmflabs.org/phetools/stats.html -- Slowking4 ‽ SvG's revenge 13:37, 27 September 2018 (UTC)

hyphenated words

Just FYI: Such usage is broken now due to phab:T104566 change in proofreadpage (it was "queen mother" in transclusion before by change). Probably some review of pages ending with hyphen (minus) is needed. Ankry (talk) 22:27, 29 September 2018 (UTC)

Er, you mean a hyphenated word broken at the hyphen at the page break? Like mother-in-law? You can use the {{hyphenated word start}} and {{hyphenated word end}} templates for that. Eg. If mother-in-law is broken like 'mother-' and 'in-law', then you can do: {{hws|mother|mother-in-law}} and {{hwe|in-law|mother-in-law}}.

So for queen-mother it would be {{hws|queen|queen-mother}} and {{hwe|mother|queen-mother}}.

Unless I've misunderstood what you're getting at? --Mukkakukaku (talk) 23:02, 29 September 2018 (UTC)

@Mukkakukaku: I mean, that the hyphen is now removed by software. So if it is intended to remain, its usage is broken. Ankry (talk) 23:06, 29 September 2018 (UTC)

In most cases, the removal makes things working as an editor intended however (as most hyphens at the end are missing {{hws}}/{{hwe}}). Ankry (talk) 23:08, 29 September 2018 (UTC)

I'm still not sure what you're getting at? I've looked and it appears to be working as expected, and as we've described it at Help:Formatting conventions (section "hyphenated end of page words"). Do you have an example where it's not working this way? --Mukkakukaku (talk) 03:16, 30 September 2018 (UTC)

@Mukkakukaku: The change is this: say the word is beautiful. On first page end, you can write beauti- and on next page start, -ful. No template required. On transclusion, it will become beautiful. But for rendering actual hyphenated words like mother-in-law, you'll still need template use (hws/hwe). This is an alternative method. The templates still work. Hrishikes (talk) 03:51, 30 September 2018 (UTC)

Ankry is trying to say that originally there was written "queen -" on one page ane "mother" on the other, which rendered "queen - mother". However after the change in proofreading software it renders "queen mother", which is wrong, and so he changed it using the template hws. His suggestion that all pages ending with a hyphen should be reviewed because of the change and possibly also corrected in the way he did here which should have probably been done immediately after the change) sounds reasonable to me. --Jan Kameníček (talk) 07:12, 30 September 2018 (UTC)

There is also the possibility of trailing hyphens wither within or at the end of dialog. We may need to look for those as well to be certain they are not affected. --EncycloPetey (talk) 15:25, 30 September 2018 (UTC)

Words hyphenated across pages in Wikisource are now joined

Hi, this is a message by Can da Lua as discussed here for wikisource communities

The ProofreadPage extension can now join together a word that is split between a page and the next.

In the past, when a page was ending with "concat-" and the next page was beginning with "enation", the resulting transclusion would have been "concat- enation", and a special template like d:Q15630535 had to be used to obtain the word "concatenation".

Now the default behavior has changed: the hyphen at the end of a page is suppressed and in this case no space is inserted, so the result of the transclusion will be: "concatenation", without the need of a template. The "joiner" character is defined by default as "-" (the regular hyphen), but it is possible to change this. A template may still be needed to deal with particular cases when the hyphen needs to be preserved.

Please share this information with your community.

MediaWiki message delivery (talk) 10:28, 30 September 2018 (UTC)

So no more {{hws}} except for special cases maybe. This is great! Maybe we can get something done about the em dashes ending at the end of the page also? Make it default join the words with the em dash intact? Jpez (talk) 11:16, 1 October 2018 (UTC)

Except now apparently we'll need to template the opposite use case, right? So instead of the hyphenated word start/end templates which would collapse the hyphen, we'll now need something to preserve the hyphen? (And, more complicatedly, will now have to go find all the places where we were relying on the old behavior to preserve the hyphen.) --Mukkakukaku (talk) 05:37, 3 October 2018 (UTC)

For preserving the hyphen, writing &#x2010 and semicolon will suffice, if the hyphen is not part of a combined word. Template use in case of combined word with hyphen. Hrishikes (talk) 15:44, 3 October 2018 (UTC)

I suspect even typing &#45; will work to preserve the hyphen too, won't it? —Mahāgaja (formerly Angr) · talk 17:01, 13 October 2018 (UTC)

See Page:Morris-Jones Welsh Grammar 0125.png and Page:Morris-Jones Welsh Grammar 0126.png for what to do if an italicized word is split across a page boundary. The bottom of the first page requires ''gwar- (no closing double apostrophe) and the top of the second page requires <noinclude>''</noinclude>. Then the italicized word appears correctly in both Page: namespace and mainspace. If you close the double apostrophe at the bottom of the first page, the spell is broken and mainspace will show a hyphen followed by a space; see the bottom of Page:Morris-Jones Welsh Grammar 0079.png and its transclusion at A Welsh Grammar, Historical and Comparative/Phonology#80 for an example. —Mahāgaja (formerly Angr) · talk 17:17, 13 October 2018 (UTC)

Breaks around image-pages

This breaks where there is an intermediate image page, as on The Migration of Birds/Chapter 7. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:17, 9 October 2018 (UTC)

@Pigsonthewing: -- Please check whether it is OK now. Hrishikes (talk) 14:39, 9 October 2018 (UTC)

Thank you. It is, but I was leaving it so others could see the effect. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:47, 10 October 2018 (UTC)