User talk:Samwilson

From Wikisource
Jump to: navigation, search

Hi from Alex brollo[edit]

I took a look to your common.js and I found that you are running boldly eis.js. Ok! This means that you are testing it here into en.source :-)

I'll import your common.js into my one and I'll see what will happen.... I guess, I'll be fashinated by what I'm going to discover!

PS: I use my "test account", User:Alex brollo bis, to test anything new. --Alex brollo (talk) 15:04, 14 October 2016 (UTC)

Ok, I found the first (surely not the last...) issue: while importing your common.js as it is into User:Alex brollo bis/common.js, eis tool doesn't run, since a global object alex={}; (the global object I use anywhere to see what's happening inside my "iffy" and to allow objects sharing among different tools) is need into main javascript namespace. Such a need should be avoided for sure, but presently it is needed. Please add it into your common.js and test eis.js again. --Alex brollo bis (talk) 15:26, 14 October 2016 (UTC)
I moved eis.js here into User:Alex brollo/eis.js, please feel free to use it and edit it as you like, as yours (you've needed privileges for sure). Presently I'm using it into it.source, but I can fastly point again into it.source code if anything goes wrong. I already translated into English somethoing, Iì'll go on adding some comments into the code. --Alex brollo (talk) 07:24, 15 October 2016 (UTC)
@Alex brollo: Sorry for my slowness in replying. I'll let you know how I get on with eis! :-) I'll fork it to User:Samwilson/eis.js for testing. Sam Wilson 15:27, 16 October 2016 (UTC)
As soon as you like.... I'd like to share a couple of other exotic, but running, ideas to support a faster editing; but I feel better to deal one thing at a time. ;-) --Alex brollo (talk) 16:04, 16 October 2016 (UTC)

Bot archiving available[edit]

Hi SW, we have Wikisource-bot that is able to archive progressively, if that is of interest. It uses the standard pywikibot script from elsewhere at WMF that archives based on time passed on each section. — billinghurst sDrewth 22:12, 16 October 2016 (UTC)

Hm, well maybe if I become more talkative! :-) I've only just needed to archive after 8 years... hehe. I'll keep it in mind though. Sam Wilson 01:12, 17 October 2016 (UTC)

Toolbar button for curly quotes[edit]

Hello! I just wanted to thank you for creating this toolbar button. I've been reviewing the curly/straight quotation mark debate (having not realized previously that they were even possible until I ran across them when editing an EB1911 article) and decided to use them for my project Index:Repository of Arts, Series 1, Volume 01, 1809, January-June.djvu. I went looking for a bot to do the conversion and found your toolbar button instead. Not only will it make the conversion of already-proofread pages orders of magnitude easier, but it will make it easy to edit new pages. So thank you! Laura1822 (talk) 11:10, 29 October 2016 (UTC)

@Laura1822: Oh I'm glad it's of use! That's good. I use it on some novels that I'm proofreading. Curly quotes aren't super-liked by many Wikisource contributors, but they're tolerated (so long as works are consistent in their usage). Do let me know if there are any typographic situations the toolbar button can't handle. Most of the conversion steps I brought in from the Gitenberg project's clean up script. Sam Wilson 00:53, 31 October 2016 (UTC)
Yes, actually, I found it didn't work on a couple of pages in an article that had long quotations with some phrases in italics. There were a few opening or closing quotation marks next to italics that I had to convert manually, but usually it got them correct on the other end. Take a look at Page:Repository of Arts, Series 1, Volume 01, 1809, January-June.djvu/98 and the following page or two.
Even with this imperfection, the button is still so useful I'm thrilled to have it!
Since you, like me, seem perhaps to prefer old-fashioned typography, I wonder what you think about emdashes. My complaint about them is that they are far too short. I have been using {{bar}} (with |2 parameter) instead of emdashes. I'm considering changing over to a pair of so-called {{longdash}}es, which are of course much too short for their professed purpose. The main difference between them and bars appears to be that the longdashes are a little above the midpoint (which is nicer!), while bars are exactly at half-height. You can review the differences at User:Laura1822/Ackermanns#dashes_.26_ rules. What do you think? Is the length of dashes controlled by the font face or family in the user's browser (thus rendering the effort nil)? If so, do you know what fonts use longer (longest) emdashes?
Maybe we should start a support group for people who prefer "old-fashioned" typography (much of which is still current practice in actual printing practice). I can't tell you, for example, how much I despise sans-serif fonts and would like to get my hands on the person at Apple or Microsoft in the 1990s who decided that sans serif was "easier" to read on screen while serif was easier to read on paper. A completely bogus distinction which has since been disproved by study after study, to no avail.
Sorry for the rant! Keep up the good work! Laura1822 (talk) 10:24, 31 October 2016 (UTC)
@Laura1822: Yes, I'll join such a group!! :-) I'm a bit fan of getting typography right. It's one of the things that annoys me most about ereaders, but I'm discovering that lots can be done to make things better (like curly quotes).

