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 377 active users here.
As per this discussion, it would be helpful if the Style Guide explicitly stated that numbered chapters should use Arabic numbering (as per our usual practice, and as documented at Help:Subpages#Chapters and sections).
To this end, I am proposing the following change:
OLD:
Works that have chapters/sections should be numbered, not named (eg. use [[/Chapter 1/]] and not [[/The Dog Returns/]]). The section name should reflect those in the original work (Chapter 2, Act 2, et cetera). Subpage titles such as [[/Preface/]] and [[/Appendix/]] are fine though.
When a work is a collection (e.g. poetry) or a compiled work (e.g. a journal or almanac), then the subpages are works in their own right, and the original title of the work should be used in the subpage title.
NEW:
Works that have chapters/sections should be numbered, not named (eg. use [[/Chapter 1/]] and not [[/The Dog Returns/]]).
The section name should reflect those in the original work ("Chapter 2", "Act 2", etc.). Subpage titles such as [[/Preface/]] and [[/Appendix/]] are fine though.
The section number should use Arabic numerals ("Chapter 2"), even if the original work uses Roman numerals ("Chapter II") or another numbering scheme ("Chapter Second", etc)
When a work is a collection (e.g. poetry) or a compiled work (e.g. a journal or almanac), then the subpages are works in their own right, and the original title of the work should be used in the subpage title.
Oppose, since this does not provide for the handful of exceptions where the approach runs into problems, and will therefore run us into rules-lawyering. For 98-99% of cases, the above approach is desirable. But there are problems. One such issue is that nearly every citation of Shakespeare uses capital Roman numerals for the Acts, his means that any linking will have to juggle back and forth in two systems, both in the work itself, and in the linking from works that cite. Links from off-site will have to do the same juggling. This is a nearl-universal citing format for his works. I brought up this issue the last time we discussed this topic. Further, the proposed change does not actually specify that the names of subpages themselves should follow any particular rule; this could be interpreted as rules describing display fields in the header or in tables of contents. This vote is premature, because we first need a discussion to decide what it is we want the change to say, instead of jumping directly to a vote. --EncycloPetey (talk) 14:33, 23 July 2024 (UTC)Reply
WS:MOS already explicitly states that "These are not hard rules, and can be ignored where necessary". This is just a clarification of our usual guidelines to prevent confusion for new users. —Beleg Tâl (talk) 16:11, 23 July 2024 (UTC)Reply
Also: last time I submitted a proposal like this with a discussion instead of jumping to a vote, you yourself opposed it on the grounds that I had not explicitly stated what I was proposing to change the wording to. If you have a suggestion for a better wording, provide it yourself. —Beleg Tâl (talk) 16:13, 23 July 2024 (UTC)Reply
The previous proposal I recall was opposed because the wording kept changingafter people had voted, invalidating all previous votes with each change, because each vote was in support of a different wording. There needs to be a discussion first to work out problems in the wording, and then a vote to adopt the new wording. What you have presented here is a support / oppose situation, without room for discussion first. And in the previous instance there was continual revision concurrent with voting. The wording discussion should come first, then support / oppose afterwards. --EncycloPetey (talk) 23:05, 23 July 2024 (UTC)Reply
I'm with EP on this one: let's discuss our way to a proposed text first, and then vote on the resulting text as a simple yes/no vote. Trying to vote on a text that is constantly changing in small and less small ways is impossible to do cleanly. Xover (talk) 08:53, 24 July 2024 (UTC)Reply
Latest comment: 2 days ago20 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).
Latest comment: 25 days ago7 comments5 people in discussion
The {{Expand list}} and its redirect {{incomplete list}} were originally developed for use on Periodical pages where the lists of articles were incomplete. See, e.g., The New York Times/1901/08/01 where the template is used in the page's Aux ToC. However, the template is now used on around 300 Author pages, where the template is superfluous. I say superfluous because the vast majority of our Author pages are incomplete, even for works we can currently host, and potentially all Author pages will forever be incomplete because new works about authors are continuously being published. Placing a template onto every Author page that is "incomplete" is therefore superfluous since all Author pages could be described as incomplete. Placing the template serves no useful function, nor provides any useful information.
Either we should (a) officially restrict the use of this template to exclude Author pages, or (b) place the template on every Author page because 99% of our Author pages have incomplete lists of works, and all such pages will forever have the potential for new works about the author to come into existence at any time. --EncycloPetey (talk) 17:17, 13 July 2024 (UTC)Reply
Established practice is that Author: pages should not aim for completeness (they're not a bibliography); they should cover the texts we have, but with considerable leeway for adding additional text (e.g. to facilitate linking external scans). Given that, {{expand list}} on an Author: page is not appropriate. I also agree with the reasoning above. Xover (talk) 16:51, 14 July 2024 (UTC)Reply
There are two OPDS catalogs at https://ws-export.wmcloud.org/opds/ (one for English books, one for French books), but it seems they have not been updated since December 2023. They used to be regularly updated in the past. Is there a new location for them?
@Eric Y Muller, @Xover: So it seems there's some other issues, one of which is T370257 where Keeban (Little, Brown and Company) has an incorrect (but valid) cover image specified. I'll not fix it on-wiki right now, in case anyone wants an easy way to reproduce the bug, but it does suggest that Module:Header should add an error tracking category for non-existent cover names. I've made a patch to fix the problem, will hopefully get it merged and deployed soon. SamWilson11:43, 17 July 2024 (UTC)Reply
Latest comment: 29 days ago4 comments4 people in discussion
I have some djvus that I would like to host on WS (because they are UK origin) but they are just over 100MB. I can regenerate them at higher compression if needed, but was curious if there was guidance about how to get them into WS, aside from upload to Internet Archive and then import the djvu (since archive.org I believe is on the import from url allow list). Commons would not be a problem as it has higher limits, even raising the limit to 150MB would help here. MarkLSteadman (talk) 00:29, 18 July 2024 (UTC)Reply
I don't think that Internet Archive is generating djvu's anymore—but check to make sure they don't already have one of the work in question! I may be confused by your question, but maybe this is the answer you want: we seem to prefer importing files from Commons anyway, so if you can upload them there (no matter where you got them, as long as they're in the public domain), that would be ideal—Wikisource will simply use the images from Commons, so you don't need to upload anything here. P Aculeius (talk) 03:29, 18 July 2024 (UTC)Reply
Commons and enWS treat PD differently. We accept anything that's PD in the US regardless of its status elsewhere. Commons require PD in US and PD in country of origin. The files that Mark wants to upload can't go to Commons because they're not PD in the UK, thus his question about how to upload them here. Beeswaxcandle (talk) 09:42, 18 July 2024 (UTC)Reply
@MarkLSteadman: It's not really a limit as such. There's a limitation in the web serving components of Wikimedia's MediaWiki installation (varnish, apache, etc.) that caps raw HTTP uploads at 100MB. For larger files you have to use a custom MediaWiki-specific protocol called Chunked Uploading, in which case you can upload files as large as 2.5GB (IIRC). The difference between Commons and enWS is that Commons has Upload Wizard, which supports and uses Chunked Uploading, while enWS does not (we just have the plain old upload form).For an occasional need I would generally recommend that you drop your files into Dropbox or Google Drive (or whatever such service you have) and shoot the link my way so I can upload them for you. But if you anticipate having this need regularly and can deal with a relatively high geek-factor, the solution is the tool I use……namely commons:User talk:Rillke/bigChunkedUpload.js. There are som docs in that link, but the gist is that you put mw.loader.load('//commons.wikimedia.org/w/index.php?title=User:Rillke/bigChunkedUpload.js&action=raw&ctype=text/javascript'); into your common.js and then you get some new "Chunked upload" options in relevant parts of File:-namespace pages. Important thing to remember: bigChunkedUpload starts upload immediately when you select a file. There's no confirmation, extra button click, etc. unlike most other similar tools. So make sure you select the options you want in the dialog before selecting a file to upload. It also has a pretty high geek factor, so it's pretty off-putting to non-technical people, but since it's fairly limited in scope most people should be able to use it in a pinch. Xover (talk) 06:15, 18 July 2024 (UTC)Reply
User translations without scan-backed original: how long to wait?
Latest comment: 29 days ago1 comment1 person in discussion
If someone uploads a user translation of a work, which does not have a scan-backed original on the relevant language Wikisource (e.g. Translation:Does Spring Come, Even to Stolen Fields / ko:빼앗긴 들에도 봄은 오는가), how long of a grace period should we allow for the original to be added before deleting the user translation? Mostly just looking for general thoughts; I feel like it needs more grace than WS:PD would usually allow, but should still be on some sort of time limit or else there's no point disallowing this situation —Beleg Tâl (talk) 13:20, 18 July 2024 (UTC)Reply
Wikimedia Movement Charter ratification voting results
After carefully tallying both individual and affiliate votes, the Charter Electoral Commission is pleased to announce the final results of the Wikimedia Movement Charter voting.
As communicated by the Charter Electoral Commission, we reached the quorum for both Affiliate and individual votes by the time the vote closed on July 9, 23:59 UTC. We thank all 2,451 individuals and 129 Affiliate representatives who voted in the ratification process. Your votes and comments are invaluable for the future steps in Movement Strategy.
The final results of the Wikimedia Movement Charter ratification voting held between 25 June and 9 July 2024 are as follows:
Individual vote:
Out of 2,451 individuals who voted as of July 9 23:59 (UTC), 2,446 have been accepted as valid votes. Among these, 1,710 voted “yes”; 623 voted “no”; and 113 selected “–” (neutral). Because the neutral votes don’t count towards the total number of votes cast, 73.30% voted to approve the Charter (1710/2333), while 26.70% voted to reject the Charter (623/2333).
Affiliates vote:
Out of 129 Affiliates designated voters who voted as of July 9 23:59 (UTC), 129 votes are confirmed as valid votes. Among these, 93 voted “yes”; 18 voted “no”; and 18 selected “–” (neutral). Because the neutral votes don’t count towards the total number of votes cast, 83.78% voted to approve the Charter (93/111), while 16.22% voted to reject the Charter (18/111).
…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
Latest comment: 26 days ago3 comments3 people in discussion
I've noticed that the tabs that link to Source, Styles, and such at the top of a work now use "Page" for the Mainspace location. That is very confusing because we have a Page: namespace that is separate from the Mainspace. Is this an oversight on the part of the developers for the potential confusion, and what can we do about it? --EncycloPetey (talk) 16:56, 21 July 2024 (UTC)Reply
On which page (and implicitly, in what namespace) are you seeing a different text string for the content tab than previously; what text did you used to see there; and what skin are you using?As best I can recall the main content tab in mainspace has always read "Page" (meaning here, of course, "wikipage"), at least since 2007. It's always been confusing, but with no obvious good alternative. In the Index namespace (which is where you should see a "Styles" tab) the main content tab should read "Index". Xover (talk) 18:55, 21 July 2024 (UTC)Reply
Yeah, this is the default name out of the box in MediaWiki; it's only confusing for the small handful of projects that happen to also have a namespace called "Page". It's the same confusing nomenclature that you get when you're talking about the "Talk page" and the "Index page" and the "Page page" and so forth. (Yes, I have had to use the phrase "Page page", on occasion.) —Beleg Tâl (talk) 22:46, 21 July 2024 (UTC)Reply
Latest comment: 25 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
Stewards can now globally block accounts. Before the change only IP addresses and IP ranges could be blocked globally. Global account blocks are useful when the blocked user should not be logged out. Global locks (a similar tool logging the user out of their account) are unaffected by this change. The new global account block feature is related to the Temporary Accounts project, which is a new type of user account that replaces IP addresses of unregistered editors that are no longer made public.
Later this week, Wikimedia site users will notice that the Interface of FlaggedRevs (also known as "Pending Changes") is improved and consistent with the rest of the MediaWiki interface and Wikimedia's design system. The FlaggedRevs interface experience on mobile and Minerva skin was inconsistent before it was fixed and ported to Codex by the WMF Growth team and some volunteers. [1]
Wikimedia site users can now submit account vanishing requests via GlobalVanishRequest. This feature is used when a contributor wishes to stop editing forever. It helps you hide your past association and edit to protect your privacy. Once processed, the account will be locked and renamed. [2]
Have you tried monitoring and addressing vandalism in Wikipedia using your phone? A Diff blog post on Patrolling features in the Mobile App highlights some of the new capabilities of the feature, including swiping through a feed of recent changes and a personal library of user talk messages for use when patrolling from your phone.
Wikimedia contributors and GLAM (galleries, libraries, archives, and museums) organisations can now learn and measure the impact Wikimedia Commons is having towards creating quality encyclopedic content using the Commons Impact Metrics analytics dashboard. The dashboard offers organizations analytics on things like monthly edits in a category, the most viewed files, and which Wikimedia articles are using Commons images. As a result of these new data dumps, GLAM organisation can more reliably measure their return on investment for programs bringing content into the digital Commons. [3]
Project Updates
Come share your ideas for improving the wikis on the newly reopened Community Wishlist. The Community Wishlist is Wikimedia’s forum for volunteers to share ideas (called wishes) to improve how the wikis work. The new version of the wishlist is always open, works with both wikitext and Visual Editor, and allows wishes in any language.
Learn more
Have you ever wondered how Wikimedia software works across over 300 languages? This is 253 languages more than the Google Chrome interface, and it's no accident. The Language and Product Localization Team at the Wikimedia Foundation supports your work by adapting all the tools and interfaces in the MediaWiki software so that contributors in our movement who translate pages and strings can translate them and have the sites in all languages. Read more about the team and their upcoming work on Diff.
How can Wikimedia build innovative and experimental products while maintaining such heavily used websites? A recent blog post by WMF staff Johan Jönsson highlights the work of the WMF Future Audience initiative, where the goal is not to build polished products but test out new ideas, such as a ChatGPT plugin and Add a Fact, to help take Wikimedia into the future.
We should get rid of {{improve documentation}}, which you imported from enWP by cut&paste in 2019, because if there is one thing we do not need on enWS it is yet another template to point out the fact we are all aware of (our documentation is inadequate). It adds maintenance (this thread being the case in point) for no added value beyond letting people vent about inadequate docs in template form instead of in a talk page comment. Xover (talk) 11:22, 24 July 2024 (UTC)Reply
Visually you do, yes. But the markup is semantic, not presentational ("decoration"). Removing the presentational component does not change the underlying meaning. The two types of list are not the same. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits14:47, 25 July 2024 (UTC)Reply
That's not an unsigilled ordered list. That's an ordered list with sigils that cannot currently be reproduced in MediaWiki due to a combination of limitations in MediaWiki and web browsers. Making that an ordered list with hidden sigils and then manually reproducing the numbering would be unsemantic and cause a problem for, e.g., non-visual browsers (and other user agents that automatically number ordered list items, or that fall back on a default numbering style when they do not support the custom style specified). There may be use cases for unsigilled ordered lists, but absent evidence to the contrary I am sceptical that any of them occur in our content namespaces. Xover (talk) 16:09, 25 July 2024 (UTC)Reply
Latest comment: 22 days ago3 comments2 people in discussion
It takes several attempts to display a thumb of a PDF file page in page namespace. Sometimes I have to refresh the page 5 to 10 times. Also transcribing text with any of the OCR tools takes long (20+ seconds) and sometimes it fails completely. I noticed the problems yesterday morning, but I do not know when they actually started because I had not worked in the page namespace for a long time. -- Jan Kameníček (talk) 11:26, 25 July 2024 (UTC)Reply
Jan Kameníček I had this problem today. I filled the "waiting time" by purging here and at commons, multiple times; which, unfortunately, was a step backwards as I initially lost the thumb on the index page. This is not the "other problem" where there seems to be a network time out while putting the page into the exact same location and magnification that was previously used. That problem is solved, often, by twirling the mouse wheel thus adjusting the magnification and causing the page to render. Moral: fill that render time wisely and if wisely is unavailable, then fill it while calmly purging everything that might be touching it, I think.--RaboKarbakian (talk) 14:44, 25 July 2024 (UTC)Reply
I am writing to you to let you know the voting period for the Universal Code of Conduct Coordinating Committee (U4C) is open now through August 10, 2024. Read the information on the voting page on Meta-wiki to learn more about voting and voter eligibility.
The Universal Code of Conduct Coordinating Committee (U4C) is a global group dedicated to providing an equitable and consistent implementation of the UCoC. Community members were invited to submit their applications for the U4C. For more information and the responsibilities of the U4C, please review the U4C Charter.
Please share this message with members of your community so they can participate as well.
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: 18 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:) [4]
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: 11 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. [5][6]
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: 9 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: 10 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
Latest comment: 2 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: 4 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: 2 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
Support, though it may be useful to specify in the first bullet points that it does not apply to collections, else it and the last bullet point may seem contradictory. — Alien333 (what I did & why I did it wrong) 13:52, 23 July 2024 (UTC)
Oppose, since this does not provide for the handful of exceptions where the approach runs into problems, and will therefore run us into rules-lawyering. For 98-99% of cases, the above approach is desirable. But there are problems. One such issue is that nearly every citation of Shakespeare uses capital Roman numerals for the Acts, his means that any linking will have to juggle back and forth in two systems, both in the work itself, and in the linking from works that cite. Links from off-site will have to do the same juggling. This is a nearl-universal citing format for his works. I brought up this issue the last time we discussed this topic. Further, the proposed change does not actually specify that the names of subpages themselves should follow any particular rule; this could be interpreted as rules describing display fields in the header or in tables of contents. This vote is premature, because we first need a discussion to decide what it is we want the change to say, instead of jumping directly to a vote. --EncycloPetey (talk) 14:33, 23 July 2024 (UTC)
Delete these templates entirely, and on pages like The New York Times/1901/08/01 replace it with {{incomplete}} instead —Beleg Tâl (talk) 19:25, 14 July 2024 (UTC)
Done. Xover (talk) 08:27, 21 July 2024 (UTC)
Two new parser functions will be available this week:
