Wikisource:Scriptorium/Archives/2013-09

From Wikisource
Jump to navigation Jump to search
Warning 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

Wikisource:Anniversaries

I have created Wikisource:Anniversaries to list potentially useful upcoming annversaries, either for personal projects or things like Proofread of the Month and Featured Texts. - AdamBMorgan (talk) 16:51, 5 August 2013 (UTC)

HTTPS for logged in users on Wednesday August 28th

“ As we outlined in our blog post on the future of HTTPS at the Wikimedia Foundation[0], the plan is to enable HTTPS by default for logged in users on August 21st, this Wednesday. We are still on target for that rollout date.

As this can have severe consequences for users where HTTPS is blocked by governments/network operators in addition to users who connect to Wikimedia sites via high latency connections, we've set up a page on MetaWiki describing what is going on and what it means for users and what they can do to report problems.

Please help watch out for any unintended consequences on August 21st and report any negative issues to us as soon as you can. Bugzilla:, IRC (#wikimedia-operations), or the (forthcoming) OTRS email are all fine.

”

—Greg Grossmeier, wikitech-ambassadors-l

An announcement for your attention. Local admins can only advise, we won't be able to fix. To note that you can also ask questions in our IRC channel #wikisource. If there usually say the person's nick/name and and please be patient for a response. Many use name highlight to get their attention. You can also use !admin to get someone's attention.— billinghurst sDrewth 00:19, 20 August 2013 (UTC)

As I just updated on the meta page, we've delayed this rollout by one week. The change will now take place on August 28 at 1pm Pacific Time. Please take a look at gadgets or bots you maintain to make sure they'll continue to work; more information at meta. Hope I didn't mess stuff up too much by updating the section header. Sharihareswara (WMF) (talk) 19:17, 21 August 2013 (UTC)

Proposals

BOT approval requests

Bot flag request for BrandeisBot

I've created User:BrandeisBot, a pywikipedia bot that will help upload the missing U.S. Supreme Court cases. It uses a JavaScript program called lochner to pull text from Justia, and a Python program called brandeis to parse them into wikitext that can be uploaded by pywikipediabot's pagefromfile script. The bot produces an output quite similar to BenchBot's—it splits the pages into a main page, /Opinion of the Court, /Dissent [name], /Concurrence [name], etc. It also adds a talk page for each, and redirects the case number to the main case page. It will be manually-assisted—as the Justia files can vary in how they're formatted, the parser can't always keep up. It does check if the page exists before parsing, and won't overwrite any existing pages. There is more thorough documentation at User:BrandeisBot/Documentation.

I was told to demonstrate its uploads for a case, so I've (slowly) created Rice v. Cayetano. I've provided the oldid versions because I will be cleaning up the files to show what kind of maintenance is required. As a note, I did not do any editing of the text file output by brandeis before it was uploaded, just to give an idea of some of the errors it can make and things it can miss. Normally I plan to make minor changes to that before it's even uploaded.

The text file used to create it is at User:BrandeisBot/sampletext. – GorillaWarfare (talk) 22:02, 26 May 2013 (UTC)

Is there no community comment on this either way? Hesperian 00:24, 28 June 2013 (UTC)
  •  Support - and I guess if there are any issues concerning the now-idle U.S. Supreme Court project, they should call on me to see if I can't provide some insight on what was being done before and/or what else needs to be done, etc. -- George Orwell III (talk) 01:55, 28 June 2013 (UTC)

Granted.[1] Hesperian 00:42, 8 August 2013 (UTC)

Help

Other discussions

More on unlocking images

2nd version

After playing around some more and defining a 2nd css class for it, I think I've found a way for images to re-size themselves on-the-fly based on their container's size. See the image in Temp Image Testing for the re-sizng in action as you play with your browser's settings or change the dynamic layout.

No template yet but the raw html pretty much goes like this.... 

<div class="freedImg" style="  width: 100%;   [or  ### px ] ">
<p   class="freedImg" style="  width:inherit;               ">[[File:The fall of Ulysses pg 48.jpg|link=|alt=]]</p>
<p class="imgCaption" style="text-align:justify; text-indent:1.75em;">{{Lorem ipsum}}</p>
</div>


The width needs to be set to 100% in the first div class="freedImg" line for dynamic resizing to really work. You can still force a fixed px size if you wish.

An example of 33% of the textarea/screen (or 33% of the container[=100%]) follows.... 

<div class="floatnone" style="     width:  33%;      margin-left:auto; margin-right:auto;">
<div class="freedImg"  style="     width: 100%;     ">
<p   class="freedImg"  style="     width:inherit;   ">[[File:The fall of Ulysses pg 48.jpg|link=|alt=]]</p>
<p class="imgCaption" style="text-align:justify; text-indent:1.75em;">{{Lorem ipsum}}</p>
</div>
</div>

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Hope that worked - delete if it screws up the page. No tables or File: settings involved. -- George Orwell III (talk) 04:23, 6 May 2013 (UTC)

h-h..Hello?      Is there anybody out there?
It appears to work with Chrome, IE8 and IE6. I have not had a chance to test using this myself but it looks like it could be useful in a lot of situations (I have found that "frameless" is usually too small by default and have had trouble picking a useful alternative image size). I don't think this will work when captions need to be overlayed on the image but the current system will be fine for those situations. - AdamBMorgan (talk) 13:34, 7 May 2013 (UTC)
Thanks for takin' a look. The more feedback - the better (and I don't believe the full 100% setting alone will work on anything lower than IE8). -- George Orwell III (talk) 13:49, 7 May 2013 (UTC)
Yeah, it works for me on Chrome and IE8, I can check Firefox tonight. - Theornamentalist (talk) 14:05, 7 May 2013 (UTC)
Both image here and sandbox work in Firefox 20.0 :) When can we expect a template? - Theornamentalist (talk) 21:31, 7 May 2013 (UTC)
Ignore the IE6 comment. That was a work computer that was running IE6 last time I checked but has apparently been updated since and I just didn't notice (I don't use IE a lot). - AdamBMorgan (talk) 23:37, 7 May 2013 (UTC)
Yeah, I didn't put too much faith in the IE6 comment having to deal with it almost daily, but thanks for checking. I'm already thinking about how best to template-tize this but I'd like more than just the three of us to go on. -- George Orwell III (talk) 03:02, 8 May 2013 (UTC)
I am as ever late to the party. Just adding to the numbers (now 4?), this works for me using Firefox 21.0/Linux. MODCHK (talk) 00:30, 7 June 2013 (UTC)

I'm having a hard time figuring out the best approach to template-tize this. On the one hand, it seems best to just apply the container with the 100% setting alone and then have that plug into templates that would apply percentages/positions to that container like in the 33% example above. On the other hand, folks would most likely prefer an all-in-one template too. Then there is the other possibility of making all this a module first and build templates from there. Thoughts? Comments? -- George Orwell III (talk) 20:58, 11 May 2013 (UTC)