With regard to dashes, I quite agree that bars are often what's needed, and yet they're not very well supported (on ereaders, I mean; see an example here). I don't like the CSS hack of struck-through em dashes constituting a bar, but it's better than a unknown-glyph grumpy-face.

I reckon we need a sort of "hint of the day" or something, in which we could have little explanations of the various typographical things, because I reckon lots of people don't know about the richness possible (and the differences in meaning). Sam Wilson 04:05, 1 November 2016 (UTC)

Looks like bars work (not ideally), but longdashes don't work at all. Well, that's enough to make my decision to stick with bars instead of switching to longdashes! And the emdashes with or without hairspaces are moot, not to mention ugly. Also, nice to see the picture of the Kobo. I'm going to have to replace my 1st-generation Nook one of these days, and there is no way I'm purchasing another proprietary ereader. Do you like how the Kobo handles djvu files?
Is that your personal wiki?
I like your idea for a hint of the day for our group. I too like to get typography right; 30 years ago I did some desktop publishing using Pagemaker, and spent inordinate amounts of time choosing fonts and tweaking layouts to get them just so. One of my favorite books, of which I happen to have a first edition hardcover from 1955, and the printing is just beautiful, with good spacing and extra extra long dashes. It is so much easier to read! I hold it up as my ideal, wish I could format all fiction like that!
I see that you use the DBCustomMono font for proofreading too! When I first joined WS I asked for help to figure out how to use it. I got the help, but contrary to my expectations no one said, "wow, what a great idea! Everyone should be using this--let's make it the default!" -- more like, "huh? why would you want to use that?"
Some months ago I contributed an essay to Wikisource talk:WikiProject Proofreading comparing the process here to that at PGDP and suggesting improvements to implement here. The project is completely dead, however, so it garnered no response and I've been meaning to bring it up in a general discussion forum but haven't gotten around to it--don't have the energy. Laura1822 (talk) 09:52, 1 November 2016 (UTC)
Yes, I think bars have to be done by combining multiple em dashes, unfortunately. At least if one day we figure out a better way, {{bar|2}} could be changed to output a proper bar. I'd love to see how other ereaders render things, the Kobo is perhaps a bit old. New ones might be different. And I do recommend them! They work with pretty much any format (although I haven't actually tried reading a djvu, instead spending most of my time reading epubs generated from Wikisource!).
Have you come across the Standard Ebooks project? They're trying to pay attention to great typography (and sometimes use WS books, although unfortunately when they do they usually haven't submitted their corrections back here).
I'm surprised that you didn't get a good reaction about DPCustomMono! I hadn't seen your write up either, and it's really good to read. :-) I absolutely agree, there is so much more we could learn from PGDP — I've done a bit of proofreading over there, and it's a pretty good experience (ultimately, I prefer being here because we keep the link to the original scans, and Wikimedia feels generally more robust and egalitarian). Do you think a gadget for enabling DPCustomMono would help (people still have to download and install it, but at least they wouldn't have to edit their CSS)? Or, actually, perhaps we should talk about making it the default as part of the ProofreadPage extension?
Have you heard about the Community Wishlist Survey? It starts on Monday. You must think up three proposals! :-) It sounds like you've got some good ideas, and especially ones that are not just "make proofreading better" but actually are discrete accomplishable things. (I'm going to put some proposals in, but because I'm a member of the Community Tech team I won't be voting on anything.)
Sam Wilson 00:29, 2 November 2016 (UTC)
I was unaware of the Wishlist; thanks! I might have an idea or two for Commons as well. I prefer WS to PGDP for much the same reasons you do: I think the links to the original scans are important (I am always frustrated with books from PG because they do not give the edition information), and I agree that one of our strengths is that anyone can do anything, from proofreading a page to setting up a project.
I am somewhat of an ideas person. I am good at thinking things through, organizing them logically, and writing persuasively, but I am not as good at following through to the bitter end and my technical skills are on the low-to-moderate side (I was once a techno-geek but have had to exchange my geek card for a moderate Luddite card as tech has raced past me). So if you are a person who makes things happen, and you like my ideas, I am really glad I met you.  :)
I have links on my user page to a few Jane Austen texts that appeared to have had the text imported from PG rather than freshly proofread. This is a huge problem, IMO, because the scans here on WS are first editions and the PG texts are much later; there are significant differences in spelling and punctuation. Having the original text reproduced exactly would be an important resource for us to have here online since academic research has in fact focused on that very issue in the recent past (some academics are arguing that the verve of her style was actually imposed by her editor, or later editors). But even without that particular research issue, it is still important to create WS texts that exactly mirror first editions! So I am thinking that a WS Project dedicated to finding and correcting such texts (which seems to have been a habit in the early days of WS?) would be valuable. But only after, perhaps, a revival and revision of the Proofreading Project linked above and POTM. Laura1822 (talk) 09:03, 2 November 2016 (UTC)

