Latest comment: 4 months ago1 comment1 person in discussion
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Feature news
Two new parser functions will be available this week: {{#dir}} and {{#bcp47}}. These will reduce the need for Template:Dir and Template:BCP47 on Commons and allow us to drop 100 million rows from the "what links here" database. Editors at any wiki that use these templates, can help by replacing the templates with these new functions. The templates at Commons will be updated during the Hackathon at Wikimania. [1][2]
Communities can request the activation of the visual editor on entire namespaces where discussions sometimes happen (for instance Wikipedia: or Wikisource: namespaces) if they understand the known limitations. For discussions, users can already use DiscussionTools in these namespaces.
The tracking category "Pages using Timeline" has been renamed to "Pages using the EasyTimeline extension" in TranslateWiki. Wikis that have created the category locally should rename their local creation to match.
Project updates
Editors who help to organize WikiProjects and similar on-wiki collaborations, are invited to share ideas and examples of successful collaborations with the Campaigns and Programs teams. You can fill out a brief survey or share your thoughts on the talkpage. The teams are particularly looking for details about successful collaborations on non-English wikis.
The new parser is being rolled out on Wikivoyage wikis over the next few months. The English Wikivoyage and Hebrew Wikivoyage were switched to Parsoid last week. For more information, see Parsoid/Parser Unification.
The latest quarterly Language and Internationalization newsletter is available. It includes: New design previews for Translatable pages; Updates about MinT for Wiki Readers; the release of Translation dumps; and more.
Can anyone explain how the mobile view UI layout works for book index pages?
Latest comment: 4 months ago3 comments2 people in discussion
For example, let's take a look at Index:Paradise_Lost_(1667).djvu. On a desktop computer, clicking the Mobile-view link at the bottom of the page results in having the Title/Author/Editor/Year information displayed to the right from the book cover image. But on an Android tablet, I see that the same Title/Author/Editor/Year information is placed below the book cover. Where is this configured? Is this determined by some CSS, JavaScript, Wiki templates or Lua code? I also see that there are various appearance skins, such as Vector legacy (2010), Vector (2022) and the others. Do they affect anything? Even though I tried to check the default settings. I mean, the way how Wikisource is visible to the anonymous logged off users.
Should do it, but regarding the placement of the informations, I suspect it's just a question of screen width. If, on a desktop computer, you go to mobile mode, and then narrow the window, you'll eventually see the same happening. Skins may help, as some (particularly thinking of Vector 2022) add a margin on the sides, and changing to desktop mode may too, as mobile mode also adds a margin. These margin facilitate the informations just wrapping around.
Opensource Chromium browser showing a Wikisource page with different window resize @Alien333: Thanks! You are right. I'm using a Chrome/Chromium browser. Resizing the window in the mobile view mode indeed flips the placement of the Title/Author/Editor/Year information even on a desktop computer. And it doesn't look particularly neat in either case. Belarusian Wikisource policy currently discourages adding ToCs to index pages because of the mobile view ugliness. I thought that this policy could be updated if the site is re-configured not to show the ToC in the mobile view mode. I guess, the admins just need to add that tweak to some global CSS, which is responsible for the mobile view. Maybe even something smarter can be done, like stripping everything except for the chapter numbers and page numbers, thus making the ToC much more narrow. But I wouldn't hold my breath. --Ssvb (talk) 10:47, 6 August 2024 (UTC)
Reminder! Vote closing soon to fill vacancies of the first U4C
Latest comment: 4 months ago1 comment1 person in discussion
The voting period for the Universal Code of Conduct Coordinating Committee (U4C) is closing soon. It is open through 10 August 2024. Read the information on the voting page on Meta-wiki to learn more about voting and voter eligibility. If you are eligible to vote and have not voted in this special election, it is important that you vote now.
Why should you vote? The U4C is a global group dedicated to providing an equitable and consistent implementation of the UCoC. Community input into the committee membership is critical to the success of the UCoC.
Please share this message with members of your community so they can participate as well.
Latest comment: 4 months ago21 comments6 people in discussion
I know the subject of the long-s has been brought up in the past, and it's a whole can of worms. Apologies to whoever has memories of heated long-s discussions. That being said, I have a solution nagging at me, and I would like to know if it's possible.
Currently the long-s is handled by using {{ls}}, and can be visible if the user enables the Visibility gadget in Preferences. This presents two issues: (1) the editing pane is practically unreadable in any pre-1800s text due to being littered with so many {{ls}} templates, and (2) I doubt very many Wikisource users even know about the Visibility gadget, much less use it. So it seems to be a significant detriment to editors, with practically no usage.
My idea is to allow the use of the long-s character instead of the template, and add a native button on the sidebar to switch between rendering the long-s character as a round-s (normal-s) and vice versa—just like what the Visibility gadget does, but without having to be enabled in Preferences.
I have heard that the long-s character is not used is because searching for the letter "s" with "Ctrl+F" will not highlight long-s characters. This is false! Firefox and Chrome both recognize the long-s character as an "s" and will highlight it, and I would assume the other Chromium-based browsers would follow suit. Because of this, it seems to me like it's within our power to enact this change, but I could be wrong! Am I missing something here?
I've thought about the possibility of having an "automatic long-s generator" function like that, so that editors could just type round-s. But unfortunately, history presents too many exceptions in long-s usage, and over time, the character developed slightly different syntax rules. It would be near impossible to cover all the slight variations in a single function. So {{ls}} is on the right track, in that being able to type the character itself lets editors match the scans more accurately.
The way I see it, either short-s and long-s are separate characters (like 's' and 'S'), OR they are separate glyphs for the same character (like 's' and 's'). If the former, then any approach to transcription short of directly using 'ſ' is invalid and needs to be treated as an annotation, and the use of "hist" or "ss02" to modify the glyph is insufficient. If the latter, then I don't think it's a problem if slight variations are ignored, just as we ignore other differences in glyphs caused by differences in typeface between the original and the transcription. After all, replacing 'ſ' with 's' or {{ls}} is also a form of ignoring variations with a standard approach, and one which is commonplace and well-accepted here. (This is just my opinion btw.) —Beleg Tâl (talk) 17:20, 6 August 2024 (UTC)
I would argue that the long-s presents an exception: it's an unnecessary character, similar to the ligature "st," but unlike "st" it's an extremely visible difference. It seems to me like Wikisource has more of a subjective rule on what archaic characters are transcribed, and it usually comes down to how visible it is.
Consider what we do for the characters "Æ" and "Œ." These are obsolete characters, yet we transcribe them because they're used historically and they look fairly distinct from the equivalent "AE" and "OE." No offence to "st," but it doesn't look very different to "st," and so we don't waste effort on it. I would treat the long-s in the exact same way as we treat "Æ," the only differences being that it isn't a ligature.
Seems to be true, "st" isn't searchable for me. Maybe I'm wrong about conventions and we transcribe any character as long as it's supported in major search functions, or maybe it's a mix of both reasons.
FWIW, the WS internal search can be potentially adjusted in the future if tickets are opened about its problems on Phabricator. See this and this for more information. But people are probably already aware of that and my comment was unnecessary. --Ssvb (talk) 10:44, 7 August 2024 (UTC)
Æ is a good example of what I'm saying; we have decided that "Æ" and "AE" are two different (sets of) characters, and we consider it wrong to transcribe one as the other. But we consider the "st" ligature to be simply a different glyph for, well, "st" (and this is backed up by Unicode's position on the subject), so we transcribe it as "st" and leave the ligatures up to the font. Similarly, I'd say that we should either insist on transcribing ſ as ſ, or we should be fine with transcribing it as "s" and leave the presentation up to choice of font. (It's also worth noting that it may vary by context, and in many contexts "æ" is syntactically different from "ae". Is "ſ syntactically different from "s"? If so, I'd consider that evidence of treating it as a character that ought to be transcribed as-is.) —Beleg Tâl (talk) 14:07, 7 August 2024 (UTC)
I can probably come up with an argument to defend that long-s is syntactically different from round-s, but I'd like to direct this back to the fact that using {{ls}} is already a convention, as stated on WS:Orthography. I'd just like editors to be able to use "ſ" instead since it doesn't make the editing pane near-unreadable, while still following the Understandability guideline.
We convert “ and ” to ", which I consider a bigger problem. There's a range of things here; "st" is a ligature that was added to Unicode purely for compatibility purposes. Ligatures should be added by the font or typesetter. There once was typeset facsimiles, but the availability of photocopies and later scans have made that expensive process pointless.
ſ is complex to do programmatically. At the same time, it's just a positional variant of s, and I don't see any reason not to treat it as a typesetting artifact of an older time. There's no value to keeping it.
æ and œ are more recently in use, and are available in 8-bit character sets, meaning they're in basically all English fonts. Their use is more discretionary, and replacing them feels much more like a spelling change. They're also letters in various languages, meaning replacing them in all cases is simply wrong, unlike "st" and ſ.--Prosfilaes (talk) 23:22, 6 August 2024 (UTC)
I think there's a lot of value in discussing conventions on a broader scale, like the use of straight-quotes or the usage of long-s as a whole, but the fact remains that many editors already transcribe long-s with {{ls}}, and it is an accepted technique as stated in WS:Orthography. My goal is to make transcribing long-s easier by not requiring a template, while retaining the toggle function for modern reading tastes.
I don't agree that "there's no value to keeping it." It's a notable-enough character to be supported by major browsers and search functions—potentially having even more consistent search-support than "Æ," as suggested by @Alien333. It doesn't just exist in English, either. It was used in Spanish as well, and I would extrapolate that it probably existed in other Romance languages (though this shouldn't matter much, as this is English Wikisource). Plus, long-s does have syntax rules depending on the decade it was used, which are generally stated in its Wikipedia article, and which I advocate for following, though @Beleg Tâl's prototype poses a very tempting trade-off.
It's true that long-s isn't covered in every font, but it's covered at least in the default Wikisource font, and any user who changed their font to one that doesn't contain long-s and reads pre-19th century works would have no issues, since the long-s render toggle would be "off" by default, as it already is, whether or not the user enables the Visibility gadget.
You mentioned that long-s is "complex to do programmatically." Can you elaborate on that? I'm no JS programmer, which is why I can't develop this tool myself, but I'm having trouble understanding what makes my idea more complex than what the Visibility gadget already does.
The character adds nothing to the text; when it dropped out of use, the Encyclopedia Britannica was reissued with no changes but removal of the long s.
It was in use of all languages written with the Latin script at the time. But æ and œ are used as letters in languages, particularly æ in Danish and other languages; the long s isn't used to mean something distinctive.
The long s is difficult programmatically in that in some traditions, it can take morphological information to properly replace s with the long-s. I don't know the details about Wikipedia.--Prosfilaes (talk) 03:33, 7 August 2024 (UTC)
As long as we're using JS, I must admit I have trouble understanding the problem. The plan would not be, as far as I'm aware, for the proofreaders to use always s and for the script to in some cases replase by ls, but for the proofreaders to use the same characters as in the text and for the script to show either the text as it is, which requires nothing, or to replace all ls by s, wchich would just be something like a .replaceAll("ſ", "s"), wouldn't it? — Alien333 (what I did & why I did it wrong) 08:15, 7 August 2024 (UTC)
Is anyone else having an issue with AWB?
Latest comment: 4 months ago11 comments3 people in discussion
It is suddenly telling me "This user doesn't have enough privileges to make automatic edits on this wiki". Note that I am trying to make assisted edits, not bot edits, but I am unable to get far enough into the login process for that distinction to matter. BD2412T21:06, 7 August 2024 (UTC)
This actually appears to be the case on other Wikimedia projects as well, other than Wikipedia. I have had no luck with other-language Wikisource projects, or Wiktionary projects. BD2412T01:16, 8 August 2024 (UTC)
@Xover Just checked, and I'm still getting the same error here on enws and all other sites I've checked, except Wikipedia. With Wikipedias:
If I try to log in to en Wikipedia where I'm added to Project:AutoWikiBrowser/CheckPageJSON, it works fine
If I try to log in to one which doesn't have Project:AutoWikiBrowser/CheckPageJSON (the first one I found was be-tarask Wikipedia), it logs in fine
If I try to log in to one which has Project:AutoWikiBrowser/CheckPageJSON, but I'm not added to it, I get a different error message "Yodin is not enabled to use this", and when I click OK, I'm taken to the relevant Project:AutoWikiBrowser/CheckPageJSON page
Is it possible that the rollback is delayed for some reason on non Wikipedia sites (caching, etc.?) Will add this to the Phab ticket. --YodinT11:59, 8 August 2024 (UTC)
Yeah, it seems clear that this is a result of the removal of the writeapi right. Going by the logs it looked like the change had been rolled back, but it seems that's not the case. My guess is that they'll roll back the change relatively soon (it has limited benefit but is causing a lot of things to break). Failing that it'll take an update to AWB to make it work with the new output, which should be straightforward but may take some time since AWB is entirely volunteer-driven. Xover (talk) 22:13, 8 August 2024 (UTC)
@Xover, @Yodin: Per the discussion at the Wikipedia project page, the issue can now be fixed by updating to AWB version 6.3.1.0. To do so, open an instance of AWB, and on the [Help] tab on the top toolbar, click [Check for updates], and it will offer you that version as an option to which to update. I have just done so, and it is now working. BD2412T03:11, 10 August 2024 (UTC)
Tech News: 2024-33
Latest comment: 4 months ago1 comment1 person in discussion
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Stewards can now specify if global blocks should prevent account creation. Before this change by the Trust and Safety Product Team, all global blocks would prevent account creation. This will allow stewards to reduce the unintended side-effects of global blocks on IP addresses.
Latest comment: 4 months ago10 comments5 people in discussion
A screenshot of a proof of concept demo
This is effectively a continuation of the older discussion Wikisource:Scriptorium/Archives/2024-03#Proposal_to_change_{{SIC}}_display, which specifically focuses on the @Ostrea's Plan B: "I'll add that in case of a lack of consensus, a solution satisfying both those for the change and those against the change would be to implement some kind of switch which would allow to show globally either the corrected text or the original typos, as is done for some other templates."
The Dynamic Layouts system, documented at Help:Layout, already interacts with some templates. Such as Template:Right sidenote. SIC and Errata are just two small templates and they can be amended to generate the output, which would differ on the screen, depending on the currently selected Dynamic Layout. I prepared a quick and dirty demo at User:Ssvb/Sandbox/TestSIC, which works with the following common.js and common.css from the collapsed section (the code itself isn't nice, but this doesn't matter at this stage):
common.js:
mw.hook( 'ws.layouts.register' ).add( function ( cfg ) {
cfg.layouts.push( {
name: 'Faithful to the original', // what you see in the menu
id: 'authentic' // the name of the layout's class
} );
} );
mw.hook( 'ws.layouts.register' ).add( function ( cfg ) {
cfg.layouts.push( {
name: 'Annotated for scholars', // what you see in the menu
id: 'annotated' // the name of the layout's class
} );
} );
mw.hook( 'ws.layouts.register' ).add( function ( cfg ) {
cfg.layouts.push( {
name: 'For casual consumers', // what you see in the menu
id: 'modernized' // the name of the layout's class
} );
} );
The leftmost browser window, with the 'Faithful to the original' layout selected, is a genuine/authentic/faithful book representation with all its typos intact. The errata fixes are applied, because they are a part of the original book too, albeit presented there in a roundabout way. But a person, who is reading the book, can use a pencil to do corrections on paper pages as well, just like it can be seen on Page:Dombey_and_Son.djvu/143.
The middle browser window ('Annotated for scholars' layout) is the same, but additionally has detailed and clearly visible annotations.
The rightmost browser window ('For casual consumers' layout) fixes all typos and has no annotations of any kind. As a bonus, it would be also nice to be able to convert long-s into normal 's' here if this is technically feasible.
I think that this would satisfy all categories of the end users. First of all, the 'Faithful to the original' layout showcases the Wikisource's main selling feature and focuses on the maximum accuracy in every detail. The annotated version is convenient for those, who are specifically interested in analysing typos and non-standard spelling. And the fully modernized variant on the right side directly competes with Project Gutenberg and modern book publishing houses, providing something to the users who just want to read the story and don't want to be distracted by typos.
While the current way of presenting books on Wikisource is the classic "one size fits them all" approach, combining the worst features together and making sure that every user has something to dislike about it.
The "mobile view" and export to EPUB/PDF has to be addressed somehow. For the former, it would be nice to be able to switch between Dynamic Layouts in it too. As for the latter, it already does have some configuration knobs on the Print/export->Other formats page. And it's a free open source software project on GitHub, so it's fixable in principle.
Has anything happened on this front since the last discussion round? Are there any real technical blockers? Or is it stalled because of having no consensus?
Would you support or oppose having a proper implementation of such three switchable layouts on Wikisource? --Ssvb (talk) 00:51, 12 August 2024 (UTC)
I'll clarify a few more things. This proposal won't affect the Wikisource editors and won't change the existing policies. It only affects the visual presentation of the already existing Wikisource content. Similar to how clicking on the "Use serif fonts" link on the sidebar toggles the use of the serif font, the implementation of this proposal would add a new sidebar link, which would cycle through different SIC/Errata visualization options. The current behaviour (a barely visible underline with a tooltip) actually can be one of the possible visualization options. Ideally, this should be fully user-customizable via Dynamic Layouts.
The 'Annotated for scholars' layout doesn't necessarily need to add footnotes for errata (like it is shown on the screenshot). It can be side notes, tooltips or something else. The exact visual presentation doesn't matter. But the main idea is that any usages of SIC and Errata have to be clearly visible in this particular layout, so that the users can easily review all of them if they want to. And looking from this perspective, the "nodash" option to suppress the dashed underline is harmful and doesn't need to be honoured. It's similar to how the text changes are normally highlighted in a typical diff.
@Ostrea, @Ssvb: The technical implementation was never the issue. Most readers do not use gadgets, or layouts. This means that most users will only see the default, and therefore we're back to the same question: Which should be the default? We can only try to guess what readers will want, which is rather complicated. Not going to do that whole discussion again, but on one side some said that our role is really to have the exact text and be faithful to accommodate scholars, and some others said our role is to accommodate casual readers by making the text simpler to read.
Also, I think it would be much better to use tooltips rather than footnotes. {{errata}} borders on annotation, and is only used in about 800 pages (compared to SIC's more thousands than I could count). I didn't know of its existence, but I think it should be deprecated.
As I understand it, that is functioning as designed: "crying" was corrected to "cooing" on an in-work errata page so the idea is to update based on that, while fended was not and identified as a misspelling by the WS editor. MarkLSteadman (talk) 11:08, 14 August 2024 (UTC)
Yes, that's the essence of the differences between the current templates {{errata}} and {{SIC}}. That's how they are implemented by Wiktionary right now. But I wouldn't want to sidetrack this topic to discuss whether the {{errata}} template has the right to exist or how it should be visualised (footnotes, sidenotes, tooltips, text highlight, text strikethrough, ...). If there's a real proposal to deprecate the {{errata}} template or change how it looks, then it probably would make sense to start a new topic about that. --Ssvb (talk) 12:13, 14 August 2024 (UTC)
Re template:errata: if the original work used a footnote, we use a footnote, if it uses something else, we use that. We have no need of specifying that a footnote was in the original because we do not add footnotes (except in annotated works). That is why errata seems unnecessary to me. But anyway, indeed, will discuss this further later as it is not here the subject. — Alien333 (what I did & why I did it wrong) 15:07, 14 August 2024 (UTC)
Are you aware how the errata template works? Books are published with errata pages or errata slips. The template allows these published corrections to be noted at the location where the mistake occurred, with pop-up text showing the correction and with a link to the place where the errata are listed in the work. --EncycloPetey (talk) 15:57, 14 August 2024 (UTC)
Support This really does seem the best possible solution, especially since everything in it is optional and customizable. Ebook conversion would indeed be important, but this is already a huge step in the right direction. As for other works on the matter, I think @CalendulaAsteraceae had started something but I don't know how far she went with it... Ostrea (talk) 07:05, 12 August 2024 (UTC)
Policy on translation pages
Latest comment: 4 months ago7 comments3 people in discussion
What is the policy for translation pages if there’s only one translation (of which we have a copy, anyway)? Is the translation page created as usual, with only one item, or is it just a redirection? In either case I’ll need an administrator’s opinion. TE(æ)A,ea. (talk) 18:35, 13 August 2024 (UTC)
There are two opinions in the community. One opinion is that, is there is only one copy, then it should be placed at the primary page name, and the whole thing will be moved and re-edited later, if a second edition is started or if a second work with the same name necessitates disambiguation. My own opinion is that if a work is likely to need disambiguation or multiple editions, than a redirect at the main location is preferable, with the existing edition placed at a suitably disambiguated title from the start. The former emphasizes that there is no need to distinguish works now; the second emphasizes advance planning. --EncycloPetey (talk) 18:41, 13 August 2024 (UTC)
I would consider a 1929-PD translation sufficient reason to create a versions (or disambiguation) page now, listing both. But as I say, other people would disagree. --EncycloPetey (talk) 19:07, 13 August 2024 (UTC)
EncycloPetey: Sorry, that was an error on my part. I meant to say that the copyright will expire in 2029, not that it was published in 1929. (It was published in 1933.) TE(æ)A,ea. (talk) 19:12, 13 August 2024 (UTC)
@CalendulaAsteraceae: Well, the example in the documentation page is fixed, but what about other numerous pages using this template? I am sure that in the past it was displayed correctly without this special parameter. So if something got changed, some bot should go through all the occurences and fix them. --Jan Kameníček (talk) 19:41, 14 August 2024 (UTC)
I suspect it is related to caching rather than login status. If you log out, do you still see the correct updated information? —Beleg Tâl (talk) 13:45, 14 August 2024 (UTC)
yes, typically I see this when I have an old page in a tab not refreshed to current, and login refreshes the page. you can edit conflict with yourself with too many tabs. --Slowking4 ‽ digitaleffie's ghost22:30, 14 August 2024 (UTC)
Thanks for the response. It didn't happen today. I like to see the yellow or pink fill the page numbers on the index page so I always refresh the view before I close the browser or move on to a different text. I also don't like sharing problems for 2 reasons. One being who wants a boo hoo around, the other being that it can probably be fixed by importing the correct style sheet without fixing the real problem.
It might be my limited imagination, but I cannot imagine a reason for my inkscape to have migrated to a different computer that is more "good" than just leaving it alone and blocking whatever means it was taken in the first place. This wasn't about my inkscape problem, but it is also difficult to not think that every problem I have with software doesn't relate to this. (I lost the focus, zoom, thumbnails, &c. for the camera on the Fire(TM) also.) So, some of the boo hoo--RaboKarbakian (talk) 14:13, 15 August 2024 (UTC)
Latest comment: 4 months ago3 comments2 people in discussion
Could someone come through and validate the 4 pages related to 2024 Greenfield Tornado Finalized Report? The page is already linked up to an EN-Wiki article, which has had nearly 30,000 views in the last month. A validation would help ensure I didn't miss something in the proofread, for this valuable text. WeatherWriter (talk) 20:29, 17 August 2024 (UTC)
Pages validated, mainly just some missing line breaks, besides some minor adjustments to the table settings. I also removed "Event details:" on the first two pages, as I could not see said text in the source document. Were they cut off, or not there? I also added a link to the NOAA portal Portal:National Oceanic and Atmospheric Administration in the header of the transcluded text, as I was concerned that all of the "author" links were linking to Wikipedia, not Wikisource. Please edit/amend Portal:National Oceanic and Atmospheric Administration if there are other texts you have transcluded that should be added there, while including a link to the portal in the header of each transcluded work.
Coming soon: A new sub-referencing feature – try it!
Latest comment: 4 months ago1 comment1 person in discussion
Hello. For many years, community members have requested an easy way to re-use references with different details. Now, a MediaWiki solution is coming: The new sub-referencing feature will work for wikitext and Visual Editor and will enhance the existing reference system. You can continue to use different ways of referencing, but you will probably encounter sub-references in articles written by other users. More information on the project page.
We want your feedback to make sure this feature works well for you:
Sign up here to get updates and/or invites to participate in user research activities.
Wikimedia Deutschland’s Technical Wishes team is planning to bring this feature to Wikimedia wikis later this year. We will reach out to creators/maintainers of tools and templates related to references beforehand.
Latest comment: 4 months ago1 comment1 person in discussion
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Feature news
Editors who want to re-use references but with different details such as page numbers, will be able to do so by the end of 2024, using a new sub-referencing feature. You can read more about the project and how to test the prototype.
Editors using tracking categories to identify which pages use specific extensions may notice that six of the categories have been renamed to make them more easily understood and consistent. These categories are automatically added to pages that use specialized MediaWiki extensions. The affected names are for: DynamicPageList, Kartographer, Phonos, RSS, Score, WikiHiero. Wikis that have created the category locally should rename their local creation to match. Thanks to Pppery for these improvements. [5]
Technical volunteers who edit modules and want to get a list of the categories used on a page, can now do so using the categories property of mw.title objects. This enables wikis to configure workflows such as category-specific edit notices. Thanks to SD001 for these improvements. [6][7]
Bugs status
Your help is needed to check if any pages need to be moved or deleted. A maintenance script was run to clean up unreachable pages (due to Unicode issues or introduction of new namespaces/namespace aliases). The script tried to find appropriate names for the pages (e.g. by following the Unicode changes or by moving pages whose titles on Wikipedia start with Talk:WP: so that their titles start with Wikipedia talk:), but it may have failed for some pages, and moved them to Special:PrefixIndex/T195546/ instead. Your community should check if any pages are listed there, and move them to the correct titles, or delete them if they are no longer needed. A full log (including pages for which appropriate names could be found) is available in phab:P67388.
Editors who volunteer as mentors to newcomers on their wiki are once again able to access lists of potential mentees who they can connect with to offer help and guidance. This functionality was restored thanks to a bug fix. Thank you to Mbch331 for filing the bug report. You can read about that, and 18 other community-submitted tasks that were resolved last week.
Project updates
The application deadline for the Product & Technology Advisory Council (PTAC) has been extended to September 16. Members will help by providing advice to Foundation Product and Technology leadership on short and long term plans, on complex strategic problems, and help to get feedback from more contributors and technical communities. Selected members should expect to spend roughly 5 hours per month for the Council, during the one year pilot. Please consider applying, and spread the word to volunteers you think would make a positive contribution to the committee.
Learn more
The 2024 Coolest Tool Awards were awarded at Wikimania, in seven categories. For example, one award went to the ISA Tool, used for adding structured data to files on Commons, which was recently improved during the Wiki Mentor Africa Hackathon. You can see video demonstrations of each tool at the awards page. Congratulations to this year's recipients, and thank you to all tool creators and maintainers.
The latest Wikimedia Foundation Bulletin is available, and includes some highlights from Wikimania, an upcoming Language community meeting, and other news from the movement.
Sign up for the language community meeting on August 30th, 15:00 UTC
Latest comment: 4 months ago1 comment1 person in discussion
Hi all,
The next language community meeting is scheduled in a few weeks—on August 30th at 15:00 UTC. If you're interested in joining, you can sign up on this wiki page.
This participant-driven meeting will focus on sharing language-specific updates related to various projects, discussing technical issues related to language wikis, and working together to find possible solutions. For example, in the last meeting, topics included the Language Converter, the state of language research, updates on the Incubator conversations, and technical challenges around external links not working with special characters on Bengali sites.
Do you have any ideas for topics to share technical updates or discuss challenges? Please add agenda items to the document here and reach out to ssethi(__AT__)wikimedia.org. We look forward to your participation!
Boldly Done, since I can't see the value of having a separate template, apart from unnecessary confusion. If there is value, of course feel free to revert. Cremastra (talk) 23:23, 24 August 2024 (UTC)
Undone. The value of this template is that the signature may not be legally reproduced in some situations, not that we are missing an image. --EncycloPetey (talk) 00:50, 25 August 2024 (UTC)
The link you pointed to lists one situation where US copyright would protect the signature. We also have situations where the signature was redacted or otherwise not reproduced in dissemination of a document. In those situations, we know a signature was there, but we do no have a scan that reproduces it. --EncycloPetey (talk) 01:08, 25 August 2024 (UTC)
It would be good to give it a documentation specifying that its only use is for artistic signstures (it actually has none), then, vecause in most places where it's been used (like here), it doesn't match that. — Alien333 ( what I did why I did it wrong ) 01:32, 25 August 2024 (UTC)
The templates definitely have different purposes. For transcription of texts oftentimes the only part which is necessary is the existence of a signature, whereas for images usually the content of the image matters. EncycloPetey’s comment is also true; most dissertations and government documents (FOIA releases, anyway) will redact signatures so they can’t be illicitly reproduced. TE(æ)A,ea. (talk) 01:29, 25 August 2024 (UTC)
For redacted signatures, we already have {{redacted}}.
There are a lot of images that don't have any specific meaning except being there, e.g. there, and we still add them, and consider pages without them to be problematic. I don't see why signatures specifically are not necessary. — Alien333 ( what I did why I did it wrong ) 02:15, 25 August 2024 (UTC)
Alien333: The “redact” template is for text, where nothing is visible or identifiable as to the original; for redacted signatures, it is clear that it is a signature which is redacted, and in most cases the person who gave the signature is identified. Another concern is with the actual purposive nature of signatures; in most cases each signature will be (technically) a unique image, in many cases obscured by surrounding text. In no case is it necessary for the visible signature to be distinguished from, say, the text Signature. Ornamental images are of doubtful utility but are still part of the text. TE(æ)A,ea. (talk) 02:44, 25 August 2024 (UTC)
Once it's redacted, a signature looks just like a block of text.
Can you clarify why it's in no case necessary for the visible signature to be distinguished from, say, the text Signature?
What keeps us from replacing all images by an alt text, at this rate?
Latest comment: 4 months ago3 comments3 people in discussion
See title. On the one hand, I'd like to migrate from {{brace2}} if possible due to the issues of using MathJax to format a single brace; on the other hand, I've had a multitude of problems getting it working, and documentation is non-existent. Can someone help? Arcorann (talk) 02:15, 19 August 2024 (UTC)
Latest comment: 3 months ago1 comment1 person in discussion
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Feature news
Administrators can now test the temporary accounts feature on test2wiki. This was done to allow cross-wiki testing of temporary accounts, for when temporary accounts switch between projects. The feature was enabled on testwiki a few weeks ago. No further temporary account deployments are scheduled yet. Temporary Accounts is a project to create a new type of user account that replaces IP addresses of unregistered editors which are no longer made public. Please share your opinions and questions on the project talk page.
Later this week, editors at wikis that use FlaggedRevs (also known as "Pending Changes") may notice that the indicators at the top of articles have changed. This change makes the system more consistent with the rest of the MediaWiki interface. [8]
Bugs status
Editors who use the 2010 wikitext editor, and use the Character Insert buttons, will no longer experience problems with the buttons adding content into the edit-summary instead of the edit-window. You can read more about that, and 26 other community-submitted tasks that were resolved last week.
Project updates
Please review and vote on Focus Areas, which are groups of wishes that share a problem. Focus Areas were created for the newly reopened Community Wishlist, which is now open year-round for submissions. The first batch of focus areas are specific to moderator workflows, around welcoming newcomers, minimizing repetitive tasks, and prioritizing tasks. Once volunteers have reviewed and voted on focus areas, the Foundation will then review and select focus areas for prioritization.
Do you have a project and are willing to provide a three (3) month mentorship for an intern? Outreachy is a twice a year program for people to participate in a paid internship that will start in December 2024 and end in early March 2025, and they need mentors and projects to work on. Projects can be focused on coding or non-coding (design, documentation, translation, research). See the Outreachy page for more details, and a list of past projects since 2013.
Learn more
If you're curious about the product and technology improvements made by the Wikimedia Foundation last year, read this recent highlights summary on Diff.
To learn more about the technology behind the Wikimedia projects, you can now watch sessions from the technology track at Wikimania 2024 on Commons. This week, check out:
Latest comment: 3 months ago4 comments2 people in discussion
At Page:United States patent 647007.pdf/3 I have a wide table and plines. For the wide table, I used "overflow:auto;" in the style sheet which I think caused the plines to not show. While typing this, it occurred to me to restrict the overflow to the table; but perhaps pline could be fixed for this? Thanks!--RaboKarbakian (talk) 14:59, 24 August 2024 (UTC)
The {{pline}} template is to specify line numbers. You've used auto-wrapping for the text, removing the line breaks that were previously there, so no one will be able to tell which text was on line 10 as aopposed to line 9 or line 11 anymore. There is therefore no reason to try to retain the line numbers. Line numbers are meant to be keyed to specific rows of text. --EncycloPetey (talk) 15:11, 24 August 2024 (UTC)
Ignoring the off-topicness: I have found the anchored plines to be helpful to these particular texts with their repetitiveness, run-on sentences and overall horribleness as only the marriage between legal and technical languages can be. That particular patent reiterates (and describes) the table contents in those same legal/technical words, even! And certainly, leaving the plines out would be easier.
What is it with this group of editors!?! When it comes to words you are all "AS IT WAS PUBLISHED" {especially with typos) but when it comes to something like this or publisher ornamental images--you don't do that "AS IT WAS PUBLISHED". It is inconsistent and the only way I can remember these conflicting policies is to think "What would the lazy over-literate population do?" Which also makes it easier to forget.</rant>--RaboKarbakian (talk) 13:33, 25 August 2024 (UTC)
But you're not reproducing it as published, since you're removing the line breaks necessary for the line numbers to do their job. And that's the whole point of my previous comment. You have two options: (1) use pline and retain the original line breaks, or, (2) eliminate the line breaks and remove the line numbers. You have created this problem by trying to have your cake and eat it too, but you must instead make a choice. --EncycloPetey (talk) 20:01, 31 August 2024 (UTC)
Sisterlinks on category pages
Latest comment: 3 months ago3 comments3 people in discussion
A user has (relatively) recently systematically added the {{plain sister}} template (which shows links to our sister projects, fetched from Wikidata) to a lot of category pages. These links are already available as "In other projects" in all skins (even Monobook) except Minerva (the mobile site) and are fetched from the same source. The links provided by the template are therefore redundant, and I find they get in the way (especially when a category exists on many sister projects). You can see a randomly picked example at Category:Hidden categories.
I would like to remove the template, but as there is no policy or guidance one way or the other on this issue I am seeking the community's input on it first. Does anyone specifically want to retain the template on category pages? Are you ok with removing it? Other thoughts or comments? Xover (talk) 14:53, 31 August 2024 (UTC)
Comment Whatever we decide, the template is defective when applied to the Category: namespace, as it claims to link to the Wikipedia article, although it actually links to a category there. The template does not seem to have been designed to work correctly in the Category namespace, although users have been placing it there at least as far back as 2005. --EncycloPetey (talk) 19:57, 31 August 2024 (UTC)
Latest comment: 2 months ago58 comments17 people in discussion
The following discussion is closed:
It has been decided that a mainspace page with an {{Auxiliary Table of Contents}} can be created to enable linking to serialized works in periodicals. The decision has been incorporated into the Wikisource:Style guide.
Weak support. If we otherwise have a versions/translations page, listing the parts of a work under the version serialized is appropriate. Creating a new versions page for every serialised work that only contains one version is inappropriate. --Xover (talk) 05:30, 27 August 2024 (UTC)
WeakSupport: This is an excellent solution where it works, but I don't think it should be the standard solution across the board. —Beleg Tâl (talk) 13:23, 27 August 2024 (UTC)
Oppose. This is improper because there isn’t a whole work within the Review by that title; the only thing within the Review (at the first level, which is where this is) are volumes. TE(æ)A,ea. (talk) 23:09, 25 August 2024 (UTC)
Support, this seems to me the only solution that respects the relationship between the edition of the serialized work, and the edition of the periodical within which it was published. It is perhaps worth pointing out that we can have separate sections on the top level page for "volumes" and "serialized works". —Beleg Tâl (talk) 13:23, 27 August 2024 (UTC)
Oppose per the point TE(æ)A,ea. made for option #2: we're creating an edition out of whole cloth that did not previously exist and is yet another step down the slippery slope. And once you've listed them on a faux publication page you're going to want to link them together, so now it either gets double navigation (faux publication + real publication) or it only gets the faux publication and loses its original publishing context. This is a very bad idea. --Xover (talk) 05:30, 27 August 2024 (UTC)
Xover: What makes it different, in my mind, is that with 3. (as opposed to 2.), we’re not claiming that there is some published edition which exists (insofar as being one singular unit). My problem with 2. is that it logically indicates that there is a top-level subdivision “A Tale of Young Blood of ’48” within the larger (periodical) work The Czechoslovak Review. This does not happen with 3. because you recognize that the work (as an entire work) is not one, top-level subdivision, but is actually a number of lower-level subdivisions. I don’t think that this constitutes “creating an edition out of whole cloth that did not previously exist” because it is a real edition. Just because the chapters (sections, &c.) were published (1) with other material (2) in separately published issues of a periodical doesn’t mean that the material doesn’t constitute an “edition” of that work—in most cases it is the original edition and holds greater weight thereby. As for the double-navigation issue, that is already done without any issues. It is also not an unnatural, original (as in Wikisource-based editorial) modification to the text; these individual sections will often mention both that they are continuations and that they will be continued, and there’s no reason to not add that connection to the header template. I don’t know how this sort of collection would “lose[] its original publishing context,” though—wouldn’t that information be listed on the main page and be inherent in the structure of all of the (in-periodical) chapters? TE(æ)A,ea. (talk) 11:57, 27 August 2024 (UTC)
Oppose: placing the serialized work as a separate top-level page from the periodical within which it was published implies that they are two different publications, which is false and misleading. —Beleg Tâl (talk) 13:23, 27 August 2024 (UTC)
I might change this from strong oppose to weak oppose if a new, visually distinct, header template were to be used for this purpose. —Beleg Tâl (talk) 13:24, 27 August 2024 (UTC)
This is appropriate in some circumstances, but not all (or even most). I think it is good for the “Sherlock Holmes” stories because they are not in a serial order, there are other versions which have been brought together, and there are also simply a decent number of them (which all have different names because they are unique stories rather than chapter-like divisions). TE(æ)A,ea. (talk) 23:09, 25 August 2024 (UTC)
This seems like a good choice for entire series, but I'm not sure this would work well for individual stories, especially ones that aren't part of any series. --YodinT17:03, 26 August 2024 (UTC)
Comment This can be the best approach in some circumstances, though I agreee that in most situations it may not be the best practice. We can choose one of these options as generally best practice, while also describing other special cases and the possible means to approach those complex or special circumstances. --EncycloPetey (talk) 01:20, 27 August 2024 (UTC)
Support Not to overstate the perfection of this approach (it certainly isn't), but this is the only approach that does not involve us creating entirely new editions that do not exist in the real world. It is therefore the very-imperfect-but-safe option. We also haven't discussed this holistically before going to voting (Jan, you in particular should be sensitive to that issue). For example, our periodical pages suffer from exactly the same problem (our top-level page for, e.g., The New York Times corresponds to nothing physically published) so any discussion and potential change of practice should address both issues. For that discussion I have some ideas; for this narrowly-scoped one I have answered narrowly. --Xover (talk) 05:30, 27 August 2024 (UTC)
Comment The line between those two is not always clear, as evidenced by Portal:Bible, which is both a work and a collection of works. The First Folio of Shakespeare is likewise both a work and a collection of works. And many "collections" of poetry, like The Waste Land by T. S. Eliot or Flowers of Evil by Baudelaire, also blur the line. --EncycloPetey (talk) 20:44, 27 August 2024 (UTC)
Comment A portal would be inappropriate if used only to represent a single edition of a serialized work. However, I think it could be acceptable if the idea were modified slightly to be more, well, portal-esque. For example, Portal:Sherlock Holmes (UK Strand) must allow not only instalments of Sherlock Holmes in the UK Strand, but any work related to the publication of Sherlock Holmes within the Strand (because that's what portals are for). This would mean that the portal has a dual purpose, but I think that is acceptable (similar to option #1 with versions pages). —Beleg Tâl (talk) 13:23, 27 August 2024 (UTC)
I suppose I should also mention that, as far as I am aware, there is still some controversy over whether periodicals should be placed in Portal space anyway ... —Beleg Tâl (talk) 13:26, 27 August 2024 (UTC)
Neither of them are works; they're collections. The United Nations Security Council Resolutions I might move to mainspace, as a periodical. My instinct with Appendix Vergiliana would be to stuff it under Author:Virgil. Also note that Appendix Vergiliana also collects information about Vergiliana, and portals about subjects is definitely in scope for a portal.--Prosfilaes (talk) 04:48, 28 August 2024 (UTC)
We're talking about a unitary work here, not an arbitrary collection. The UN Security Resolutions are works, but the set as a whole also form a work. Portals aren't for works; they're for collections of works.--Prosfilaes (talk) 22:33, 28 August 2024 (UTC)
With regard to the Vergiliana: if the works were written by Virgil, then both those works and any articles about them would appear on Author:Virgil. Moving them to a Portal keeps the two together. If the works were moved to Virgil's Author page, then the works about them would not be, since they are not about works by Virgil, and thus there would be no place to collect both sets of items together. It also dilutes what we have if the works are listed under an author who did not write them. --EncycloPetey (talk) 04:56, 28 August 2024 (UTC)
Presumably if the works were moved to Author:Virgil, so would the works about the works. I think this is sort of off-topic; it doesn't have much to do with this vote, nor does is anyone proposing a change to that right now.--Prosfilaes (talk) 22:33, 28 August 2024 (UTC)
Having opposed all four suggestions, what's left? Transcluding a work in its context as a part of a periodical and providing double linking: a) to the previous & next works in the issue of the periodical; b) to the previous & next sections of the work. If a work is published in more than one context, then a versions page can point to the first section of the work in the periodical and to the complete publication in a different medium. Beeswaxcandle (talk) 07:31, 27 August 2024 (UTC)
Oppose. This is the worst of the options (on its own); it merely leaves the job incomplete. Your solution for versions is wrong, as one section of a work is not a version of an entire work. TE(æ)A,ea. (talk) 21:13, 27 August 2024 (UTC)
Beeswaxcandle mentioned somewhere in the voting about duplicates in search results. I got to thinking about robots.txt (the way to keep search engines from web pages) and was wondering if there would be a way to prevent the duplicates from getting into the local search results. Perhaps a template similar but different to AuxTOC that would do this?--RaboKarbakian (talk)
Support: this is definitely a cool idea, since it allows readers to read through in either context (periodical part / next serial installment). Cremastra (talk) 21:08, 29 August 2024 (UTC)
Oppose, as this is both incompatible with what we use previous / next for here as well as incompatible with what Wikidata does with those values. That's in addition to problems with epub, mentioned above. --EncycloPetey (talk) 21:37, 29 August 2024 (UTC)
Comment this is already what we do, and is separate from the options listed above, so I think any proposal to stop doing this should require a separate proposal. —Beleg Tâl (talk) 20:12, 2 September 2024 (UTC)
Results
The last vote (and at the same time the last contribution to the discussion) came 20 days ago, so I believe this voting can be closed. Here are the results:
Proposal 1: 2x support, 2x oppose.
Proposal 2: 3x support, 3x oppose.
Proposal 3: 11x support, 4x oppose.
Proposal 4: 2x support, 2x oppose.
Additional proposal (5): 2x support, 2x oppose.
Support for proposal no. 3 is strong enough to consider it accepted and it will be included into Wikisource:Style guide. All other proposals did not gain enough support and so they can be considered rejected. The additional proposal has been rejected only in terms of being the only way of handling serialized works; the current practice of interlinking individual parts ("next" and "previous") of serialized works has not been discussed enough and so it cannot be considered as rejected by this voting. If somebody wishes to ban this practice, a separate discussion is needed. --Jan Kameníček (talk) 16:09, 27 September 2024 (UTC)
Two new parser functions will be available this week: 
Support This really does seem the best possible solution, especially since everything in it is optional and customizable. Ebook conversion would indeed be important, but this is already a huge step in the right direction. As for other works on the matter, I think @CalendulaAsteraceae had started something but I don't know how far she went with it... Ostrea (talk) 07:05, 12 August 2024 (UTC)
Done, since I can't see the value of having a separate template, apart from unnecessary confusion. If there is value, of course feel free to revert. Cremastra (talk) 23:23, 24 August 2024 (UTC)
Please review and vote on Focus Areas, which are groups of wishes that share a problem. Focus Areas were created for the newly reopened Community Wishlist, which is now open year-round for submissions. The first batch of focus areas are specific to moderator workflows, around welcoming newcomers, minimizing repetitive tasks, and prioritizing tasks. Once volunteers have reviewed and voted on focus areas, the Foundation will then review and select focus areas for prioritization.
Comment Whatever we decide, the template is defective when applied to the Category: namespace, as it claims to link to the Wikipedia article, although it actually links to a category there. The template does not seem to have been designed to work correctly in the Category namespace, although users have been placing it there at least as far back as 2005. --EncycloPetey (talk) 19:57, 31 August 2024 (UTC)
Oppose. Unless there is another version/edition, then this isn't an appropriate use of a versions page. Beeswaxcandle (talk) 07:31, 27 August 2024 (UTC)