Maybe wrap the template in a 400px container or something; I think that the template can only really be useful in something like Layout 2; otherwise using a 25% or something of the screen width works on a desktop, but would obviously be too small on a tablet. The opposite, a 100% on a tablet would be great, but on a desktop, obviously too large. 400px is somewhat arbitrary, but it at least has some value according the enwp on image formatting for browsability, and it goes along with our layout 2. Just some thoughts... And can we get rid of that damned forced font on layout 2? - Theornamentalist (talk) 21:40, 11 May 2013 (UTC)
That is kind of backwards imho - I'd just add a line to the Dynamic Layout to impose a percentage of the full image container if need be rather than having the template perform resizing tricks based on which layout is in effect. Plus your rather large viewscreen is the exception; not the rule - even the extra large malaria poster looks fine here in Layout 1 for example. Its the font size being too small that throws layout 1 off and not so much the lack of margins imo. -- George Orwell III (talk) 23:26, 11 May 2013 (UTC)
I apologize, I may have not understood exactly what you were asking so please forgive any ignorance. As someone who intends to use this, I wanted to give an input. I've made an example in a sandbox with my concerns, and with the point that I was trying to make; that it might not be a bad idea to cap off the 100% width somewhere. - Theornamentalist (talk) 00:26, 12 May 2013 (UTC)
Input appreciated but I'm afraid its skewed by current practices. If the standalone image was created based in proportion with its caption size to its printed text size and the border trim turned into padding or margin instead of cropped, you'd see all this quite differently. Look at your sandbox again to see what I mean. -- George Orwell III (talk) 01:05, 12 May 2013 (UTC)
Still afraid I don't understand. The change you made still shows the same case regardless of trimming and caption, that for a monitor, 100% image width not contained by a layout or table will simply be too much image for a desktop (yet decent for mobile), and that reducing the size to say 33% will simply be too little for a tablet or mobile device (yet decent for a monitor). I suspect neither of us is helping each other out, so for now I withdraw my input. - Theornamentalist (talk) 01:40, 12 May 2013 (UTC)
I'll admit to not entirely getting this to work as I envisaged; but if somebody cleverer with CSS than I runs with this... How about applying both max-width (say 600px) and min-width (say 300px) elements along with overflow:auto (this is where I came unstuck in my experiments!) to restrict the dynamic scaling range to reasonable limits for the mainstream device dimensions. Really small screens should clip the image and simply permit it to scroll (this is what I was attempting with overflow, but only with limited success...)?
Here is my best attempt so far: User:MODCHK/Sandbox (uses User:MODCHK/Template/dynamic image) Warning: annoyingly breaks centring…suggestions please! MODCHK (talk) 00:30, 7 June 2013 (UTC)
Impatience has gotten the best of me and I can only hope that neither parties are upset. I've created {{dynamic image}}. It would be nice if we could use {{image}} though. I've left the min-width empty, don't see any need to have a default. The max-width I've currently set at 400px for no real reason outside of an opinion that most images with a portrait orientation can interrupt a great deal of text beyond a 400px width. Feel free to change it. Again, I apologize for any hastiness. - Theornamentalist (talk) 21:09, 10 June 2013 (UTC)
I'm impressed. That works very well for me, and without the failings of my own flailing attempt!
None of these are serious issues, but may I suggest/ask:
  1. Provision for some kind of clear:left/right control would be useful in situations of stacking floated images?
  2. Control over text-align: for caption? This would reduce the requirement for text-indent, which seems to me to be somewhat at odds with the idea of variable image size: neither fixed values (1.75em), nor percentages cover all the cases well.
  3. I originally suggested min-width as a possible means to prevent the image becoming unusably small on narrow displays, especially as the default image-linking-to-?-linking-to-commons actions is suppressed. If a value were specified, then the enabling of overflow:auto or equivalent might be nice? (Although my experiments to date fail to give a satisfactory result on any of the current containers...)
  4. Use of link= appears to pretty much destroy dynamic resizing, at least the way I've tried it. Is there a way of usefully having both? MODCHK (talk) 22:44, 10 June 2013 (UTC)