Toolbar button error report[edit]

I just noticed that on Page:Repository of Arts, Series 1, Volume 01, 1809, January-June.djvu/93, when I click the toolbar button, it mis-converts one of the italics marks on the fourth line to a curly-single-quotation mark. The phrase is "as yet." I didn't look closely at the others on the page, just noticed this one. Laura1822 (talk) 10:51, 2 November 2016 (UTC)

Hm, thanks for pointing it out! I can't quite see immediately why it's being stupid. :( I'll get it fixed though!
(Oh, you probably do it already, but it's a good idea to add any scripts you include in your common.js to your watchlist, that way you'll be alerted to any changes or discussions there.)
Sam Wilson 00:55, 3 November 2016 (UTC)
Okay, maybe is all good now? Sam Wilson 01:10, 3 November 2016 (UTC)
The error on that page appears to be corrected. Thanks! You do good work!  :) I added your script page to my watchlist; thanks for the suggestion. Laura1822 (talk) 11:23, 7 November 2016 (UTC)

Sorry to report another page where it seems to be confused by numbers and italics: Page:Repository of Arts, Series 1, Volume 01, 1809, January-June.djvu/12. Note that at the end of the fourth paragraph, for "15th," it works correctly, but at the end of the last paragraph, it doesn't handle "1st" correctly. (This work has a lot of this sort of mixing because apparently the printer did not have, or chose not to use, italics for numbers for the principal typeface.) Laura1822 (talk) 15:44, 7 November 2016 (UTC)

invisible button with reversed colors[edit]

