Wikisource:Scriptorium

SpBot archives all sections tagged with {{section resolved|1=~~~~}} after 31 days and sections whose oldest comment is older than 30 days.

Proposals

A minor Charinsert modification suggested

I suggest to modify our MediaWiki:Gadget-charinsert-core.js by moving the 'User' row to be the first row, (which is the default row). I modified a copy in my user space CharInsert|HERE, and it works fine.

The reason being is that the browser cookies no longer store the user's preferred selection to be the default row. If there is a replacement mechanism, it's not working. I must re-select the 'User' row on every page being edited. This being the 23rd row, it defies logic. Ineuw (talk) 18:08, 14 July 2019 (UTC)

Tentative  Support though it would be better to have it remember selection per user (I use "insert" far more often than "user") —Beleg Tâl (talk) 15:20, 15 July 2019 (UTC)

@Ineuw: MediaWiki:Gadget-charinsert-core.js uses the mediawiki.storage API, which is a wrapper around HTML5 Web Storage. This works similarly, but not identically, to traditional cookies. The biggest difference in this case is that there is no good way to inspect what's in this storage in any of the big browsers that I've found (though I might be able to cook you up a custom script to inspect the charinsert cookie if you want it for debugging).

However, I just checked using the custom charinsert list from your vector.js and it seems to work just fine in the latest Safari, Chrome, Firefox, and Vivaldi. Is it possible that you've jacked up a security setting anywhere at some point? You don't have some kind of extra-paranoid antivirus running?

In any case, I don't have any strong opinion on the proposed change beyond it seemingly being prompted by what looks like a local issue; and that it will mean everyone without a preference set (including all non-logged-in users) will be presented with an empty list and a drop down labelled "User". I use charinsert so rarely that I don't really have a good grasp of the needs of those who do. -- Xover (talk) 15:36, 15 July 2019 (UTC)

@Xover: Thanks for the offer but I am really satisfied using the modified script of my namespace. The problem was that the new wrapper worked for awhile, but stopped working before the current wmf software update. Most likely because of the prior update. So, this solution is only good for those who are logged in and mostly use the "User" row. PS: I scanned for viruses an hour ago, but will re-boot and do a boot time scan as well. Ineuw (talk) 01:15, 16 July 2019 (UTC)

@Ineuw: It's also still working fine for me. It remembers whatever section I last chose. I believe that Xover was suggesting that you might be experiencing interference from a security or anti-virus program, not that you have a virus. After checking your security settings (to make sure they aren't restricting the use of Web Storage by Javascript), you might also want to clear out your local storage for Wikisource from the browser's Javascript console: localStorage.clear();. Hope that helps. Kaldari (talk) 01:12, 15 August 2019 (UTC)

Thanks for the warning. I've been focusing on what I might have done with the various antivirus etc. settings. — Ineuw (talk) 01:26, 15 August 2019 (UTC)

If it is failing, it is on a user basis, or a browser basis (which seems disproven). I am seeing no issues with Firefox with it remembering between pages or sessions. Probably worth testing on another browser, or another computer, to see if you can replicate. — billinghurst sDrewth 01:35, 15 August 2019 (UTC)

 This section is considered resolved, for the purposes of archiving. If you disagree, replace this template with your comment. — billinghurst sDrewth 02:10, 15 August 2019 (UTC)

New speedy deletion criterion for person-based categories

Following on from a discussion at WS:PD#Speedy deletion of author based categories.

It is long established and in the main uncontroversial that English Wikisource does not use person-based categories (of the type "Works by John Smith", "Poetry by John Smith", etc.). Some previous discussions can be found at: 1, 2, and 3 (and the two following threads). However, absent a speedy deletion criterium specifically for these, admins have to rely on the provision for precedent-based deletions. In practice this means such categories must be brought to WS:PD to be rubber stamped, wait at least two weeks (because inertia and habit), and then hopefully someone will remember to process them. Eventually.

I therefore propose that we extend the deletion policy with a new G8 criterion as follows:

• Person-based categories—Categories where the defining characteristic is person-based. This includes, but is not limited to, author-based categories like "Works by author name".

All deletions (modulo CU type concerns) are subject to community challenge in any case, and are clearly visible in the deletion log, so there is no particular benefit to the bureaucracy where there exists no significant uncertainty or controversy. --Xover (talk) 14:32, 15 July 2019 (UTC)

 Support, but I'd note that there is an exception discussed in link #2: namely, American presidential documents categorized by president. This is due to the fact that the administration of the executive branch is tied to who is the president at the time. There was no consensus as to the scope of this exception: what kinds of presidential documents it applies to, or whether other governments may have the same treatment, etc. —Beleg Tâl (talk) 14:42, 15 July 2019 (UTC)

 Oppose 2 weeks is not too long to wait. organization of subject of a work is useful, a migration to a stable ontology is necessary. Slowking4 ‽ Rama's revenge 13:58, 30 July 2019 (UTC)

2 weeks is definitely too long to wait when a full beaurocratic procedure with a foregone conclusion could be replaced with a simple administrative action. —Beleg Tâl (talk) 14:32, 30 July 2019 (UTC)

Also it is worth pointing out that this proposal is not regarding whether such categories should be kept or deleted (since we have already established that they should be deleted), but only whether they should be posted to WS:PD before we delete them. —Beleg Tâl (talk) 18:51, 30 July 2019 (UTC)

And that strictly speaking, under current policy, they can be deleted a few days after a notice has been posted to WS:PD (no two week wait required, just that the discussion must have "started"). It's just that habit and inertia inevitably means that almost all cases will in practice suffer this 2+ week purely bureaucratic delay. I'm a big believer in process and the value of bureaucracy when properly deployed, but even I think this one is a pointless waste of volunteer time. We have issues that require actual discussion or other action that have sat open on the noticeboards for a year and a half; we should not waste those resources on filling out forms in triplicate for issues that are not controversial. Any deletion can be reviewed and overturned, if needed, by the community; let's save the cautious multiple-safeguards approach for stuff that might actually need it. --Xover (talk) 19:11, 30 July 2019 (UTC)

I always wait until there has been a full month of inactivity, since there are many editors who only edit occasionally, but that's just me. —Beleg Tâl (talk) 19:17, 30 July 2019 (UTC)

 Support --EncycloPetey (talk) 17:40, 30 July 2019 (UTC)

 Support --Jan Kameníček (talk) 19:38, 30 July 2019 (UTC)

 Support though if possible I'd like to see the exception Beleg Tâl specified firmed up a bit, i.e. perhaps a general exception for things like governments, ministries, and reigns which are "person-based" but serve an obviously different function to categories-by-author (noting on the UK side things like Category:Acts of the Parliament of Great Britain passed under George III). —Nizolan ^(talk) 00:44, 1 August 2019 (UTC)

• Note Based on the discussion above I have added the above criterion with an additional limitation to exempt things like UK governments tied to a monarch's regnal period or the administrations of US presidents. I read the above as general support for this criterion—sufficient for adding it—but with some remaining uncertainty about the optimum phrasing. I'll therefore leave this discussion open for a while longer so that interested parties may object or suggest better wording. I'll also add that minor changes to the wording (that do not change the meaning) can easily be made later with a proposal at the policy talk page. And we can always bring bigger changes up here for reevaluation if it causes problems. --Xover (talk) 19:32, 11 August 2019 (UTC)

 This section is considered resolved, for the purposes of archiving. If you disagree, replace this template with your comment. — billinghurst sDrewth 02:09, 15 August 2019 (UTC)

Bullets paragraph separator

Does anyone have any objection if I create a new template with bullets from a copy of {{***}}?

⁠•⁠•⁠•⁠

⁠•⁠•⁠•⁠•⁠

⁠•⁠•⁠•⁠•⁠•⁠

⁠•⁠•⁠•⁠•⁠•⁠•⁠

⁠•⁠•⁠•⁠•⁠•⁠•⁠•⁠

-- — Ineuw (talk) 15:53, 31 July 2019 (UTC)

Shouldn't be a problem, but why not use {{***|char=•}} ? —Beleg Tâl (talk) 17:40, 31 July 2019 (UTC)

In order to form an opinion on that I would need to understand what the new template's purpose was, and why the existing template doesn't do the work. I am generally of the opinion that we have too many obscure and poorly documented templates that are hard to maintain—and that this is something we should seek to improve, or at least avoid making worse—but I can't say whether that would be at all relevant to this specific case. *shrug* Is it possible to adapt an existing template to do what you want? --Xover (talk) 17:51, 31 July 2019 (UTC)

Thanks for the reminders. I was daft for not re-checking the documentation. P.S: This won't be my last "ingenious" proposal, so please bear with me and continue to point out the errors of my ways. — Ineuw (talk) 22:59, 3 August 2019 (UTC)

Not done existing capability — billinghurst sDrewth 02:11, 15 August 2019 (UTC)

 This section is considered resolved, for the purposes of archiving. If you disagree, replace this template with your comment. — billinghurst sDrewth 02:11, 15 August 2019 (UTC)

RFC: Allow curly quotes under some conditions

Per the discussion above, I would like to propose that the following change be made to Wikisource:Style guide: Replace... Use typewriter quotation marks ("straight," not “curly”). ...with...
Curly quotation marks are permitted only if they are used in the original work and are used consistently throughout the transcription. Otherwise straight quotation marks are recommended.
Please express whether you support or oppose this change. Kaldari (talk) 15:39, 14 August 2019 (UTC)

Support. Two suggested tweaks to the language:

Instead of the word "ensure" (which occurs twice), I suggest "unless one or more Wikisource users are committed to ensuring." It's impossible to ensure anything on a public wiki; and I can foresee unresolveable arguments about what it means to "ensure" this in any given case. But, the stated intention of a single wiki user can be a powerful thing, and is possible to define more clearly.

I find the parenthetical section slightly confusing. I think it means that a large number of contributors would make it harder to ensure consistency; but that isn't entirely clear, and that's not necessarily true. So instead, perhaps, "(e.g., because many contributors, without a clear or enforceable agreement on style conventions, are likely to contribute to this particular work.)" -Pete (talk) 17:09, 14 August 2019 (UTC)

@Peteforsyth: I've tweaked the wording to address your concerns. Kaldari (talk) 00:55, 15 August 2019 (UTC)

Thanks, that's an elegant solution. -Pete (talk) 01:04, 15 August 2019 (UTC)

Oppose. 1) Curly quotes should be allowed regardless of the style of quotes in the source scan, just like straight quotes. 2) I cannot tell if your wording intends to cover other systems of punctuation such as „lower quotation marks“ or «guillemets», which should never be replaced with upper quotation marks of either style. —Beleg Tâl (talk) 17:27, 14 August 2019 (UTC)

@Beleg Tâl: I've tweaked the wording to address your concerns. Kaldari (talk) 00:53, 15 August 2019 (UTC)

I agree with what I think Beleg Tâl is saying...if we're going to alter the policy, it should permit using other kinds of quotes (at least, if they are what the original uses). In fact, I think if several contributors agree that guillemets are the appropriate choice in a specific work, even if they weren't used in the original, there might be good reason for it, and it shouldn't be expressly disallowed. -Pete (talk) 01:04, 15 August 2019 (UTC)

@Kaldari: I appreciate the update. My concern #1 still applies so I am not comfortable supporting the proposal as it stands. —Beleg Tâl (talk) 13:24, 15 August 2019 (UTC)

Oppose. I do want curly quotes allowed but don't favor the proposed version of the proposal. I agree with both Beleg Tâl’s comments. I think that the only restriction should be something like, if a work already wholly or partially proofread uses straight quotes throughout, a user should not introduce curly quotes unless they're committed to changing the whole thing to curly. Levana Taylor (talk) 18:26, 14 August 2019 (UTC)

@Levana Taylor: I've tweaked the wording to address your concerns. Kaldari (talk) 00:53, 15 August 2019 (UTC)

I don’t think "all contributors to the transcription agree to use them consistently" is a practically workable condition to impose. What if (as is extremely likely) some early contributors can no longer be contacted? Someone who comes in later ought to be able to make a global change as long as they change the whole thing. Levana Taylor (talk) 02:22, 15 August 2019 (UTC)

@Levana Taylor: I've tweaked the wording again. Hope that sounds better. Kaldari (talk) 02:43, 15 August 2019 (UTC)

Yes! This is more like it. I can support this simplified version, which leaves it open whether consistency is to be achieved by consensus (e.g. on projects that have a discussion page), or (in smaller works) one person going through the whole thing. And I don't mind restricting use of curly quotes to works that use them in the original. Use of straight quotes is something of a special case -- might be found in modern documents (e.g. government work being added here), and it makes sense to keep that style, I guess. We still have to mention. guillemets and German „goose feet“ … maybe the wording should be re-organized, more or less thus: straight quotes, guillemets, etc. should be kept as in the original. If the original has curly quotes, these may have straight quotes substituted for them, or curly quotes may be used; the latter should only be done if they are used consistently throughout the transcription. Levana Taylor (talk) 03:51, 15 August 2019 (UTC)

Comment. The previous voting discussion has shown that there are supporters of the change in favour of other than only straight quotes, but they prefer various solutions. For this reason it is probably not a good idea to pick one of them and vote simply for or against, it would be better to vote about all of them and choose the one with the biggest support. (BTW, the chaos accompanying this process, when somebody considered the discussion to be voting, while others were waiting for the voting to start, is a result of missing instructions similar to Wiktionary:Voting policy and Template:vote on hold.) --Jan Kameníček (talk) 18:57, 14 August 2019 (UTC)

Pinging other folks involved in the original discussion: @Prosfilaes, @EncycloPetey, @Billinghurst, @Xover: @Nizolan, @TE(æ)A,ea., @Koavf, @Beeswaxcandle:. Kaldari (talk) 10:03, 15 August 2019 (UTC)

Support. I have made two changes to the style guide in favour of this; the first, a more general approach favouring standardisation, and the second, a more specific approach similar to the desires of Jan Kameníček and Levana Taylor. TE(æ)A,ea. (talk) 11:51, 15 August 2019 (UTC).

Sorry to contribute to the nit-picking but though I'd like to support this I'm not sure on the current wording because there's a disproportion between the two parts: if curly quotes are only permitted under certain conditions then why are straight quotes merely recommended otherwise? What's the alternative? Also agree with BT above that exceptions for guillemets and other forms should be specified. —Nizolan ^(talk) 12:49, 15 August 2019 (UTC)

Oppose. We're having a vote where the text is being tweaked throughout the vote after some people have voted. We need to vote on a set text, not be adjusting it throughout the vote. You don't change the candidates or platforms once the vote has begun. --EncycloPetey (talk) 15:18, 15 August 2019 (UTC)

If the tweaking doesn't go on for too long, it's not very hard to check in with the early voters and find out whether/how it impacts their votes. I stated above that the tweaks were to my liking, other early voters could always comment/clarify as well. But I think we're in agreement that it's best to at least limit/minimize changes in order to have a coherent vote. -Pete (talk) 16:49, 15 August 2019 (UTC)

Weak Support, as it is better than forcing everybody to use only straight quotes, but I am not very happy with the specific expression “curly quotes” instead of "the same kind of quotation marks as the work presents". There are several kinds of "curly" quotes and I believe they should not be used interchangeably. If a work uses “” the contributors should not use ’ ’ or „“, although they are all curly. --Jan Kameníček (talk) 22:18, 15 August 2019 (UTC)

