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


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

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


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)


Bot approval requests[edit]

Repairs (and moves)[edit]

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

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

N-like character[edit]

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

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

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

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

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

Tech News: 2018-35[edit]

16:16, 27 August 2018 (UTC)

em-dash at page end[edit]

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)TCM 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?[edit]

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

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 -- Slowking4SvG's revenge 21:44, 2 September 2018 (UTC)

Word order jumbled[edit]

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

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)

Tech News: 2018-36[edit]

16:47, 3 September 2018 (UTC)[edit]

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 (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[edit]

13:33, 6 September 2018 (UTC)

CC-BY 4.0 as default license in upload forms[edit]

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.
Derivative of medical imaging.jpg
  • 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:

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


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)TCM 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 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)TCM 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. Slowking4SvG's revenge 12:24, 5 September 2018 (UTC)
  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) Slowking4SvG'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[edit]

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

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)

Yes check.svg 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[edit]

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)
Yes check.svg handled at template talk:Authorbillinghurst sDrewth 21:53, 13 September 2018 (UTC)

Tech News: 2018-37[edit]

22:35, 10 September 2018 (UTC)


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)
  • Pictogram voting comment.svg 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 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[edit]

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

Aux TOS now full-width?[edit]

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

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

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

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)
  • Pictogram voting comment.svg 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[edit]

21:58, 17 September 2018 (UTC)