Noting your discussion below, I'll go ahead and point out that I don't see the button. (I tried reloading the page (as below) and that did not fix it.) I did not report this earlier because I presumed it was related to my non-standard setup: I use a black background with light foreground for everything (as I am extremely light sensitive), and it's pretty normal for me to find that things like buttons don't show up (for example, I can't see the previous, next, and up buttons on an editing page, nor does the switch-from-vertical-to-horizontal button appear any longer after I use the preview——but I think that in that case the button really disappears, and is not just there-but-not-visible). As long as I know what and where the button is, I don't worry too much about it. Laura1822 (talk) 11:34, 7 November 2016 (UTC)


Hi. The script works fine in over/under mode, have lots of workspace. Many thanks. — Ineuw talk 05:46, 7 November 2016 (UTC)

Oh cool! I'm glad. :-) Let me know if you have any ideas for it. :-) Sam Wilson 05:52, 7 November 2016 (UTC)
The only issue is that the icon disappears, once it's activated. — Ineuw talk 06:05, 7 November 2016 (UTC)
That's frustrating! Do you mean, as soon as you click it and it goes fullscreen, the toolbar button disappears? :-( So you can't return to normal? Sam Wilson 06:16, 7 November 2016 (UTC)
Please don't be frustrated. I was told (rightly or wrongly), that Rome wasn't built in a day :-) I retested it thoroughly, and I suspect that it's a caching issue. If the user reloads the browser's current page a couple of times, all controls reappear. Which means that when activated initially, all controls disappear, meaning the user controls row of preferences etc., the page controls like read edit etc., the Charinsert bar (mine is set to display on top), and the editor toolbar (I am using the advanced version). However, a couple of page reloads and all controls return to normal. Will try to create a screenshot of what I get in full screen editing mode. — Ineuw talk 06:52, 7 November 2016 (UTC)
Hm, yes, I think I've seen what you describe (or some part of it). I sometimes have to reload a page to get all scripts that I've got in common.js to work properly; I think it's a fact of these scripts not being part of the normal resource-loader world, but rather addons after the fact, and with the vagaries of downloading them sometimes they get missed. :-( The upcoming Gadgets 2.0 stuff, things should get better! :-)
Oh, and do you like the way that fullscreen editing remembers your last-used state (it sets a cookie)? Or is that annoying? Sam Wilson 06:56, 7 November 2016 (UTC)
Now everything is working fine, all controls are visible in all views by opening the page for editing without refreshing. Perhaps it was a cache issue, or the cookie was not set the first time? And, I like the storing the last state feature. It's logical. — Ineuw talk 07:03, 7 November 2016 (UTC)

Problems into la.source[edit]

As you know, la.source is a very small and poorly active project, its a pity since it could be considered the "second multilingual project" of wikisource family, since Latin is something like a international language. Its present advantage over mul.source is, that its pages can be linked fully to wikidata, while pages of mul.source can't (I don't know if this big issue has been fixed?)

I'm a (almost inactive) sysop there, and sometimes I try to import templates and tools; presently I'm trying to run FullScreenEditing.js, but I found it painful, and I'm far from satisfied by the result, since it randomly fails. Often the whole tools group (where FullScreenEditing icon should be appended) is not loaded at all. Could you take a look to general settings of that project? Is perhaps some importent setting lacking?

A question about FullScreenEditing.js: I see that it uses cookies. I abandoned them for my tools and presently I only use localStorage, with pretty good results. Is there some good reason to avoid the use of localStorage and to prefer cookies? --Alex brollo (talk) 15:33, 10 November 2016 (UTC)

