Wikisource:Scriptorium/Archives/2017-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. |
Announcements
Proposals
Bot approval requests
Repairs (and moves)
Other discussions
A question about the random work search
Whenever I use "Random work", it always searches the main namespace. Is there a way to limit random searches to the Page namespace? Perhaps someone already has a script to accomplish this? . . . OR, perhaps t is available but I missed a setting somewhere? — Ineuw talk 22:32, 1 August 2017 (UTC)
- I think you are looking for Special:Random/Page —Beleg Tâl (talk) 23:18, 1 August 2017 (UTC)
- Thanks for the reply, but this also reverts to works in the main namespace. I suspect the two are the same.:-( — Ineuw talk 02:23, 2 August 2017 (UTC)
- There's a link on WS:PotM that gives a random proofread page for validating. See if you can version that to do what you want. Beeswaxcandle (talk) 07:19, 2 August 2017 (UTC)
- Beleg Tâl's link works for me as expected (10 from 0). This was fixed ages ago, see mw:Help:Random page, mw:Manual:Random page and mw:Extension:Random pages. — billinghurst sDrewth 13:52, 2 August 2017 (UTC)
- Thanks to everyone for the help, especially to the editor/programmer who added 'Random transcription' to the sidebar. That is exactly what was wanted. — Ineuw talk 18:32, 2 August 2017 (UTC)
Cutters Practical Guide
http://45.33.57.149/wiki/History100pages1893to1898cuttersguide
Can someone that's good with DJVU PLEASE consider grabbing the Hi-res JPG's and making a suitable Djvu?
The Part 1 I am working from on Wikisource isn't that clear in places compared to the scans on the the linked site. Index:The Cutter's Practical Guide 1898 Edition Part 1.djvu
Also Index:The Cutter's Practical Guide Part 13.djvu exists on Wikisource, but again comparison of scan quality would be appreciated.
Plus there are a number of other parts!! (Want an entire tailors manual very nearly? ;) ) ShakespeareFan00 (talk) 21:48, 2 August 2017 (UTC)
- might not need djvu conversion. you could download; stitch together with http://scantailor.org/ ; upload to internet archive; and upload to commons using IAuploader.
- in the meantime, volume 13 is done, you could snip the images for that one, and upload to commons and finish that one.
- i’m kinda buried until after wikimania. sorry Slowking4 ‽ SvG's revenge 22:02, 2 August 2017 (UTC)
Moving file File:AEW Mason--The affair at the Semiramis Hotel.djvu to wikisource
(I hope this is the right place for the request). I just realized after importing the text to Wikimedia that the author (A E W Mason) is still under copyright as far as Wikimedia is concerned (deathyear 1948 + 70 yrs). Can it be moved to WS? Or, alternatively, be deleted from WS and WM? Thanks —Akme 12:31, 1 August 2017 (UTC)
- @Akme: To move a file to local, you need to do two things: 1. Upload the file directly to Wikisource. 2. Use the template commons:Template:Copyvio on the file that you uploaded to Commons so that it will be deleted there.
- However: are you certain that this text is still under copyright? The rules for Commons are: 1. The file must not be copyright in the United States, and 2. The file must not be copyright in the source country (or countries), where it was first published. This file is not copyrighted in the United States because it was published in 1917. The work was published in New York, so we need to ask: was it published in a different country at the same time, or earlier, than the one you uploaded? I googled the work, and I did not see any information saying it was published elsewhere. Therefore the United States is the only source country. Since it is not copyrighted in the United States, this work meets both rules for hosting on Commons. You do not need to delete or move the file. —Beleg Tâl (talk) 13:52, 1 August 2017 (UTC)
- Thanks you! Looks like I haven't read the act properly. I didn't know that where the work was first published had a bearing on non-US authors' works. Thanks again :) —Akme 14:04, 1 August 2017 (UTC)
- a cursory search of worldcat [1] indicates new york edition, but not british edition (confused by epublisher showing original date) saved again by the pre-1923 for yanks. as you were. Slowking4 ‽ SvG's revenge 22:19, 2 August 2017 (UTC)
- Thanks you! Looks like I haven't read the act properly. I didn't know that where the work was first published had a bearing on non-US authors' works. Thanks again :) —Akme 14:04, 1 August 2017 (UTC)
- @Akme: Done. Please update the file locally, and add {{do not move to Commons|expiry=2019}} — billinghurst sDrewth 08:21, 3 August 2017 (UTC)
- Will do, thank you. But I'm really confused now:) — I really thought Beleg Tâl's explanation meant that the file was not under copyright where Commons was concerned. But thank you, anyway. —Akme 08:33, 3 August 2017 (UTC)
- Trust deficit for Commons. We host it and in 2019 we move it, no hassles. — billinghurst sDrewth 13:33, 3 August 2017 (UTC)
- Will do, thank you. But I'm really confused now:) — I really thought Beleg Tâl's explanation meant that the file was not under copyright where Commons was concerned. But thank you, anyway. —Akme 08:33, 3 August 2017 (UTC)
Concerns about ability (lack of progress on certain issues) etc.
Owing to certain technical issues in formatting something, I am considering an extended absence, on the ground that if I continue at this point, I am going to get slowly more and more frustrated with the apparent inability of mediawiki to behave in what might be considered a consistent and intuitive way when it comes to certain formatting considerations, and transclusions.
Perhaps I will reconsider if there's a step change in the response to a number of issues (which have been placed on a low priority by certain developers and contributors), and appropriate hard lobbying for a re-write of proofread page, so that there is no longer a need for the various "hacks" and "clever" work-arounds that have been developed over the last decade, which in an increasing number of areas fail to address the issue that parts of core mediawiki were never apparently designed for the technical challanges of massive-multiple block constructions that use things like table, lists and complex formatting which need to span over a number of these blocks.
The embedding of header/footer/page quality data within a page text is also not ideal, and to my mind portions of (but not limited to the) parser, editing tools, Proofread page and Listed section Transclusion need to be fundamentally re-written, so that I and other contributors aren't every few months trying to figure out what obscure quirk or work-around needs to be used on a very specfic instance this time.
Congratulations, you have potentially lost a long-standing contributor, owing to a noticeable lack of progress on fixing a bad ceiling with a well-aimed sledgehammer, rather than just merely tinkering with the collapsing plaster. ShakespeareFan00 (talk) 16:29, 3 August 2017 (UTC)
Additionaly, The following gadget " Generate paragraph (pilcrow) markers, ¶ , in the left margin of the Page: namespace to indicate HTML paragraph tag starts. ( IE7 and lower not supported )" no longer works when editing for me under certain circumstances, which would have been rather useful in trying to diagnose where the parser THOUGHT (and where it actually was) it was putting white-space in some works.
I don't for example see any of the relevant marking when viewing this page: https://en.wikisource.org/wiki/Page:The_Cutter%27s_Practical_Guide_1898_Edition_Part_1.djvu/18 which suggests that the Gadget isn't aware or can't cope with multiple columns. I am also suspecting a conflict with another script, but testing every single pair of gadget and script interactions is more effort then I feel confident in undertaking right now.
If things don't improve, I will consider reverting the entire layout to a single column one, on the basis that the mutli-column support is STILL a bit experimental, and a layout not using it should have minimal issues with respect to the current apparently "broken" combination of Parser,Proofread page, LST and other scripts etc.
I've also noted that it's not possible to easily find out which pages I validated specifically, without reading (or re-reading the history of every single page I've edited nearly.). This is highly inefficient waste of time, although in the process of re-reading some earlier efforts, I've HAVE found and hopefully eliminated a number of OCR and typing errors that had been regrettably missed on a less than perfect first pass. I can get a list of pages I have at one time edited that NOW have validated status, but it doesn't seem to be possible to easily generate a list of those I specifically marked as being validated (in some instance prematurely as others have commented). I have recently raised a Phabricator ticket about this (albiet on a Low priority). At the last query I had contributions to about 30,000 or more pages which are now nominally validated. It's simply not feasible to re-read that many pages, and certainly not to a "perfection" standard as is now demanded, in any available time-scale.
When I started editing on Wikisource, it was a "nice" project. Over time I get the impression there is now a move towards a more "professional" and possibly "commericaly-focused" attitude, This isn't of itself a bad thing, but it means that the tolerance level has decreased to such an extent that contributors like myself don't feel as welcome.
So the standard question, Where from here? ShakespeareFan00 (talk) 18:48, 3 August 2017 (UTC)
- I didn't add my first response, it was blunt. So some answers
- We have always professed that we want better proofreading, this was the prime reason for moving to scans with Page: ns.
- We would like it right at the occasion that it is proofread
- We want it right by validation
- If a person thinks that an initial pass is required and/or they are not paying full attention then don't advance the proofreading marker. It is that simple. Each of us needs to take our ego out of proofreading, and just look to do a better job.
- Don't use multi-columns, that has been our instruction for a long time. So please stop it.
- We are bringing old books to the web, and the web means wide screens, and it means mobile devices. Getting hung up on a 19thC representation of a piece of paper is ridiculous. Stop it.
- We get limited developer time. We all had an opportunity to put forward our ideas, and we voted on our (WS) priorities.
- Mediawiki is less than perfect, sure, but it is our tool at WMF. It is nowhere as problematic as you make it out, and IMO half of your issues are that you make it harder than it needs to be.
- Complex templates are problematic for standard proofreaders
- Where you choose a complex methodology, you cannot expect others to fix it when you run into problems; and getting cranky about it ... well ... how to win friends and influence people.
- Do as much as you enjoy, and when it becomes troublesome take a break, or do something different, it is what the rest of us do. It is meant to be fun for ourselves, and for others. Don't be a diva.
- We have always professed that we want better proofreading, this was the prime reason for moving to scans with Page: ns.
- — billinghurst sDrewth 23:29, 3 August 2017 (UTC)
- I'll also add, as I briefly mentioned on the Help page, that if you are having trouble with the behaviour of the parser or gadgets like Easy LST your best bet is to raise the issue at Phabricator. I don't think there's anyone here on WS with the ability to fix problems like this. —Beleg Tâl (talk) 01:12, 4 August 2017 (UTC)
- As a mild aside if some administrator type could edit MediaWiki:Gadget-pilcrowMarkers.css and either modify existing line:
body.ns-104 div.pagetext > p:before {
- to instead read:
body.ns-104 div.pagetext div.mw-parser-output p:before {
- OR
body.ns-104 div.pagetext p:before {
- I think this might address the basic problem. 101.174.193.14 07:16, 4 August 2017 (UTC)
- i would say taking breaks should be a part of your standard practice. you should also consider reducing your expectations. this is an open code project, with all that entails. it is a miracle it works at all. UX and code improvement requires working in a collaborative manner. the squeaky wheel may not always get the grease. (people suggest i use scripts to customize, but i do not, because KISS; and they are broken by others; and serious flaws in workflows should be part of code review, rather than worked around.) Slowking4 ‽ SvG's revenge 13:33, 4 August 2017 (UTC)
- @ShakespeareFan00:In the meantime, I replaced the line:
body.ns-104 div.pagetext > p:before {
- to read:
body.ns-104 div.pagetext div.mw-parser-output p:before {
- Please test it if it works. — Ineuw talk 18:37, 4 August 2017 (UTC)
Pilcrow's now display on single columnular layout Page:The Cutter's Practical Guide 1898 Edition Part 1.djvu/28 which I am cleaning up the relevant work to.
They don't look right if div col is used see-https://en.wikisource.org/w/index.php?title=Page:The_Cutter%27s_Practical_Guide_1898_Edition_Part_1.djvu/48&oldid=5389753, for example, they display, but the pilcrows are overlaid on the left hand side. This however was expected, and resolving the compatibility issue fully is perhaps irrelevant as I am converting the work to a single column per advice I was given above. Thanks for the fix :) ShakespeareFan00 (talk) 18:44, 4 August 2017 (UTC)
Index:Lives of Fair and Gallant Ladies Volume II.djvu
Just checking my edit history, and it says I made an edit on the Index page. Here: https://en.wikisource.org/w/index.php?title=Index%3ALives_of_Fair_and_Gallant_Ladies_Volume_II.djvu&action=historysubmit&type=revision&diff=6953049&oldid=6184510 Must have been an error, because I don't remember editing the Index page on this one. But it also won't let me revert myself. It says that's already done. But can someone please check to see if I messed up that Index page, please?
Also, since Wikimedia started rolling out its changes a month or so ago, major issues for what I see across Wikimedia sites. Browser incompatibility (and not just my Firefox) On Wikisource, it's usually just having to reload, Show Preview, reload again, Show Preview again, before all the tools load on the left. Save that edit, and do the whole routine over again on the next page. Not your fault, but it takes 3-6 times as long to validate one page. And, yeah, the browser incompatibility been discussed with me over at Wikipedia's Village Pump. Maile66 (talk) 21:49, 4 August 2017 (UTC)
- I've noticed this happening since the the Index edit interface changed in mid-July. The first one in my history is July 11. It seems that after some update in mediawiki, the first person who began to edit a page associated with an index page thereby caused an edit in index page itself. So you can see the edit I actually made and the one that occurred just before in the index page. Mudbringer (talk) 21:33, 5 August 2017 (UTC)
- Some of the "edits" are the result of the system making null edits to correct issues caused by earlier versions of the interface. This is why removing a blank line in the Index page shows up as removing 264K. There's a lot of hidden garbage in some of our pages that gets cleaned up as we go. An edit on a page associated with an Index causes the Index to be cleaned up of some of these known problems automagically. --EncycloPetey (talk) 21:37, 5 August 2017 (UTC)
- Thank you both. I sometimes make null edits on index pages, so I probably did that on this one. Maile66 (talk) 23:12, 6 August 2017 (UTC)
- @Maile66: I am not seeing your issues. It is quite possible that your common.js file is at issue, or and the gadgets that you are using. Try nulling out the loaded element in the file to see if it makes a difference. — billinghurst sDrewth 01:19, 7 August 2017 (UTC)
- @Billinghurst: Thanks for replying, but I was just venting my frustrations about browser incompatibility. Believe me, it's Firefox and the technical changes Wikimedia is rolling out. On almost the exact date Wikimedia began the roll outs, Firefox updated to a new version. I've already been through this on the Village Pump over at English Wikipedia. Wikimedia has someone on their team with Firefox, and they got the same flubs. When it first happened, I removed all scripts, and it made no difference. It's all the sites now. Hopefully, Firefox and Wikimedia will eventually have a harmonic convergence, and this will go away. Maile66 (talk) 16:08, 7 August 2017 (UTC)
- @Maile66: I am not seeing your issues. It is quite possible that your common.js file is at issue, or and the gadgets that you are using. Try nulling out the loaded element in the file to see if it makes a difference. — billinghurst sDrewth 01:19, 7 August 2017 (UTC)
- Thank you both. I sometimes make null edits on index pages, so I probably did that on this one. Maile66 (talk) 23:12, 6 August 2017 (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
- You can now see which Wikipedia language versions are read in a specific country. This tool is called Wikipedia Views Visualized. [2]
- The Architecture Committee is now the Wikimedia Technical Committee. You can read the charter. [3]
Problems
- You can get an email when a page on your watchlist was edited. You can choose not to get emails for minor edits. There is a bug that means that you then don't get an email when someone does a normal edit after a minor edit. The developers are working on fixing this. Until it has been fixed you can activate "Email me also for minor edits of pages and files" at the bottom of "User profile" in your preferences if you want to. [4]
- The thanks button sometimes didn't work for mobile users. This was because of a new bug and has now been fixed. [5]
Changes later this week
- The new version of MediaWiki will be on test wikis and MediaWiki.org from 8 August. It will be on non-Wikipedia wikis and some Wikipedias from 9 August. It will be on all wikis from 10 August (calendar).
Future changes
- Editors and readers who still use Internet Explorer 8 on Windows XP will not be able to use Wikipedia. Internet Explorer 8 on Windows XP can't connect securely to the wikis. When we allow them to do so it means that we get less security for everyone else. If you use Internet Explorer 8 on Windows XP you can install Firefox 52 ESR instead. Around 0.1% of the traffic to the Wikimedia wikis comes from Internet Explorer 8 on Windows XP. [6]
- Links to sections on Wikipedia don't work well in languages that don't use the Latin script. The URL in the address bar in your browser shows Latin characters like
.D0.A1.D1.81.D1.8B.D0.BB.D0.BA.D0.B8
instead of the section heading in the wiki's language. Links to sections in non-Latin scripts will be in the script of that wiki in the future. This will happen in the next few months. [7][8] - Wiki pages printed by the web browser "Print" function will have an updated style. This new style will be similar to the when you download a page as PDF. It will be better at showing tables, infoboxes and headings. [9][10]
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
21:45, 7 August 2017 (UTC)
Share your thoughts on the draft strategy direction
At the beginning of this year, we initiated a broad discussion to form a strategic direction that will unite and inspire people across the entire movement. This direction will be the foundation on which we will build clear plans and set priorities. More than 80 communities and groups have discussed and gave feedback on-wiki, in person, virtually, and through private surveys[strategy 1][strategy 2]. We researched readers and consulted more than 150 experts[strategy 3]. We looked at future trends that will affect our mission, and gathered feedback from partners and donors.
In July, a group of community volunteers and representatives from the strategy team took on a task of synthesizing this feedback into an early version of the strategic direction that the broader movement can review and discuss.
The first draft is ready. Please read, share, and discuss on the talk page. Based on your feedback, the drafting group will refine and finalize this direction through August.
SGrabarczuk (WMF) (talk) 16:11, 8 August 2017 (UTC)
RL sidenote
In the past, {{RL sidenote}} was supposed to display a sidenote in the right margin in the Page namespace, but a left sidenote in the Main namespace. However, as you can see comparing Page and Main, the template is displaying a right-margin sidenote in both namespaces now. --EncycloPetey (talk) 21:24, 11 August 2017 (UTC)
- That's in Layout 2. Sidenotes have different behaviours in the various Layouts. Beeswaxcandle (talk) 21:53, 11 August 2017 (UTC)
- Hmm. I just noticed that {{left sidenote}} also displays to the right, at least in Layout 2. Is this documented anywhere as expected behavior? According to Help:Layout sidenotes should appear on the left and right, and IIRC they used to do so. Has the layout been changed to force sidenotes to the right? --EncycloPetey (talk) 22:07, 11 August 2017 (UTC)
- Comment do you mean {{outside L}} and {{outside RL}}? — billinghurst sDrewth 08:57, 12 August 2017 (UTC)
- No, I do not. --EncycloPetey (talk) 14:25, 12 August 2017 (UTC)
- Comment note that the "sidenote" templates have hard-coded formatting classes that align with code in MediaWiki:Gadget-PageNumbers-core.js. I would hazard a guess that we are at the consequence of template and GOIII's css coding. This should all be part of our review when we get template style sheets. We will seriously need help of someone competent. @Samwilson: maybe you can find someone at Wikimania with css skills who may have an interest in helping us sort out our lost ways. — billinghurst sDrewth 09:03, 12 August 2017 (UTC)
- @Billinghurst: I'll ask around! The problem doesn't seem to be in {{RL sidenote}}, but rather that a left sidenote is displaying at the right in mainspace. Which as you say is because of that javascript. It seems to be styling them both the same, e.g. for layout 2:
'.sidenote-right':"position:absolute; left:37em; width:16em; text-indent:0em; text-align:left;", '.sidenote-left': "position:absolute; left:37em; width:16em; text-indent:0em; text-align:left;",
Is that desired? Should the latter of those be left:-37em
? This is all rather complicated! :-)
—Sam Wilson 11:02, 12 August 2017 (UTC)
Wikipedia translations
We have some translations of non-English texts that were created on Wikipedia by their own editors. It seems to me that current practice is to put these translations in Translation namespace, which labels them as translated by Wikisource (as opposed to translated by Wikipedia). I just want to confirm: is this the best practice? and if so, should the translation header be updated to allow attribution of WP—or are we sufficiently integrated with WP that the distinction doesn't matter? —Beleg Tâl (talk) 14:59, 8 August 2017 (UTC)
- Possibly relevant: w:Wikipedia:Copying within Wikipedia —Beleg Tâl (talk) 12:45, 15 August 2017 (UTC)
- I would think that we could capture on the notes page using {{textinfo}} and the use of the edition parameter — billinghurst sDrewth 13:19, 15 August 2017 (UTC)
A template that links to the Index page without transcluding anything
I seem to recall seeing a template somewhere, which one would use in Mainspace to trigger the "Source" tab and other ProofreadPage items even if no transclusion were actually taking place. (This would be used for works with no front matter, such as The Holly & the Ivy, and Twelve Articles.) Does anyone know if this template is real, and what it is? —Beleg Tâl (talk) 21:44, 13 August 2017 (UTC)
- @Beleg Tâl: I did some trial edits through there yesterday(ish). — billinghurst sDrewth 06:04, 15 August 2017 (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
- Bureaucrats can now set users as confirmed. Previously only stewards could do this on most wikis. Nothing will change for wikis that have previously decided to let administrators set users as confirmed. [11]
Problems
- The symbols in the language list that show that an article is good or featured in that language doesn't work. Links to the Commons category in the sidebar doesn't work either. The developers are working on fixing it. [12][13]
Changes later this week
- The new version of MediaWiki will be on test wikis and MediaWiki.org from 15 August. It will be on non-Wikipedia wikis and some Wikipedias from 16 August. It will be on all wikis from 17 August (calendar).
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
23:28, 14 August 2017 (UTC)
Timeless skin in beta very soon
A while back we agreed to trial the skin "Timeless" to identify its ability to work at Wikisource, especially in the ProofreadPage environment. The talk is that this will be with us soon. — billinghurst sDrewth 06:04, 15 August 2017 (UTC)
Pl. do suggest Commerce, economic, and law pages for proof reading for academic project
Hi,
MES, Garware College Pune is planning to take up a wikisource proof reading as an academic project mainly at mr.wikisource. Depending on students liking proofreading responsibility may be given on en wikisource transcription project.
Pl. do suggest Commerce education , economic, and Commercial Indian law pages for proof reading for academic project for first year B.Com. students.
Pl do note students may not have detail previous exposure to wikipedia or wikisource. Edits in first training workshop scheduled 18 August 2017 may happen from ip address-even may be dynamic one. User accounts will get opened over next week or so.
known ip addresses will be informed at https://phabricator.wikimedia.org/T173487
Thanks for community co-operation.
Mahitgar (talk) 08:50, 17 August 2017 (UTC)
Update logo
I would like to start discussion or voting whether to update Wikinews logo so it uses PNG rendered from File:Wikisource-logo-fr.svg. There is a task on Phabricator, so local community should say whether they agree or disagree with this. Thanks. --Obsuser (talk) 20:32, 2 August 2017 (UTC) [e]
- @Obsuser: I assume you mean 'Wikisource' and not 'Wikinews'? :) What's the rationale for proposing the change? What are the actual changes? (For ease of reference here, the proposed change is from this to this.) Personally, I prefer the existing one (a bit darker, and with slightly bolder text). Sam Wilson 23:21, 2 August 2017 (UTC)
- Yes. Reason is to have all SVGs used for generated PNGs. OK, I will correct it so that it is has bolder text (I don't see that it is darker; File:Wikisource-logo.svg is supposed to be used). There are no actual content changes, that's why affirmation is just formal. Are there any other objections? --Obsuser (talk) 10:56, 3 August 2017 (UTC)
- not supported Seems pretty pointless to me (even after reading the Phabricator task). The current one is just fine. Beeswaxcandle (talk) 07:13, 4 August 2017 (UTC)
- As I explained on en:Wikinews:Water cooler/technical#Update logo, it is not pointless. Currently, it is not possible to have logo with icon placed exactly same on all Wikisource language editions; specifically, I want to update also sr.wikisource logo and to have same icon on same position with text changed only (other Wikisource projects will probably have to do this some time in the future). Other reason for update is to have clear SVG used to create PNG, what will also enable translation into other languages (PNG is not properly or anyway translatable). --Obsuser (talk) 09:33, 9 August 2017 (UTC)
- comment still using File:Old Wikisource logo used until 2006.jpg. square versus round. Slowking4 ‽ SvG's revenge 12:23, 4 August 2017 (UTC)
- Support. My own philosophy is to support initiatives unless there's a good reason not to. However I must add that this also seems pointless to me, and I would like some more information on this proposal. First: why would we want to replace the PNG logo with a SVG logo? Would there be any observable difference to the site at all if the PNG logo were replaced with an identical PNG thumbnail of a SVG logo? Second: why would we use a thumbnail generated from File:Wikisource-logo-fr.svg with its slightly different colour scheme, when we could create a new File:Wikisource-logo-en.svg that is visually identical to the current one? —Beleg Tâl (talk) 17:53, 4 August 2017 (UTC)
- Thank you. I explained above that it is very useful to have SVG used for creating PNG and enable translation of text only. PNG logo will not be replaced with SVG; as you said in the next sentence, PNG [static] image will be created from SVG, and even if there is no observable difference to this language wiki it will be useful for other Wikisources. I don't see "different colour scheme" in File:Wikisource-logo-fr.svg (for icon, File:Wikisource-logo.svg should and is used everywhere). Only difference to the current logo is the font which is a bit thicker, and I will shortly try to recreate it so that it is same as current one. --Obsuser (talk) 09:33, 9 August 2017 (UTC)
- The colours look the same in Chrome for some reason, but they are different in Firefox. See also Samwilson's post below. —Beleg Tâl (talk) 16:22, 9 August 2017 (UTC)
- Thank you. I explained above that it is very useful to have SVG used for creating PNG and enable translation of text only. PNG logo will not be replaced with SVG; as you said in the next sentence, PNG [static] image will be created from SVG, and even if there is no observable difference to this language wiki it will be useful for other Wikisources. I don't see "different colour scheme" in File:Wikisource-logo-fr.svg (for icon, File:Wikisource-logo.svg should and is used everywhere). Only difference to the current logo is the font which is a bit thicker, and I will shortly try to recreate it so that it is same as current one. --Obsuser (talk) 09:33, 9 August 2017 (UTC)
- I definitely support the idea of generating the PNG version of the Wikisource logo from an SVG file, but I don't really see that the file in question above (which isn't even named correctly) is ready yet to be the replacement. The font is different, and so are the colours (the existing background blue is #375493, but the proposed one is #225991). I know these are small changes, but I really don't think we want to have different versions of the logo (e.g. there are lots of other places that use the logo that we can't control, e.g. exported epubs).What's the history of the current logo, and why don't we have the original vector source for that?Sam Wilson 10:32, 9 August 2017 (UTC)
- Color is same; I downloaded file from Chrome and Firefox and got #375493 in both cases for both versions (Adobe Illustrator eyedropper).
- I will try to fix font and update the proposed file to match current version in the next few days.
- I don't know the history of the current logo nor where is original vector source... It would be best if someone could find original SVG or tell who created it, then there would be no need for updating here because translation would be possible. --Obsuser (talk) 01:54, 10 August 2017 (UTC)
- The original file appears to be File:Wikisource-newberg-de.png; both File:Wikisource-logo.svg and File:Wikisource-logo-fr.svg are direct derivatives from it by the original creator, User:Zanimum. @Zanimum: your input here would be valuable. —Beleg Tâl (talk) 12:46, 18 August 2017 (UTC)
- So, basically I was at college one day, saw about the contest, and digitally scribbled the logo together in maybe an hour, if that? I didn't honestly think it would win, and so by the time they were asking for the source file, it was gone. What's used as the logo is a very faithful tracing of my logo concept. By whom, I'm guessing @Rei-artur:, because I made some sort of incredible trivial to the point of invisible change to their file, according to the edit logs. -- Zanimum (talk) 14:35, 18 August 2017 (UTC)
- Actually, let me check my external storage, there's a slim chance that I have it still. -- Zanimum (talk) 14:36, 18 August 2017 (UTC)
- (I presume it's not relevant to the conversation, but for posterity's sake, I literally drew the logo on top of File:Iceberg.jpg, also online as File:Old Wikisource logo used until 2006.jpg. I wouldn't say traced, but the proportions are nearly the same.) -- Zanimum (talk) 14:43, 18 August 2017 (UTC)
- The original file appears to be File:Wikisource-newberg-de.png; both File:Wikisource-logo.svg and File:Wikisource-logo-fr.svg are direct derivatives from it by the original creator, User:Zanimum. @Zanimum: your input here would be valuable. —Beleg Tâl (talk) 12:46, 18 August 2017 (UTC)
- I definitely support the idea of generating the PNG version of the Wikisource logo from an SVG file, but I don't really see that the file in question above (which isn't even named correctly) is ready yet to be the replacement. The font is different, and so are the colours (the existing background blue is #375493, but the proposed one is #225991). I know these are small changes, but I really don't think we want to have different versions of the logo (e.g. there are lots of other places that use the logo that we can't control, e.g. exported epubs).What's the history of the current logo, and why don't we have the original vector source for that?Sam Wilson 10:32, 9 August 2017 (UTC)
While I have an ear, I posed a question at Wikisource talk:WikiProject Social media. Londonjackbooks (talk) 10:11, 18 August 2017 (UTC)
Formatting images for mobile view
I am a recent convert from flip-phone to smart, and have been exploring Wikisource through mobile eyes. But I have for some months been aware that using the formatting [[File:Example.jpg|center]] is no guarantee that images will be centered in mobile view (<center> works, however); line spacing (and who knows what else) is also affected in some cases. Most images appear screen left. See Alice Meynell's Preludes for a visual, noting image placement, line spacing issues (title page), and even TOC placement.
Is mobile-friendly formatting something the community feels important to address? Londonjackbooks (talk) 09:48, 18 August 2017 (UTC)
- I think being mobile-friendly is very important, as we get nearly a million mobile pageviews a month (compared to nearly three million on desktop).One thing that could help with us making sure pages look good on mobile is the mobile sidebar gadget from Meta (and English Wikipedia). It displays a right-hand side emulated view of the mobile skin. It's pretty easy to install.—Sam Wilson 10:13, 18 August 2017 (UTC)
- You can enable the mobile sidebar by putting these two lines into your vector.js:—Sam Wilson 10:26, 18 August 2017 (UTC)
mw.loader.load('//meta.wikimedia.org/w/index.php?title=User:Brion_VIBBER/mobile-sidebar.css&action=raw&ctype=text/css', 'text/css'); mw.loader.load('//meta.wikimedia.org/w/index.php?title=User:Brion_VIBBER/mobile-sidebar.js&action=raw&ctype=text/javascript');
- Having the tool active for all namespaces is problematic when editing, if it is going to be that way, it needs to be collapsible. I would prefer the ability to toggle it on and off for it to be usable in an ongoing "checking" sense.
- I agree. I think it's meant to do that, too, but the script seems to be a bit buggy. If there's interest, we could probably see about making it work better. Sam Wilson 07:44, 19 August 2017 (UTC)
- Having the tool active for all namespaces is problematic when editing, if it is going to be that way, it needs to be collapsible. I would prefer the ability to toggle it on and off for it to be usable in an ongoing "checking" sense.
- You can enable the mobile sidebar by putting these two lines into your vector.js:
- Comment we most definitely need to be ensuring that we have a sensible mobile view. Our issue is how do we coordinate that our needs are addressed. We need to have someone who has CSS expertise work with us to assist us to fix our errors. — billinghurst sDrewth 07:30, 19 August 2017 (UTC)
- And it's not just mobile that will benefit; better-structured styling can help with epub generation too. Sam Wilson 07:44, 19 August 2017 (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
- You can now test the new Timeless skin on the test wiki and mediawiki.org. You can turn it on in your preferences. You can report bugs in Phabricator. It will come to more wikis soon. [14][15]
- Your watchlist can now have the option to unwatch pages. You have to turn this on in your preferences. [16]
- If a table has several columns you can often choose which column you want to use to sort the table. This has not worked for some columns for readers who have used Firefox or Safari. This has now been fixed. [17]
- The RelatedArticles extension has shown related pages on Wikivoyages. You will now see the related pages at the end of the article together with an image. Previously the links were in the sidebar. Wikis that want this extension can request it on Phabricator.
Changes later this week
- Videos will now be played in the WebM format in all browsers. Previously some browsers used Ogg Theora (.ogv). If you use Safari, Internet Explorer or Edge you may see slower playback speed at high resolutions. Instead we will get better quality and smaller file size. You can still upload video as Ogg files. They are automatically converted to WebM. This doesn't affect Ogg audio files. [18]
- The default font in the edit window will change for some users this week. Instead of using the browser default, it will be monospace. Users can change this in their preferences. This should only change this for some users on Macs and iOS devices. [19]
- The new version of MediaWiki will be on test wikis and MediaWiki.org from 22 August. It will be on non-Wikipedia wikis and some Wikipedias from 23 August. It will be on all wikis from 24 August (calendar).
Meetings
- You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 23 August at 15:00 (UTC). See how to join.
- You can join the next meeting with the Editing team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on 22 August at 19:00 (UTC). See how to join.
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
18:00, 21 August 2017 (UTC)
New skin, "MinervaNeue"
For those who were brave enough to test the new skin, "MinervaNeue" and stuck in the nowhere because the hamburger menu is not working, click the center button of the mouse on the same hamburger menu and this may, or may not, gives access to one's Preferences where you can revert the skin. Also, some features used with Vector do not work with this new skin. — Ineuw talk 23:14, 21 August 2017 (UTC)
- Note that you can also go to https://en.wikisource.org/wiki/Special:Preferences?useskin=vector to make it use vector (just for that page load). Sam Wilson 00:25, 22 August 2017 (UTC)
- Think that I may have been misunderstood. When switching /Preferences/Appearance to "MinervaNeue" (from Vector), I lost access to my Preferences. Just clicking on the hamburger should have brought up my list of options, but it didn't. It took awhile to access them by opening them in a new tab. — Ineuw talk 04:04, 22 August 2017 (UTC)
- it loads faster than the flat sidebar gadget, but cannot edit by section, so not much use here. Slowking4 ‽ SvG's revenge 21:59, 23 August 2017 (UTC)
- well now can edit by section. the drop down menu is a dummy for now. so it is faux VE with wikitext. cannot advance by page, since no page buttons. eventually it might be useful if it included some menus. runs fast. Slowking4 ‽ SvG's revenge 00:33, 31 August 2017 (UTC)
- menu works on wikipedia, and mobile view, but not here on desktop. if you can edit the url to navigate, it can work, but it is clunky. Slowking4 ‽ SvG's revenge 13:19, 7 September 2017 (UTC)
When using this theme, custom rules such as on https://en.wikisource.org/w/index.php?title=Narrative_of_the_Life_of_Frederick_Douglass,_An_American_Slave&useskin=minervaneue are left-aligned instead of center-aligned. -Einstein95 (talk) 09:51, 18 September 2017 (UTC)
Proposal to have transclusion tab in Page namespace
Some Wikisources have a transclusion tab (a book icon) at the top of the Page namespace, beside the index (up-arrow) tab. Clicking it takes you to the Mainspace chapter where that page is transcluded. This is a handy gadget, obtained by installing the mul:MediaWiki:TranscludedIn.js. In English Wikisource, you have to follow a roundabout way if you want to visit from a Page: to the transcluded chapter: you can navigate the TOC from the index page or the root page in Mainspace, after knowing the chapter number. If there is no TOC and you have not created an AuxTOC, then such navigation is very problematic. I propose that this gadget be included in English Wikisource. Hrishikes (talk) 14:27, 31 August 2017 (UTC)
- Support —Beleg Tâl (talk) 15:31, 31 August 2017 (UTC)
- Comment How would this work when the page is transcluded in more than one location? For example, (a) a poem that is transcluded both as part of a book and as a poem in its own right, or (b) an encyclopedia page that has sections transcluded separately to more than one mainspace article? --EncycloPetey (talk) 15:38, 31 August 2017 (UTC)
- There will be multiple transclusion tabs in such a case. e.g., this page. Hrishikes (talk) 15:47, 31 August 2017 (UTC)
- What limits the number of tabs if a page is transcluded in multiple locations? Some encyclopedia pages have eight or more articles, and that many extra tabs becomes cumbersome, especially on mobile devices and smaller monitors. --EncycloPetey (talk) 15:57, 31 August 2017 (UTC)
- I do not know the limit. The vast majority of pages won't have more than three tabs. However, I think it should be possible to tweak the gadget so that specific works (like encyclopedias and dictionaries) are excluded from its purview. Maybe @Samwilson: can say? Hrishikes (talk) 16:59, 31 August 2017 (UTC)
- @Hrishikes: I think converting it to a drop down when there's more than one would be a great way to go. Shouldn't be too hard. And I agree with @Billinghurst below that this should just be a gadget that people can enable if they want. It's a thing I've been wanting for years! Sam Wilson 01:00, 1 September 2017 (UTC)
- There does not appear to be any limit. I wonder how hard it would be to modify it to be a drop-down? I've made a local copy for sandboxing at User:Beleg Tâl/TranscludedIn.js. —Beleg Tâl (talk) 17:15, 31 August 2017 (UTC)
- I do not know the limit. The vast majority of pages won't have more than three tabs. However, I think it should be possible to tweak the gadget so that specific works (like encyclopedias and dictionaries) are excluded from its purview. Maybe @Samwilson: can say? Hrishikes (talk) 16:59, 31 August 2017 (UTC)
- What limits the number of tabs if a page is transcluded in multiple locations? Some encyclopedia pages have eight or more articles, and that many extra tabs becomes cumbersome, especially on mobile devices and smaller monitors. --EncycloPetey (talk) 15:57, 31 August 2017 (UTC)
- There will be multiple transclusion tabs in such a case. e.g., this page. Hrishikes (talk) 15:47, 31 August 2017 (UTC)
- Comment we should not have it by default, if it is to be used, it should be available as a gadget. Of course, people can install it themselves directly via their global or common javascript pages. We should be looking to not impose more javascript onto people than is necessary. — billinghurst sDrewth 22:13, 31 August 2017 (UTC)
- Support —Ciridae (talk) 07:12, 3 September 2017 (UTC)
- Comment The best way now to navigate to the transcluding pages is to click the "What links here" link. Since not many pages link to the Page namespace, it's always easy to find the page you're looking for, such as from this list. I agree with Billinghurst that it would be better to make the transclusion tabs optional. Mudbringer (talk) 01:19, 6 September 2017 (UTC)
- Comment As optional gadget. Londonjackbooks (talk) 01:37, 6 September 2017 (UTC)
- Support, as optional gadget. --Zyephyrus (talk) 17:51, 12 October 2017 (UTC)
- Comment Optional gadget not required, IMO, because users can add it to their common.js (as I have done), and it will work fine. Hrishikes (talk) 00:31, 13 October 2017 (UTC)