I'll add what I can from your suggestions, they all make sense. I didn't think of the min-width as an issue, but after your response I could see where there would be one. I'd set it rather small, for example some small publishers marks occupy (something like) 20% of a printed page width, so naturally I'd want to match it when compared with the rest. How about if the min-width is set at 10% of whatever the max-width is? I'll make it 40px for now. - Theornamentalist (talk) 23:33, 10 June 2013 (UTC)
Just realised I worded point 3 really badly.. I did not mean the earlier template default of no minimum limit was wrong; I just meant it would be nice if the template user had specified a min-width, that choice might be taken as a trigger for scroll-box handling (and of course the extra research getting that to work... See GOIII's comments below.) Anyway, nothing wrong with what you have done! MODCHK (talk) 01:37, 11 June 2013 (UTC)
No worries about the template - the whole point after figuring out how to "properly" inherit settings thru containers was to make FreedImg accepted by the community thru some participation other than solely mine. However, I'd make 'Dynamic image' a shorcut to the "real" template code if you're planning on applying it to existing works today - the eventual template name will be 'FreedImg' with 'FI' as the primary shortcut to it fwiw.

I'll try to save you the time of trying to get the core premise here to do things like floating around text and stuff {point 1 above) - most of those things won't fly by manipulating the existing 2 or 3 lines (in the code/pre box far above) of FreedImg; you'd need to place the FreedImg stuff in still another container with the formatting you desire for any chance of getting both the dynamic resizing and the desired functionality to work in harmony together.

For point 2 - the caption line was included more to avoid the inevitable return to the safety of the familiar formatting templates around here (you know, a span within a div when really a paragraph tag handles the same thing) and screwing things up even though to the rendering eye nothing seems out of whack. You can manipulate it however you wish as long as it primarily remains a paragraph tag (please - not another div!).
Not sure about point 3 - I'd have to double check but I seem to recall the min/max thing wasn't universally workable browser wise even when excluding IE 6&7 from the mix. Again, we pretty much need to leave existing 2 or 3 lines of FreedImg as is and concentrate on placing them with some other container for any hope of keeping the dynamic resizing functional. Still, I'll take another look at this specifically when I get some real free time to be sure.
Point 4 is a guaranteed fail. Since there is no way to directly manipulate the IMG tag under the wikicode, trying to customize it through the normal File: parameters makes the whole FreedImg thing unstable if not out-right broken afaict. The only other thing that might be of use here was the class= setting for the File: string. I tried to use that parameter in the section directly above this one btw. Otherwise you can forget about making changes to the File: string & even if there is some nuance that manages to work today it probably won't in the future as more and more of the wikicode attempts to become HTML 5 compliant (please see http://validator.w3.org/ I make it point now to always check everything including this FreedImg stuff against it to be sure). --George Orwell III (talk) 23:47, 10 June 2013 (UTC)
Thanks George, I'll play around a bit with it, but I pale in comparison to your coding even if you were to jump in now without any "real free time" :) I'll move the template to {{FreedImg}}. I know it would require a bot and consensus, but how do you guys feel about one day moving it to {{image}}? - Theornamentalist (talk) 23:59, 10 June 2013 (UTC)
I really did not expect point 4 to be workable. If anything I thought I might not have been doing something really obvious to you guys. And FWIW choosing a final resting place of {{image}} has got my vote. The current redirection to {{missing image}} seems to me to be a bit.. inscrutable. MODCHK (talk) 01:37, 11 June 2013 (UTC)
Its not that point 4 can't be workable someday as it is more that I'd rather avoid doing so for the time being because it adds the <a href=....> container around the <img> portions and I can't entirely account for that tag's current behavior because I haven't [re]researched its properties under HTML5 just yet. The fact that the wikicode manipulates the <img> tag by default is only a secondary irritation to getting it to work (I hope).

Note that I've made some changes to the preliminary FreedImg template - forcing center rather than letting the omission of left or right to produce centering is highly problematic down the road was paramount there. I also tweaked some of the parameter naming and changed the doc accordingly - please review/refine it. I left margin-left/right undocumented on purpose re: the same letting the default intuitively become centered on its own rather than [re]directing or forcing it. Folks shouldn't need to mess with that just yet anyway so lets leave it undocumented.

As for usurping the 'Image' template name - rather not as doing so (a.) ridiculously presumptuous of us to think such a "standard "should or could be wisely usurped; and (b.) is in use by some of the sister sites as it is & however that may be; a unique name just avoids possible overlap imho. Either way, if we want to easily rename the template later, always using the FI shorctut now guarantees that option for us, bot or not. -- George Orwell III (talk) 02:09, 11 June 2013 (UTC)

Just quickly cos I'm turning in for the night soon, the width parameter seems to be not working. - Theornamentalist (talk) 02:19, 11 June 2013 (UTC) Actually, I don't know if the width works when previewing. Maybe it's just my eyes... - Theornamentalist (talk) 02:27, 11 June 2013 (UTC)
Well I can't check that just on your say so - do you have a sandbox or an example in use that I can verify/play-with? Don't mean to be d!ck here; its just hard to work to fix something I didn't entirely create - you added min & max width for example & I didn't test for that just because the absolutely simple settings weren't fully vetted yet! -- George Orwell III (talk) 02:35, 11 June 2013 (UTC)
Settle down guys. Width works fine if max-width is omitted. An over-larger min-width will unsurprisingly tend to swamp the effect of the other two. The three parameters probably should never be specified at once―and likely not very portably at all. We are still exploring possibilities. A little broken glass on the floor is only to be expected. MODCHK (talk) 02:59, 11 June 2013 (UTC)
Check this out: test
You'll see that the percentage width of the title page image is not active unless it is limited by some other container. The top is "free," the bottom in a 400px table, you can see that the 80% width I've placed on the title page image isn't working in the top, but is in the bottom. - Theornamentalist (talk) 03:08, 11 June 2013 (UTC)
And now??? You sure all those templates imposing auto div line spacing, div centering and anything I might be missing being used the page didn't affect FreedImg? As soon as closed the "centering" template before the title page image and reopen it afterwards the 10-little piggies line-drawing returned to 75% of the entire width in the Sandbox for example. Is that what you meant to be as broken? -- George Orwell III (talk) 03:49, 11 June 2013 (UTC)
That is, thanks George.
I think we should a default value for widths set to something, rather than have to enter a max-width / min-width everytime. I'd say a good majority of illustrations tend to be portrait oriented that span a printed page width. This value needs to be set at something; I looked at your sandbox MODCHK and an issue I could see. Imagine you start with an image width set at 40% as the portrait, and you want to set something to a quarter width in relation to that as it appears in the printed book. You now have two transcluded images set respectively to 40% and 10%. Since the scale has been reduced, they can quickly both get sent to the min-width on a portable device or tablet. I think keeping the largest range after defaulting to a max-min-width in the template allows for better consistency, better range of images on a variety of devices, and more control if we as a community decide to change default values.
I don't really mind what the max-width / min-width values are (just not too extreme!) but I think they should be set at something. - Theornamentalist (talk) 14:56, 11 June 2013 (UTC)
Did I go over the top in removing the defaults for max-width & min-width from {{FI}}? I thought this approach might be best at least for early testing, so the various effects may be isolated, but I'm certainly not opposed to putting them back.
Regarding image proportion relationships, is this the sort of thing you mean? I must admit I was surprised at how well-behaved it seems to be―I was expecting the two images would have to be encapsulated in a common container, thus breaking use of the template. However, it seems to work for me at least (i.e. both images resize in proportion to one another (really ∝ page width―but at least to a common factor‥) MODCHK (talk) 23:55, 11 June 2013 (UTC)
My opinion comes from the idea that though printed page widths vary, if we default the width to some value, we can help standardize and simplify the entire process. For example, if you look at this transclusion you'll see that the images using the current {{FI}} are entirely too large. What I was working on is that the illustration at the top is 100% of the books printed page width in portrait orientation. The title page illustration with all the piggies spans (from my eyes) roughly 80% of the books printed page width. For ease of sizing and relations between images in a given book, I would like to use 100% and 80% between the two, as opposed to having to constantly do math. Without a default width, it would be up to me to choose the width per image or per book, which kind of sucks. Or, I'd have to do what you've done in your sandbox, which is consider a full page image width in portrait to be some percentage from the full 100% (not in a container) and then settle on something like 40%. Next, I'd have to think "what is 80% of 40%?" in order to make the title page image 80% of whatever I've set the illustration preceding it to be so that they size and resize proportionally to how they appear in print.
So, some people might choose to proportion images in a given print by using max-widths or by doing percentages of percentages. This seems like a hassle in the long run between editors and potential styles of handling image sizing. Just some thoughts; I don't want to push a particular width but 400px seems to be a good middle of the road thing. And of course, defaulting to a width makes it easy for the 90% of the image sizing, and the special cases for sizing that will arise can change their default max-widths. So there is only extra work when not setting a default. - Theornamentalist (talk) 01:10, 12 June 2013 (UTC)
@Theornamentalist: You make a good argument. The shame of this is that the three of us represent varying extremes of views (I am deliberately being hyperbolic to make the point: Doesn't anybody else have an opinion?), which doesn't help when determining choices.
Not all proofreaders will be thinking about the final presentation, so {{FI}} might not always be the best choice, at least initially. Perhaps in practice it may be only used when reworking a transclusion―post-proofing?
I expect that (like yourself?) a default max-width of about 400px is a pretty sound compromise. MODCHK (talk)
For now I've changed it to the previous defaults; odd thing though; some of the percentage widths don't seem to be forced until after changing my browser size. For example, the cover image set at 100% compared to the frontispiece, set at 80%, are identical in size until shrinking my browser to 400px, seen here. After it's shrunk, they begin to obey the set percentages.. - Theornamentalist (talk) 02:28, 13 June 2013 (UTC) here's] a better example.

┌───────────────────────┘
 Unfortunately, the premise here was to do away with any of the previous limitations being imposed on image [re]sizing first and worry about how or if it behaves for the various User applications as they come afterward. We can't "unleash" something on the one hand and hope to limit it on the other - that just doesn't make sense and probably why max & min width parameters within the current scheme won't fly. This doesn't mean it can't be done somehow - only that the approach of directly adding those parameters to what is now a template is not the way to do it. What happens if we add another container? 

<div style="min-width:34px; max-width:394px; margin-left:auto; margin-right:auto;">
<div class="floatnone" style="     width: 100%;      margin-left:auto; margin-right:auto;">
<div class="freedImg"  style="     width: 100%;     ">
<p   class="freedImg"  style="     width:inherit;   ">[[File:The fall of Ulysses pg 48.jpg|link=|alt=]]</p>
<p class="imgCaption" style="text-align:justify; text-indent:1.75em;">{{Lorem ipsum}}</p>
</div>
</div>
</div>

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Seems to work the same as if we tweaked the Primary DIV Container. If this way pans out to work for everyone all we need to do to keep things pure is create a template that adds this container while calling the FreedImg template to produce the same results.

The alternative solution to directly meddling with the FreedImg parameters is to add min & max somewhere in the CSS and see if that works. I'd rather not mess with the CSS if at possible however. -- George Orwell III (talk) 20:33, 13 June 2013 (UTC)

Very cool, I was working on something in userspace but your idea is not surprisingly more elegant. My concern came from the transclusion, and even worsened after you removed the min-width and max-width. I don't want to be doing percentages of percentages so that the images aren't too large; ideally I'd like to wrap the image in a max-width container like you've shown above with the premise that such a "max-width" does exist for decent functionality of the transclusions. I'm gonna create a draft subpage of {{FI}} with the container you've made above to play around with at Red Riding Hood. - Theornamentalist (talk) 21:34, 13 June 2013 (UTC)

Impo'tant!!!

If your browser has anything like an "enable Automatic Image Resizing" setting or settings, please make sure to disable them while you test anything related to the FreedImg initiative being introduced/discussed in this section. It will greatly reduce the chances of 'false' positives but don't forget to renable it when your done (or not). -- George Orwell III (talk) 22:06, 22 August 2013 (UTC)

Twitter accounts

Hi! Who is managing the 2 twitter accounts? (wikisource_org, wikisource). Would it be possible to use them for general announcements about the Wikisource User Group too? --Micru (talk) 13:43, 19 July 2013 (UTC)

I cannot remember, John Vandenberg was asking questions a couple of years ago, he may have found out the answer. — billinghurst sDrewth 13:29, 21 July 2013 (UTC)

Tech News: 2013-30

Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Translations are available.

Recent software changes (Not all changes will affect you.)

Future software changes

Tech news prepared by tech ambassadors and posted by Global message delivery • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

21:03, 21 July 2013 (UTC)

Arup kumar duty

I entered a search query "Kolkata" and got the article Arup kumar duty. Is there any reason why this article has not been speedily deleted yet? Solomon7968 (talk) 17:16, 22 July 2013 (UTC)

I guess nobody noticed it was [improperly] added last month. Done George Orwell III (talk) 17:51, 22 July 2013 (UTC)

Pywikipedia is migrating to git

Hello, Sorry for English but It's very important for bot operators so I hope someone translates this. Pywikipedia is migrating to Git so after July 26, SVN checkouts won't be updated If you're using Pywikipedia you have to switch to git, otherwise you will use out-dated framework and your bot might not work properly. There is a manual for doing that and a blog post explaining about this change in non-technical language. If you have question feel free to ask in mw:Manual talk:Pywikipediabot/Gerrit, mailing list, or in the IRC channel. Best Amir (via Global message delivery). 13:07, 23 July 2013 (UTC)

Very frustrating, to be forced to study new settings just to run old (and running) ones, painfully learnt. :-( --Alex brollo (talk) 16:42, 23 July 2013 (UTC)

1st Annual DPLAFest, Boston (October 2013)

I'm copying the following from the wikisource-l mailing for those that read this page but not the list. - AdamBMorgan (talk) 16:41, 24 July 2013 (UTC)

DPLA is planning the first annual DPLAFest, in Boston this October 24-25.
It would be great to have groups in attendance from Wikisource, Wikidata, and Commons. There are already some collaboration underway on Commons: Commons:Digital Public Library of America
If groups from each project would be interested in organizing a tent or sessions at the festival, space (both physical and on the agenda) could be provided. This is a good opportunity to connect with the heads of GLAM institutions, and the more technical curators and archivists (who should be recruited to the generative side :-)
[DPLA is] the Digital Public Library of America — a digital platform for sharing digital collections, and metadata about physical collections, of all sizes. Started in America, aiming to contribute to shared standards for similar work everywhere in the world. Focused on free-software toolchains, CC-0 metadata, and data APIs.


Translations & MoM

I see that moving Wikisource translations to the new name space is on the menu for Maintenance of the Month in September. Other thing have been keeping me busy, so just wanted to check in and see if we have all the bugs worked out now. Jeepday (talk) 22:42, 26 July 2013 (UTC)

There are still no embedded pagelinks. Wikisource:Administrators'_noticeboard#New_Name_Space. --D.H (talk) 07:31, 27 July 2013 (UTC)
According to the latest update of bugzilla:51980, ProofreadPage only creates a "Source" link in the mainspace. Page numbers might be resolvable locally but the source tab will need a change to the extension itself. I am not sure what, if any, activity is going to happen regarding this. Hopefully it will be resolved before September (I had hoped it would be resolved before August, everything else seems to work, but that seems unlikely now). - AdamBMorgan (talk) 12:58, 29 July 2013 (UTC)

Tech News: 2013-31

Latest tech news from the Wikimedia technical community. Please inform other users about these changes; not all changes will affect you. Translations are available.

  • The latest version of MediaWiki (1.22/wmf12) was added to test wikis and MediaWiki.org on July 25. It will be enabled on non–Wikipedia sites on July 29, and on all Wikipedias on August 1. [9]
  • Wikivoyage was offline for around 40 minutes on July 24. [10]
  • Pywikipediabot moved their code from SVN to git; bot owners need to update their tools. [11]
  • The Notifications and Thanks extensions were added to Meta-Wiki on July 26; other wikis will get them soon. [12]
  • It is now possible to add edit summaries on Wikidata using the API; the feature will be added to user interface soon. [13]
  • The software that resizes large PNG images on all wikis was changed on July 25. Resizing of PNG files bigger than 35 megapixels should be faster and more reliable now. [14]
  • Three new webfonts (Gentium, Old Persian and Shapour) will be added to Universal Language Selector. [15], [16], [17]
  • Special:MIMESearch, which gives a list of files by type, will be enabled on all Wikimedia wikis with MediaWiki version 1.22/wmf12 (bug #13438). [18]
  • A mailing list to discuss multimedia features was started; users are encouraged to sign up.
  • VisualEditor news:
    • On July 24, VisualEditor was added for logged-in users on the German (de), Spanish (es), French (fr), Hebrew (he), Italian (it), Polish (pl), Russian (ru) and Swedish (sv) Wikipedias; it will be added for all users on those wikis on July 29. [19]
    • A preference to completely disable VisualEditor while it is in beta phase was added on July 24. [20]
    • Many bugs were fixed in right-to-left languages. [21] [22] [23] [24] [25] [26]
    • It is possible again to scroll down in the template editing window (bug #51739).
    • VisualEditor now works with the FlaggedRevisions extension. (bug #49699)
    • If the user opens VisualEditor using a section edit link, the title of the section is added to the edit summary (bug #50872).
    • Invisible templates now can't be deleted by accident or on purpose (bug #51322).

Tech news prepared by tech ambassadors and posted by Global message delivery • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

20:44, 28 July 2013 (UTC)

Hosting of works

Unless my knowledge is outdated and policy has changed, shouldn’t source files be hosted on the Commons? I noticed that we are hosting more an more files on WS.— Ineuw talk 15:28, 29 July 2013 (UTC)

Nothing has changed and I noticed the same uptick in the local uploading of source files too. Much of it seems driven by the circumvention of local restrictions (internet provider?) put on accessing "true" Commons so they wind up uploading here to get around those limitations apparently. -- George Orwell III (talk) 20:44, 29 July 2013 (UTC)
Thanks for the clarification. I will move some items to the Commons - once I find out their source and copyright status.— Ineuw talk 23:56, 29 July 2013 (UTC)

Promoting Wikisource via YouTube

http://www.youtube.com/watch?v=n2aFziR5gHc

This is the first video of a series that Maury and I are creating to promote Wikisource via YouTube. We would just like to hear what you think.--Erasmo Barresi (talk) 14:21, 31 July 2013 (UTC)

In terms of style, it's well done and looks professional, but could make use of more color/font adjustments to emphasize key points. In terms of content, it's a little bare, without much information for the person who does not know what Wikisource is. The video was over before much had happened, and I think the average viewer will not understand something like "page insertion without scans is also possible". But the key difficulty is the narration; you need a speaker with a clearer, surer voice. Some words are badly mispronounced, are there are a few sentences that I can't understand at all; I expect this is because you are not a native speaker. I'd be willing to help with that last point, if you're interested and if we could work out a format and means of sharing an audio file. I've recorded spoken items for Wiktionary and Wikipedia before. --EncycloPetey (talk) 20:23, 1 August 2013 (UTC)
Thanks for your feedback and your kind offer. This is just the first video of a series and gives an overview of Wikisource. Other videos will focus on specific facets like policies and the community. At first I wanted to make one long video, but then Maury suggested me to make several short ones instead. I am very interested in your help and I'm going to email you for this.--Erasmo Barresi (talk) 14:11, 2 August 2013 (UTC)
, great start, Short ones are better. Jeepday (talk) 23:17, 2 August 2013 (UTC)
Very neat! Keep up the good work and shorts are best. — Ineuw talk 19:56, 7 August 2013 (UTC)

Is there copyright for dictionaries?

One typical page

Here is page from A Dictionary of the Sunda language (1862). It is a typical dictionary, a list of words in alphabetic order, each followed by a brief explanation and samples sentences. If this dictionary was instead written in 1962, would it be covered by (eligible for) copyright? Is it a copyrightable work of literature, or merely a list of facts? Or is there a line between non-copyrightable lists and a copyrightable kind of dictionaries? Is there any case law that draws that line?

As Swedish copyright law has evolved over the last century, there is plenty of case law for various strange cases, e.g. a factory playing music for their workers during an exercise break, and so on. But I haven't heard of any Swedish case law regarding the copyrightability of dictionaries. What about other countries, and in particular the U.S.? --LA2 (talk) 16:11, 1 August 2013 (UTC)

I'm pretty sure dictionaries are copyrightable. Possibly a simple list of words would be in the public domain but the definitions would count as creative works. Wiktionary uses modern dictionaries as references but copies older editions, just like Wikipedia and encyclopedia. - AdamBMorgan (talk) 16:19, 1 August 2013 (UTC)
Yes, dictionaries can be copyrighted. Older dictionaries can enter the public domain, but there is formatting, organization, quote selection, phrasing, and much other work that can be construed as original. The Oxford English Dictionary protects their copyright quite successfully. An individual translation of a word into English can't be copyrighted, but a collected database in the form of a dictionary can be protected.
Please note that Wiktionary tries not to use modern dictionaries as references, but looks for current examples of words in use. On Wiktionary, we prefer to find quotations that demonstrate the meaning of a word, rather than use dictionaries that claim the meaning of a word without supporting evidence. The idea being that dictionaries are secondary sources, and (as we have often found) are prone to some serious errors. Some translating dictionaries we've looked at have an error rate higher than 10% in spelling, orthography, and translation. I myself have a Galician-English dictionary by Routledge that isn't worth the paper it's printed on. --EncycloPetey (talk) 20:13, 1 August 2013 (UTC)
When you write that the OED "protects their copyright quite successfully", what evidence is there to support this? Any links? Anyway, the OED might be an extreme case of a dictionary with very detailed articles under each headword, with a simple list of words being the other extreme which obviously should not be copyrightable. Where is the line drawn between these extremes? --LA2 (talk) 20:26, 1 August 2013 (UTC)
I'm not looking for an argument, just enlightening you from my experience working for eight years on the English Wiktionary. Are you unable to look for this information yourself? A Google search for "oxford english dictionary copyright case study" pulls up numerous useful listings, so I don't understand why you're asking me to provide you with the evidence instead of putting out a little effort yourself. I can only conclude that already have made up your mind, and are not actually looking for the advice of others, so I won't bother with this discussion any more. --EncycloPetey (talk) 21:10, 1 August 2013 (UTC)
I'm really sorry, Google must give you and me quite different hits. I haven't found anything useful, relating to the OED. --LA2 (talk) 21:40, 1 August 2013 (UTC)
  • Brazil, case 04.127327-3 (Dec. 14, 2004), plagiarism of a dictionary of legal terms, verdict on June 6, 2007: copyright was valid, Summary by Luciana Carvalho
  • India, V. Govindan vs E.M. Gopalakrishna Kone And Anr. (1 December, 1954), plagiarism of an English-Tamil dictionary, copyright was valid, Judgment


Under US copyright law (in which jurisdiction WMF operates), there can be no copyright in facts themselves.

But there can be copyright in

  1. the creative decision of what facts to include and what to exclude, how the facts are ordered, arranged, etc.
  2. the way in which those facts are expressed in words.

And the threshold of originality required to attract copyright is extremely low.

A typical dictionary would hold both of the above forms of copyright. The individual definitions of each word would meet the threshold of originality and be protected. And the list of words to be included would generally be protected too, although a dictionary that claimed to be 'complete' would have less claim to protection than a more selective dictionary.

For more information see Feist v. Rural / w:Feist v. Rural: "A compilation is not copyrightable per se, but is copyrightable only if its facts have been selected, coordinated, or arranged in such a way that the resulting work as a whole constitutes an original work of authorship."

Hesperian 00:57, 2 August 2013 (UTC)

Reprinted works

I have two books that I'd love to scan and upload, but I'm not 100% sure about their copyright status. They are 1800 Mechanical Movements, Devices, and Appliances, by Gardner D. Hiscox (ISBN 978-0-486-45743-7) and 507 Mechanical Movements Mechanisms and Devices, by Henry T. Brown (ISBN 978-0-486-44360-7). The copyright page of the Hiscox book states, "This Dover edition, first published in 2007, is an unabridged replication of the 1921 sixteenth (enlarged) edition of the work originally published in 1921 by The Norman W. Henley Publishing Co., New York, under the title Mechanical Movements, Powers and Devices: A treatise describing mechanical movements and devices used in constructive and operative machinery and the mechanical arts, being practically a mechanical dictionary, commencing with a rudimentary description of the early known mechanical powers and detailing the various motions, appliances and inventions used in the mechanical arts to the present time. The first edition was published in 1899." The Brown book has a similar note: "This Dover edition, first published in 2005, is an unabridged replication of the nineteenth edition (1901) of the work originally published in 1868 by Brown and Seward, New York."

So, are these books {{PD-old}} because of the original publication date? Or has the reprint renewed the copyright, even though no substantive content has been added? Thanks :) – GorillaWarfare (talk) 19:20, 1 August 2013 (UTC)

A reprint can't renew a copyright; although editing or adding to the work could create an entirely new copyright. If they really are unabridged replicas they are not under copyright (in the same way that Wikisource cannot claim copyright on the works we replicate in unabridged form). There are some Hiscox books online according to U. Penn., although a lot are on HathiTrust, from which it would be a pain to extract them. - AdamBMorgan (talk) 17:47, 2 August 2013 (UTC)
I forgot to add, Brown might actually be {{PD-1923}} as I can't find his death date. Hiscox died in 1908, so he is {{PD-old}}. - AdamBMorgan (talk) 17:53, 2 August 2013 (UTC)
Ah yes, I meant PD-1923. – GorillaWarfare (talk) 18:59, 2 August 2013 (UTC)
According to this page, Brown died in 1906. Is that correct? —Clockery Fairfeld (talk) 13:14, 3 August 2013 (UTC)
Yes; I found this New York Times obituary scan from 1906 that confirms. – GorillaWarfare (talk) 17:11, 4 August 2013 (UTC)

Maintenance of the Month for August

Crossed spanner and screwdriver overlaid on the standard Wikisource iceberg logo

The current Maintenance of the Month task is:

Portal classification review

Checking the classification of Wikisource portals

Previous maintenance: Works with no copyright tag

There are currently 978 portals needing review, but the task would be completed if each active user reviewed the classification of just four portals. If you feel that a portal is classified incorrectly, you can raise the issue here.--Erasmo Barresi (talk) 11:30, 3 August 2013 (UTC)

I don't understand how this is supposed to be checked, what is supposed to be checked, or what this will accomplish. What exactly is being checked? Is categorization being checked? Is the letter code being checked? Is the title being checked? What is being checked?
And how will this review help with issues like Portal:Drama and Portal:Plays that appear to duplicate the same subject, but not exactly? --EncycloPetey (talk) 20:24, 10 August 2013 (UTC)
The letter code is the main thing. Checking that the portal itself makes sense, that it is properly categorised, etc, can be done too. Last time it came up I quickly made this page, which might help: Help:Portal review. I've just added categorisation to it. As for what it will accomplish: it was requested when the portals were being moved from indexes in the project space, which was when the classification system was first implemented. We wanted to be sure it was being done properly. Personally, a lot of the classification has been done by me (and I'm still occasionally making small adjustments to the structure) and it would be nice to know if it loots like it is being done properly, if it makes sense, and so forth.
The two portals you mention might need to be merged. It's not my area but I think I tried to work out the difference between the two related categories a while ago. It appears I moved Drama to be subordinate to Plays, while I haven't done the same to the portals. I would prefer that someone who actually understands the subject have a look at it and fix whatever needs fixing. - AdamBMorgan (talk) 22:20, 10 August 2013 (UTC)
Thanks for the reply. As for Drama/Plays, it would depend on what meaning we gave to the term "Drama". Drama can refer to the overarching genre, or to a particular style of dramatic literature. Drama certainly shouldn't be subordinate to Plays, since "play" is the more narrow term. Drama is any form of fiction presented through performance, while a play is a specific subset of that genre in which there is scripted dialogue. Drama sometimes lacks dialogue, or lacks a script. I'm not sure whether there is a need to have separate portals, but I could see an advantage in having "Drama" contain works about the medium, as well as those works that are not plays, and to have the indiviual plays listed at "Plays". Failing that, the two probably should be merged. --EncycloPetey (talk) 22:40, 10 August 2013 (UTC)
I think Category:Drama might need to be disambiguated to Category:Drama (genre) as it is currently a partner to Category:Comedy and Category:Tragedy. The portals are a different case. - AdamBMorgan (talk) 21:18, 11 August 2013 (UTC)

Is there any merit in using WikiProject banners?

I'm just curious if this would be useful on Wikisource and I'm not sure myself. Wikipedia makes wide use of WikiProject banners; practically every page has one or more on its talk page. Mostly they are just a message box with an image and the text "This article is within the scope of PROJECT, a collaborative effort to improve the coverage of PROJECT articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks." Often they have a page status "quality assessment" feature that we don't need. Is there any merit in adding something similar to talk pages on Wikisource?

On one hand, this could allow users interested in particular topics to get together and/or show them other works in the subject area that they may like to work on. A lot of our WikiProjects are a little dormant at present and this could change that.

On the other hand, it would be a lot of work which might turn out to be pointless. A lot of our WikiProjects are a little dormant at present and they might stay that way, so pointing them out isn't useful (also, we would need to start at least a few more WikiProjects to cover everything). - AdamBMorgan (talk) 17:56, 5 August 2013 (UTC)

I'm not sure. Most of our WikiProjects seem to be work-specific rather than the more topic-based projects on WP. Our equivalent to the topic-based projects is Portals, which we link to from the header. Beeswaxcandle (talk) 20:28, 7 August 2013 (UTC)
In my view, such banners are useful for many internal Project aims (like tracking) and little else on Wikisource. I just don't believe we have the traffic in general & project membership in particular to justify the roll out of an across-the-board seeding of such banners at this time.

In addition, the once popular notion that adding such banners in the mainspace early on in WS development has since faded (to a large degree) by the consensus today that such Wikipedia-ish banner practices detracts from the goal of presenting our works as near and as clean as first published in the mainspace.

Finally, applying Project banners in the associated talk namespace instead gains en.WS very little in the way of additional exposure, since 1.) internally, talk pages are frequently overlooked without the presence of some pointer to its existence (such as | edition = yes ) at the same time; and 2.) externally, search engines rarely make it a point to crawl wikifoundation-like talk pages as part of their formulas in building search result hits.

So unless you want to increase internal awareness of established Projects amongst what already amounts to regular contributors, who probably already know about the ones we already host, I just don't see any real reason to pursue this any further until "conditions" improve enough to warrant their full development &/or implementation. -- George Orwell III (talk) 21:07, 7 August 2013 (UTC)

Part of my thoughts on the matter concerned connecting users to other users and more specific information. From the reader side of things, we have categories and portals to cover the "more works like this" area. However, if a user is interested in the editing side of things a WikiProject could serve the "more projects like this" and "users interested/experienced in editing this type of thing" areas. Most new users are probably going to be at least a little familiar with Wikipedia, which essentially trains its editors to look for a banner on the talk page. WikiProjects, if they are used, could help get people started or get advice about a specific aspect. (Also, for simplicity, we could start with broad new projects like WikiProject Poetry or WikiProject Fiction, possibly with task forces like "Romantics" or "Victorian novels" within them for more specific things). It may well be more trouble than it's worth at this stage, of course. - AdamBMorgan (talk) 17:43, 9 August 2013 (UTC)


From my experience at the English Wikipedia, 99% of the work that is done at WikiProjects is targetted at maintaining the WikiProjects themselves. They are self-sustaining busywork projects that contribute little or nothing to the encyclopedia. For example, hundreds of editors rush around tagging talk pages into the latest WikiProject, and hundreds more run article 'assessments' that involve little to no actual assessment, and then a bot generates stats, which no-one ever uses in a meaningful way. The one good thing that a WikiProject does offer is a talk page where like-minded people can come together to discuss and coordinate their contributions. The really successful WikiProjects are the ones with really successful talk pages e.g. WikiProject Plants. In such cases, nearly all of the real value of the WikiProject stems from the discussion page. Where a suitable venue for discussion already exists (e.g. the Australian Wikipedians' notice board), a WikiProject has little of value to offer (hence the Wikiproject Australia talk page was a wasteland for years until some sensible person finally redirected it to the notice board). So my view is, by all means create Wikiprojects if there is a community of common interest to be brought together to discuss and coordinate their work. But let's not go down the road of all that Wikiproject paraphernalia: tagging, banners, awards etc. It offers nothing of substance, and will only serve to distract us from our mission. Apologies for the negative post; I've always had a cynical view on this. Hesperian 01:44, 10 August 2013 (UTC)

No problem on the negative post. I wasn't sure myself and none of the other posts were exactly positive. I'll probably give this up as not worth it. - AdamBMorgan (talk) 02:40, 10 August 2013 (UTC)
I have some tentative ideas on WikiProjects operating inter-wiki rather than intra-wiki. I would agree that the scope of WikiProjects here on enWS doesn't need so much expansion just for "corporate identity" reasons. It would seem natural for a project on a multiply-authored work to want to curate its group of authors here, for example, via author pages. When I say "inter-wiki", I'm thinking now of tools on Labs that could effectively support curation of WP articles matching articles here, as does the recent DNB ratios tool. But banners here wouldn't really come into it. Charles Matthews (talk) 06:37, 10 August 2013 (UTC)

Superscript/Subscript annoyances

I'd like to add the following to our css: 

sup, sub {
	line-height:0;
}

It will prevent superscripts and subscripts from automatically adjusting the line height. Compare the final line(s) of:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean commodo ligula eget dolor. Aenean massa. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec quam felis, ultricies nec, pellentesque eu, pretium quis, sem. Nulla consequat massa quis enim. Donec pede justo, fringilla vel, aliquet nec, vulputate eget, arcu. In enim justo, rhoncus ut, imperdiet a, venenatis vitae, justo. Nullam dictum felis eu pede mollis pretium.[1]

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean commodo ligula eget dolor. Aenean massa. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec quam felis, ultricies nec, pellentesque eu, pretium quis, sem. Nulla consequat massa quis enim. Donec pede justo, fringilla vel, aliquet nec, vulputate eget, arcu. In enim justo, rhoncus ut, imperdiet a, venenatis vitae, justo. Nullam dictum felis eu pede mollis pretium.[2]

  1. ↑ Integer tincidunt.
  2. ↑ Integer tincidunt.

I don't believe this will have any unwanted side effects, however I would like others' opinions first. --Eliyak T·C 03:57, 7 August 2013 (UTC)

  • I'll go along with (the third version of—only teasing!) this:  Support MODCHK (talk)
  • I  Support this. And if we don't do this site-wide, I'm still adding it to my style sheet because I've always hated that behavior.—Zhaladshar (Talk) 14:01, 7 August 2013 (UTC)
  •  Support - just so I can finally remove something similar from my User: .css settings once and for all. And fwiw... I had modified these a long time ago with no adverse effects in the various final renderings of their most common usage whatsoever but those of you who SUB/SUP in your signatures might not like the fact you will no longer "stand-out" as much when you sign your comments however. -- George Orwell III (talk) 21:18, 7 August 2013 (UTC)
A minor clarification: In my tests this did not cause the superscript or subscript to be higher/lower than before, it just changed the line spacing spacing between the lines of a body of text (or the line-height in .css terms). On a rare occasion this will make the super/subscripts on consecutive lines somewhat close together, but not (as far as I can see) overlapping. --Eliyak T·C 23:34, 7 August 2013 (UTC)
fwiw... I never saw any "overlap" either and I was using a line-height of 1.0em instead of Eliyak's 0.0 setting. What I never could figure out is why or what prevented the line-height from changing on other sites like Wikipedia in the first place. You'd think if this setting "came down" from the .css on the servers for them, it should already be our default as well (granted I haven't checked for this in quite some time now however). -- George Orwell III (talk) 01:58, 8 August 2013 (UTC)

┌───────────────────┘

  • I couldn't take it anymore and went ahead with adding Eliyak's proposal to our Common.css file. Hopefully everyone is seeing this addition in uniform effect. Plz report any issues as a result of this change asap. -- George Orwell III (talk) 20:46, 10 August 2013 (UTC)
Seemingly a dream,
text and footnote are in line.
Thank you, GO3. --Eliyak T·C 03:12, 11 August 2013 (UTC)

Author page links to other language Wikisources

Is it acceptable to link to author pages of Wikisources of other languages, such as in this page? Most of the authors listed there wrote in French and don't have any works here. Or should new author pages be created? —Clockery Fairfeld (talk) 09:47, 9 August 2013 (UTC)

In this case new author pages should be created as they have contributed to this particular work, which we are hosting here on enWS. Beeswaxcandle (talk) 09:53, 9 August 2013 (UTC)
I would rather red-link than link to other Wikisources. For casual readers who are unfamiliar with our multi-language projects, they would experience it as clicking on a link and finding themselves suddenly stuck in a foreign language interface. Hesperian 09:57, 9 August 2013 (UTC)
Concur with Beeswaxcandle & Hesperian. JeepdaySock (AKA, Jeepday) 10:29, 9 August 2013 (UTC)
Pretty much the same here, though I am more likely to create the author page, and Phe's author lookup script (check my common.js file) helps to check enWP for the author and assist in the creation, similarly the authority control script assists too, and then you can add the interwiki link on the author page. — billinghurst sDrewth 07:37, 11 August 2013 (UTC)
I just created the author pages. I agree with everyone else, especially as these links exist because there are going to be works on English Wikisource, so there should be author pages here. Aside from the expectations of and benefits to our readers, how will someone looking at the French or Greek page for Anna de Noailles know that there are English versions if there is no corresponding page here? (Not all of them had pages on other Wikisources anyway.) - AdamBMorgan (talk) 21:13, 11 August 2013 (UTC)

"Bollywood" on WikiPEDIA

On WikiPedia's Featured article for today I saw, "She has become one of Bollywood's highest-paid actresses and ..." I looked for Bollywood on WP and found nothing. I know no one on WP these days and did not know where to post but someone here knows who to contact there to make a correction.—Maury (talk) 21:19, 14 August 2013 (UTC)

See w:Bollywood.--Mpaa (talk) 22:27, 14 August 2013 (UTC)
She was quite good in Krrish. As it happens, lots of countries have an -ollywood. Lollywood, for example, is the name of both the Pakistani film industry (based in Lahore) and the Nigerian film industry (based in Lagos). I don't know when or why it became popular but language is sometimes odd like that. - AdamBMorgan (talk) 23:19, 14 August 2013 (UTC)
Well, somehow I missed Bollywood even though I found w:Dollywood and even an w:Ollywood. Trees are a historical and interesting industry. —Maury (talk) 03:11, 15 August 2013 (UTC)

Template:Cl-act-section

Enough. This template, which myself and others have tried to get working consistently still refuses to do so.

The problem is that apparently owing to the way mediawiki parses, two issues arise which at present seemingly assert themselves in a complementary manner. The two issues are :

  1. paragraph continuation over a page break.
  2. line breaks between multiple paragrpahs.

At present attempts to fix either of these issue results in the other one re-appearing.

Can someone re-write the template in a non-breaking manner so that NEITHER issue occurs?

If this issue is not resolved in a 7 days, I am going to start removing it and marking the pages that formerly used at as problematic, due to parser technical issues. ShakespeareFan00 (talk) 12:49, 15 August 2013 (UTC)

Requesting deletion of entries here:

on the basis that these are the only items actually using the cl-act-section derived templates. ShakespeareFan00 (talk) 13:33, 15 August 2013 (UTC)

Not being familiar with the problem, could someone be more specific? What is the template's actual purpose? (It has no documentation!) Examples of a page affected by each issue would also be helpful. --Eliyak T·C 15:50, 15 August 2013 (UTC)
The purpose of cl-section is to format blocks of text with side titles (based on markup passed from higher level templates.) For an example of the paragrpah continutation issues see: Cinque_Ports_Act_1821, in a number of locations here a text paragraph should flow continuously over a page break. It's not doing this. When this issue is solved (as explained above) normal markup pargrpah breaks are not generated correctly. Because the issue of no line feeds only manifests when the page continuation issues is 'fixed' it is not possible to provide an example of this glitch in operation right now.

I'm NOT willing to enter into a prolonged thread about this, the template needs to be re-written, or it will be removed. ShakespeareFan00 (talk) 16:50, 15 August 2013 (UTC)

Proposed for deletion - it doesn't work, and there seems to be a lack of interest in ensureing it does. ShakespeareFan00 (talk) 12:19, 16 August 2013 (UTC)
Always the simple things, it wasn't this template that was broken, it was my logic  :( ShakespeareFan00 (talk) 22:07, 16 August 2013 (UTC)
I don't know about that but it is rendering better than before. Still - I can't get your "anchor id" part to produce a true anchor designation that interlinks could link to & work. See HERE (skip the first 16 or so errors; those are universal to any transclusion to the mainspace not just your's). -- George Orwell III (talk) 01:17, 17 August 2013 (UTC)
It seems that the ID linking doesn't like brackets. Not sure how to easily fix this ShakespeareFan00 (talk) 09:00, 17 August 2013 (UTC)
Other than by obviously taking them out :) ShakespeareFan00 (talk) 09:06, 17 August 2013 (UTC)

Arabic character list

Is it possible to have Arabic characters listed in the traditional character list (below the text edit area) like the listings of Hebrew Greek and Cyrillic? I know that Arabic characters exist in the advanced editor but I am using the "legacy" Wiki editor. — Ineuw talk 03:27, 17 August 2013 (UTC)

Done Used list in enWP equivalent. If there are glyphs missing or in the wrong sequence let me know and I'll add them. Beeswaxcandle (talk) 04:52, 17 August 2013 (UTC)
Thank you very much.— Ineuw talk 04:55, 17 August 2013 (UTC)

Sporadic rendering of classic toolbar ...

In the past 24 hours we have had the rollout of mw:MediaWiki 1.22/wmf13, with that I am having sporadic presentation of additional toolbar buttons loaded with mw-customeditbutton. I am presuming that others are having the same issue, and I guessing that it is due to with the ResourceLoader finishing rendering parts earlier before the buttons are ready. I have emailed wikitech-l asking some questions, and hope that there will be some response and a suggested resolution. — billinghurst sDrewth 03:43, 20 August 2013 (UTC)

I have the same problem, not realizing/checking that there was a new version rolled out. This compounds with my other issue for which I filled a bugzilla report. After opening in edit mode, clicking the the 'edit' button restores both the image and the toolbar. — Ineuw talk 04:16, 20 August 2013 (UTC)
The function mw.toolbar.addButton used on User:Billinghurst/common.js and User:Ineuw/common.js is defined on module "mediawiki.action.edit". You need to make sure it is only called after that module is available. See mw:Manual:Custom edit buttons#Classic edit toolbar and mw:ResourceLoader/Default modules#mw.loader.load for more information.
PS: You may also want to use a single mw.toolbar.addButtons call to add all buttons. Helder 13:00, 20 August 2013 (UTC)
mw.toolbar.addButtons don't work.— Ineuw talk 16:55, 20 August 2013 (UTC)

Okay, I have converted (successfully) to mw.loader.using and mw.toolbar.addButtons. I will see whether it is successfully resolving my issue, or not. Then I will work out how to integrate my if statement button into place. — billinghurst sDrewth 01:00, 21 August 2013 (UTC)

Hi Billinghurst. Have you implemented yet, the new edit toolbar? I copied your code after your yesterday's post, but couldn't get it to work, so reverted to my old code - which now functions constantly! My major problem is still the sporadic non-display of the scans. I also considered that my "unorthodox" editing toolbar was related to the OCR display issue, but it didn't because I proofread for a day without the custom edit toolbar (removed all code), but the OCR display problem still persisted. — Ineuw talk 22:58, 21 August 2013 (UTC)

HotCat

Does HotCat work for you? For me, it works on enWP and Commons but not WS. Bye--Mpaa (talk) 14:57, 20 August 2013 (UTC)

Working for me. Try blanking your common.js file (or monobook.js if you are using that in preference), and retry, to see if it is related. — billinghurst sDrewth 00:55, 21 August 2013 (UTC)
Now should be OK. I blanked commons/vector.js. Funny thing is that rolling them back, it still works. Strange world ... Thanks for the tip.--Mpaa (talk) 07:39, 21 August 2013 (UTC)
Guessing that it was a caching issue due to the upgrade, and if that is the case, we probably should have started with a 'flush your cache'. — billinghurst sDrewth 14:02, 21 August 2013 (UTC)

HTTPS for users with an account

Greetings. Starting on August 21 (tomorrow), all users with an account will be using HTTPS to access Wikimedia sites. HTTPS brings better security and improves your privacy. More information is available at m:HTTPS.

If HTTPS causes problems for you, tell us on bugzilla, on IRC (in the #wikimedia-operations channel) or on meta. If you can't use the other methods, you can also send an e-mail to https@wikimedia.org.

Greg Grossmeier (via the Global message delivery system). 18:59, 20 August 2013 (UTC) (wrong page? You can fix it.)

As I just updated on the meta page, we've delayed this rollout by one week. The change will now take place on August 28 at 1pm Pacific Time. Please take a look at gadgets or bots you maintain to make sure they'll continue to work; more information at meta. Sharihareswara (WMF) (talk) 19:17, 21 August 2013 (UTC)

Blog post about Score - help me write this?

To follow up on Wikisource:Scriptorium/Archives/2013-06#Help_with_a_blog_post.3F: now that the big bugs are fixed, I believe we are now ready to write and publish a WMF blog post about the ability to add musical scores to Wikisource and other Wikimedia projects. Anyone want to help me with the draft this week? Sharihareswara (WMF) (talk) 21:11, 21 August 2013 (UTC)

I've never collaboratively written a blog post before. What sort of help are you looking for? - AdamBMorgan (talk) 21:21, 22 August 2013 (UTC)

Too many exclamation marks make Jack a dull boy.

Something I keep seeing around the wiki is a template informing me that "relevant formatting guidelines may have already been established!!!" and I should check the discussion page - an example can be seen here. My questions, for discussion: one, does anyone know where this lives? And two, does anyone have any objection to me changing it? One exclamation mark is alerting (sorta), three makes us seem overexcited. And, three: why does it appear to be being included on pages by default, even if they have no relevant formatting guidelines? It seems silly to be cautioning users against something unless that something is actually prohibited. Ironholds (talk) 20:25, 22 August 2013 (UTC)

If you were to open a book you would notice that it is consistent throughout the book. You will notice the font is all the same, the spacing is the same(etc). Depending on how the work is styled depends on how it should be styled. It's a good idea to keep work consistent. If people do not look at the discussion page and go ahead and make edits the work will not be consistently styled. It would be annoying reading something that has all types of font sizes etc. Some times the format is debatable and it is a good idea to discuss it in the discussion page. Also The discussion page is a good go to resource for how to format something.
Rochefoucauld (talk) 20:38, 22 August 2013 (UTC)
Yes; I'm not taking issue with that. As you say, when there is discussion on the talkpage, or there are existing conventions, it's useful to maintain consistency. This header, however, appears regardless of whether such discussion exists. I've got no problem with having it where they do, but it seems odd to warn people about something by default, when that something may not exist. That is inconsistency. Ironholds (talk) 20:45, 22 August 2013 (UTC)


Don't see the problem - it clearly states "guidelines may have already been established". What makes you think that means guidelines do indeed exist 100% of the time? The general point is to check the talk page for guidelines, if any, among any other relevant info being added there before editing/adding any Page:s.

I reduced the exclamation marks for now until the rash of independent formatting becomes an issue [again] which almost always runs contrary to the established formatting (whenever established formatting was made clear at Index: creation/start of course). -- George Orwell III (talk) 21:46, 22 August 2013 (UTC)

Yeah, the notice itself isn't unclear - what's unclear is why we're displaying that notice as the default. So, let me rewind.
The notice has one goal; preventing multiple, conflicting styles being used in a single work. That's laudable, and it's something we should encourage users not to do. To fulfil this goal, the notice is placed on index pages (possibly by default? I can't find how that's done) regardless of whether they have established style guides, or users working on them. In doing this, we undermine the goal, because it ensures that the notice is a default part of the user experience that bears no relation to whether a confirmed style actually exists - users learn to blot it out of their memory, and swiftly ignore it when they're looking at an index, because many of the times they have listened to it they've found that no such style exists.
Yes, it says "there may be guidance" - but given that the sole purpose of the template is to draw peoples' attention to guidance, why do we have it on pages where that guidance does not exist? What purpose does it serve, other than to create warning fatigue that undermines the template on those pages where it serves a purpose? Ironholds (talk) 21:53, 23 August 2013 (UTC)
The notice only appears when there is an Index talk: page. The primary purpose of the Index talk: page is hold information about where images can be found and to document any variations on style from WS:STYLE. The other main use is to indicate problems with the scanned file (such as missing pages). Any other uses of the Index talk: page are occasional, but most of the time the notice is relevant. We've had various versions of the notice appearing for ca. 18 months, but older versions were being missed and we ended up with multiple uploads of images and a wide variation of styles, thus the current version is a little more "in your face". Beeswaxcandle (talk) 22:28, 23 August 2013 (UTC)
Hrm; fair enough. Has it had a noticeable impact? Ironholds (talk) 01:00, 24 August 2013 (UTC)
How would you gauge whether it has had a noticeable impact? I do know that, once I had put guidelines for poetry formatting on the PotM (Diaries...) all of the previously inconsistent poetry formatting became consistent in subsequent edits. If that qualifies as "noticeable", then yes, it has had such an impact, as I've noticed this happen on other projects. I know that I always check for such guidelines on new PotM projects. --EncycloPetey (talk) 02:02, 24 August 2013 (UTC)
We have used that area to state where images are located on commons, to state which images are to be in .jpg or .png, I myself reminded all the use of "in use" command when we work on some of our works and more. That area serves us in many ways. Just one important statement there can be of much importance much less more than one important statement there. I am in the habit of looking there and I suspect most of us who have been here awhile look at what our administrators create and/or state which is important—even if they don't "state" it, if it is created we know our administrators and trust them to guide us and they do. Therefore they have our respect as administrators and very hard volunteer workers as well as aid that help us over years. Don't use the option if you dislike it. Life is filled with inconsistency. "Ironholds" only for a while but water makes rust of it—especially seawater. —Maury (talk) 05:15, 24 August 2013 (UTC)
I'm having difficulty parsing that comment, on several levels, but: I'm not saying the administrators are not hard-working volunteers (indeed, I'd argue we're all hard-working volunteers, to various degrees), and I'd love to have the opportunity to not use it - but that opportunity doesn't exist, firstly because (if I'm understanding Beeswaxcandle correctly) it appears automatically when an index talk page is created, and secondly because I'm objecting as a reader as much as an editor - I found it objectionable in execution more than in concept. Having said that, some serious thought has clearly gone into it, and if EncycloPetey's comments reflect a wider experience, then it's probably more good than it is harm. Ironholds (talk) 16:34, 24 August 2013 (UTC)
Gday Ironholds. I created the original concept of the notice, though it has morphed slightly in time. The original concept is based upon the issue that when we ha(ve|d) many people working on the same piece, that there was often a lack of consistency with the first cut of the editing, and this was most noticeable from "Proofread of the Month" works. My solution was that we could utilise the Index talk pages to make notes about what is happening, especially as this is usually not the norm, especially as historically we have not been using those talk pages. If we have had a practice change in ise, then maybe we could look to do some more to purify the situation. How many situations are we talking? — billinghurst sDrewth 13:07, 26 August 2013 (UTC)

Bloody Red Exclamations

If possible, would someone with the authority please remove the pretty red exclamation marks to the postings of Hywel Dda (talk)?

I have been doing them one-by-one and the person has probably passed the required number of exclamatory marks. Thank you to whomever does it. —Maury (talk) 22:20, 22 August 2013 (UTC)

From what I see there are only edits in the Page: ns, and I like to see edits in the main ns before I give autopatrolled. You shouldn't be perturbed by the patrol marks, and there is no need for you to do anything with them, they are only indicators. — billinghurst sDrewth 08:45, 24 August 2013 (UTC)

Deletion Request

Please delete the following: - The Traffic Signs (Welsh and English Language Provisions) Regulations and General Directions 1985 The Traffic Signs (Welsh and English Language Provisions) Regulations and General Directions 1985/Part2 The Traffic Signs (Welsh and English Language Provisions) Regulations and General Directions 1985/Explanatory Note

Whilst these were transcribed in good faith, I can't find a clear notice that these are in fact covered by the OGL license, the advice here ( http://www.legislation.gov.uk/contributors#westlaw) not being helpful in confirming the Westlaw Contributions as OGL. Given no clear license statment, there is no clear OGL release..

ShakespeareFan00 (talk) 15:53, 23 August 2013 (UTC)

Done via CSD notification process. Beeswaxcandle (talk) 22:29, 23 August 2013 (UTC)
I would have thought that these clearly come under the {{PD-GovEdict}} licence. — billinghurst sDrewth 08:41, 24 August 2013 (UTC)
The text might, the scans I was working from don't necessarily. There's a number of threads at Commons concerning a related issue with legislation.gov.uk scans of original eanctaments of primary legislation.

The issue here (and at commons) isn't that the items aren't PD, it's that the release was unclear, as to the applicability of the OGL license. I've mentioned the ambiguity to the relevant contact point for the legislation.gov.uk site, if as I am expecting, they confirm this is a non-issue, the pages can be restored. You of course are welcome to make your own representations to them directly. ShakespeareFan00 (talk) 10:03, 24 August 2013 (UTC)

If it is the scans which are the issue, and not the text, then that should have been the discussion. We could have substituted the text, so that the scans could have been removed. We have a process for a good reason, and it would have been worthwhile if it had been followed. I request that the pages be resurrected, and if the scans have been deleted, then we can resurrect to have the text substituted. — billinghurst sDrewth 14:40, 24 August 2013 (UTC)
No objection to page restoration if the status can be confirmed. This was a manual TEXT transcription I hadn't uploaded the scans. It was in adding the 'frame' at the bottom to do the required attribution that the seeming ambiguity of the release on the leigslation.gov.uk site prompted my concerns. ShakespeareFan00 (talk) 16:27, 24 August 2013 (UTC)
The source scans (Not uploaded) are :- http://www.legislation.gov.uk/uksi/1985/713/made (but are sourced to a third party, the third party being a commercial entity whose main product is a legal publication subscription service.) ShakespeareFan00 (talk) 16:33, 24 August 2013 (UTC)
They may have published a copy of the documents, that however does not make them the copyright owner. I believe that the files should be undeleted. @Beeswaxcandle — billinghurst sDrewth 12:53, 26 August 2013 (UTC)
I deleted these as G7 Author request rather than for any license issues. I have restored them so that a discussion can tale place in the appropriate place. i.e. either WS:DEL or WS:COPYVIO. Beeswaxcandle (talk) 03:52, 27 August 2013 (UTC)

m:Requests for comment/Global ban for Ottava Rima

Per the m:Global bans global policy, you are informed of the discussion above. Please comment there and feel free to appropriately distribute more widely in prominent community venues in order to «Inform the community on all wikis where the user has edited». Nemo 10:10, 24 August 2013 (UTC)

Tech News: 2013-34;

Latest tech news from the Wikimedia technical community. Please inform other users about these changes. Not all changes will affect you. Translations are available.

New features

  • The previous version of MediaWiki (1.22/wmf13) was added to test wikis and MediaWiki.org on August 15. It was enabled on non-Wikipedia sites on August 19, and on all Wikipedias on August 22. [28]
  • The latest version of MediaWiki (1.22/wmf14) was added to test wikis and MediaWiki.org on August 22. It will be enabled on non-Wikipedia sites on August 26, and on all Wikipedias on August 29. [29]
  • You can now use new styles of galleries. Please give feedback to User:Bawolff. [30]
  • You can now visit a random page in a category, for example Special:RandomInCategory/Science. (25931) [31]
  • You can now use the <wbr> HTML5 tag to say where a word can be cut. (52468) [32]
  • Gadget authors: you can now use the wikipage.content hook, so that your scripts are re-run when a page is changed after the document-ready event (for example using Ajax). (30713) [33]

Problems fixed

  • There was a bug where file redirects didn't work when a file was renamed; it is now fixed. There is still an issue with purging, but it should be fixed soon. (52200)
  • Maintenance reports provided by special pages will now all be updated on each wiki every six months. This will for example give you recent information on uncategorized pages, unused templates and most wanted pages (see details).
  • There was a bug that caused false positives for anti-blanking edit filters; it is now fixed. (52077) [34]

VisualEditor news

  • The "edit" and "edit source" tabs and section edit links can now be changed more easily; for example, some wikis are using "edit source" for wikitext editing, and "edit beta" for VisualEditor. You can ask for the same change in bugzilla.
  • You can now edit references that are added inside a <references> block. (51741)
  • You can now test on mediawiki.org new basic tools to add and edit struck text (with the button for the <s> tag), lower text ( for <sub>), upper text ( for <sup>), underlined text ( for <u>), computer code ( for <code> and <tt>), math text ( for <math>), Egyptian hieroglyphs ( for <hiero>), and to say that text is in another language ( for lang="ar" dir="rtl"). (51609, 51612, 51611, 51590, 51610, 52352)
  • You can now use VisualEditor with the Opera browser. [35]

Future

  • Starting on August 26, you will be able to use data from Wikidata on Wikivoyage sites. [36]
  • Starting on August 27, you will also get notifications on the mobile site if you're logged in to a wiki using notifications. [37]
  • Starting on August 28, all users with an account will be using HTTPS to access Wikimedia sites. HTTPS brings better security and improves your privacy. Some countries (like China) will not use HTTPS. If HTTPS causes problems for you, tell us on meta. [38]
  • Starting on August 29, you will get the code editor interface to edit JavaScript and CSS pages on all wikis. [39]
  • The plan to use Solr for search in MediaWiki was changed; instead, Elasticsearch is now planned. [40]

Tech news prepared by tech ambassadors and posted by Global message delivery • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

19:56, 25 August 2013 (UTC)

Please delete all of this book

Index:Treatise_on_Navigation.pdf It should have been .djvu vs .pdf because no text is coming in. —Maury (talk) 01:59, 26 August 2013 (UTC)

Done you can just tag it with {{sdelete}} — billinghurst sDrewth 12:50, 26 August 2013 (UTC)
Thank you, billingsworth, but where exactly would I place that tag and reason for speedy delete? My respects, —Maury (talk) 15:47, 26 August 2013 (UTC)
It can be placed in the space where you enter the details about the pages. Or, if you prefer it, in the Contents area. —Clockery Fairfeld (talk) 16:23, 26 August 2013 (UTC)
Thank you. —Maury (talk) 03:24, 27 August 2013 (UTC)


/* HELP Please - New Zealand */

Done

Retrieved from "https://en.wikisource.org/w/index.php?title=Wikisource:Scriptorium/Archives/2013-09&oldid=13996712"