Wikisource:Scriptorium/Archives/2020-08
|
Please do not post any new comments on this page. This is a discussion archive first created in , although the comments contained were likely posted before and after this date. See current discussion or the archives index. |
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Problems
- All queries to the Wikidata Query Service failed between 17:50 and 17:59 UTC on Thursday 23 July. Some queries failed during a longer period. [1]
- Interlanguage links were ordered incorrectly for the past few weeks. This problem was also mentioned in Tech News two weeks ago. The problem is now fixed. [2]
- There is a problem with the global preferences for the "Use Legacy Vector" option. Developers are working on fixing it. [3]
- A bug in the Wikibase extension had disabled the "move" and "create" types of protection in the main (Gallery) namespace on Wikimedia Commons. New protections could not be added, and existing protections were not enforced, allowing some page moves and page creations that should not have been possible. This has now been fixed. [4]
Changes later this week
- The video player will change to be simpler and more modern. This week, the current beta feature will become the video player for everyone on most non-Wikipedia wikis. The old player will be removed. [5]
- Users'
global.jsandglobal.csspages will now also be loaded on the mobile site. You can read documentation for how to avoid applying styles to the mobile skin. [6] 
In the MonoBook skin, the searchGoButtonidentifier is nowsearchButton. This may affect CSS and JS gadgets. Migration instructions can be found in T255953. This was previously mentioned in issue 27.- Bot operators can use Pywikibot to regularly archive discussions. The behavior when the bot uses
counterto prevent large archives was changed. [7] 
The new version of MediaWiki will be on test wikis and MediaWiki.org from August 4. It will be on non-Wikipedia wikis and some Wikipedias from August 5. It will be on all wikis from August 6 (calendar).
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
15:43, 3 August 2020 (UTC)
- Even looking at the Phab task and the associated patch I'm having trouble figuring out what the Pywikibot archive change actually does. But we have multiple bots archiving our discussion pages (such as the Scriptorium, and including user talk pages) so it might be worthwhile to keep an extra eye out for any wonky archiving behaviour over the next couple of weeks. --Xover (talk) 17:53, 3 August 2020 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
- FileImporter and FileExporter became standard features on all Wikis during the first week of August. They help you transfer files from local wikis to Wikimedia Commons with the original file information and history intact. [8]
Problems
- The mobile skin displays a message at the bottom of the page about who edited last. This message showed raw wikitext. This has now been fixed. Some messages in Structured Discussions and content translation may still appear as raw wikitext. Developers are working on it. [9]
Changes later this week
- The new version of MediaWiki will be on test wikis and MediaWiki.org from August 11. It will be on non-Wikipedia wikis and some Wikipedias from August 12. It will be on all wikis from August 13 (calendar).
Future changes
- All wikis will be read-only for a few minutes on September 1. This is planned between 13:30 and 15:30 UTC. More information will be published in Tech News and will also be posted on individual wikis in the coming weeks. [10][11]
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
16:06, 10 August 2020 (UTC)
"Validated texts" search box on Main Page?
Almost a year ago, Kaldari proposed "Making our validated texts discoverable" through, among other things, adding a dedicated search box on the Main Page that searches only validated texts. Specifically, they proposed an experiment to add the search box to see if it had any impact on page views and related metrics. The proposal had general support and no opposition.
They also created a mockup, which I have now updated to fit in the new Main Page here:
Unless there is some particular reason not to or to wait, I propose updating Main Page with this change in the relatively near future. --Xover (talk) 07:07, 12 August 2020 (UTC)
- @Kaldari: Is there anything that needs to be in place before that in order to realise the goals you had for the experiment? Do we still need a bot run to flesh out Category:Validated texts? Do we need a particular date for the switchover to match the stats period? Anything else? --Xover (talk) 07:08, 12 August 2020 (UTC)
- Why only "Validated"? We have many "Proofread" texts that are perfectly serviceable, and likely to remain in that state for a considerably long time. For example, Some Particulars of the Life and Adventures of James Guidney - third edition has been in that limbo since September 2018, despite comprising just ten pages. [And on a related note, why is Bird Haunts and Nature Memories in Category:Proofread texts and not Category:Validated texts?] Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:12, 12 August 2020 (UTC)
- Distraction/bikeshed alert: I believe this is where a "good for export" (to borrow frWS's phrase) distinction is more appropriate than proofread or validated. P/V status only really refers to the completeness of the text, good for export means it's at least proofread and also checked to make sure it can be exported usefully for consumption in ways that "outsiders" can consume (e.g. on an e-reader). If you're a newcomer to WS and you just want to read a book, the latter is more likely what you want.
- Not least, lots of "bitty" works are kicking about in Category:Proofread texts that are unlikely to be what the average Kindle-toting punter expecting something like Project Gutenberg has in mind, e.g. the first member of that category 1911 Encyclopædia Britannica/Alcestis, which is just one rather short article (in general, both categories are clogged with DNB and EB1911 articles).
- On the other side of the coin, there are "validated" works that might be unsuitable for export, like A Dancer's Tale, which due to a fixed-width formatting choice is likely to fail to render properly on some devices (in my case, Moon Reader+ does OK, but Calibre reader doesn't like it). Inductiveload—talk/contribs 12:44, 12 August 2020 (UTC)
- @Pigsonthewing, @Inductiveload: I'm bringing this up mainly has a technical thing, and because it's a change to the Main Page. Searching only validated texts is a place to start that I don't think anyone will find objectionable (except in the sense "insufficient"), and once we have the search box we can expand or adjust as needed. There was a follow-on discussion in "A new category for validated texts?" that's relevant too, but I'm mainly just looking to get the ball rolling right now. --Xover (talk) 14:21, 12 August 2020 (UTC)
- An objection that would be maintained, even for the limited search you propose, is that pages like this show up. This is not an independent work, merely an article, and the inclusion of these in the search is my primary objection to this new search tool. TE(æ)A,ea. (talk) 14:36, 12 August 2020 (UTC).
- @Xover: absolutely, it was more a sidebar than an attempted roadblock. :-). I'd be inclined to agree with Pigsonthewing on that Proofread is a better cut-off than Validated, as a Proofread work is generally as fit for general interest users as Validated.
- @TE(æ)A,ea.: agreed, but we have no better category for "completed" works at the present time. Any infrastructure that slurps from some categories can have the cats changed later easily. There's also massive under-representation of works in Proofread/Validated cats - there are ~2500 works there in total, most of them there are EB911/DNB and there must be a lot of works missing such a cat at all. I think if we were to promote such a tool to the front page (which should indeed have such a tool), there should also be a road map to a situation which results in a category (or equivalent) that allows the tool to be useful to outside readers. If there is no such road map, then the tool is probably premature and will never be particularly useful, and will mostly serve to give a bad impression that WS is full of incomplete dictionaries, legal cases and executive orders. Inductiveload—talk/contribs 14:52, 12 August 2020 (UTC)
- An objection that would be maintained, even for the limited search you propose, is that pages like this show up. This is not an independent work, merely an article, and the inclusion of these in the search is my primary objection to this new search tool. TE(æ)A,ea. (talk) 14:36, 12 August 2020 (UTC).
- @Pigsonthewing, @Inductiveload: I'm bringing this up mainly has a technical thing, and because it's a change to the Main Page. Searching only validated texts is a place to start that I don't think anyone will find objectionable (except in the sense "insufficient"), and once we have the search box we can expand or adjust as needed. There was a follow-on discussion in "A new category for validated texts?" that's relevant too, but I'm mainly just looking to get the ball rolling right now. --Xover (talk) 14:21, 12 August 2020 (UTC)
- @Xover: Thanks for resurrecting this. The only reason I hadn't moved forward with it is because I wanted to do a bot run to set the Wikidata flag for all the validated works, but writing a bot to set flags in Wikidata proved to be more complicated than my original idea of just running a bot to add the category directly in Wikisource (via Wikitext). So I never actually got very far in doing the bot part. That's why most validated works still aren't in Category:Validated texts. Kaldari (talk) 01:03, 13 August 2020 (UTC)
- @TE(æ)A,ea.: Personally, I don't care what category the search box pulls from, but in the discussion from last year there seemed to be consensus that searching validated texts made sense. I agree with you that including texts such as Gordon, Charles George (DNB00) isn't ideal, but unfortunately we don't have any clear delineation on Wikisource between complete and component texts, and crafting such a delineation would be very difficult. Would a book-length article in a periodical be eligible for inclusion? Would a single volume of a multi-volume book? What about a single work from a "Collected Works"? What about a single volume from a "Collected Works"? What about a single poem from a "Collected Poems"? What if it was a book-length poem? There are endless edge cases. We shouldn't let the perfect be the enemy of the good. That said, I'm very interested in hearing other ideas for a potential category of "readable" works that we could offer people. Kaldari (talk) 01:24, 13 August 2020 (UTC)
- I think what is desired is what could be considered an “independent” work. To counter your above selections: complete articles from periodicals would generally qualify, if they had a use separately from the periodical in which they were published; and individual volumes of either a periodical or an independently published work would be left out, in favour of the individual articles (in a periodical) or the entire work (for a multiple-volume work). As Inductiveload mentioned above, I believe that a category designed for this purpose would be very valuable. TE(æ)A,ea. (talk) 23:30, 14 August 2020 (UTC).
Feedback requested: Ebook Export Improvement Project
Note: This message is in English, but we encourage translation into other languages. Thank you!
Hello, everyone!
I am pleased to announce that the Community Tech team at WMF has posted our August update on the Wikisource Ebook Export Improvement project! This project came out of our 2020 Community Wishlist Survey, and it was the #1 wish voted on by survey participants.
So, what does this mean? In short, we want your feedback! Now that we have posted the August update, we want to know what you think. The update includes findings from our community consultation, results from two separate analyses conducted by the team (on improving WSExport reliability & font rendering support), and proposed next steps. It is our hope that people can read our analysis, share their feedback, and engage in a conversation with us on the talk page. Your feedback will be invaluable, and it will help determine the next steps of the project.
Thank you to everyone who has participated in the consultation so far! It's been a joy to explore how we can improve the ebook export experience. Now, we look forward to reading a new round of feedback on the project talk page!
-- IFried (WMF) (Product Manager, Community Tech)
Sent by User:SGill (WMF) using MediaWiki message delivery (talk) 12:14, 17 August 2020 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
- If you revert an edit using the undo link your edit is marked with an
undotag. This will now only happen if you don't change anything in the edit window before publishing the undo. This is to keep users from marking edits as undos when they actually do something else. [12] - The new OOUI version will not work with Internet Explorer 8. This means the wikis will look strange and not work well in Internet Explorer 8. This was reported in Tech/News/2020/17. This is because keeping the wikis working with very old browsers creates other problems. [13]
Changes later this week
- The new version of MediaWiki will be on test wikis and MediaWiki.org from 18 August. It will be on non-Wikipedia wikis and some Wikipedias from 19 August. It will be on all wikis from 20 August (calendar).
Future changes
- All wikis will be read-only for a few minutes on September 1. This is planned between 13:30 and 15:30 UTC. More information will be published in Tech News and will also be posted on individual wikis next week. This is a reminder. You can help by translating the announcement message. [14][15]
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
20:41, 17 August 2020 (UTC)
Missing pages: Walks in the Black Country
Much to my annoyance, I find that the PDF I used to create Index:Walks in the Black Country and its green border-land.pdf - on which I have done a fair amount of work, today - is missing the final three pages. IA has two other copies, which appear complete.
What's the best way to fix this? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:18, 18 August 2020 (UTC)
- Unfortunately either of the other copies will result in some re-jigging of the pages you've already done. The best copy of the three is this one, which has the advantage of having a djvu file available and isn't a Google scan. Upload the replacement file over the current one, then put in a Bot Request to have the pages you've already created moved to account for the new pagination. Beeswaxcandle (talk) 06:42, 19 August 2020 (UTC)
- Thank you; perhaps I'm being dense, but will Commons let me overwrite a PDF with a djvu file? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:00, 19 August 2020 (UTC)
- No, but when there is one the images are better quality on IA for fishing out. Beeswaxcandle (talk) 18:04, 19 August 2020 (UTC)
- OK, done; please see my bot request. Thanks again. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:22, 19 August 2020 (UTC)
- Actually, by luck, it seems the old and new pages align. Does anything else need to be done? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:24, 19 August 2020 (UTC)
- Excellent! It's rare that they do. In that case, there's nothing else to do—other than proofreading, of course <grin> Beeswaxcandle (talk) 01:48, 20 August 2020 (UTC)
- No, but when there is one the images are better quality on IA for fishing out. Beeswaxcandle (talk) 18:04, 19 August 2020 (UTC)
- Thank you; perhaps I'm being dense, but will Commons let me overwrite a PDF with a djvu file? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:00, 19 August 2020 (UTC)
Preventing a well-intentioned renaming of a page
Sometimes a title appears to be incorrect, but is actually correct. For example, if the work itself uses a misspelling in the title. Or in the case I am working on now, someone might be tempted to move Songs of Old Canada/A la claire fontaine to Songs of Old Canada/À la claire fontaine. What do you think is the best way to prevent such a move? I thought of maybe protecting the page, but this would also prevent legitimate moves such as disambiguating the work to Songs of Old Canada (McLennan)/A la claire fontaine or Songs of Old Canada (1886)/A la claire fontaine. I will put a note on the talk page, but a well-intentioned page mover might not look there and see the note. —Beleg Tâl (talk) 18:04, 8 August 2020 (UTC)
- @Beleg Tâl: How about a redirect from the potential move target to the actual page? Redirects can have a note entered after the redirect code if you want, and if they have an edit history they can't be overwritten during a move. Then a move would be quite an effort for a non-admin: you'd have to move the redirect out of the way, move the page, then move or recreate the redirect in reverse and soft-redirect/speedy-request the temporary page. It's likely a would-be-mover would find the note in that case. Moving the whole work to another root page would need the redirect to be updated, but it wouldn't be a major impediment, and trawling subpages for incoming links is part of that process anyway. Inductiveload—talk/contribs 19:03, 8 August 2020 (UTC)
- @Inductiveload: I did not realize that an edit history would prevent move over redirect, but now that I know this I can see that this is the perfect solution. Thank you! —Beleg Tâl (talk) 15:53, 20 August 2020 (UTC)
FYI: Wikipedia's template for citing LDS scriptures now links to WS
Just FYI, the {{LDS}} template on Wikipedia, which is used to cite LDS (aka Mormon) scriptures, now links to Wikisource by default instead of the website of the Church of Jesus Christ of Latter-day Saints (which is, unsurprisingly (and appropriately), not a very NPOV source). Many thanks again to Xover for the technical assistance; he also suggested I post here to make sure the WS community is generally aware. I initially thought I would have to make some custom additions to the markup here on WS to make sure there were appropriate HTML anchors to jump to in some of the different books, but consistent usage of the {{chapter}} and {{verse}} templates made it so that there's nothing unique about those works after all. Thanks for maintaining Wikisource as a great NPOV repository of texts! Biggins (talk) 02:36, 21 August 2020 (UTC)
Template:Missing image showing error
{{Missing image}}, along with some other templates, is showing the error “This message box is using an invalid "type=cleanup" parameter and needs fixing.” It appears to be caused by this change to Module:Message box. Could someone who knows how Module coding works fix this error? TE(æ)A,ea. (talk) 12:24, 20 August 2020 (UTC).
- @TE(æ)A,ea.: Looking at the code I can tell that it's broken, how it's broken, and why it broke; but I'm having trouble finding any examples of the error message you refer to. Where did you see it? --Xover (talk) 13:49, 20 August 2020 (UTC)
- @TE(æ)A,ea.: Nevermind; found it! :) --Xover (talk) 13:57, 20 August 2020 (UTC)
- Xover: Template:Missing score, Template:Missing table, Template:Missing chess diagram, and Template:Shorthand missing have the same and Template:Poor OCR has a similar error. Also, there should probably be some discussion on the necessity of Template:Cih image (which is based on Template:Missing image) and Category:Texts with missing shorthand, as that is not clearly defined; see also this category. TE(æ)A,ea. (talk) 15:17, 20 August 2020 (UTC).
- Xover: Your change needs to be fixed, as it causes all of the templates to appear at the top of the page; see here. TE(æ)A,ea. (talk) 15:51, 20 August 2020 (UTC).
- @TE(æ)A,ea.: This is a separate bug, tickled by the same import as the original error message, rather than a side-effect of the workaround. This one is (I'm fairly sure) in the page numbers script, and is (I think) an additional symptom of a bug that was already causing some lesser cosmetic problems. I'm looking into it, but my available time is a bit spotty just now so it may take a while to track down and fix.@Inductiveload: If you feel like wading in, the issue TE(æ)A,ea. is reporting is probably caused by MediaWiki:PageNumbers.js: to do its thing it wraps
#mw-content-textin three divs, and then it manually hoists {{header}}, {{no license}} and a few similar things (page level messages) out of those divs again. Once the pmbox changes were overwritten by the above import, the message boxes generated by {{missing image}} (and a few related templates) started getting caught by this hoisting and are now being hoisted out and up top instead of being displayed where they are used. The fix may be as simple as adding a class to the {{pmbox}} invocations in {{missing image}} and friends, but may also require actually fixing the code in MediaWiki:PageNumbers.js (depends what selector pagenumbers.js is looking for). And that script is also a likely culprit for another recent issue: the footer (which is automatically generated from the {{header}} in javascript) has been showing up narrow instead of full-width (as the header does). I'm guessing this is due to a similar problem, only in reverse, in that the footer is probably being left inside the main content div and thus being limited in width by the active dynamic layout (e.g. Layout 2). This could be due to either the recent site css changes, or the recent MW changes to which html elements are used (cf. the need to remove over-specifiedelement.classselectors).I haven't had a chance to dig into either issue in depth yet, and my available time looks like it will be spotty until at least early next week. I'll try and dig whenever I find a moment in there, but this will probably take a medium-sized block of uninterrupted attention to nail down. --Xover (talk) 17:48, 20 August 2020 (UTC) - Oh, I forgot to post, and the original issue is as follows: we have imported Module:Message box from enwp, but then made local modifications to it to create a new {{pmbox}} message box type. When a new import from enwp was made today it overwrote our local changes, meaning the pmbox message box type disappeared. Since Module:Message box is being about five times more clever than it should be (it reads message box definitions from a config module, and then modifies the metatable associated with the function lookup table to add pseudo-functions corresponding to each message box type: polymorphing the object interface based on configuration), it ends up showing an error message about a
type=cleanuptemplate argument that isn't actually relevant, instead of telling you that there isn't actually a "pmbox" message box type defined. To work around it I switched {{missing image}} from {{pmbox}} to {{ambox}}, since enwp has ambox by default and our pmbox was a carbon copy of its config. We could just pick the pmbox config out of the revision history, but it's just hide (not fix) all these problems, and then they would just reappear the next time we sync from enwp. The proper fix will be either reusing one of the enwp message box types and possibly style it, or to get upstream to add explicit support for a separate "localconfig" module so we could customise it without getting bit every time we re-sync. --Xover (talk) 17:59, 20 August 2020 (UTC)- Actually, I take that back: .ambox is special-cased in MediaWiki:Common.js (among the other code that's there to compensate for MediaWiki:PageNumbers.js), so the switch to {{ambox}} did cause it to get hoisted (just by a different script). I was fooled by a test case that legitimately had the template before the header. I've switched it to {{ombox}} now, and just removed the bogus
type=cleanupparameter. That should take care of both the magical floating message boxes and the error message for now. The rest still needs fixing properly though. --Xover (talk) 19:20, 20 August 2020 (UTC) - And in the interest of finding a cleaner long-term solution I've requested (permanent link) support for a separate site configuration file in the upstream module at enwp. --Xover (talk) 09:51, 21 August 2020 (UTC)
- Actually, I take that back: .ambox is special-cased in MediaWiki:Common.js (among the other code that's there to compensate for MediaWiki:PageNumbers.js), so the switch to {{ambox}} did cause it to get hoisted (just by a different script). I was fooled by a test case that legitimately had the template before the header. I've switched it to {{ombox}} now, and just removed the bogus
- @TE(æ)A,ea.: This is a separate bug, tickled by the same import as the original error message, rather than a side-effect of the workaround. This one is (I'm fairly sure) in the page numbers script, and is (I think) an additional symptom of a bug that was already causing some lesser cosmetic problems. I'm looking into it, but my available time is a bit spotty just now so it may take a while to track down and fix.@Inductiveload: If you feel like wading in, the issue TE(æ)A,ea. is reporting is probably caused by MediaWiki:PageNumbers.js: to do its thing it wraps
- @TE(æ)A,ea.: Nevermind; found it! :) --Xover (talk) 13:57, 20 August 2020 (UTC)
Portals for ordinary people
As more full newspapers are transcribed and hosted at Commons, is there away to have a page for a subject of multiple articles that are transcribed here? Lets say we have the Postmaster of New York City and we have transcribed three articles on him, how would we tie them together? In the past if I created a Portal:Bob_Smith based on their name it would be deleted. I was told only famous people get portals. Can anyone with a Wikidata entry or that has a Commons category get a portal? Is there a minimum number of entries before someone gets a portal? --Richard Arthur Norton (1958- ) (talk) 17:27, 21 August 2020 (UTC)
- @Richard Arthur Norton (1958- ): see Help:Portals#When to create a new portal. If there are multiple articles about the person (i.e. not merely mentioning them in passing), then there are enough works to make a portal listing them. And yes, the page would be Portal:Bob Smith based on their name. —Beleg Tâl (talk) 23:17, 21 August 2020 (UTC)
- Thanks! Good to see the rules have changed, or at least the person that had been deleting them has been convinced to no longer delete them. --Richard Arthur Norton (1958- ) (talk) 23:22, 21 August 2020 (UTC)
- @Richard Arthur Norton (1958- ): The policy/rules have not changed, the rule for a portal is based on local content, and there will always be an element of notability. — billinghurst sDrewth 00:14, 22 August 2020 (UTC)
- If nothing has changed, does that mean you are going to delete them a second time? --Richard Arthur Norton (1958- ) (talk) 01:06, 22 August 2020 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Changes later this week
- The new version of MediaWiki will be on test wikis and MediaWiki.org from 25 August. It will be on non-Wikipedia wikis and some Wikipedias from 26 August. It will be on all wikis from 27 August (calendar).
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
17:59, 24 August 2020 (UTC)
Technical Wishes: FileExporter and FileImporter become default features on all Wikis
The FileExporter and FileImporter will become a default features on all wikis until August 7, 2020. They are planned to help you to move files from your local wiki to Wikimedia Commons easier while keeping all original file information (Description, Source, Date, Author, View History) intact. Additionally, the move is documented in the files view history. How does it work?
Step 1: If you are an auto-confirmed user, you will see a link "Move file to Wikimedia Commons" on the local file page.
Step 2: When you click on this link, the FileImporter checks if the file can in fact be moved to Wikimedia Commons. These checks are performed based on the wiki's configuration file which is created and maintained by each local wiki community.
Step 3: If the file is compatible with Wikimedia Commons, you will be taken to an import page, at which you can update or add information regarding the file, such as the description. You can also add the 'Now Commons' template to the file on the local wiki by clicking the corresponding check box in the import form. Admins can delete the file from the local wiki by enabling the corresponding checkbox. By clicking on the 'Import' button at the end of the page, the file is imported to Wikimedia Commons.
If you want to know more about the FileImporter extension or the Technical Wishes Project, follow the links. --For the Technical Wishes Team:Max Klemm (WMDE) 09:13, 6 August 2020 (UTC)
- @Max Klemm (WMDE): We've been using FileExporter for a while now on enWS and it's been working great. Very very appreciated feature! However, we also really miss the ability to import files from Commons to Wikisource: the projects have different copyright policies so some files up for deletion on Commons need to be imported locally here. If the UI is difficult with all the different project combination, we could do that in a local Gadget, just so long as the core functionality was available. We wouldn't even strictly need the configuration stuff on meta; if we can easily move the file and preserve the revision history we can take care of the rest manually. Any chance this could happen at some point? --Xover (talk) 11:35, 6 August 2020 (UTC)
- @Xover:, Thanks for your feedback and your question. I will come back to you with an answer at the end of next week, beginning of the week after, since I need to discuss your question with my team, which requires some time. -- For the Technical Wishes Team: Max Klemm (WMDE) (talk) 11:57, 6 August 2020 (UTC)
- @Xover:, I am sorry for the late answer. We have recorded your request. However, with a lot of other projects in the making, we are not having time or manpower to modify the FileImporter in such way that you can use it to move file from WikiMedia Commons to WikiSource. -- For the Technical Wishes Team: Max Klemm (WMDE) (talk) 09:05, 26 August 2020 (UTC)
- @Max Klemm (WMDE): Thanks for looking into this! Is there perhaps some lesser adaptation possible that would let us implement the missing parts ourselves in a Gadget? It is specifically the importing of revisions that requires core/extension support; all UI and higher level logic looks like it should be possible to implement with site/user scripts or Gadgets. --Xover (talk) 11:49, 26 August 2020 (UTC)
- @Max Klemm (WMDE): As a note, one can move files from Commons to here using one of Magnus's scripts (excommons.js), though to do that one has to be an administrator at both Commons and the source wiki, and that is very limiting. I would endorse for local administrators to have the ability to transfer into a wiki from Commons. I don't think that it needs to be all-in for such an ability. — billinghurst sDrewth 13:23, 6 August 2020 (UTC)
- @Xover:, I am sorry for the late answer. We have recorded your request. However, with a lot of other projects in the making, we are not having time or manpower to modify the FileImporter in such way that you can use it to move file from WikiMedia Commons to WikiSource. -- For the Technical Wishes Team: Max Klemm (WMDE) (talk) 09:05, 26 August 2020 (UTC)
- @Xover:, Thanks for your feedback and your question. I will come back to you with an answer at the end of next week, beginning of the week after, since I need to discuss your question with my team, which requires some time. -- For the Technical Wishes Team: Max Klemm (WMDE) (talk) 11:57, 6 August 2020 (UTC)
Important: maintenance operation on September 1st
Read this message in another language • Please help translate to your language
The Wikimedia Foundation will be testing its secondary data centre. This will make sure that Wikipedia and the other Wikimedia wikis can stay online even after a disaster. To make sure everything is working, the Wikimedia Technology department needs to do a planned test. This test will show if they can reliably switch from one data centre to the other. It requires many teams to prepare for the test and to be available to fix any unexpected problems.
They will switch all traffic to the secondary data centre on Tuesday, September 1st 2020.
Unfortunately, because of some limitations in MediaWiki, all editing must stop while the switch is made. We apologize for this disruption, and we are working to minimize it in the future.
You will be able to read, but not edit, all wikis for a short period of time.
- You will not be able to edit for up to an hour on Tuesday, September 1st. The test will start at 14:00 UTC (15:00 BST, 16:00 CEST, 10:00 EDT, 19:30 IST, 07:00 PDT, 23:00 JST, and in New Zealand at 02:00 NZST on Wednesday September 2).
- If you try to edit or save during these times, you will see an error message. We hope that no edits will be lost during these minutes, but we can't guarantee it. If you see the error message, then please wait until everything is back to normal. Then you should be able to save your edit. But, we recommend that you make a copy of your changes first, just in case.
Other effects:
- Background jobs will be slower and some may be dropped. Red links might not be updated as quickly as normal. If you create an article that is already linked somewhere else, the link will stay red longer than usual. Some long-running scripts will have to be stopped.
- There will be code freezes for the week of September 1st, 2020. Non-essential code deployments will not happen.
This project may be postponed if necessary. You can read the schedule at wikitech.wikimedia.org. Any changes will be announced in the schedule. There will be more notifications about this. Please share this information with your community.
U.S. copyright of 1929 book
Author:Axel Munthe (1857–1949) wrote The Story of San Michele (1929). Now that he's been dead for 70+ years, and the book is out-of-copyright in Europe and already online at another website, what about the U.S. copyright? Is there a chance that it was never renewed, and the book is free enough for Wikisource? Or should we wait 4 or 9 more years? --LA2 (talk) 20:27, 26 August 2020 (UTC)
- According to this page, The Story of San Michele was first published in 1929 in the United Kingdom. As that work was still in copyright in that country as of the URAA date, the copyright in the United States, (which is what matters for inclusion on English Wikisource,) was extended to 95 years after the original publication of the book. The work will be eligible for inclusion here in five years. TE(æ)A,ea. (talk) 21:08, 26 August 2020 (UTC).
Image template
On Wikispecies, species:Template:Image calls the primary image for the subject, from Wikidata. It can be added to articles and will not show, if Wikidata has no image, but once an image is added at Wikidata, it shows on the page. The Wikidata image can still be overridden with a local value.
I think such a template would be useful here, for author pages. Can someone import it? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:48, 22 August 2020 (UTC)
- {{Author}} is supposed to do this already. Beeswaxcandle (talk) 03:47, 25 August 2020 (UTC)
- Fair enough. What about portal pages? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:16, 25 August 2020 (UTC)
- ...or works? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:40, 28 August 2020 (UTC)
- For people in the Portal namespace, {{person}} works in the same method as does {{Author}}. Images are only sparingly used elsewhere. TE(æ)A,ea. (talk) 21:20, 28 August 2020 (UTC).
The years of registration vs. publication of the United Nations Treaty Series since Volume 401
Anyone interested in the United Nations Treaty Series? I just found that since Volume 401, each cover displays a year, likely when it was published. This is different from the year when any treaty was registered with the Secretariat of the United Nations. See also commons:Commons:Village pump#The years of registration vs. publication of the United Nations Treaty Series since Volume 401 where I request comments before re-categorizing File:UN Treaty Series - vol 402.pdf to File:UN Treaty Series - vol 599.pdf Please comment as I also plan to redesign the table at [[United Nations Treaty Series.--Jusjih (talk) 04:32, 28 August 2020 (UTC)
epub export only targeting the page rather than whole book
Hi there,
The epub export links on the of the .en books I have set up here seems to be exporting only the top level page, rather than the whole book. The contents page is on the index page, which seems to be required by the export tool.
In contrast, the books at .la Wikisource are exporting fine, with what looks like the same request to the same WSexport tool, so this is very strange. Any ideas? Are people seeing the same thing?
Examples: la:Easy Latin Stories and Key to Easy Latin Stories for beginners.
Thanks for any help you can give! JimKillock (talk) 08:11, 28 August 2020 (UTC)
- @JimKillock: Try it now. And a question for you. Is that a real ToC from the published work, or is that one that you created to fill a void?
- Thank you; this is working now. In fact I don't think it was broke, I got confused by the fast response and small file size.
- The ToC is indeed one I created in order to make the epub export work (the epub export won't work without a ToC on the initial page AIUI). I did put this on the front page, rather than the source, and then moved it to a blank page in case this made a difference with the epub export, and left a note at the source page to this effect. I will move it back, let me know what best practice is here (the source page can't fully refect the sourece without breaking the export function). JimKillock (talk) 13:05, 28 August 2020 (UTC)
- @JimKillock: The local style for constructed ToC is to apply it directly to the root page of the work and to wrap it in {{AuxTOC}}, not to imply that it was in the work by transcluding it. — billinghurst sDrewth 13:52, 28 August 2020 (UTC)
- Thanks @Billinghurst: that's done JimKillock (talk) 14:29, 28 August 2020 (UTC)
- @JimKillock: The local style for constructed ToC is to apply it directly to the root page of the work and to wrap it in {{AuxTOC}}, not to imply that it was in the work by transcluding it. — billinghurst sDrewth 13:52, 28 August 2020 (UTC)
The score extension is still disabled
Despite the fact that phab:T257066 is marked as “resolved,” the issue still remains. Is there anyone who can edit that page to correct this? It’s been meaning to proofread some music, but have been unable to do so. TE(æ)A,ea. (talk) 15:16, 26 August 2020 (UTC).
- Note, the ticket has been reopened. —Beleg Tâl (talk) 01:52, 30 August 2020 (UTC)
CSS and Width in MediaWiki:Proofreadpage_index_data_config
Hi. I am sysop at Spanish Wikisource. I've noticed that in your index forms there are this two fields we currently don't have: CSS and width. I have some questions, if someone is kind enough to answer them.
- Do they actually work as intended?
- Where are they documented?
- How can I export them to my local Wikisource?
Thanks in advance, --Ignacio Rodríguez (talk) 23:28, 30 August 2020 (UTC)
- @Ignacio Rodríguez: From memory you just need to add them into place in your config. These are already defined as part of the extension and it is up to the projects to add and name/translate as needed, explained at mul:Wikisource:ProofreadPage/Improve index pages. — billinghurst sDrewth 23:46, 30 August 2020 (UTC)
- @Billinghurst: Thanks! The extension page at mediawiki is very lacking in this things! --Ignacio Rodríguez (talk) 23:53, 30 August 2020 (UTC)
Linking to external audio recording of song
I'm coming from en-WP, and just created my first Wikisource page, Hail, Pomona, Hail, the alma mater of Pomona College. There's an audio recording of the song from a 2000 Pomona College Glee Club performance here; I assume we can't embed that for copyright reasons, but would there be a way to include it as an external link? Sdkb (talk) 19:12, 31 August 2020 (UTC)
- @Sdkb: Not a straight, yes/no. If there is an out of copyright version, please download it and stick it at Commons, then utilise {{listen}}. If it is in copyright and hosted by copyright owner, and on an existing article, then we would allow it from within the "notes" section, as such we allow a soft "external links". If a work is in copyright, and someone is breaching copyright, no. Sounds like you fall into a permissible "yes". — billinghurst sDrewth 21:47, 31 August 2020 (UTC)
- Thanks; I just added it. Sdkb (talk) 21:52, 31 August 2020 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Problems
- This is a reminder. All wikis will be read-only for a few minutes on September 1. This is planned between 14:00 and 15:00 UTC. Please check on the details on the announcement message. [16][17]
Changes later this week
- There is no new MediaWiki version this week.
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
20:11, 31 August 2020 (UTC)
Alternative solution to preferences previously stored in cookies
How can I fix the Charinsert display order, so that the "User" definition is the displayed definition? — Ineuw (talk) 00:53, 29 August 2020 (UTC)
- Usually the dropdown stays for whichever was last opened. — billinghurst sDrewth 07:32, 30 August 2020 (UTC)
- @Billinghurst: Thanks. This is so only for the current session and does not always work. I wonder what possible technical reason was this omitted from Wikisource cookies? After all, the browser is inundated with Wikisource cookies. Wouldn't care if I could add the current copy of Charinsert to my namespace, but my attempt failed. The advantage would be is to set User: as the first entry, and reorder/customize the list. — Ineuw (talk) 14:32, 1 September 2020 (UTC)
- It works for me, and is persistent as best as I see. — billinghurst sDrewth 14:34, 1 September 2020 (UTC)
- And I not see that "User" is the best option as most will not use it. — billinghurst sDrewth 14:36, 1 September 2020 (UTC)
- It works for me, and is persistent as best as I see. — billinghurst sDrewth 14:34, 1 September 2020 (UTC)
- @Billinghurst: Thanks. This is so only for the current session and does not always work. I wonder what possible technical reason was this omitted from Wikisource cookies? After all, the browser is inundated with Wikisource cookies. Wouldn't care if I could add the current copy of Charinsert to my namespace, but my attempt failed. The advantage would be is to set User: as the first entry, and reorder/customize the list. — Ineuw (talk) 14:32, 1 September 2020 (UTC)
Bibliographic data: OCLC, ISSN, DOI, LCCN codes
The related discussion has developed in the article tilted Index talk:On the Atmospheric Bude-Light.pdf. Wikidata elements allow user to add an OCLC code, but the association of the bibliographic data isn't automated nor it is always imported from external databases.
It concerns the verifiability of the cited sources as usually required on Wikipedia and Wikiquote projects. Probably, there exists also on Wikisource a similar policy for which anyone can verify the source as well the exact correspondance of electronic/digitized copies to the related original paper formats and manuscripts. It is a useful information in order order to prevent pages omissions or image editing that interest from third-party sponsorized works with an internal conflict of interest.
According to the CC-BY-SA license, anyone could reproduce or manipulate the original texts for an original and creative work. Users have the right to be acknowledged on what they are looking for: if it is a copy closely compliant with the original readable in an university library or in a public one, versus something of manipulated or not yet integral.Philosopher81sp (talk) 18:47, 30 August 2020 (UTC)
- @Philosopher81sp: The data that you identify belongs at Wikidata, and it is added locally through the application of {{authority control}} to the work. The issue for much of what we do is that we work with old editions of works, and many of these works pre-date those major categorisation aspects, also to add to that is that we work with editions, not with the works, and the databases are not so useful about differentiating between the two. I am unaware of a bot that does this.
With regard to verification, we require sources to be added, typically where we are working with scans, that is self-evident and the Commons file will be sourced. If there is no scan to support, then we require source data to be added using {{textinfo}} on the talk page of the work. — billinghurst sDrewth 23:01, 30 August 2020 (UTC)
- yes, Template:At, effectively the codes as in object mainly identify a title and not a specific edition. The code is a starting point for more accurate informations in order to identify a single edition.
However, a more complete set of bibliographic data can supply to that problem. The Commons file doesn't ensure the scanned copy is philologically faithful to the original primary source (paper or manuscript). If I Just remember, the CC-BY-SA gives anyone the right ti manipulate the original work, to omit some parts, e.g. to create a new original work, even for commercial purposes. The author isn't obliged to explain his innovations in respect of the primary source. But this would be of great interest for this project. Readers think to have a full and integrale digitized Copy of an original paper or manuscript. It's reasonable to Imagine they also want ti know where the single scanned edition is physically located and can be seen, even by specialists. I think people providing a scanned copy and the related Commons file can easily upload on Wikidata or in the article of Wikisource, metadata like: pages of each volume, Place and date of publication, the imprinter /typographer, the people to whom the questioned work has bene dedicated. A similar set of informations is adequate to univocally identify a single edition and enable any user (if provided of the necessary rights) to access and verify the primary source, a paper copy or a manuscript. Thanks for your reply.13:55, 1 September 2020 (UTC)
- Not certain what you are wanting. The edition/version metadata lives at Wikidata, the transcript belongs here. Whilst we have a CC-by license, we aim to truthfully reproduce a work, so what can be done to a work is irrelevant to the work that we are doing to reproduce it. What someone does to our works after they leave is their business, not ours.
Request to shorten this hideously long file name.
See Index talk:A pronouncing and defining dictionary of the Swatow dialect, arranged according to syllables and tones.djvu#Title of the book; c:Commons talk:File renaming#Renaming a file to have a shorter name?.
The file on Commons has already been renamed. Suzukaze-c (talk) 09:22, 22 August 2020 (UTC)
- 👋 Suzukaze-c (talk) 05:09, 14 September 2020 (UTC)
- Better if someone makes a bot to quickly move everything. If this request is not done in a timely matter, the file on Commons may have to be reverted to display related pages/transclusions, like what once happened to File:UNTS 1.pdf--Jusjih (talk) 23:49, 25 September 2020 (UTC)
- Done for Index/Page and transclusion. It is not clear if also Main ns pages shall be renamed. Pls clarify.Mpaa (talk) 10:09, 3 October 2020 (UTC)
- Better if someone makes a bot to quickly move everything. If this request is not done in a timely matter, the file on Commons may have to be reverted to display related pages/transclusions, like what once happened to File:UNTS 1.pdf--Jusjih (talk) 23:49, 25 September 2020 (UTC)
- @Mpaa: Yes, the Main pages should be renamed too. Suzukaze-c (talk) 03:42, 7 October 2020 (UTC)
- @Suzukaze-c: Done. Mpaa (talk) 09:34, 7 October 2020 (UTC)
- @Mpaa: Wonderful; thank you so much! Suzukaze-c (talk) 06:35, 8 October 2020 (UTC)