Yes, I think the idea is to make mul.source be linkable from Wikidata, but I'm not sure of the state of progress. Can't find the phab item right now. :(
There are known and rather large issues about the system of using mw.loader.load to load user scripts. Basically, from what I read, there's no absolute guarantee that scripts will load, or load in order. The new gadget system will fix this, but I've no idea when that's happening. It'll mean that gadgets etc. will be minified and served along with other page scripts in the proper way. I don't really know how! :-) Do you get it to work on when you repeatedly hit reload? (not that that's a solution, but it narrows the problem down; I'm getting that behaviour on
And that's a great idea re localstorage; I didn't have any particular reason to use a cookie, just that it was simple. I'll look at changing it; I'm sure it's more efficient that way, and it's probably generally good to reduce the number of cookies being set.
Sam Wilson 01:48, 11 November 2016 (UTC)
As soon as I understood what localStorage is, and how it works, we "itsourcians" used it a lot for heavy jobs too; i.e. there's a tool to add "author's references" (links to Author namespaces) that uses a localStorage object containing the whole list of Author page titles, with a pick-up box that lists existing authors for similitude of names (you know howoften authors names change from book to book). The list is more than 6000 items long, nevertheless seach is extremely fast. Obviously localStorage data are local, but they are uploaded and updated by shared js tools, so that in practice they are shared among all users that use those tools.
About la.source: the intriguing issue is that the right tools group disappears after refreshing the page (i.e. by Ctrl+R); this doesn't happen into it.source nor into en.source. I've been so much confused by ResourceLoader that I've been tempted to stop any js and css contribution. I'll try to convert FullScreenEditor into a gadget for la.source - just a try. --Alex brollo (talk) 11:27, 11 November 2016 (UTC)

Looking for an old script.[edit]


I am using over and under editing, and when I had the problem of the full sized OCR display window, you gave me this script to deal with the problem. Now everything is OK, but I was wondering if the script can be modified to resize this OCR window with my specified height. I find the current window too small under certain work conditions. Thanks. — Ineuw talk 02:16, 2 January 2017 (UTC)

@Ineuw: Hm, I thought the over-under setup was that it'd resize itself to be ~⅓ of the window height? Is that not happening? Maybe you've got an old version of the script; you can just use User:Samwilson/FullScreenEditing.js instead of your sandbox (there are a few differences between them now). I'll have a look at what can be improved too. Sam Wilson 05:07, 3 January 2017 (UTC)
In order to avoid sowing confusion, please forget about the reference to past problems, and the following is much clearer (I hope): Currently, my text area edit window is set to 11 lines, measuring 252px. The opening which displays the original page is currently 250px (using a pixel ruler) I would like to be able to open the upper window (the original page display) set by my preferred size, which I don't know but certainly more that 250px. The code pasted in the sandbox is from my archive folder. Currently, I have none of your code in my common.js and I wouldn't know where it is set. — Ineuw talk 05:41, 3 January 2017 (UTC)
Uploaded THIS IMAGE to further clarify. — Ineuw talk 06:15, 4 January 2017 (UTC)
@Ineuw: Cool, makes sense. So you want the height of the page image to be more? Will that mean you have to scroll to get to the summary and save buttons etc.? And is this about big screens or small ones (primarily)? Do you need to be able to switch between sizes? I guess the best solution would be to have a draggable bar at the bottom of the page image, and for it to remember your previous setting. What do you think? Maybe the sort of generic improvement that should be incorporated into proofreadpage? Sam Wilson 06:22, 4 January 2017 (UTC)
@Ineuw: have you first considered sizing the editable window size through special:preferences#mw-prefsection-editing? — billinghurst sDrewth 06:29, 4 January 2017 (UTC)
@Billinghurst:, I am familiar with the edit window settings, but they affect only the lower edit window. I played with the settings between 10 to 14 lines which depend on the selected font size. But, that doesn't help me see more of the original and that is my wish.

Also, @Samwilson: Thanks for the quick reply. I don't want anything fancy. Just thought that a small script in the common.js (or the .css) where I can set the window size to about ~300px so that I can read a few more lines. As for accessing the various objects and controls, I am used to scrolling up an down for access, or make extensive use of the keyboard tab key, and alt+shift+p, or alt+shift+s to get the job done. By now, both methods are 2nd nature. — Ineuw talk 06:44, 4 January 2017 (UTC)


Parameters "birthyear" and "yearyear"? Is the latter a typo? --EncycloPetey (talk) 00:18, 17 January 2017 (UTC)

@EncycloPetey: Ha! Yes, definitely. Oops. I'm still working on the docs (and still on the module too, so no doubt lots will change). I'm going to ask about it soon on scrptorium. Sam Wilson 00:22, 17 January 2017 (UTC)