Project members can often be found in the #wikisource IRC channel webclient. For discussion related to the entire project (not just the English chapter), please discuss at the multilingual Wikisource. There are currently 384 active users here.
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)
Latest comment: 2 days ago21 comments6 people in discussion
I think we should come to some general recommendation how serialized works in periodicals should be dealt. At the moment each contributor deals with them differently, which is imo a problem with periodicals especially, as different attitudes within one periodical sometimes occur.
I have seen two attitudes which make sense in my opinion. The one which I slightly prefer is creating a version/translation page containing one version/translation of the work with links to all parts of the series. Although we usually create version pages only when we have at least two editions of the work, in similar cases it could be acceptable to create it for one edition only. Once more editions appear here, they can be easily added. An example of such a page is e. g. Fame (Čech).
Another attitude which also makes sense is creating a special subpage of the periodical containing just an auxilliary ToC with links to individual parts of the work. An example can be seen at The Czechoslovak Review/A Tale of Young Blood of '48. IMO there is some minor disadvantage: subpages of the main page are only volumes, while articles are subpages of these volumes or of individual issues. With this attitude the subpages with AuxToC would be on the same level as volumes, which is a bit confusing. Besides, not everybody (e.g. me) likes how the pages with pure AuXToC look, but that is very subjective, I admit. Despite these minor objections, I would not have any problem accepting this attitude if more people prefer it, because some unification is really needed.
There are also other related things which might be discussed, like whether and how individual parts should be interlinked from their headers etc., but I suggest leaving such discussions for later or at least making them separate from this one, not to lose the main goal. -- Jan Kameníček (talk) 16:46, 13 July 2024 (UTC)Reply
Once upon a time, I was working on a magazine which had a Jules Verne short story serialized within. I thought to keep the magazine in tact, but to also make a separate instance where the story was complete (Magazine/Title of story) so that the work could be downloaded intact for my ereader device. That effort was deleted, citing something officious that I did not read. But it was easy to do (set up the separate instance) and perhaps a way to include it in the main toc but exclude it from being downloaded with the whole magazine volume could be found. And the officious document changed accordingly.--RaboKarbakian (talk) 15:27, 14 July 2024 (UTC)Reply
Jan Kameníček: I made a Volume/whole_work and transcluded all of the parts to there (as well as how they appeared in the journal), it was crufty, klutzy and overall not elegant, really. Since then, I have come to more understanding of the exporter. To my understanding, The Czechoslovak Review/A Tale of Young Blood of '48 would indeed work with the exporter for the purpose of making an epub, etc version of that one specific work. I thank you for putting this all here so I had the time to think about it. And also agree that it is the best, cleanest and most non-redundant of solutions to the need for a recommendation and more importantly (to me), a means to export 'just the work' into other formats.--RaboKarbakian (talk) 15:15, 16 July 2024 (UTC)Reply
I've worked on a few of these recently, and agree that it would be good to develop a guideline. I had been following Wikisource:Serial works, and creating a separate single-page transclusion in addition to transcluding them as part of the periodical (e.g. 1, 2, 3, 4, 5). I'd also used the versions page approach you described, with sub-bullet points for each part; I'm not against this, but haven't been very happy with it, as it means serial works take up so much more space on these pages than other works, and I also dislike readers having to click through many extra pages to view the work they want to read. Hadn't come across The Czechoslovak Review/A Tale of Young Blood of '48 method before; I understand what you mean that it might seem odd to have subpages that aren't just the volumes, but this does seem like a logical place to put these pages (I personally don't mind AuxTOC only pages, but you could also add the source text's title and date of first publication to the page's header notes if it was a translation, which would make the page a bit less empty). It looks like a good approach to me, as this could be the page you link to on any author/versions/translations page, and would avoid having to link to all the sub-parts on those pages. --YodinT14:03, 16 July 2024 (UTC)Reply
Normally, comments come first, then the community votes on the changes, and only then is the core Wikisource document changed in accordance with the proposal. Changing the core policy document, then asking for comment is backwards. --EncycloPetey (talk) 17:15, 2 August 2024 (UTC)Reply
I'll note, Jan, that the one time I can recall you and I disagreeing vehemently on something it was because I had failed to make sure there was sufficient opportunity to discuss the proposal before it even came to a vote. This is a difficult issue and rushing into establishing a new status quo is not appropriate. Xover (talk) 07:33, 3 August 2024 (UTC)Reply
I did not consider the change controversial after the discussion above where only opinions in favour of one solution appeared and nobody seemed to add anything else relevant to it. Anyway, I have reverted the change for now. --Jan Kameníček (talk) 08:04, 3 August 2024 (UTC)Reply
Yeah, I know the feeling. :) It's hard sometimes to gauge what's controversial or not, and getting the community to even engage in the discussion can be an uphill battle. Thanks for reverting; and thanks for trying to figure out a solution to this issue. I agree that it's something that should be addressed somehow. Xover (talk) 09:13, 3 August 2024 (UTC)Reply
It is a possibility too, though it does not seem to be used by contributors for serialized works in periodicals at the moment. Portals are probably more understood as a tool to gather different works on a specific subject. But I am not against this solution either. --Jan Kameníček (talk) 08:12, 3 August 2024 (UTC)Reply
I thought it would be good to link to some example of such a portal containing a single edition of a work serialized in a periodical, but I failed to find any. --Jan Kameníček (talk) 08:48, 3 August 2024 (UTC)Reply
Portal:Sherlock Holmes (UK Strand).Portals are the tool we have for arbitrarily grouping texts by properties other than the specific forms they were originally published in, and can be on any arbitrary (but consistent and logical) grouping principle. The above example was created because a contributor who shall remain nameless was a bit more than averagely concerned with first editions. Personally I think versions pages like The Problem of Thor Bridge would have been sufficient for this case, but it should illustrate the general approach that's also adaptable to this use case.Not that portals are by any means perfect, but it's the established tool for this kind of need and I am extremely sceptical of any approach that creates pseudo-editions of one story within the structure of a periodical. Xover (talk) 09:07, 3 August 2024 (UTC)Reply
Just noting that the linked portal does not contain one serialized work in a periodical but a series of works by one author in a periodical. (Also not sure why AuxToC is used in that portal.) This portal is imo not really necessary, though possible, while parts of a serialized work really need to be gathered somewhere so that they can be linked to as a whole when needed. Although I originally also slightly preferred the version pages, now I realized that once another edition is added to such a version page, it cannot be used for linking to a particular periodical edition only. For linking purposes we need a solution for gathering individual parts of specific editions in a periodical, which can be done by an auxilliary subpage of the periodical or by a portal. --Jan Kameníček (talk) 10:04, 3 August 2024 (UTC)Reply
No more opinions seem to come so I think we can start voting soon. Before doing so, let's summarize the options we have:
Advantages: Easy to create, no special tool needed.
Disadvantages: Not suitable to be linked to if a link to the whole work is needed, as other versions/translations may be added to the page later. Some people also may not like a version page containing just one version.
Advantages: Solves the linking problem mentioned above. It is an established tool.
Disadvantages: Not a current practice to use it for serialized works. It contradicts the definitions of the portal at Wikisource:Portal guidelines (Portals are pages intended to serve as "main pages" for specific topics or areas) and at Help:Portals (Portals exist as a gateway to a subject area on Wikisource), which would have to be extended (which can be done easily).
…have a bit of a backlog that it would be nice if the community helped out with. The two overlap so it's not quite as bad as at first glance (889 + 675), but it's still enough that it's a "dip in, do a few" kind of task that's easy work if enough people help out. Xover (talk) 08:47, 16 June 2024 (UTC)Reply
105 of the Files with no machine-readable author are volumes of Blackwood's Magazine. What do we even put as an Author for such volumes? --EncycloPetey (talk) 21:29, 16 June 2024 (UTC)Reply
I would probably simply put "multiple". Or...?PS. if there are a hundred of them that should all get the same value it's probably better to have a bot add it. Xover (talk) 21:44, 16 June 2024 (UTC)Reply
The same 105 files are also in the other category. Someone who knows what data to add, and can run a bot, could clear those 105 files from both ctageories quickly. --EncycloPetey (talk) 22:45, 16 June 2024 (UTC)Reply
Another sizeable set of images that could be handled by bot are the illustrations to "The House at Pooh Corner (1961)", and whose filenames start with that phrase. The illustrator (author) for these images is E. H. Shepard. --EncycloPetey (talk) 21:31, 17 June 2024 (UTC)Reply
I've done few, and I thought we could make the Maintenance of the Month for July, since it's easy to step in and fix two or three. Cremastra (talk) 11:55, 20 June 2024 (UTC)Reply
There are 46 files with names of the form "FigNNdescription.png" (with or without a space after the NN fig. number) are from the 1910 A Practical Commentary on Holy Scripture by Author:Friedrich Justus Knecht. No illustrator is credited. These files can be exported to Commons, since the work was published more than 95 years ago and the author dies more than 100 years ago. However, the files should probably be renamed to include the source work title. Since there are 46 images requiring a similar rename, addition of the same author and description, and a similar export, this task might be best handled by bot. --EncycloPetey (talk) 19:05, 24 July 2024 (UTC)Reply
There are 56 illustrations with names that begin "File:The Strand Magazine . . . " that might be given basic data by bot. Many of these apparear to be illustrations for Sherlock Holmes stories. --EncycloPetey (talk) 22:45, 24 July 2024 (UTC)Reply
I've whittled these Sherlock Holmes illustrations down to about a dozen, and for those the illustrator is not clearly stated. The illustrations that I've processed were all from two illustrators. However, I've noticed while doing these that all were tagged with the {{book}} template, but the files aren't books. The template should be swapped out for an appropriate template, preferrably by bot, in order to switch the information in each field to a suitable corresponding parameter in the new template. --EncycloPetey (talk) 06:36, 26 July 2024 (UTC)Reply
Using the book template at commons allows all of the information to fill in from wikidata, including the scan image which then can be "opened", via "|Image page" to the page in the scan that the image came from. Template names are not a "law" are they? If so, the {{book}} template could be renamed {{book and everything in that book}} for the pedantic among us. A more elegant solution is to get the book template here working and then maybe share it with commons, as that template makes great use of the Art module which then complains because the books there don't seem to be two dimensional objects and throws them into several maintenance categories. The {{information}} template is very very 2004!--RaboKarbakian (talk) 12:00, 26 July 2024 (UTC)Reply
The {{book}} template is fine, as long as the object is a scan of a book. It should not be used for files that are extracted illustrations, which are not books. --EncycloPetey (talk) 16:02, 26 July 2024 (UTC)Reply
Among wikisource screenshots, the following files should be deleted as they were added as "temporary" multiple years ago:
Alien333: The “test=yes” was added by CalendulaAsteraceae (in both cases) sometime after the files were created. It should not have been added in either case, as both files are in use. TE(æ)A,ea. (talk) 16:36, 31 July 2024 (UTC)Reply
While that change was indeed made, the files previously had "why=temporary file" so the change was merely one of syntax, rather than content. However, both of those files have Index pages and transcription completed, so it is not clear why these files were ever tagged as such. --EncycloPetey (talk) 16:47, 31 July 2024 (UTC)Reply
FWIW, I've been getting more timeout errors using the OCR button. It takes longer to successfully retrieve an OCR output, and I'm getting timeout errors with greater frequency. I noticed the increase following this weekend's server maintenance downtime. I do not know whether this is the same issue, a related issue, or coincidentally similar, however. --EncycloPetey (talk) 16:35, 28 July 2024 (UTC)Reply
I am grateful if the above posters provide links to the projects for my benefit. I am collecting information on the type of documents being scanned. i. e.: I follow this issue closely as well, but lack data on numerous conditions that may be considered as one of the causes of the problem. Thanks. — ineuw (talk) 18:59, 2 August 2024 (UTC)Reply
I'm just guessing (but it's an educated guess), but I think the root cause is probably the performance and reliability problems on Commons that especially affect PDF files (but DjVu files aren't immune either). It's the same issue that's causing the various problems with Index: pages for newly uploaded files, showing page thumbnails in Page: namespace, etc. and that can sometimes be fixed by purging the file description page. All the OCR engines have to start by downloading the thumbnail of the relevant page from Commons, and usually they ask for a different-sized thumbnail than what's displayed by Proofread Page so that Commons has to generate a new one (instead of just serving the one it already has). Xover (talk) 09:20, 3 August 2024 (UTC)Reply
@Xover: Thanks for adding to my understanding. My work is almost exclusively with .djvu files by preference, which are somewhat slow but consistent page after 100's of pages.
Internet Archive's claim, for ceasing to publish .djvu format, was that the demand didn't justify it. I regret their decision when I come across some interesting material (to me), and is not available in .djvu format. — ineuw (talk) 16:25, 3 August 2024 (UTC)Reply
— ineuw: I made the mistake of saying that Modern Japanese Stories was working fine, because when I proofread the latest story that I’ve done it started to not load again. It’s bad enough that it happens, but it’s so annoying that it’s inconsistent. TE(æ)A,ea. (talk) 13:08, 4 August 2024 (UTC)Reply
Latest comment: 29 days 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 using the Visual Editor in languages that use non-Latin characters for numbers, such as Hindi, Manipuri and Eastern Arabic, may notice some changes in the formatting of reference numbers. This is a side effect of preparing a new sub-referencing feature, and will also allow fixing some general numbering issues in Visual Editor. If you notice any related problems on your wiki, please share details at the project talkpage.
Bugs status
Some logged-in editors were briefly unable to edit or load pages last week. These errors were mainly due to the addition of new linter rules which led to caching problems. Fixes have been applied and investigations are continuing.
Editors can use the IP Information tool to get information about IP addresses. This tool is available as a Beta Feature in your preferences. The tool was not available for a few days last week, but is now working again. Thank you to Shizhao for filing the bug report. You can read about that, and 28 other community-submitted tasks that were resolved last week.
Project updates
There are new features and improvements to Phabricator from the Release Engineering and Collaboration Services teams, and some volunteers, including: the search systems, the new task creation system, the login systems, the translation setup which has resulted in support for more languages (thanks to Pppery), and fixes for many edge-case errors. You can read details about these and other improvements in this summary.
There is an update on the Charts project. The team has decided which visualization library to use, which chart types to start focusing on, and where to store chart definitions.
One new wiki has been created: a Wikivoyage in Czech (voy:cs:) [1]
L’année 1866 fut marquée par un événement bizarre, un phénomène inexpliqué et inexplicable que personne n’a sans doute oublié. Sans parler des rumeurs qui agitaient les populations des ports et surexcitaient l’esprit public à l’intérieur des continents, les gens de mer furent particulièrement émus. Les négociants, armateurs, capitaines de navires, skippers et masters de l’Europe et de l’Amérique, officiers des marines militaires de tous pays, et, après eux, les gouvernements des divers États des deux continents, se préoccupèrent de ce fait au plus haut point.
THE year 1866 was signalized by a remarkable incident, a mysterious and inexplicable phenomenon, which doubtless no one has yet forgotten. Not to mention rumors which agitated the maritime population, and excited the public mind, even in the interior of continents, seafaring men were particularly excited. Merchants, common sailors, captains of vessels, skippers, both of Europe and America, naval officers of all countries, and the governments of several states on the two continents, were deeply interested in the matter.
En effet, depuis quelque temps, plusieurs navires s’étaient rencontrés sur mer avec « une chose énorme, » un objet long, fusiforme, parfois phosphorescent, infiniment plus vaste et plus rapide qu’une baleine.
For some time past, vessels had been met by "an enormous thing," a long object, spindle-shaped, occasionally phosphorescent, and infinitely larger and more rapid in its movements than a whale.
What kind of additional page markup syntax and visualization plugins could be used to get this implemented for a few books? Or is this totally out of scope of the Wikisource project? --Ssvb (talk) 21:50, 31 July 2024 (UTC)Reply
If you have an edition of the text that is bilingual, that belongs at mul:. Do you have one like that or are you trying to compare two different texts of the book? —Justin (koavf)❤T☮C☺M☯21:53, 31 July 2024 (UTC)Reply
I'm trying to compare two different texts of the book. The "chapter" markup is already there and it's possible to open, let's say, the third chapter of the French book in one browser window and the same third chapter of the English book in another browser window. A more fine grained "paragraph" or "sentence" level markup would make it easier to see the matching parts of text. --Ssvb (talk) 22:13, 31 July 2024 (UTC)Reply
Hmm, now I see that Wikisource:Annotations is probably very much related. But the banned items list there includes: "Comparison pages: Pages from different versions of the same work, whether whole works or extracts, placed alongside each other (whether in series or in parallel) to provide a comparison between the different versions". --Ssvb (talk) 23:00, 31 July 2024 (UTC)Reply
Ssvb: I mean, you could create (and export) a book in userspace without an issue; for the French-language text, you can use {{iwpage}} and similar templates for that purpose. TE(æ)A,ea. (talk) 15:03, 1 August 2024 (UTC)Reply
Wow! Thanks! This is a very useful information and it seems to work. I didn't know that it's possible to transclude pages from another wiki. --Ssvb (talk) 16:32, 1 August 2024 (UTC)Reply
If it's only for comparing text, have you considered opening two browser windows side by side, one in English, and one in French? I am experimenting with similar concept for the same reason, but my current needs are offline, although later it will progress to online. I am only limited by time. Setting the window properties, like aligning side by side, with a minimal border may be much quicker. — ineuw (talk) 19:18, 2 August 2024 (UTC)Reply
@Ineuw: In reality I'm interested not in an English-French pair, but in a Belarusian-English pair (but this doesn't change anything in principle). What I wanted to have is to be able to easily match pages between the Belarusian translation and its English original.
I think that I found some sort of a solution at least for now. For example, a page in the Belarusian translation of "The Prince and the Pauper" now got its page number at the top also working as a wikilink to its approximate location in the English book here. I'm using a Scribunto Lua script to calculate the mapping between chapters and some templates to establish this link. Now if somebody is reading a Belarusian book, then the approximate location of the corresponding text fragment in the English book is just a few clicks away. The correct chapter is identified precisely, but the actual page is estimated approximately. The accuracy can be improved via implementing a few additional tricks. It's not fully finished yet, but the results look very promising. --Ssvb (talk) 08:50, 6 August 2024 (UTC)Reply
Comment: I don't know about the policy of belarusian wikisource on links, but you might want to make sure that it's allowed to do that there. Also, though it may be intentional, you're putting these links in the headers in the page namespace, which will not be transcluded onto the finished version of the work. — Alien333 (what I did & why I did it wrong) 09:31, 6 August 2024 (UTC)Reply
@Alien333: Yes, I'm in contact with the most active contributors of the Belarusian Wikisource right now. My personal opinion is that this kind of wikilink from the page number in the running head of a page is non-invasive, doesn't change the overall visual representation of the page and possibly can be categorized as a "basic wikilink" per Wikisource:Wikilinks#Basic_wikilinks rather than an "annotation". This feature is still in a "pilot mode" and is only enabled just for a few books, which are still being OCRed as we speak. It's possible that the feature may evolve into something else. Or it can be ditched if it proves to cause some problems or is deemed to add little value. As for being used only in the page namespace for now, this is intentional. But this can be changed later if necessary. --Ssvb (talk) 08:11, 7 August 2024 (UTC)Reply
I will validate a few pages of yours if you validate mine. 😬
Latest comment: 22 days 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. [2][3]
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.
Latest comment: 20 days 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)Reply
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)Reply
Æ 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)Reply
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)Reply
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)Reply
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)Reply
Can anyone explain how the mobile view UI layout works for book index pages?
Latest comment: 21 days 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)Reply
Reminder! Vote closing soon to fill vacancies of the first U4C
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.
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)Reply
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)Reply
@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)Reply
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)Reply
@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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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: 13 days 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?
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
Latest comment: 15 days 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: 13 days 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)Reply
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)Reply
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)Reply
@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)Reply
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)Reply
Latest comment: 10 days 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)Reply
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.
Latest comment: 2 days 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)Reply
Latest comment: 8 days 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: 8 days 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. [6]
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. [7][8]
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.
Latest comment: 2 days ago3 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)Reply
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)Reply
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)Reply
Sign up for the language community meeting on August 30th, 15:00 UTC
Latest comment: 5 days 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!
Latest comment: 1 day 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. [9]
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:
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)
Support: 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)
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)
Done. Xover (talk) 08:27, 21 July 2024 (UTC)
Two new parser functions will be available this week: 
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.