The current MOS guideline to use straight quotes only does not imply that users can use ' ' in place of "; neither would this updated guideline imply that users can use ’ ’ in place of “”. Curly quotes in this context means specifically “this” as opposed to "this", and ‘this’ as opposed to 'this'. It would still be wrong to use “this” in place of ‘this’, or in place of «this», or in place of literally anything except "this". —Beleg Tâl (talk) 23:50, 15 August 2019 (UTC)

Alt proposal: Allow curly quotes under any conditions

I propose that, rather than the above change to WS:MOS, we instead change

• Use typewriter quotation marks ("straight," not “curly”).

to the following:

• Use a consistent style of quotation marks ("straight" or “curly”) within a given work. It is recommended to use "straight" quotes in works where there are a large number of contributing editors, since consistent use of “curly” quotes may be difficult to achieve.

—Beleg Tâl (talk) 19:48, 15 August 2019 (UTC)

 Support —Beleg Tâl (talk) 19:48, 15 August 2019 (UTC)

 Support, simple is good. (@Beleg Tâl: there's a typo at the end, "consistant" -> "-ent" fixed)—Nizolan ^(talk) 21:43, 15 August 2019 (UTC)

Support. This is generally similar to my second change to the style guide. TE(æ)A,ea. (talk) 21:47, 15 August 2019 (UTC).

I used your second change as a basis for wording my proposal. —Beleg Tâl (talk) 23:51, 15 August 2019 (UTC)

Oppose. I do not agree with allowing to use curly quotes even in cases when the original works use straight quotes. --Jan Kameníček (talk) 22:00, 15 August 2019 (UTC)

And yet you agree with allowing to use straight quotes even in cases when the original works use curly quotes. I think that if we allow straight quotes in place of curly, but do not allow curly in place of straight, then we may as well continue to disallow curly altogether. —Beleg Tâl (talk) 23:37, 15 August 2019 (UTC)

In my opinion, disallowing the use of curly quotes when a scan uses straight quotes is similar to: disallowing the use of 'a' when a scan uses 'ɑ'; disallowing the use of 'g' when a scan uses 'g'; disallowing the use of '$' when a scan uses ''; &c. —Beleg Tâl (talk) 00:03, 16 August 2019 (UTC)

What if a scan uses German-style lower-level quotation marks, but those quotation marks are straight? There is no straight lower-level quotation mark to replace it with, and you would not allow the replacement of the straight quotation marks with „curly ones“. —Beleg Tâl (talk) 00:04, 16 August 2019 (UTC)

Hmm, I have a hard time imagining a case where this hypothetical problem becomes an actual problem. In most cases, there is no practical problem with one kind of quote...if it's an academic essay, for instance, I really don't see how a reader is done a disservice by encountering “curly quotes” where they expect "straight ones." In a few cases, like poetry, it might actually be significant. In those cases, I have more trust in the good judgment of my fellow Wikisourcers to find the proper solution, than I have in any policy. If a poem had straight quotes, and its appearance would be substantially altered by using curly quotes, it's hard for me to imagine a Wikisource editor who appreciates the poem using the policy to justify changing them to curly quotes. Your objection, Jan, seems to me rooted in worry about something that's very unlikely to happen. -Pete (talk) 00:52, 16 August 2019 (UTC)

Support. Nice, this is very similar to the original proposal, but slightly clearer, and uses more straightforward language. -Pete (talk) 00:52, 16 August 2019 (UTC)

 Support The more I work with epubs the more I want our exported books to look as nice as possible. —Sam Wilson 06:55, 16 August 2019 (UTC)

Bot approval requests

• See Wikisource:Bots for information about applying for a bot status
• See Wikisource:Bot requests if you require an existing bot to undertake a task

Repairs (and moves)

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

Index:The librarians of Harvard College 1667-1877.djvu

In the course of checking the page list, this turned out to be a entire volume of a periodical of which the current title of the Index is only a single issue. I think the file and Index should be retitled and the relevant pages relocated? ShakespeareFan00 (talk) 09:09, 14 July 2019 (UTC)

Moving pages and fixing transcluded pages is a PITA. Make notes on the file that it is a single file, and we can work around it. Even make a redirect at the best name and direct it to this file. This mistake can only occur once, later files will not make the same mistake. — billinghurst sDrewth 02:34, 24 July 2019 (UTC)

Smallrefs and tables over 2 pages

{{Smallrefs}} are not displayed correctly if there is a table spanning over two pages (they are displayed above the table instead at the bottom), see Page:Poet Lore, volume 31, 1920.pdf/489. Can it be corrected, please? --Jan Kameníček (talk) 20:49, 18 July 2019 (UTC)

Done Whenever you have table syntax on the top line of the text editing area, you need to use {{nop}} so that the table syntax will stay on its own line instead of getting moved to flow after the contents of the previous page or section. —Beleg Tâl (talk) 21:11, 18 July 2019 (UTC)

I see, thanks for the help! --Jan Kameníček (talk) 21:17, 18 July 2019 (UTC)

Better that you use {{nopt}} as it is span-based which works better in tables. "nop" is div-based and has issues. — billinghurst sDrewth 02:14, 15 August 2019 (UTC)

Per some advice I was given a while back I've been advised to do multi-page tables like this...

On the first page: (Body):

{|
!Header line
|-
|Line 1

(Footer):

<!-- this goes in the footer -->
|}
{{smallrefs}}<!-- This MUST be on it's own line.

On the intermediate pages:

(Header)

{|
|-
!Header

(Body):

<!-- Continuation of table -->
|-
|Line 1 on page X

(Footer):

<!-- this goes in the footer -->
|}
{{smallrefs}}<!-- This MUST be on it's own line.

On the last page:

(Header):

{|
|-
!Header

(Body):

<!-- Completion of table -->
|-
|Line 1 on Page N
|}

The comments (and the subsequent line-feed HAVE to be included for it to work. (I've used this because it also allows some customisation of the comment used, (such as to note carried over figures to aid other proofreaders and validators.)

{{nopt}} or the approach above will also need to be considered if you have a multi-page table split into sections, which are not coincident with the page boundaries, getting such table right is straightforward if tiresome when building the transcluded versions.ShakespeareFan00 (talk) 06:14, 15 August 2019 (UTC)

Index:H.R. Rep. No. 94-1476

The pages of this should be moved over to the consolidated version of the file under: Index:H.R. Rep. No. 94-1476 (1976).djvu , the destination pages being Page:H.R. Rep. No. 94-1476 (1976).djvu/1 to Page:H.R. Rep. No. 94-1476 (1976).djvu/368, respectively, All the pages of this have been validated, so a simple mass move/rename would be sufficient, (ideally done with a bot.) I already moved the Erratum. ShakespeareFan00 (talk) 16:35, 21 July 2019 (UTC)

Why would we want to move these, I don't see the point. The work is presumably okay, and has been transcluded, so not sure why we would want to move them, and then go and then have to go and check all the tranclusions. Sure it is not the presentation that we prefer, however, it isn't wrong. — billinghurst sDrewth 02:29, 24 July 2019 (UTC)

Okay then, if you think having the single pages is better, then the Erratum should be moved back, I can't do this directly as it would need an admin to ensure the history stayed intact. The consolidated file should then either have the pages duplicated (a bot task) or the consolidated file should be ditched as a direct duplicate. ShakespeareFan00 (talk) 08:51, 24 July 2019 (UTC)

Template:Translation header

It seems that the parameter "original", which should include the name of the page that hosts the original language work with the interwiki link, does not work. --Jan Kameníček (talk) 21:36, 23 July 2019 (UTC)

It works for me, can you give examples? —Beleg Tâl (talk) 02:17, 24 July 2019 (UTC)

The Works of the Right Honorable Edmund Burke/Volume 2 (minor admin request)

Was meant to be a simple replacement of an unsourced text with a scan but for some reason I've been having a complete brainfart putting these in the right place. This and the one subpage at The Works of the Right Honorable Edmund Burke/Volume 2/Speeches at Bristol, 1774 should be at The Works of the Right Honourable Edmund Burke (or possibly something more specific like The Works of the Right Honourable Edmund Burke (1887) because there are a bunch of versions by different publishers all called that). Would be grateful if an admin could move them and delete the pointless hanging redirects I've been leaving while bumbling around (Works of the Right Honorable Edmund Burke/Volume 2/Speeches at Bristol, Works of the Right Honorable Edmund Burke/Volume 2/Speeches at Bristol, 1774, Works of the Right Honorable Edmund Burke/Volume 2). —Nizolan ^(talk) 16:16, 14 August 2019 (UTC)

Done

 This section is considered resolved, for the purposes of archiving. If you disagree, replace this template with your comment. — billinghurst sDrewth 02:17, 15 August 2019 (UTC)

Other discussions

Revisiting curly quotes

Per EncycloPetey's suggestion at the style guide talk page, I would like to have the community revisit the idea of allowing curly quotes. Personally, I hate curly quotes and think they are a pox on humanity, but considering how we go to such great lengths to make our source texts faithful to the originals, it does seem like a prominent inconsistency. I'll try to list a few of the advantages and disadvantages that have been discussed...
Advantages

• Can be more faithful to original text.
• Consistent with Project Gutenberg (and probably the majority of commercial e-texts).
• In some cases, may be easier to read, especially when multiple quote characters are in sequence.

Disadvantages

• Harder to enter.
• Some browsers may not be able to render (according to EncycloPetey in 2015).
• They are often used incorrectly.

As this would be an optional style, I wouldn't give much weight to it being difficult to enter. It's certainly easier that most of our TOCs. And given that it's been 5 years since this was last debated, I have serious doubts that there are still issues around rendering. That basically leaves the objection that they are often used incorrectly, which I would say is also true of all the different dash characters we allow (and even expect). Are there other disadvantages that I'm forgetting? I suppose one is that it would cause inconsistent styles across Wikisource. What are other folks' opinions and thoughts about this? Kaldari (talk) 01:41, 2 July 2019 (UTC)

Curly quotes are better typography and are recommended by Unicode. Some quotation styles are not compatible with straight quotes (like „German quotations“). Browsers that can't handle basic web standards like Unicode are going to have far more serious problems on Wikisource than being able to render curly quotes. It is ridiculous that curly quotes are against our MOS. —Beleg Tâl (talk) 01:48, 2 July 2019 (UTC)

Re: "more faithful to original text" No, this is a typography issue, and has nothing to do with faithfulness to a text. A text has curly quotes because of a printer's choices, not any choice made by the author. And just as we do not specify fonts, we shouldn't bother specifying specific styles of punctuation either. Re: "Consistent with Project Gutenberg" this is irrelevant, and is at odds with the previous claim that using curly quotes would be "faithful to original text". If we're worried about the original text, then why should we care what other sites are doing? And if we're worried about what other sites are doing, then we're not caring about the original text. I'd also point out that Project Gutenberg is in no way consistent about the style of quotes they use. Additional disadvantage: We will need an additional series of quotation template to handle situations currently done with templates like {{' "}} which provide for clarity of punctuation. --EncycloPetey (talk) 03:32, 2 July 2019 (UTC)

It seems like we often try pretty hard to match the typography in the source: Page:KJV 1769 Oxford Edition, vol. 1.djvu/10. Should this be discouraged, in your opinion? Kaldari (talk) 04:02, 2 July 2019 (UTC)

RE: "we often", no this was a single editor over-formatting that page. --EncycloPetey (talk) 17:22, 6 July 2019 (UTC)

•  Comment In the vast bulk of our works curly quotes are not required, and should not be encouraged, and their addition doesn't give value to the works, ie. disadvantages outweigh advantages, especially in true communal works. That said, we have always allowed some variation where there is a reasonable explanation of why a deviation from the style guide can be justified. We haven't been absolutionist about these matters, we just have a valid reasoning for setting a style guide, and generally asking people to follow it, and not deviate "just because", or "because I like them better". The test for a deviation has been an open conversation, and a semblance of consensus. — billinghurst sDrewth 05:32, 2 July 2019 (UTC)

In the vast majority of our works, neither casing, accents nor non-monospace fonts are required. We could go all old-school computer printout style, but given that we support Unicode and rich text, it seems reasonable that we write English as it is supposed to be written, with curly quotes. Their addition makes the text easier to read by adding additional cues as to the meaning of a quote, whether it is opening a quote or closing it. --Prosfilaes (talk) 07:14, 2 July 2019 (UTC)

I Would Çonsidér Accürate Reprǒductión Of Casing And Aççénts To Be Requĩred —Beleg Tâl (talk) 12:58, 2 July 2019 (UTC)

I THINK DECADES OF TELEGRAPHIC AND COMPUTER USE ESTABLISH THAT ACCURATE REPRODUCTION OF CASING IS NOT REQUIRED and a lack of accents in English has decades more of use with ASCII and normal keyboards.--Prosfilaes (talk) 09:32, 3 July 2019 (UTC)

I was considering opening up a discussion on this; it definitely is more faithful to the way English is published. Typographical norms should not be scorned for just being typographical norms.--Prosfilaes (talk) 07:14, 2 July 2019 (UTC)

•  Comment I wouldn't mind them being used but I wouldn't use them personally, because it's another pain for us proofreaders to worry about that isn't worth the hassle. I wouldn't discourage other users from using them though, neither would I mind if a user were to add them in to a work I've proofread and used straight quotes on. In my opinion it is a minor typography issue and I really wouln't care if they're used or not. Jpez (talk) 11:45, 2 July 2019 (UTC)

•  Comment The relevant current text of the Manual of Style reads:

"Use typewriter quotation marks (straight, not curly)."

I agree with what I think most above are saying, which I think would be most succinctly stated as follows:

"Any given work should be self-consistent in terms of the style of quotation marks and apostrophes used. That is, such marks should either all be curly, or all be straight, within any given work. If the initial transcriber of a work has chosen one style, the other style should not be adopted in that work unless a user intends to update the entire work to the new style choice."

I am very skeptical about this: "unless a user intends to update the entire work to the new style choice". Imagine occasional proofreaders doing small chunks of an encyclopedia. I doubt they will check what others have done and even more make it consistent. Pretty sure we will end up with mixed style except for committed users on single works.— Mpaa (talk) 23:30, 2 July 2019 (UTC)

@Mpaa: That's exactly the kind of thing I'm imagining (and have experienced). Here's how I imagine it working, with such a policy (perhaps worded a bit better) in place:

• Me: Hi, I see you've validated about 5% of the pages of this work. That's awesome, thanks! I've proofread about 80% of them. I see that you have changed straight quotes to curly. Are you intending to go through the whole document and change them all to curly?

1. Other editor: Yes, I plan to do that.

Me: Great! I look forward to seeing the final result.

1. Other editor: No, I was just passing through, only interested in this one chapter of the book. I probably won't do more than a few more.

Me: Ah, I see. In that case, would you mind sticking with the convention I began with? (links to MOS) I'd rather stick with straight quotes than go to the trouble of updating all the pages.

In my view, that's a nice, easy way to resolve this "conflict" (which doesn't even need to be a conflict). Having a manual of style that guides us in this direction would, in my view, be a great advantage, and make it possible to quickly and easily arrive at an acceptable solution. -Pete (talk) 22:04, 3 July 2019 (UTC)

A satisfactory solution to an imaginary and likely situation, but that is not how it plays out in folk-lore. CYGNIS INSIGNIS 11:26, 6 July 2019 (UTC)

Hmm, I don't see anything relevant on that work's discussion pages, what am I missing? This is a type interaction I've seen work on many wikis over the years. I'm not sure where you'd anticipate it going off the rails...but, having a clearly articulated policy that sets the parameters is a necessary ingredient. -Pete (talk) 22:19, 6 July 2019 (UTC)

One practical concern is that various automated tools implement one style or the other, and may need to be rewritten or eschewed in order to comply with a change in the Manual of Style. -Pete (talk) 20:27, 2 July 2019 (UTC)

One of the reasons why I was doing this was because the OCR seems to spit out curly quotes, and I was tired of fixing them.

I’m guilty of using curly quotes in some works, where I am (or try to be) completely consistent throughout the whole work. That said, I normally only do it in novels (or this comment), where I’m planing on spending a fair bit of time sitting reading the thing — I think proper typography matters more then (and indeed, I’d say curly quotes, along with correctly-sized dashes and various other non-typewriter or -computer conventions are “proper”). For reference, non-prose, works, I think straight quotes are fine. (Maybe the distinction I’m getting at is between works with large amounts of dialog and those without?) I’ve seen people make the argument that they’re not required because we can make automatic replacements later, but that’s not really true: there are various situations in which it’s impossible to programmatically determine which type of quote character should be used. Anyway, I hope I’m not on the wrong side of common opinion here, but I do like to be able to use curly quotes on Wikisource. —Sam Wilson 11:33, 3 July 2019 (UTC)

I agree with this and Jpez's comment above. I don't see a good reason to forbid them categorically, and can see plausible use cases in novels and the like, even though I probably wouldn't use them myself (the projects I work on are generally academic and often require enough heavy lifting in Unicode without having to fiddle with quote marks). —Nizolan (talk) 14:30, 3 July 2019 (UTC)

On a personal level, I like curly quotes & find them easier to read. But from an editor's-usability standpoint it sure does make sense to convert everything to straight quotes, as the only way to avoid inconsistency. It is much easier to convert curly to straight than vice versa; I have a little application to straighten the quotes in all OCR output, but the reverse process would be no easy matter. I actually began entering Once a Week magazine with curly quotes but EncyloPetey pointed out the standards so I went through several hundred pages I'd entered and straightened the quotes. I am now up to 2000 pages and I am most emphatically not going to revisit all of them and curlify them .... We seem to be stuck with straight quotes as a legacy issue. There would have been ways to make entering curly quotes easier if they had been favored from the beginning; and the OCR output from the application that this site uses now gives us them automatically; but although I don't see a problem with allowing them in certain cases (there are, for a parallel example, a few texts displayed with long s's) a person would have to be urged to think carefully before they started down that route, because so much of the existing apparatus favors straight quotes that avoiding inconsistency would be difficult. Levana Taylor (talk) 23:08, 3 July 2019 (UTC)

It is much easier to convert curly to straight than vice versa is also an argument for curly quotes; transcribing text is all about recovering information from the images that can't be done automatically.

We should be stuck with nothing as legacy issues. If it's better we should make the change, and earlier is better. I'm not sure that much of the existing apparatus favors straight quotes, but this is a chance to change the existing apparatus.--Prosfilaes (talk) 01:07, 4 July 2019 (UTC)

Curly quotation marks are a legacy of printed blocks of text that required incremental spacing, denoting a beginning or end of a quotation if the squelching and stretching of the line made that ambiguous, and few of those legacies are transcribed here (often [or yet]). CYGNIS INSIGNIS 11:18, 6 July 2019 (UTC)

Quotation marks are a legacy of printing; inline quotation marks date no earlier than the 17th century. Printing pervades how we write English, and an attempt to abandon those legacies would produce something unusable or unwelcomed by most of our audience.--Prosfilaes (talk) 07:15, 7 July 2019 (UTC)

There is nothing difficult in writing curly quotes. On Macs and on all modern mobile devices they are easy to enter using the built-in keyboards. On Windows it's probably not built into the default keyboard, but that's what the Special characters button is for.

Old browsers are not a reason not to use modern technology. If they aren't upgraded today, they will be upgraded in a year or two.

A lot of websites that care about quality of presentation use curly quotes. Wikis in some languages have a gadget that converts straight quotes to elegant quotes automatically. Some sites where text can be edited do it as well, for example Quora, and Wikisource could do it (it must not be forced, though).

I actually find it surprising that there are people on English wiki sites who are against curly quotes, given that the English language has such a long typographic tradition of using rich punctuation, with quotes, dashes of various length, etc. --Amir E. Aharoni (talk) 05:47, 4 July 2019 (UTC)

(unindent) I have an idea; it'd take some programming, though. Suppose it was allowed to enter curly quotes, but the software would display them as straight quotes by default. That way, if only part of a text was entered curly, people would usually never notice because it'd all be displayed straight. However, there'd be a user-controlled setting allowing displaying curly quotes where they exist. Levana Taylor (talk) 02:12, 5 July 2019 (UTC)

I don't see the advantage. There's a lot of criticism of the "just add another user-controlled setting" idea in the UI world. It seems a lot better to offer tools to help make the changes and encourage not doing inconsistent changes.--Prosfilaes (talk) 03:46, 5 July 2019 (UTC)

I am also not sure it's a good idea to correct all curly quotes to typewriter quotes user-side by default. There are some cases in texts I've transcribed myself where curly quotes are necessary independently of the general guideline. An example of this is in transliterations of Semitic languages, where the distinct letters ayin and aleph (the half-rings ʿ and ʾ in modern scientific transcription) are often represented by curly apostrophes, ‘ and ’ respectively. In this case correcting these to typewriter quotes would remove necessary information. —Nizolan (talk) 11:51, 5 July 2019 (UTC)

• So far, it looks like myself, Beleg Tâl, Prosfilaes, Jpez, Pete, Sam Wilson, Nizolan, Levana Taylor, and Amir E. Aharoni support allowing curly quotes for some works. EncycloPetey and billinghurst are opposed to the idea, although EncycloPetey more strongly than billinghurst it seems. Kaldari (talk) 04:51, 6 July 2019 (UTC)

Some additional advantages and disadvantages have been mentioned:

More Advantages:

• Easier to convert from curly quotes to straight quotes than vice versa.
• OCR tools already output curly quotes.

More Disadvantages:

• Some new templates will be needed.
• Some tools will need to be updated.

Let me know if I'm overlooking any. Kaldari (talk) 04:53, 6 July 2019 (UTC)

• @EncycloPetey: I'm curious if any of the arguments above have led you to reconsider your opposition (as you seem to be the main opponent of the idea). Kaldari (talk) 04:54, 6 July 2019 (UTC)

  I may be more vocal, but that doesn't mean I'm the "main opponent", it merely means that my voice is stronger in this discussion. It is normal in the Wikisource community for long-time participants to sit back and read discussions without chiming in, so long as their opinion has been expressed by someone in the discussion. I have done this myself. No one in this discussion has explicitly voiced support or oppose, and it would be premature to interpret anyone's opinion when there has been no call for a vote. You've also biased your interpretation: where some editors have said "I don't care", you have interpreted that as "support", but it is not at all the same thing. This is a "community revisit", and not a vote to change policy. --EncycloPetey (talk) 17:32, 6 July 2019 (UTC)

  For the record, I explicitly  Support changing the policy to allow curly quotes at the editor's discretion, and  Oppose continuing to disallow curly quotes. However, this discussion didn't contain a proposal either way, so it doesn't matter until someone posts a proposal for !voting. —Beleg Tâl (talk) 23:19, 6 July 2019 (UTC)

• I think Kaldari's summary is helpful, and I'm not sure why we're talking about whether this is a formal vote when nobody has claimed that it is. FWIW I have no objection to the characterization of my position. I like Jan's version below, making "straight" the default and only permitting “curly” where there's some evidence that curly will be used consistently throughout the work. In fact, that seems like a useful formalization of a principle I expect is already in use in some places, but not formally documented or endorsed. Which IMO is one of the best ways to develop policies on a wiki. -Pete (talk) 22:29, 6 July 2019 (UTC)

To make my position clear, I am very much in favor of allowing curly quotes on a case-by-case basis as long as the editor intends to make a good-faith effort to see they're used consistently (the guideline could be, "please don't add curly quotes to a work that's already partly straight quotes unless you're about to change the whole thing.") Though I worry about how to get it done, I think the problems are solvable, so yeah, in favor. Levana Taylor (talk) 03:20, 7 July 2019 (UTC)

@EncycloPetey: I wasn't trying to hold a vote, I was trying to see if maybe there was consensus for a change in the style guide, in which case, there would be no need for a vote. It is clear from your reply, however, that you are still against the idea, and maybe there are other silent voices that are as well. Also, please let me know whose opinion I have misinterpreted, and I will be happy to revise my statement above. Kaldari (talk) 14:43, 8 July 2019 (UTC)

And by "consensus", I meant actual consensus, not wiki-speak consensus. Kaldari (talk) 14:47, 8 July 2019 (UTC)

I have been following the discussion and thinking over the pros and cons and finally came to this opinion: The main disadvantage of allowing curly quotes is a danger of different attitudes of two or more people transcribing one work. For this reason I would explicitely allow curly quotes only if the contributor is able to ensure consistency of their usage throughout the whole work, typically when the contributor transcribes the whole work by himself/herself. When more people cooperate on transcription of a work, straight quotes should be recommended, unless they are all able to make an agreement about curly quotes (of course such agreement is practically impossible with such large works as Encyclopaedia Britannica). --Jan Kameníček (talk) 18:53, 6 July 2019 (UTC)

That's a nice thought, but even with the best will in the world, people start projects and don't finish them. The better thing is for the person who starts a project to document all their style choices on the talk page -- the note at the top of the index indicating that style guidelines exist is a great invention. Quote-style is no different from many other choices in that respect and can be handled the same way. If we shift to curly quotes and they become normal, then there will be no problem with expecting people who sign on late to a future project to use them. It's only the possibility of transitioning to curly quotes in projects that are already begun now that presents difficulties. Levana Taylor (talk) 21:03, 6 July 2019 (UTC)

A policy doesn't have to be perfect to be useful, sometimes "good enough" is good enough. I believe most Wikisource users would answer in good faith if asked, "do you intend to complete this project?" For myself, I think I'd answer "yes" for about half, "no" for about half. If a few projects end up with some inconsistencies because somebody intended to finish it but then got distracted or busy elsewhere, is that too high a price to pay if there are benefits elsewhere? -Pete (talk) 22:33, 6 July 2019 (UTC)

Both sides of this argument are starting to fall into the desperate position of trying to shore up numbers of supporters by appealing to the everybody who is reading this and not making their position clear must by inference be on my side of the argument. So for the sake of this alone I must delurk and declare that I am a closet supporter of the use of curly quotes for reasons I shall not go into here as they have already been adequately covered by others.

On the matter of automated tool use favouring straight quotes I have some sympathy. Creative laziness is always admirable but at heart it is just that: laziness. If some piece of scripted magic could perform reliable verification then why is everybody here at all? Proofreading still has an aspect of bespoke craft and we should take pride in our input.

As for perceived difficulty of entry of characters, aside from resort to UNICODE, there are the various pickers available both mediawiki supported and local. Nobody appears to have yet noted that native HTML such as the <q></q> construct works well under mediawiki, and all reputable browsers now handle the so-called HTML entity-forms: &ldquo; → “; &rdquo; → ” &lsquo; → ‘; &rsquo; → ’ Learn them; they are your friends! 114.78.66.82 22:56, 6 July 2019 (UTC)

Suggestion for implementation of quotes: there should be a gadget that finds all straight quotes on a page and converts them to curly while highlighting them so the editor can check the result for correctness (because it wouldn't be perfect). This would go a long way toward easing worries about inconsistency. Not only would it allow quicker, better conversion of works that have been begun using straight quotes, but if someone happens to notice stray straight quotes in a work that's mostly curly, they can rapidly find them all. Levana Taylor (talk) 03:20, 7 July 2019 (UTC)

 Comment I agree with the spirit of @Levana Taylor's suggestion but point out the occasional real-world case of quotations crossing pages — commencing on one page and terminating on a later one — would completely reverse the sense of correct quotation mark appearance. Which makes implementation of such a gadget tortuously impractical — as the analysis must take place at the work/chapter level to enable sensible decision for the gadget to act on the component page level. Only the {{nop}}-inserter gadget attempts this at present and for a vastly simpler case. 114.78.66.82 03:43, 7 July 2019 (UTC)

I don't see the problem. Ending quotes are at the end of words, lines and paragraphs, and starting quotes are at the start of words, lines and paragraphs. Quotes never cross paragraphs in normal English style, so any tool should restart at a new paragraph. On proofed text, it's possible the tool will put the wrong quotes on the first paragraph, but it won't be a problem for the whole page.--Prosfilaes (talk) 07:02, 7 July 2019 (UTC)

Arbitrary break (curly quotes)

⁈ I have… questions… 🤔

• Are we proposing to allow straight vs. non-straight quote mark style to be at the whim of the first contributor? Of any contributor that has a good-faith intent to update all previously proofread pages? Only when based on some set of criteria related to the work? What, if any, are the constraints on the choice?
• Is the proposal for the benefit of proofreaders with a preference, or for our readers? That is, is our goal to achieve the best presentation for our readers, or to allow our proofreaders some flexibility or to express their own preference? What are we trying to achieve by making a change in this area?
• At what level do we care about consistency? The work? The chapter? Individual entries in the DNB and similar? Across works within a series? How would we achieve such consistency in practice? How would we resolve conflicts in preference?
• What kind of curly quotes (there are on the order of 30 of them) would be allowed, and how would the style be decided? Would the “Anglophone” style be allowed or preferred for a work by a « Francophone » or „Germanic“ author? How about for reproducing an official text of some kind (English translation of a law, say) where the originating country specifies (sometimes by law) a specific quote style?
• How would we handle the issues currently dealt with by {{" '}}, {{' "}}, et al (there are 5 of them just for straight quotes; each extra style of quote would generate at least 5 more)? How do we detect and correct instances where accent marks are (accidentally) substituted for single quote marks? How about the inevitable Windows CP1252 character set issues?

I don't as yet have a firm opinion on the issue of curly quotes except that they do create a lot of complexity and that that complexity must be addressed if we are to adopt them. I do hold the opinion that good typography aids readability; that good typography creates visually appealing works, and that visual appeal is a desirable trait; that our goal should be the benefit of our readers over our own contributors; and that our readers are a diverse group with many different needs. I am also by inclination prone to prefer more diplomatic reproduction of works (I've driven certain community members to distraction by insisting on using {{lgst}})—which inclines me to want to reproduce a work's quotation style, and against any style that differs from the one use in the work (including substituting straight for curly)—but experience has taught me that there are good reasons to moderate that impulse (see, Billinghurst, I do listen and learn!).

And, ultimately my main concern is maintainability and manageability over the totality of the project, over a decade or two, and in the face of practical realities like the occasional conflict between contributors, the perennial slow changing of the guard (who now remembers why we made every decision shaping the project?), and the necessity of either automating or having the manpower for certain kinds of necessary cleanup or guidance for new contributors.

I like fancy quotes (and other typographic affordances), but they sound like they'd be really hard to do right. --Xover (talk) 07:18, 7 July 2019 (UTC)

Curly quotes should match the scanned text. That's simple.

We should deal with {{" '}} with fire, and then dump the ashes into a heart of a live volcano. I mean, if that's your bag, then whatever, but it seems weird about arguing for curly quotes against claims that the typography doesn't matter and that consistency is important, but have to deal with an idiosyncratic set of templates that surely have no consistency in use and tackle an issue of micro-typography that can and should be handled by modern text layout systems in web browsers; TrueType fonts have supported kerning pairs of characters for 25 years.

I would hope that modern systems won't dump CP1252 characters into the browser. We should have a bot checking the pages for inappropriate Unicode characters (Private Use, unmapped, etc.) and include 0080-009F in there.--Prosfilaes (talk) 07:56, 7 July 2019 (UTC)

I have not observed that the kerning issues with adjacent quote marks (or with "rn" and "m", for that matter) have been rendered moot by modern text layout systems. I have no particular affinity for those templates, but I do care about the issue they are attempting to solve. I also do not think making templates to deal with this issue that are consistent (what are the problems with the existing ones?) should be impossible. --Xover (talk) 08:06, 7 July 2019 (UTC)

Modern text layout systems are well-capable of dealing with kerning. If they don't, well, that's still stepping into their territory. There's no way of making such templates consistently used unless we make a big fuss about them, which I strongly object to. I haven't seen them in any thing I've used text I've worked on.--Prosfilaes (talk) 08:36, 7 July 2019 (UTC)

That they have advanced support for kerning (which they do, even on Linux) does not mean they can intuit the need for such automatically: we need to make use of such facilities for anything to happen. --Xover (talk) 08:52, 7 July 2019 (UTC)

In a TrueType font, there is a table listing pairs of characters and the space that needs to be added or removed between them. If "' needs extra space, then that table should list the amount of extra space it needs and the typesetting program should adjust the distance between the two glyphs appropriately. See w:Kerning.--Prosfilaes (talk) 12:31, 7 July 2019 (UTC)

Yes, that is indeed how the TrueType specification handles it; and OpenType has even more advanced features for this. However, so far as I know, no web browser on any operating system does this automatically, and the CSS features for explicitly enabling it are only partly supported (and would require some sort of markup on our side in any case). And even with that support it would require an OpenType font which has the appropriate kerning setting for these pairs, and that was available for us to use, which mythical beast may exist but I couldn't name one off the top of my head. I agree that it would be very nice if we didn't have to worry about this, but, again so far as I know, that is not actually the world we live in. If you know otherwise I'd be happy to get rid of those templates even if we only use straight quotes: they're nobody's idea of a perfect solution, they're just the best we've got available.--Xover (talk) 15:22, 7 July 2019 (UTC)

I have never used these templates; "'this'" or “‘this’” have always been completely adequate. If/when browser support for kerning becomes more common, then the appearance will be improved slightly, but in the meantime there is no need for manually padding the punctuation imho. —Beleg Tâl (talk) 20:11, 7 July 2019 (UTC)

I'd say pretty much this is the definition of a problem we don't have to deal with. We send "' down the line, and the other side renders it. If that rendering of a common pair of characters is unsatisfactory, the spirit of HTML and text transcription is that we don't know their fonts, their system. If systems don't do this automatically, and fonts don't set kerning for these pairs, then obviously it's not considered a big problem.--Prosfilaes (talk) 21:42, 7 July 2019 (UTC)

That's a fair stance (both of you). I don't agree with it—it goes to readability so a similar argument applies to this as to using typographers quote marks (or distinguishing between plain, en-, or em-dashes)—but it is absolutely an issue it is reasonable to consider falling within the limits of "good enough". Thus the question, above, of whether what we are trying to achieve in this discussion is flexibility for our contributors or a better reading experience for our readers. What the goal is affects the calculous of how much effort to put into stuff like getting typography and layout correct vs. getting it "good enough" (wherever you draw that line in general) and letting the users' browsers deal with it. --Xover (talk) 04:31, 8 July 2019 (UTC)

I think the difference is here that users' browsers can't add curly quotes properly; it is up to human intelligence to add them. On the other hand, we can't add space properly, given that we don't know what fonts are being used. In the long run, properly recording the characters that are there will help all usages of the text, where manually kerning characters will help only certain users, and make usages that don't reflect current web browsers more complex.--Prosfilaes (talk) 11:24, 8 July 2019 (UTC)

I use the {{" '}} group in my projects after seeing them in use elsewhere since it seems like a neat solution to the problem, and the templates can easily be made inoperative whenever browsers do get round to displaying them better. Given that I regularly have to add manual padding when typesetting documents in InDesign using professional typefaces I am somewhat sceptical about how effectively those TrueType and OpenType specifications are being used by fonts at the moment. As Xover said above fonts using the full scope of these settings properly are a bit of a mythical beast.

For the record, in Arial on Windows 10 and the current version of Chrome I can't distinguish "' from '" at all (or for that matter '''). In curly quotes, though, it seems much easier to distinguish “‘ and ‘“, so it's possible that the templates are simply unneeded in that case. —Nizolan (talk) 15:15, 8 July 2019 (UTC)

Back to topic of curly quotes, I checked the French, Italian, and German Wikisources and they all seem to use curly quotes by default. (It seems Spanish has their own style of quotation marks and doesn't use apostrophes.) Kaldari (talk) 14:35, 9 July 2019 (UTC)

@Kaldari: It looks to me like there's enough consensus in the discussion above to justify a more formal proposal. Do you have thoughts of putting something together? -Pete (talk) 20:57, 24 July 2019 (UTC)

@Peteforsyth: Unfortunately, I'm still somewhat of a newbie on Wikisource, so I'm not familiar with community practices here. How do these things work? Do you call a vote? Write an RFC? Honestly, I would love it if a more experienced Wikisource editor took over the process from here. Kaldari (talk) 22:10, 24 July 2019 (UTC)

@Kaldari: French uses the same style quotes as Spanish, namely« », so I'm not sure how you determined that they use curly quotes. Italian Wikisource is inconsistent, and they currently have about six active contributors, but Italian also has a different set of quotes, namely “ „ , than English does, so they (along with Spanish and French) are not a good basis for comparison. --EncycloPetey (talk) 01:49, 26 July 2019 (UTC)

@EncycloPetey: True, but the French, German, and Italian Wikisources seem to use the curly apostrophe pretty consistently. My point is, our use of straight quotes seems to be the exception, not the rule. Kaldari (talk) 17:44, 26 July 2019 (UTC)

@Kaldari: I still don't know how you came to that conclusion, because I looked at the same sites and didn't reach that conclusion. You should also consider that the apostrophe in languages like French and Czech can be coded differently. For example, there is a single Unicode character available for French ľ that is typically used, and French style is to prefer that over using separate characters. That being the case, it is inappropriate to make comparison because English uses no such character. --EncycloPetey (talk) 23:36, 26 July 2019 (UTC)

When comparing other projects, Czech Wikisource and also Czech Wikipedia use curly quotes, though a „different type“. "Straight quotes" are just tolerated but not recommended. --Jan Kameníček (talk) 18:43, 26 July 2019 (UTC)

• As the consensus appears to be against the sole restriction on typewriter quotes (",") against “curly” quotes (“,”), I have edited the appropriate section of the style guide to reflect this discussion. If any one wishes to revise the wording, that would be more appropriate. TE(æ)A,ea. (talk) 21:18, 25 July 2019 (UTC).

  I disagree that such a conclusion has been reached that there should be change to the style guide, and have undone the change. — billinghurst sDrewth 22:10, 25 July 2019 (UTC)

  • Why do you disagree? There is no one who reasonably supports the current guideline; there is only a difference of opinion on the proper wording and implementation. TE(æ)A,ea. (talk) 23:33, 25 July 2019 (UTC).

    Did you read my sentence up to the comma? Could it be any more specific? PS. Don't flip me any metaphorical bird, I have done my time here, and earned my rights the hard way, and supported them with work the whole way through my many years here. — billinghurst sDrewth 04:42, 26 July 2019 (UTC)

  • Did you read mine? The reasoning you provided earlier aligns with my change to the style guide, That there should be consistency within a work preferably to authoritarian commands without reasoning. TE(æ)A,ea. (talk) 12:39, 26 July 2019 (UTC).

    "no one reasonably supports" is a way to wave your hand and dismiss any counterarguments, and suggests there is not a consensus. The last post before you made your comment was a move to write an explicit proposal and vote. It is therefore inappropriate to circumvent that process by offhandedly dismissing the whole thing on a whim. --EncycloPetey (talk) 01:49, 26 July 2019 (UTC)

Oh my, seems there's still some tension around here. I'd suggest there's no benefit to implementing a change before everybody involved has had the chance to review it an comment on it. I'm happy to prepare a more specific proposal, based on the gargantuan input in this section and that above, as I suggested earlier; until then, I'm not sure there's any pressing need to make changes to the style guide. That said, I appreciate @TE(æ)A,ea.: making the effort, and it might be useful to consult Special:Diff/9483059 in building the proposal. If anybody wants to propose alternative wording, feel free to do so here or on my talk page, and I'll do my best to incorporate it. -Pete (talk) 00:10, 27 July 2019 (UTC)

The proposal should have three options: 1. Keep the style guide as is (straight quotes only) 2. Write style guidelines that consider curly quotes to be the normal, standard usage 3. Allow curly quotes but only under certain circumstances or with certain restrictions, or do a gradual implementation of option 2, or a test implementation of it, or..... This option is a catchall meaning "not 1 or 2" and if we choose it we'll be starting another round of discussions leading to another proposal. Levana Taylor (talk) 00:32, 27 July 2019 (UTC)

@Peteforsyth: I would very much appreciate a proposed guideline that addresses directly (answers) the questions above, as opposed to a more general "Yes (figure out details later)" vs. "No" approach. On this issue I find myself leaning towards being conservative (perhaps overly so) and preserving the status quo when not all consequences are clear. I therefore think it would be best to ask this question in the form of a fully-formed assertion: "this is what the guideline should be, do you agree or disagree?". If a significant number disagree we revise the proposed guideline to address the concerns raised and try again. PS. I'm happy to help out here, so never hesitate to ask or ping me, but I don't think I'll actually be of any help as I am too uncertain and conflicted on this issue. --Xover (talk) 10:49, 27 July 2019 (UTC)

Break (curly quotes) for discussing changes to guideline

1. Use typewriter quotation marks ("straight," not “curly”). Status quo, unchanged from original.
2. Use the same quotation marks (either "straight" or “curly”) in a work, but not both. This, possibly with rewording, was my suggestion; this proposal favors standardization within a work, but not a universal idea.
3. Use the same quotation marks as the work presents; i. e., if the work shows "straight" quotation marks, use those, or if it shows “curly” quotation marks, use those instead. This would likely be the most simple proposal, as there would be no need to change what the original source shows.
4. It is allowed to use either straight quotation marks or the same kind of quotation marks as the original work presents, with the following condition: Other than straight quotations marks are permitted only if it can be ensured that they will be used consistently in the whole work. If such consistency cannot be ensured (e. g. because of a large number of contributors to the work or because of disagreement of some of them), straight quotation marks are recommended.
5. The use of curly quotes is encouraged, and considered to be the default style in all texts, with or without a source. In cases where the source text uses a different typography (guillemets « », typewriter quotes, or whatever) that style can be used (encouraged, but not required). They are the standard form of “ ” ‘ ’ and " '. The use of typewriter quotes in texts where the original doesn't have them should be considered deprecated, to be phased out.

If any one else has an idea, write it out above; however, if you wish to reword an above proposal, please mark that as indicated above. I support either no. 2 or no. 3. TE(æ)A,ea. (talk) 12:33, 27 July 2019 (UTC).

I have added one more point. --Jan Kameníček (talk) 13:13, 27 July 2019 (UTC)

• I have changed no. 4 to a sub-section of no. 2, as it appears to be quite similar to no. 2. TE(æ)A,ea. (talk) 21:08, 27 July 2019 (UTC).

  @TE(æ)A,ea.: Seems to me that numbering it as "1." again is quite confusing for discussions. What is more, it is very different from no. 2 because no. 2 lets the contributors choose only between two kinds of quotes, and also lets them choose the curly quotes even if they are not used in the original. My suggestion a) lets them choose any kind of quotes, but b) only if they are used in the original and c) not in complex works. --Jan Kameníček (talk) 06:12, 28 July 2019 (UTC)

  I think it's simpler to leave it as Jan wrote it to ensure that each proposal has its own number, and I've reverted it to that accordingly. —Nizolan (talk) 12:53, 28 July 2019 (UTC)

  No. 4 revised after discussion below, to make it more clear. --Jan Kameníček (talk) 05:11, 30 July 2019 (UTC)

I support #2, [edit: #4 per Jan's rewording below,] or, failing that, retaining the status quo per #1: be consistent but do not enforce curly quotes. I strongly disagree with #3 being the "simplest proposal"; given that the vast majority of texts here are typeset using curly quotes this is effectively the same as enforcing their usage and would sum to a potentially enormous amount of extra work. Many OCR programmes, such as Google's, do not automatically add curly quotes so this would need to be done manually. I don't see the point of #4. —Nizolan (talk) 17:54, 27 July 2019 (UTC)

To explain the point: I believe that contributors should be allowed to use any quotes that are presented in a work (e. g. curly), but they should not be forced to it, and should be allowed to use straight quotes only, if they prefer so. (this is ensured by no. 2, but not by no. 3). On the other hand I do not consider it good to allow to use curly quotes if there are straight quotes in the original (this is ensured by no. 3, but not by no. 2). Therefore I suggested the new point, which ensures this + recommends how to deal with complex works where contributors are not able to reach consensus which quotes to use. Number 2 gives the contributors the right of choice, but does not deal with the situation when the contributors have different opinions. Thinking about it again, it can happen not only with large works, but with any work where 2 or more people contribute, so I am rewording the point for "... If two or more people contribute to one work and are not able to reach consensus what kind of quotation marks to use, straight quotation marks are recommended." --Jan Kameníček (talk) 15:31, 28 July 2019 (UTC)

@Jan.Kamenicek: I see your point regarding curly quotes where typewriter quotes are used in the original. I would say as currently worded #4 is problematic for a number of reasons, though. As worded, it seems to forbid using straight quotes unless they are present in the original, as per #3. I'm not sure that works that are internally inconsistent are enough of a problem to need special mention, but as currently worded the suggestion doesn't say anything about what to do when they are. The last point seems over-complicated, imo: Wikipedia's "don't mess around with an article's established formatting preferences" seems like the most straightforward way to prevent these disputes.

I would personally firm it up along these lines: "1. Curly quotes may be used if and only if the work being typeset consistently uses curly quotes. 2. The marks used in proofread material should be consistent. Contributors to projects that have already started should ensure that they follow whatever convention has already been adopted in the work." And perhaps a final clarification for exceptional cases where curly or straight quotes are required in a particular instance regardless of general convention (e.g. in a transliteration system that distinguishes them) would also be helpful. —Nizolan ^(talk) 00:58, 29 July 2019 (UTC)

@Nizolan: It definitely does not forbid straight quotes, there is explicitely written: "Use either straight quotation marks or the same quotation marks as the work presents". So if there are e. g. curly quotations marks in the work, contributors can use straight or curly. If there are double angle quotation marks, contributors can use straight or double angle ones. If there are straight quotation marks, they can use only straight. I think this point is quite clear.

The rule says what to do so that there were not internally inconsistent works. I do not think it is necessary to say what to do, if such situation occurs because somebody has broken the rule (e.g. a bot can be applied to make it right???).

As for "follow whatever convention has already been adopted in the work." This is exactly what I wanted to avoid, because IMO nobody should be forced to use curly quotes if they do not want to. Contributors who start a large work and know that they will need help of other contributors should also know that straight quotes are the default formatting and curly ones can be used only if they can ensure that the others are willing to follow. It is undesirable that somebody starts a new encyclopaedia, adds first 50 articles with curly quotes, and willy-nilly all others who come later have to follow it.

The rule "don't mess around with an article's established formatting preferences" does not help with works consisting of many articles, where different contributors might establish different formatting in different articles, which is undesirable. The last part of no. 4 is definitely open for better rewording, but the result should recommend straight quotes which can be changed in favour of the curly or other quotes only if the contributors are all able to agree on that.

I am not sure what you mean by "curly or straight quotes are required in a particular instance regardless of general convention", can you explain it in more detail, please? --Jan Kameníček (talk) 06:16, 29 July 2019 (UTC)

@Jan.Kamenicek: "as the work presents" means "use the formatting of the work", it doesn't give an option. If you meant something else it should be rewritten. On the last point, e.g. in transcription of Arabic ’ and ‘ represent different sounds; ' is used in some Russian transcriptions, etc., these must be preserved regardless of the general convention of the work. —Nizolan ^(talk) 10:34, 29 July 2019 (UTC)

@Nizolan: I am afraid I really do not understand the problem: "Use EITHER straight quotation marks OR the same quotation marks as the work presents." The option is clearly expressed.

As for the transcription symbols: these are not quotation marks and so imo they are not in the scope of this rule. --Jan Kameníček (talk) 12:22, 29 July 2019 (UTC)

@Jan.Kamenicek: I'll try to explain the problem for you: either ... or can be inclusive or exclusive. If read as exclusive, then your guideline states that if the usage is consistent, use the same marks; if it isn't, use typewriter marks. So, based on what you want it to say, it is not clearly expressed. (Edit: Also just to add, if it did just say "Use EITHER straight quotation marks OR the same quotation marks as the work presents" I think that would be fine—the problem comes with the "under the condition…" modifier.) —Nizolan ^(talk) 12:41, 29 July 2019 (UTC)

@Nizolan: Now I see your point. So what would you say to the following wording: "It is allowed to use either straight quotation marks or the same kind of quotation marks as the original work presents, with the following condition: Other than straight quotations marks are permitted only if it can be ensured that they will be used consistently in the whole work. If such consistency cannot be ensured (e. g. because of a large number of contributors to the work or because of disagreement of some of them), straight quotation marks are recommended." --Jan Kameníček (talk) 15:47, 29 July 2019 (UTC)

That seems decent to me. I'll add it as another option I'd support. —Nizolan ^(talk) 17:08, 29 July 2019 (UTC)

I support this point (no. 4) too, or, if it does not succeed, no. 3. --Jan Kameníček (talk) 05:20, 30 July 2019 (UTC)

I support statement 2, and do not support the others. In my opinion, imitating the source with respect to straight vs curly quotes is like imitating the source with respect to serif vs sans serif font. I would word statement 2 like follows: Either straight quotes or curly quotes are acceptable, but a consistent style of quotes should be used within a single work. Straight quotes are advised in collaborative projects to ensure consistency. —Beleg Tâl (talk) 12:29, 30 July 2019 (UTC)

Also, guillemets and other marks used for quotations are completely different characters, and should be used as in the source regardless of the straight-vs-curly conventions being used. —Beleg Tâl (talk) 12:32, 30 July 2019 (UTC)

Agreed on this. —Nizolan ^(talk) 23:32, 30 July 2019 (UTC)

┌──────┘
@Beleg Tâl: Various kinds of quotes are different characters and have their own Unicode or html codes. If you change Serif into Sans serif, only shapes of letters change. If you change one kind of quotes for the other, you changed the chosen character. If you change the kind of font used for quotes, their shape may change but the characters still stay.

It is also not clear what is meant by "curly" quotes, often mentioned here, since several characters used for quoting have curly shapes, and can be combined in various ways, e.g ” ” (&rdquo; &rdquo;); ‟ ” (&#8223; &rdquo;); „“ (&bdquo; &ldquo;); „” (&bdquo; &rdquo;); and their single variants like ’ ’ (&rsquo; &rsquo;) ...

What is more, various national typographic systems use different kinds of quotes and so the chosen kind can sometimes also have this national connotation (which is the reason why I decided to use „“ in Page:Guide to the Bohemian section and to the Kingdom of Bohemia - 1906.djvu/16 and the following pages, as it was published in Bohemia and so uses the kind of quotes typical for this region.) --Jan Kameníček (talk) 07:18, 31 July 2019 (UTC)

@Jan.Kamenicek: Curly quotes in this discussion are the ones that can be replaced with " and '—specifically these: “ ” ‘ ’ and possibly ‟. Alternative quotation symbols like „ should never be replaced with these upper quotation marks. The fact that there does not exist any "straight" variant of „ is, as I said earlier in this discussion, one of the biggest reasons curly quotes should be permitted. However, in general, the appearance of “ vs " in a source scan, like the appearance of a vs ɑ, or s vs ſ, is generally an accident of publication and typeface, and is therefore beyond what Wikisource editors should be expected to reproduce. —Beleg Tâl (talk) 12:42, 31 July 2019 (UTC)

I modified Point 5 to reflect this. Levana Taylor (talk) 17:04, 31 July 2019 (UTC)

I have added another point, which positively encourages the use of curly quotes, just to round out the set of proposals by going the maximum distance. I'm not saying this is my favorite option, but I think it's at least a plausible one. Anyone who can think of a less extreme form of this option should add it as a subsection. Levana Taylor (talk) 16:51, 29 July 2019 (UTC)

Add me as someone who is in favor of typographic quotation marks and deprecating straight ones. —Justin (koavf)❤T☮C☺M☯ 06:56, 2 August 2019 (UTC)

• As there has been a recent dearth of discussion, I will follow the beliefs of the majority of editors and modify the style guide accordingly. The new wording is a simplified version of no. 4. —unsigned comment by TE(æ)A,ea. (talk) 23:49, 11 August 2019‎.

Hang on, it’s not decided which option we prefer yet! For example, I have not yet put on record that I like number 3 best, followed by number 2, and don’t favor number 4. Levana Taylor (talk) 10:32, 12 August 2019 (UTC)

I have been aware of the above discussion, but have not contributed as I was waiting for a formal proposal. All that's happened so far is a discussion on how to word the proposal. Once this has been decided, then a formal proposal with the suggested options needs to be made in a new section away from this tldr discussion. Beeswaxcandle (talk) 07:09, 13 August 2019 (UTC)

Palestine Order-in-Council

I'm asking if someone that has access to the Hebrew Wikisource, can do a check of this against the original there, as in the preamble notes there is a sentence that to me looks like it has letter missing in the translation here? ShakespeareFan00 (talk) 20:39, 17 July 2019 (UTC)

I can access the Hebrew Wikisource, but I can't read the Hebrew. Our text is checked against this version though, not against the Hebrew. Here is the requested passage:

הואיל ולמען תת תוקף להוראות סעיף 22 מספר הברית של חבר הלאומים הסכימו מעצמות ההסכמה הראשיות למסור לידי הממונה, שייבחר ע״י אותן מעצמות, את הנהלת ארץ ישראל שהייתה שייכת קודם לכן לממלכת תורכיה, בתוך אותם הגבולות אשר ייקבעו על ידן;

והואיל ומעצמות ההסכמה הראשיות הסכימו גם לכך שהממונה יהיה אחראי להגשמת ההצהרה שניתנה מלכתכילה ביום 2 בנובמבר, 1917 ע״י ממשלת הוד מלכותו ונתקבלה ע״י המעצמות הנ״ל, לטובת ייסוד בית לאומי בארץ ישראל לעם היהודי, בתנאי ברור שלא ייעשה כל דבר העלול לפגוע בזכויות האזרחיות והדתיות של העדות שאינן יהודיות, הקיימות בארץ ישראל, או בזכויותיהם ובמעמדם המדיני של היהודים בכל ארץ אחרת;

והואיל ומעצמות ההסכמה הראשיות בחרו בהוד מלכותו להיות הממונה על ארץ ישראל;

והואיל ויש להוד מלכותו סכמות וכח שיפוט בארץ ישראל בתוקף חוזה, שעבוד, מתנה, מנהג, הסכמה־שבשתיקה ובתוקף אמצעים חוקיים אחרים;

לפיכך נאות הוד מלכותו לצוות, בתוקף הסמכויות המסורות לו לתכלית זו בחוק השיפוט בארצות נכר, 1890, או בכל חוק אחר, ובעצת מועצתו הפרטית, ובזה מצווים לאמור:–

—Beleg Tâl (talk) 01:20, 18 July 2019 (UTC)

Thanks, I don't read Hebrew either , but I'll see what Google Translate makes of it.

The sentence I actually had concerns is in small text below the above (noting an ammendment), and as of my enquiry read as follows on English Wikisource page:- "In Accordance with Articles 14 and 15 of the Law and Administration Ordinance every function formerly vested in the King of Britain or in the High Commissioner shall now be vested in the Cabinet of Israel and the term "Palestine (E"I)", whenever appearing in any law, shall no be read as "Israel".

The "no" should I think be read as "now"? The rest of the preamble matches up. I didn't want to change it without someone checking.ShakespeareFan00 (talk) 08:11, 18 July 2019 (UTC)

That paragraph does not appear in the source edition so it should be removed entirely. —Beleg Tâl (talk) 12:59, 18 July 2019 (UTC)

@ShakespeareFan00: Where is the original Hebrew? Also, the text is currently left aligned - it should be right aligned. — Ineuw (talk) 06:32, 26 July 2019 (UTC)

The Hebrew Wikisource he:דברי_המלך_במועצה_על_ארץ-ישראל which gives - https://main.knesset.gov.il/Activity/Legislation/Laws/Pages/LawPrimary.aspx?lawitemid=2000035 as the source for the 'in-force' version. ShakespeareFan00 (talk) 08:39, 26 July 2019 (UTC)

Isthmus of Krà

I've nearly completed work on Notes of a journey across the Isthmus of Krà. The original does not have a table of contents; would it be acceptable to add one, for the convenience of readers? If so, how should the fact that it is a new addition be indicated? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:52, 18 July 2019 (UTC)

there should be more help on this, but see also Template:Auxiliary Table of Contents -- Slowking4 ‽ Rama's revenge 10:37, 18 July 2019 (UTC)

@Slowking4: Perfect, thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:49, 18 July 2019 (UTC)

 This section is considered resolved, for the purposes of archiving. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:01, 23 July 2019 (UTC)

Tech News: 2019-30

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

• Communities interested by easing newcomers' first steps can now benefit from the Growth team experiments on their wikis. Check the conditions and the request process.
• The Coolest Tool Award 2019 is looking for nominations. You can recommend tools by July 29. The awarded tools will be presented at Wikimania. [1]

Problems

• The release of the last version of MediaWiki (1.34.0-wmf.14) has been blocked for groups 1 and 2. [2]

Changes later this week

• Phabricator database will be moved to a different server. Writes will be blocked on Thursday 25 July, between 05:30 and 06:00 AM UTC. Reads will remain unaffected. [3]
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 23 July. It will be on non-Wikipedia wikis and some Wikipedias from 24 July. It will be on all wikis from 25 July (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 24 July at 15:00 (UTC). See how to join.

Future changes

• Some items in the visual editor will change later this week. This will make it easier to edit links, citations, and templates on both desktop and mobile. [4][5]
• With advanced search turned on you will be able to choose the sorting order of the search results when you do a search. [6][7]
• Users who edit from IP addresses whitelisted on a request for temporary lift of the IP cap for mass account creation will bypass CAPTCHAs. This will happen in August. If you think this should not happen for some reason, please let us know.
• The variable user_wpzero will be removed from AbuseFilter. A list of filters needing a fix is provided.

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

13:07, 22 July 2019 (UTC)

Better Eyesight Magazine/March 1922

This needs to be split up as it contains a number of issues not just March 1922 as claimed, or a scan found to replace it. What seems to be here is an OCR copy dump :( . ShakespeareFan00 (talk) 14:27, 22 July 2019 (UTC)

agreed —Beleg Tâl (talk) 20:16, 22 July 2019 (UTC)

https://archive.org/details/BetterEyesightByWIlliamHoratioBates/page/n266 is a scan of the complete "Better Eyesight" magazine, however it has been compiled into what seems to be an ebook and has 2 pages per page. Due to the inclusion of the advertisements at the front and back of each magazine, it is a bit bard to determine where one month's issue ends and another begins. --Einstein95 (talk) 04:23, 13 August 2019 (UTC)

tosection issue

I can't see why Quarterly journal of the Geological Society of London/9/179 is including the start of the following section, when I have used |tosection=End Jukes in my markup. Can someone debug it, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:53, 22 July 2019 (UTC)

@Pigsonthewing: See diff:9466667 and diff:9466668. |tosection=X doesn't mean "up until the section named X", it means "on the page given by |to=, include only section X". So on any page that contains content from more than one sequence to be transcluded (two+ chapters, two+ poems, two+ encyclopedia entries, etc.) each sequence has to be wrapped in <section> tags, for which the "##" syntax is just a shortcut that a javascript gadget transforms into start and end tags (see the diffs). --Xover (talk) 19:12, 22 July 2019 (UTC)

Noted, thanks Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:00, 23 July 2019 (UTC)

 This section is considered resolved, for the purposes of archiving. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:00, 23 July 2019 (UTC)

Undo move

I mistakenly moved:

Page:Quarterly journal of the Geological Society of London, volume 9.djvu/310

to:

Page:Quarterly Journal of the Geological Society of London, volume 9.djvu/310.

Please can someone reverse that?

(What intended to move, and later did, was Quarterly Journal of the Geological Society of London/9/179.) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:41, 22 July 2019 (UTC)

Done — billinghurst sDrewth 21:08, 22 July 2019 (UTC)

Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:00, 23 July 2019 (UTC)

 This section is considered resolved, for the purposes of archiving. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:00, 23 July 2019 (UTC)

Future of the OCR gadget and its maintenance

The OCR button has recently been quite often out of service and so is also at the moment. From what Xover wrote at Scriptorium/Help I understood that the main problem is that its maintenance depends only on one person who has been inactive at Wikisource for quite a long time and so he is difficult to reach and his interventions are not very systematic. As a result contributors have to rely either on original OCR layers of DJVU or PDF files, which are often very poor, or on the Google OCR gadget, whose results are also considerably worse than those fo the original OCR gadget (the most annoying problems: it often moves parts of lines to a different place of the text and the contributor has to find the correct place and move it back; it usually does not recognize ends of paragraphs) and so it significantly slows the work down).

Therefore I think that some systematic solution needs to be found but I have no clue what. The tool is very important for Wikisource and when it breaks down, it should be repaired as quickly as possible, but Phabricator community has got extremely long solving times, if they solve the problem at all. Does anybody have any idea what to do? --Jan Kameníček (talk) 08:40, 23 July 2019 (UTC)

Index:KAL801Finalreport.pdf

Several images used in this index (on file pages 20, 30, 31 and 49) were deleted from commons a few months ago. Posting here per the instructions at Category:Pages with missing files. * Pppery * _{it has begun...} 15:50, 24 July 2019 (UTC)

Images were nominated for deletion by User:ShakespeareFan00 due to being fair use which is not allowed on Wikisource.

• commons:Commons:Deletion requests/File:KAL801Finalreport - Figure 1.jpg
• commons:Commons:Deletion requests/File:KAL801Finalreport - Figure 4.jpg
• commons:Commons:Deletion requests/File:KAL801Finalreport - Figure 5.jpg
• commons:Commons:Deletion requests/File:KAL801Finalreport - Figure 7.jpg

@ShakespeareFan00: looks like you forgot to clean up the transcription after you had the images deleted. —Beleg Tâl (talk) 17:01, 24 July 2019 (UTC)

keep and allow fair use here. Slowking4 ‽ Rama's revenge 03:43, 29 July 2019 (UTC)

A semi-sequel to the Mueller Report

The Senate dropped this today, part one of five: File:Report of the Select Committee on Intelligence United States Senate on Russian Active Measures Campaigns and Interference in the 2016 U.S. Election Volume 1.pdf. There was a concerted effort here to transcribe the Mueller Report and while I don't know that this is as timely and high-traffic, many users who were interested in that would be interested in this as well. —Justin (koavf)❤T☮C☺M☯ 19:34, 25 July 2019 (UTC)

• Thank you for notifying everyone. I would not have noticed it otherwise. I have started by creating the header, footer, index page, title page, and table of contents. Do you know when the other volumes are being released? TE(æ)A,ea. (talk) 13:33, 26 July 2019 (UTC).
  • I do not. :/ —Justin (koavf)❤T☮C☺M☯ 20:50, 1 August 2019 (UTC)

Typo words, LintErrors and other mistakes...

A while back I'd made a very incomplete list of some typo words I'd found whilst cleaning up OCR, User:ShakespeareFan00/Typo words

I was wondering if there were other contributors with related lists, which could be combined?

I would also strongly suggest that someone compile's a Help:Formatting howlers list, which also has the consensus solutions to some of the more commonly encountered Lint concerns that arise out of Special:LintErrors.

I've also sometimes found situations which Lint doesn't detect but which are still misformatting 'howlers', such as to give an example:

Mis-formatted '''The inner portion is supposed to be in italic.'' Not in '''bold.''''

Correct formatting {{'}}''The inner portion is supposed to be in italic.'' Not in '''bold'''{{'}}

Are there others? ShakespeareFan00 (talk) 11:06, 26 July 2019 (UTC)

I know Distributed proofreaders have a very comprehensive list. I would add all of the ligatures as 2 separate letters. I try to add idiosyncratic scannos to the Index page discussion list so that these could be checked by bot before transclusion e.g. persistent R as K, also names that recur misscanned. Zoeannl (talk) 09:23, 28 July 2019 (UTC)

My rule with ligatures is that ae, oe get transcribed directly if present in the original, fi , fl etc, I type as two separate letters. ShakespeareFan00 (talk) 18:07, 28 July 2019 (UTC)

Choice about whether or not to preserve a ligature can be affected by the language of the text. It's not something for which I would advocate automated replacement. --EncycloPetey (talk) 17:02, 29 July 2019 (UTC)

Little hack for even/odd page headers

Hello to everyone. I am sysop at Spanish Wikisource, and came here to present one little hack that we deviced there, and so far it works. It's Template EPI (Encabezado Par/Impar, Even/Odd Header), a template for using at the Index: namespace form, for helping with the variable running headers in odd/even pages. Right now it have to be used like this: {{ {{{|subst:}}}EPI|{{{pagenum}}}|Even header|Odd header}} , because of the way the software handles the "pagenum" parameter (it's only accesible during the loading of the page), but so far so good. I hope you take a look at it, and see if you can make any improvements. --Ninovolador (talk) 16:55, 29 July 2019 (UTC)

Can you provide some examples of works where the template has been used successfully? One of the potential problems I can see is that the page header for a page can be a {{RunningHeader}} with three or four parameters of its own, and that becomes tricky to code inside another template, especially when that template is subst'ed. --EncycloPetey (talk) 17:00, 29 July 2019 (UTC)

@Ninovolador: Thanks for the tip: I'm really glad to see such cooperation across the different language Wikisources! As it happens I threw together something similar a few weeks ago (must be in the zeitgeist) here: {{rvh}}. To the degree there's anything useful in it all, do, of course, feel free to grab the bits you want. --Xover (talk) 17:02, 29 July 2019 (UTC)

@EncycloPetey: right now I am using it in es:Índice:Las tinieblas y otros cuentos.djvu. Tbf is a fairly simple running header, and I am only using it there for testing reasons.

@Xover: Wow! your example is much simpler! Mine is more versatile, but your code is much cleaner. --Ninovolador (talk) 17:15, 29 July 2019 (UTC)

@Ninovolador: Well, as EncycloPetey points out, running headers can contain all sorts of complicated surprises, so {{rvh}} gains its simplicity by just not trying to handle anything complicated. So limited, but seems to work well for those simple cases. I should also point out that I got the idea from ShakespeareFan00 who, I believe, originally got the concept from Beleg Tâl (iow, I can take minimal credit for this). I've been meaning to look into whether it would be practical to make something more fancy that could be a general solution (like {{rh}} with built-in support for recto—verso alternation), but haven't gotten around to it yet. I imagine the big stumbling block would be chapter titles, as these change frequently and can't be automated (maybe if we throw some javascript into the mix?). --Xover (talk) 17:29, 29 July 2019 (UTC)

A handy tool I stole and modified from Phe years ago is User:Inductiveload/Running header.js. This adds a sidebar menu item to add a running header, and it takes the contents from 2 pages previously and updates the number (also handles roman numerals). It will go 4 pages back if it can't find anything 2 pages back (e.g. there's a chapter heading on that page). You still have to manually change the first page of a new chapter when the chapter name is in the RH. Inductiveload—talk/contribs 17:22, 29 July 2019 (UTC)

Nothing to add on the technical side but @Inductiveload, @Xover, @Ninovolador: These tools are all hugely helpful, thanks. —Nizolan ^(talk) 19:34, 29 July 2019 (UTC)

This is all great, I echo Nizolan's thanks! Seems like it should all be documented somewhere central. I find that WS:HEADER is a redirect, and I'm not sure if the page it redirects to is the best place. I'm happy to try to write a short overview with links, but I'd appreciate guidance on where the best location is for that. Alternately, I could start it in user space and then ask around... -Pete (talk) 20:28, 29 July 2019 (UTC)

All this looks great. Ninovolador's template seems best to me, as it substitutes the text. Can the EPI template be founded here as well? --Jan Kameníček (talk) 16:17, 3 August 2019 (UTC)

Why not just use {{subst:rvh}}? —Beleg Tâl (talk) 20:37, 3 August 2019 (UTC)

@Beleg Tâl: Because there still remains redundant code text after substitution, see [8], while after substitution of the template EPI the code is clear, see [9] --Jan Kameníček (talk) 23:37, 3 August 2019 (UTC)

@Jan.Kamenicek: Hmm. To the degree one can use a word such as "design" for this without blushing, the choice to not subst the content of this template was by design. It is also not designed to be subst'ed at invocation.

However, looking at the page you give as example I'm a little confused. You have subst'ed it on the Index: page, leading to the template internal code showing up on the header of every page of the work. The intended usage is to put {{rvh|{{{pagenum}}}|achapter|awork}} in the Header field of the Index: page, which should produce {{rvh|42|achapter|awork}} in the header section of each page in the Page: namespace.

Is your goal to have only the resulting {{rh}} invocation show up on the page in the Page: namespace? I.e. {{rh|42|achapter|}} on even pages and {{rh||awork|43}} on odd? If so that was not the design goal of this template, but I'm sure we can create a parallel one specifically for this use case. There are so many moving parts involved here (subst: is relatively arcane to begin with, coupled with ProofreadPage sticking its nose in both providing variables and doing some subst'ing of its own, etc.) that I can't really promise anything in that regard, but at the very least I can't immediately see any reason why that wouldn't be doable; and most likely it'll simply be a matter of duplicating the approach Ninovolador took in es:Plantilla:EPI. --Xover (talk) 06:44, 4 August 2019 (UTC)

@Xover: Exactly, it would seem better to me if only {{rh|42|achapter|}} on even pages and {{rh||awork|43}} on odd pages remained. However, it is not a big issue so I did not want to bother you with reprogramming your template and thought it would be easier just to found and use the EPI template, and leave yours for contributors not familiar with substituting. Anyway, if you decide to change it, it would be good if the substitution was just an option, so that the template stayed friendly to less experienced users as well. --Jan Kameníček (talk) 07:25, 4 August 2019 (UTC)

@Jan.Kamenicek: I'll look into it. It should be possible to make {{rvh}} behave differently depending on whether it is substituted or not, but as mentioned… complicating factors. PS. Never hesitate to ask me for technical stuff like that. I'm happy to help when I can; I just make no promises regarding response times or ability to actually help. :) --Xover (talk) 08:00, 4 August 2019 (UTC)

Tech News: 2019-31

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

Problems

• Wikidata will be in read-only mode on 30 July from 05:00 to 05:30 UTC because of a server switch. [10]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 30 July. It will be on non-Wikipedia wikis and some Wikipedias from 31 July. It will be on all wikis from 1 August (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 31 July 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.

21:42, 29 July 2019 (UTC)

Finalizing the Mueller Report

The Report is close to finished; it needs only a bit more validation.

Note also that if you are adding links, there is now an epub version with many external references (but not, I think, the court cases) turned into hyperlinks. (on DPLA) Sj (talk) 12:30, 31 July 2019 (UTC)

Border/table interaction problem

Template interaction failure found: If you try to surround a piece of text containing a table with {{border}}, this is the result. I don't actually need to use this combination at the moment, but I thought I'd give a heads-up because it's probably going to come up for somebody else sooner or later. Levana Taylor (talk) 16:33, 1 August 2019 (UTC)

@Levana Taylor: Have you tried escaping the equals signs and other characters that are significant inside a template invocation? Everything in there is a single parameter to the border template so any equals signs or vertical pipes will confuse the parser. —Xover (talk) 17:01, 1 August 2019 (UTC)

OK, that explains the problem but it doesn't fix it, since it leaves you unable to use other templates inside the border. Levana Taylor (talk) 17:08, 1 August 2019 (UTC)

@Levana Taylor: Use {{border/s}} at the beginning, and {{border/e}} at the end, and it should work. —Beleg Tâl (talk) 17:14, 1 August 2019 (UTC)

It does work! Is that documented somewhere? Levana Taylor (talk) 17:20, 1 August 2019 (UTC)

Yes, but only for the use case of spanning page breaks - Help:Page breaks —Beleg Tâl (talk) 17:26, 1 August 2019 (UTC)

I guess the thing to do is to figure out which templates this sort of thing is an issue for and put a note on each one's page. I am doing that for {{border}} now. Levana Taylor (talk) 17:53, 1 August 2019 (UTC)

Database error

Anyone else getting database errors when creating pages this morning?

A database query error has occurred. This may indicate a bug in the software.

[XUMaQgpAADsAAJzbhxIAAAAA] 2019-08-01 16:58:42: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"

—Beleg Tâl (talk) 17:23, 1 August 2019 (UTC)

Great news: 80% of books published between 1924/1963 are public domain

https://www.crummy.com/2019/07/22/0 —Justin (koavf)❤T☮C☺M☯ 20:51, 1 August 2019 (UTC)

First, that's 80% of books published in the US. Also, I've spent some time looking at non-renewed books, and that's not what it feels like. I would bet that 80% of all copies of books were renewed; that is, books printed in a million copies that you can find copies of and that you might have heard of are virtually always renewed, and that most of those non-renewed books are printed in tiny numbers and forgotten. I arbitrarily chose the bestselling novels of 1930, and all ten were renewed. This is not to discourage anyone, but I've been quite discouraged by that 80% figure and comparing it to what I've found in real life.--Prosfilaes (talk) 21:28, 1 August 2019 (UTC)

It also seems that bibliographical databases like HathiTrust do not bother checking whether the work was renewed or not and for sure limit access to all works published after 1923 :-( --Jan Kameníček (talk) 21:55, 1 August 2019 (UTC)

Even IA will sometimes bow to claims, even if the claims are unfounded. An incredible 1912 anonymous publication was pulled from their listing because a later edition (with added content and altered text) was under copyright. --EncycloPetey (talk) 23:24, 1 August 2019 (UTC)

Prosfilaes might be right on 80% of physical books, though it's really a matter of the sorts of things you're interested in. Most of the stuff I've looked up has been academic histories and I've generally found them un-renewed (even though they're typically from major university presses). The ones that were seem to have been at the initiative of the author if I read the copyright records correctly, so the publishers weren't doing it automatically. Anyway, it's a good reason to always double-check the renewal status. —Nizolan ^(talk) 17:57, 2 August 2019 (UTC)

doesn't matter when commons won’t do the work of an actual renewal inquiry. we could have a work flow of non-renewed works, but why bother, when you would have to defend them in perpetuity. the open source librarians are doing the research. and their efforts will continue to show up in press reports. Slowking4 ‽ Rama's revenge 02:31, 3 August 2019 (UTC)

Also on BoingBoing: "Data-mining reveals that 80% of books published 1924-63 never had their copyrights renewed and are now in the public domain" - [11]. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:34, 2 August 2019 (UTC)

Roman Numerals in Page titles...

Elsewhere a template was updated {{article link}}, with the reasoning that English Wikisource had opted, to use standard digits in page names (on the LEFT hand side of piped links) as I understood it, with another contributor returning the relevant template to this in respect of both sides of the template.

Whilst the use of roman numerals for DISPLAY purposes is a different issue, I decided to check on how many works linked using roman Chapter Numerals, in Main namspace.

https://tools.wmflabs.org/grep/index.php?lang=en&project=wikisource&namespace=0&pattern=Chapter+%5BMCLDXVI%5D

At least 19,000 entries use Roman numerals ( based on Chapter numbers only.) . As there isn't as such anything wrong with these, I'd like opinions as to whether there should be a bot derived move and standardisation of format (including updating all links.).

If there's a standard, it should be used correctly? ShakespeareFan00 (talk) 11:50, 2 August 2019 (UTC)

I am considering if looking for roman numerals used as sub page links would be reasonable ShakespeareFan00 (talk) 11:50, 2 August 2019 (UTC)

https://tools.wmflabs.org/grep/index.php?lang=en&project=wikisource&namespace=0&pattern=volume+%5BMCLDXVI%5D (volume) ShakespeareFan00 (talk) 11:50, 2 August 2019 (UTC)

https://tools.wmflabs.org/grep/index.php?lang=en&project=wikisource&namespace=0&pattern=section+%5BMCLDXVI%5D (section) ShakespeareFan00 (talk) 11:50, 2 August 2019 (UTC)

https://tools.wmflabs.org/grep/index.php?lang=en&project=wikisource&namespace=0&pattern=part+%5BMCLDXVI%5D (part).

We've been moving away from using Roman numerals for volumes, chapters, or sections. There are some exceptions where they might be more reasonable to use than standard numerical values, but I think that would depend on the reasons for using them. There should be some reason for preferring one numerical system, and this is one instance where "following the source" isn't (by itself) enough of a reason. Most 19th century works give their year of publication in Roman numerals, but we don't record the date that way; we use the standard numerical system of Arabic numerals for dates.

The trend in both publishing and library science has been to move away from Roman numerals. And using Roman numerals for volume, issue, or chapter numbers makes sequential sorting impossible. The only place I use them with any regularity is in the Acts of plays, where Roman numerals are still standard for bibliographic purposes. Also, because the number of such Acts in a play is also typically limited to five or fewer, sorting is not a serious issue. In fact they will sort correctly up to VIII because the Roman numerals I to VIII are in alphabetical as well as numerical order. The problem begins with IX, which alphabetically falls between IV and V. --EncycloPetey (talk) 18:58, 2 August 2019 (UTC)

The other main reason for transitioning away from Roman numerals is to allow for a standard approach to linking. Newly added works should all be using Arabic numerals at all levels. Works without scans should be updated as scans are found. Older scan-backed works will need careful management as internal links (e.g. TOC) will also need to be updated at the same time. In other words transitioning our entire collection is a major undertaking. Do not rush into it. Beeswaxcandle (talk) 20:38, 2 August 2019 (UTC)

Movement Strategy online surveys - opportunity to share your thoughts about reworking movement structures

Community conversations are an integral part of movement strategy “Wikimedia 2030”. They have been ongoing in multiple formats and in numerous languages over the last 2.5 years. Now it is possible to also contribute to the development of recommendations on structural change via an online survey. We are keeping the survey open for additional 2 weeks and post it to wikis to provide wider opportunities to participate for people interested in it.

The survey is available in 8 languages: Arabic, English, French, German, Hindi, Portuguese, Simplified Chinese, and Spanish. They contain designated questions about each of the nine thematic areas that the working groups are analyzing and drafting recommendations for. You can freely choose the thematic areas you want to contribute and respond to. The survey questions have been created and designed by the members of the working groups.

Here is the link to the survey.

Here you can find more information about the survey.

With any questions, please contact me on my meta user talk page.

Thank you for your kind attention! --KVaidla (WMF) (talk) 14:39, 4 August 2019 (UTC)

p.s. If this is not the right place to post such message on your wiki, I apologize. Feel free to move it where appropriate according to your guidelines. Thank you!

Auth. control squashed

Recently, something has changed that has horizontally squished the width of {{Authority control}} in the main namespace. The template no longer disaplys full width on the page, but is bounded by whatever margins are set by the transcluded page text.

There has been no change to the template itself since 2015, so I assume something has been down to another template or to some other function in the way that the template is displayed. --EncycloPetey (talk) 20:48, 4 August 2019 (UTC)

If I recall correctly, {{authority control}} was one of the boxes that gets repositioned via JS after the page loads. Perhaps this change to the navbox module caused the repositioning script to no longer work? —Beleg Tâl (talk) 12:10, 5 August 2019 (UTC)

Note: I am also seeing the Auth. Control template displayed within the page content, such as HERE where the footnotes appear below the template. Can no one help with this issue? --EncycloPetey (talk) 21:55, 7 August 2019 (UTC)

Fixed in this edit (ignore my edit summary, which was in error). References will always appear last, unless a template such as {{reflist}} or {{smallrefs}} dictates otherwise.

If I have understood it right, the problem is not that references are displayed at a wrong place, but that the authority control box is displayed as narrow as the width of the text (such as at Henry IV Part 1 (1917) Yale), instread of being stretched across the whole page regardless of the text boundaries. --Jan Kameníček (talk) 10:58, 9 August 2019 (UTC)

Two unrelated issues were reported; I responded to the second. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:58, 9 August 2019 (UTC)

Indeed, but the point of my previous post was that its behavior shows the template is being displayed as if it is part of the body text, and that it should not be displayed that way. The display problem persists'. --EncycloPetey (talk) 14:53, 9 August 2019 (UTC)

It's displaying exactly as expected, given the placement of it and other templates on the page. How would you like it to be shown differently? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:23, 9 August 2019 (UTC)

It's supposed to be displayed below the license tag, the same width as the license tag. —Beleg Tâl (talk) 17:17, 9 August 2019 (UTC)

← On the page in question, the templates are occur in the markup in this order:

{{Authority control}}
{{Pd/1923|1927}}

and so they display in that order. The solution to this issue is left as an exercise for the reader. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:39, 9 August 2019 (UTC)

@Andy Mabbett: Can you please specify the alleged solution instead of the irony? Thank you. --Jan Kameníček (talk) 06:50, 10 August 2019 (UTC)

Arbitrary break (Auth. control squashed)

This needs an interface admin to fix (ping Billinghurst: are you up for it?).

The problem here is that MediaWiki:PageNumbers.js uncritically wraps all page content (everything generated directly from the wikimarkup that we can edit) in a set of layout containers that it needs to do the layout it needs. That leaves things like authority control and license boxes inside those layout containers and makes them subject to the same layout that the rest of the content are. Since this is not desirable there are manual fixup functions added to MediaWiki:Common.js that move these page elements outside the layout containers that PageNumbers.js just wrapped them in (note the fragile dependency on load order here, btw).

The code that moves {{authority control}} out of the layout containers is:

  …
  $( 'table.acContainer' ).insertAfter( $( 'div.printfooter' ) );
  …

Note that it uses a selector specifically for a HTML table element, and it looks for a specific class attribute. When Module:Navbox was updated from enwp two things happened: 1) the custom code we use here for adding a class to a navbox (which authority control makes use of) was overwritten and thus stopped adding that class, and 2) navboxes switched from being based on tables and are instead based on div elements. Thus neither part of the selector would match, and the authority control box was no longer moved out of the layout containers, leading to the squashed appearance noted here.

I have added back in the custom code to Module:Navbox, so the ".acClass" part of the selector will now match. But the assumption that the box is a table needs to be changed in MediaWiki:Common.js which requires interface admin rights to modify. The needed change is to simply drop the "table" bit of the selector, making the line:

  …
  $( '.acContainer' ).insertAfter( $( 'div.printfooter' ) );
  …

I can't really test this change (all this stuff is happening in global javascript that is loaded unconditionally), but so far as my code analysis can determine that should be sufficient. And that selector shouldn't be that specific in any case: selecting for the class name should be both sufficient and a lot more flexible. --Xover (talk) 10:02, 10 August 2019 (UTC)

Done change made; if it isn't right, then it isn't going to kill much. — billinghurst sDrewth 10:35, 10 August 2019 (UTC)

Thanks! I've also started a discussion at enwp to see if we can get the necessary parameter added upstream so we won't have to keep patching it in every time we resync from there. --Xover (talk) 10:39, 10 August 2019 (UTC)

use LinuxLibertine font in wikisource logo.

Tracked in PhabricatorTask T229769

retouned, kerning adjusted to match original File:Wikisource-newberg-de.png

For consistency with Wikipedia logo. Viztor (talk) 02:31, 5 August 2019 (UTC)

The current WikiSource logo is graphic drawn from here. Are you suggesting that this particular font was not used when constructing that image? Will the change process not require resort to a new Phabricator request, even assuming the change is justified? 114.78.171.144 11:11, 5 August 2019 (UTC)

Logo updated to commons. The current logo does not use that font as it was created in 2006 and was not updated following a font change of wikipedia logo in 2010. Notice the related phab task will also add hd logo to display.Viztor (talk) 16:12, 5 August 2019 (UTC)

Also discuss on Multilingual Wikisource Viztor (talk) 16:13, 5 August 2019 (UTC)

deterioration on subpages

It seems that we have had what I call an less than desirable practices occurring on subpages, and not being picked up in patrolling

1. The addition of year parameter
2. running and repeating notes
3. The use of a hard title rather than [[../]]

For the first two, they should only be appearing at the top level of a work, the subpages would only appear if the detail differs from the parent page. The third point, enables a link to the top of the work. — billinghurst sDrewth 12:06, 5 August 2019 (UTC)

Also to note that I am coming across numbers of hard links for prev/next rather than relative links. — billinghurst sDrewth 12:08, 5 August 2019 (UTC)

There is no guideline recommending the date be omitted on subpages. For many works hosted here, subpages can contain complete works in and of themselves (poems, plays, translations), for which the year is a desirable inclusion. Notes can be especially helpful on articles to provide the citation form for academic articles. The use of a sem-hard title is sometimes necessitated (i.e. [[../|TITLE]] ) especially in cases where the work's main page title is a disambiguative title containing elements which are not part of the title itself. In short, none of these things you've listed is a problem, in and of itself. You'll need to provide specifics as to what sort of instances you see as problems. --EncycloPetey (talk) 15:01, 5 August 2019 (UTC)

Ditto, I’m not sure what the problem is. Yeah, I wouldn’t need to repeat the year every page if it was inherited from the volume, but as for the others ... do you object to the use of the notes field as a place to put something to page through the parts of a serial work [see example]? It’d be nice if there was a dedicated way of putting that at the head and foot of the serial part, but otherwise, notes is the natural place for it at the top, and at the bottom, I link the "to be continued" to the next part. For the latter I use a hard link so it is clickable from Page namespace. --Levana Taylor (talk) 15:24, 5 August 2019 (UTC)

There is the template {{series}}, though in my opinion it's kind of ugly and your solution is nicer. —Beleg Tâl (talk) 02:26, 6 August 2019 (UTC)

Just a note, the "year" parameter is supposed to be the year of the edition, so having a different year on different subpages should only be the case for works that are published in parts over the course of several years (such as some multi-volume works). —Beleg Tâl (talk) 02:11, 6 August 2019 (UTC)

Indeed, I have worked on a three volume series in which each volume was published in a different year, or where our local copy of a particular volume comes from a different year than the other volumes. But it is also not unusual in works I have done for the subpage to contain a work complete in and of itself (journal article), or complete edition or translation of a work (play or poem) included within a volume that contains multiple works. It is useful then to have the date of publication displayed on the same page with that edition/publication, rather than force the reader to go to another page looking for the date that particular edition was published. --EncycloPetey (talk) 22:01, 7 August 2019 (UTC)

Is this written somewhere? I'm not arguing about the points, but it's hard to know what to do or expect others to know what to do if it's not written down anywhere.--Prosfilaes (talk) 02:01, 6 August 2019 (UTC)

Auto generated headers always include the year, and personally I will add the year to subpages if it is omitted. —Beleg Tâl (talk) 02:07, 6 August 2019 (UTC)

It's worth noting that despite the disagreement on this point, I agree that it is undesirable to have general notes regarding the work repeated on every subpage, and of course hard title links on subpages are a bad practice and should be fixed when seen (and I mean specifically [[Title]] and not [[../|Title]], the latter of which is excellent practice). Even worse are works where the subsections are top-level pages, though these are usually really old collections of poetry, and I haven't seen any new works added in this way recently. —Beleg Tâl (talk) 02:15, 6 August 2019 (UTC)

•  Comment The year in the header replaced the manual addition of [[Category:YYYY works]] and categorises the work (primary purpose), and tagged the top level the work, and was added as a parameter to be a good cue to do the addition, as it had been sporadic in its addition in the early years [check archives of this page]. Why would we want every subpage categorised? The year has been the year published, and has been for years; and the practice for the use of the notes field for specific additional detail is the purpose of the notes field, and has regularly carried additional detail like "written in YYYY", "first published in ...". Where we have a three volume/three different year work, then that is the time that we would look to identify volumes specifically, and it is why it remains as an option to be used as required.— billinghurst sDrewth 11:48, 10 August 2019 (UTC)

The dating of the volumes of Once a Week seems problematic, then, because the collected volume was assembled in e.g. 1862, but some of the contents had appeared in 1861. Currently the date is being entered as "1861-1862," which prevents "xxxx work" from being created automatically. I have no problem with entering only 1862 for the volume’s own page, but it leaves me puzzled what to do on subpages. There should be a date on each subpage so that stories and articles are categorized by date. But, the ones that appeared in 1861 should probably be "1861 work." The problem is that when you enter the year parameter the year is displayed next to the title of the main work. What to do when you want to enter a year that is different from that of the volume? Admittedly, this may not be a very big problem, since the only issue from the previous year included in the volume is the last week of December! So if you categorized a story from Dec. 27, 1861, as an "1862 work" that’d hardly be very inaccurate… Levana Taylor (talk) 16:01, 10 August 2019 (UTC)

The categorization of the work is not the only purpose of the year in the header (otherwise it would categorize only and not display). I think that having the year in the header of a subpage is as valuable as having the author in the header of a subpage, if only so that the top line of WORK (YEAR) BY AUTHOR remains relatively consistent on all pages of the work. —Beleg Tâl (talk) 01:16, 11 August 2019 (UTC)

• The notes fields was designated to cover all the non-published content that was going to be of valuable to a page. It is why we poke {{CompactTOCalpha}}, {{Illustrator}}, and the like in that space. — billinghurst sDrewth 11:49, 10 August 2019 (UTC)

OT re illustrators -- Is it encouraged to creat "Author" pages for illustrators who don't have text works? I couldn’t find anything about this in help. Levana Taylor (talk) 16:01, 10 August 2019 (UTC)

@Levana Taylor: definitely create Author pages for illustrators. See Category:Illustrators for examples. —Beleg Tâl (talk) 01:13, 11 August 2019 (UTC)

{{Illustrator}} has an #ifexist statement, so reactively it will hyperlink to existing author pages.

Tech News: 2019-32

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

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 6 August. It will be on non-Wikipedia wikis and some Wikipedias from 7 August. It will be on all wikis from 8 August (calendar).

Problems

• A change in RelatedArticles extension accidentally enabled it for everyone, not just for mobile users. This has been fixed. [12][13]

Meetings

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

Future changes

• Today everyone can see IP addresses if someone edits without an account. In the future this could be more hidden. This is to protect unregistered editors so fewer can see their IP address. This would only happen after we make sure the tools for vandal fighting can still be effective. You can read more and comment.

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

13:25, 5 August 2019 (UTC)

Emoji symbols

Symbols such as ⚓ (anchor) ✈ (airplane) ⚙ (gear) ⚒ (hammers) ⚔ (swords) that might appear in dictionaries have a dual nature in Unicode, either as printed text symbols or as emojis (possibly with coloured background). Friends tell me that they can be followed by 0xFE0E to enforce text style (⚓︎⚙︎⚔︎) or 0xFE0F to enforce emoji style (⚓️⚙️⚔️). (It seems Mediawiki doesn't show any difference, at least in my browser.) Should e-texts in Unicode/UTF-8 contain these additional characters? Or should we expect that an e-text always contains only printed text symbols, and make the software produce the right HTML/CSS markup for this? Has this ever been discussed? --LA2 (talk) 15:09, 6 August 2019 (UTC)

There shows a difference in my browser. Messing with MediaWiki is unlikely, so we might want to make a note or template to enforce text style where necessary. I don't know that it matters that much; a dictionary that used an anchor to mark nautical words, which seems to be one of the more obvious uses of characters like these, in the environment of a full-color screen, would be better off with emoji forms, and letting the system choose would be easier and arguably a better solution.--Prosfilaes (talk) 01:40, 7 August 2019 (UTC)

The character ☞︎ appears in a large number of texts, and is increasingly shown as ☞️. I don't think it's possible currently to control this display in a meaningful way using CSS or similar, but it looks like this is in the works for a future CSS specification. I am okay to leave it be in the meantime, but otherwise a template would be the most reasonable solution. —Beleg Tâl (talk) 13:17, 7 August 2019 (UTC)

By default, that's displayed as ☞.--Prosfilaes (talk) 18:55, 7 August 2019 (UTC)

I only see the difference in IE; Chrome on Windows 10 and Android show only the plain text style. But the bright yellow finger in IE really does stand out, but not in a good way. We will start having works best displayed in emoji style, though; wait until Wikileaks dumps the important texts of some millennial law maker.

We could have one template like {{textstyle}} or one for each character; it might be easier for the later. Subst or no?--Prosfilaes (talk) 19:01, 7 August 2019 (UTC)

Picture reproductions

While preparing the image on this page I found out that a much higher quality, colour version of the picture is already available on Commons here. There's no additional info on the book page, as there sometimes is with e.g. photographs of paintings, so is there any reason not to use the better version given that the quality of the book copy is presumably a technical limitation and not the author's intention? I've already cleaned up the book version so it's no skin off my back either way, but it did occur to me that it's potentially odd not to just use the better one. —Nizolan ^(talk) 22:05, 7 August 2019 (UTC)

The two versions can be compared in this version of the page (which I have since reverted). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:39, 8 August 2019 (UTC)

I've used a crop of the colour version now, it can be seen in context at the chapter subpage here. —Nizolan ^(talk) 12:31, 9 August 2019 (UTC)

Requesting import of "Links count" gadget

Please can someone (an admin, or whoever has the necessary permissions) import the very useful gadget "Links count" (counts total number of pages linked to a specific page on Special:WhatLinksHere (and transclusion, for templates)), as used on Wikidata Wikispecies and Commons? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:20, 10 June 2019 (UTC)

Can anyone help with this, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:13, 9 August 2019 (UTC)

@Pigsonthewing: I am not certain that we need the gadget as it isn't likely that it will be widely utilised, suggest that you add it to your special:mypage/common.js or better yet add to your m:special:mypage/global.js so you have it everywhere you go. If you are unsure what that would look like then please look at my global js page at meta. — billinghurst sDrewth 08:18, 10 August 2019 (UTC)

Or I can add it to either of those two places for you. — billinghurst sDrewth 09:31, 10 August 2019 (UTC)

Template:URL to diff

Please can someone import w:Template:URL to diff from en.Wikipedia? Its use is described over there. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:15, 9 August 2019 (UTC)

Done — billinghurst sDrewth 08:30, 10 August 2019 (UTC)

@Billinghurst: Thank you, but it seems to be missing w:Module:OutputBuffer and w:Template:Subst only. Please could you also import those and an further child items? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:30, 10 August 2019 (UTC)

Brought over the module. Not brought over the template, we will need to edit it out of wherever it is. You will need to work out whether there are other templates that need importing and let us know. — billinghurst sDrewth 12:40, 11 August 2019 (UTC)

Thank you. Let's see 9533417. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:12, 11 August 2019 (UTC)

No :-( the displayed text is "diff", it should be "if this works". It seems that {{diff}} works differently on this project. Can anyone see any issues with updating it to work like w:Template:diff? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:16, 11 August 2019 (UTC)

Tech News: 2019-33

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

• Editors using the mobile website on Wikipedia can opt-in to new advanced features via your settings page. This will give access to more interface links, special pages, and tools. Feedback on the discussion page is appreciated. [14]
• Due to the absence of volunteer maintenance of Cologne Blue skin, the link to activate it will be hidden. The skin will still work, but editors using it are encouraged to switch to another skin. [15]

Changes later this week

• Due to Wikimania, there is no deployment this week. [16]

Meetings

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

Future changes

• The "Wikidata item" link will be moved from "Tools" to "In other projects" section on all Wikimedia projects, starting on August 21. Full announcement, Phabricator task.

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

18:19, 12 August 2019 (UTC)

SVG?

For simple graphics like the image on Page:Aircraft in Warfare (1916).djvu/250, is it best to take a screenshot, or find someone who can recreate them as SVG graphics? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:54, 12 August 2019 (UTC)

It's definitely worth recreating them as SVG if possible, but screenshots are ok too if you don't have someone to recreate them in SVG. —Beleg Tâl (talk) 20:25, 12 August 2019 (UTC)

Suggested changes Template:Header

Template:Header has been mishandling translations of subpages where the subpages have page specific & different information from the work, I started a discussion at Template talk:Header a little while back. I have made suggested changes to the sandbox for the template with testcases. I would appreciate if someone could look at the changes, and if considered problematic, then please put such commentary and suggestions on the template's talk page. Thanks. — billinghurst sDrewth 10:56, 13 August 2019 (UTC)

I've bascily had enough...

Index:Ruffhead - The Statutes at Large, 1763.djvu

Having tried various approaches to get the sidenotes to behave CONSISTENTLY over the long term, (and in a manner which is translateable to the other Wikisource on which the equivalent French and Latin parts are transcribed. I've effectively found it's IMPOSSIBLE to use ANY of the approaches in a way that would adequately represent the text this particular volume.

If this kind of work can't be adequately represented (and currently I feel it can't), then it's not worth the hassle in retaining it, despite the considerable effort expended in trying to find appropriate ways to represent what's present figuratively, and ALL nine volumes should be removed from English Wikisource. (The scanned volumes can be retained at Commons, until someone is actually prepared to make the back end changes needed to adequately represent it.). ShakespeareFan00 (talk) 14:21, 13 August 2019 (UTC)

I've mentioned the issue with the side-notes as well as various incompatibilities with other typographic templates repeatedly in the past (with certain contributors apparently unwilling to attempt an update to either the templates or back end code, for entirely practical reasons). Currently when there are a number of indivdual sidenotes close together, or another "floated" template, the positioning of sidenotes can be unexpected, and they can also undesirably overlap. This is down to the use of "position:absolute;" and an inline span. The use of this means that in the absence of specfying a vertical shift on the subsequent sidenotes in a line, they all map to the same horizontal postion on the SAME line, which means naturally that they will overlap (which is not what is typically desired.)

The alternative approach, and the one which would be considerably more benefical to contributor sanity in the long-term is to finally STOP trying to shorehorn sidenotes and sidetitles in as "inline" content in the first place. They should be in a seperate part of the "dynamic" layout. However, based on past experience I don't see this being implemented any time in the next decade.

ShakespeareFan00 (talk) 14:48, 13 August 2019 (UTC)

Sidenotes are problematic, and we know it. Few of us have the CSS skills, and they don't translate well to modern broad landscape screens from portrait pages. Most of us just shy awy from such works, and do something else. We don't keep hammering away on the blindingly difficult. — billinghurst sDrewth 14:52, 13 August 2019 (UTC)

Well on that basis, I will certainly consider putting all the content related to this at Proposed Deletions. If it can't be adequately represented, there's no point in hosting a partial and poor version. Most of it's raw unproofread OCR in any instance. ShakespeareFan00 (talk) 15:47, 13 August 2019 (UTC)

I also from your comment, will reconsider if certain other partially transcribed works, should also continue to be hosted in their current formats, if there's a lack of expertise to support the functionality necessary. ShakespeareFan00 (talk) 16:13, 13 August 2019 (UTC)

I will also (again) note that the sidenotes issue isn't assisted by a lack of documentation of how the underlying code is intended to function, (such as the relevant classes and document structuring), as i found when attempting to figure out what broke in the various approaches used.ShakespeareFan00 (talk) 16:35, 13 August 2019 (UTC)

i would support a consensus of proceeding without sidenotes. we could note that at these works, and move on. Slowking4 ⚔ Rama's revenge 17:32, 13 August 2019 (UTC)

no need to delete, it is not a deletion rationale, rather a lack of consensus of how to proceed, with a backlog. raw OCR is better than nothing. Slowking4 ⚔ Rama's revenge 19:19, 13 August 2019 (UTC)

I agree with @Slowking4: The presence of sidenotes is rarely something I'd view as a make-or-break issue. Texts are generally just fine without them, and it's not mission-critical that all printers' decisions be represented accurately. That said, I appreciate the efforts of @ShakespeareFan00: and others to create tools to make it work as well as possible. -Pete (talk) 18:05, 13 August 2019 (UTC)

yeah, it was an attempt to replicate the marginalia of manuscripts.[17] and we attempt to preserve the anachronism. it was worth an effort, but i would move on, without them. it’s a wiki and if a better solution comes along, we can always add them in. Slowking4 ⚔ Rama's revenge 19:22, 13 August 2019 (UTC)

It would also be nice if (as opposed to having various ever so slightly different templates), there was ONE template for doing sidenotes, margin notes etc, that actually worked in all use-cases, so far there have been various and inconsistent different templates used in this work, which is why it may be easier to start again completely, with someone else ENFORCING and FULY DOCUMENTING a SINGLE approach for how it's SUPPOSED to be done, as opposed to the various inconsistent experimental approaches, various contributors (myself included) have attempted. ShakespeareFan00 (talk) 20:48, 13 August 2019 (UTC)

For sidenote references like the ones in the works linked above the obvious option imo, which I suggested recently for Index:Commentaries of Ishodad of Merv, volume 1.djvu recently but haven't summoned up the interest to implement properly yet, is simply to convert them into an ordinary group of footnotes, with notes in the text. Looking at the text I don't see any reason why that would be an inadequate representation of the data in this case. The only problem is deciding where exactly to put the notes in the text, but that's an issue for sidenotes anyway. They can't just be ignored, though, they are an integral part of the work. —Nizolan ^(talk) 00:21, 14 August 2019 (UTC)

Noting ftr that discussion is split here and Wikisource:Proposed_deletions#Index:Ruffhead_-_The_Statutes_at_Large,_1763.djvu —Nizolan ^(talk) 00:32, 14 August 2019 (UTC)

An aside , but it's essentially Biographical research on 18th and pre-18th century English Jurists and legal scholars, would be the list I started compiling here- Index_talk:Ruffhead_-_The_Statutes_at_Large,_1763.djvu#Identification_of_references.. Knowing the authors cross refrenced (and the editions of the works concerned) might help in placing the sidenotes. ( especially if the cross-referenced editions are now online in scanned form somewhere.)ShakespeareFan00 (talk) 07:26, 14 August 2019 (UTC)

British English in an American work

I'm new here, and I can't find any guidelines on this. The question came up as I read Jack London's John Barleycorn. London is an American author, and the book is a memoir set in the US, but the Wikisource version contains distinctly British spellings such as 'meagre' and 'centreboard'. The original at Project Gutenberg has no obvious publisher information. Google Books has versions published in the US, with American spelling (e.g. this one from Century) and others published in the UK, with British spelling (e.g. this from Mills & Boon).

The WS version with British spelling is true to the source in the sense of being faithful to the Project Gutenberg file, but not, I believe, in showing the book as it was originally written and published. What should be done? I see several options, in order from least amount of work required to most:

1. Do nothing.
2. Change the current WS version to American spelling.
3. Add a new source file with the American version.

My preference would be the second: The book's language would then reflect its American origin, and the amount of labo(u)r involved would be minimal. Would this violate any policies or guidelines? BlackcurrantTea (talk) 04:50, 14 August 2019 (UTC)

We do not do ad-hoc changes to works. WS:Annotations is limited, and is only ever done on a separate copy of the work. If you want this, you'll need to add a new source file and transcribe it.--Prosfilaes (talk) 05:55, 14 August 2019 (UTC)

If the original edition used different spelling, than the best solution is to upload scans of the original edition to Commons and transcribe it separately. --Jan Kameníček (talk) 08:15, 14 August 2019 (UTC)

Here is a full scan of the Mills & Boon edition, which uses the spellings of "meagre" and "centreboard" as in our edition. I'd guess it's the edition that the Gutenberg text is based on, and we could use it as a starting point for backing our own copy. —Beleg Tâl (talk) 12:28, 14 August 2019 (UTC)

•  Comment @BlackcurrantTea: Add a new source file with the American version. We publish versions/editions of work and reproduce them as they were published. We are not restricted to one copy of a work, so if you have the time and inclination to work on a publication that is in the presentation from the publisher/edition that you prefer, then that power to you. — billinghurst sDrewth 22:56, 14 August 2019 (UTC)

I'll leave the language in the current one in its UK form, and keep the option of adding a new source text in mind. Thank you all for your replies. BlackcurrantTea (talk) 05:12, 15 August 2019 (UTC)

Scans not showing, again

Having recently uploaded the DJVU file and created Index:Aerial Flight - Volume 1 - Aerodynamics - Frederick Lanchester - 1906.djvu, I am again left with editing windows where the PDF scan is not showing, at all, on the right-hand side, for any of the pages.

If I click on the "image" tab, they render correctly and immediately.

For a while they did show correctly in the editing view.

This occurs even after restarting my browser, and my laptop.

Can anyone advise or assist, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:55, 14 August 2019 (UTC)

@Pigsonthewing: [you mention pdf, for a djvu, so I am presuming that is a slip of the tongue.] I am seeing images, where I visit. What you are mentioning is often (usually?) an artefact of the thumbnail rendering of the media, and it pops its head up at times. One of the means you can force something if it is stuck is to change the image size via the Index page Scan resolution in edit mode, and just change the default by a pixel (here it is a unitless field). It isn't a perfect scenario. — billinghurst sDrewth 23:12, 14 August 2019 (UTC)

@Billinghurst: Yes, I meant Djvu. As you say, it seems to be working OK now. Thanks for the tip. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:54, 16 August 2019 (UTC)

 This section is considered resolved, for the purposes of archiving. If you disagree, replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:55, 16 August 2019 (UTC)

Update on the consultation about office actions

Hello all,

Last month, the Wikimedia Foundation's Trust & Safety team announced a future consultation about partial and/or temporary office actions. We want to let you know that the draft version of this consultation has now been posted on Meta.

This is a draft. It is not intended to be the consultation itself, which will be posted on Meta likely in early September. Please do not treat this draft as a consultation. Instead, we ask your assistance in forming the final language for the consultation.

For that end, we would like your input over the next couple of weeks about what questions the consultation should ask about partial and temporary Foundation office action bans and how it should be formatted. Please post it on the draft talk page. Our goal is to provide space for the community to discuss all the aspects of these office actions that need to be discussed, and we want to ensure with your feedback that the consultation is presented in the best way to encourage frank and constructive conversation.

Please visit the consultation draft on Meta-wiki and leave your comments on the draft’s talk page about what the consultation should look like and what questions it should ask.

Thank you for your input! -- The Trust & Safety team 08:03, 16 August 2019 (UTC)

Biodiversity Heritage Library template

Based on {{Google Book Search link}}, I have just created {{BHL page link}} for linking to scans on the Biodiversity Heritage Library. {{BHL}} is available as a shortcut. The template adds pages to Category:Scans from BHL.

The Google template is multilingual; should we do the same with the new template? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:34, 16 August 2019 (UTC)

Smithsonian Transcription Center

I just saw https://transcription.si.edu/about at wikimania:2019:GLAM/The Smithsonian: A Partnership to Improve Gender Representation Online. It was started in 2013 and apparently it has hundreds of volunteers transcribing catalogue cards etc. It's based on Drupal and I'm told they're trying to publish it as free software. Nemo 13:11, 16 August 2019 (UTC)