Wikisource

Wikisource:Scriptorium/Archives/2014-02

< Wikisource:Scriptorium‎ | Archives
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

Proposals

Expand New texts

{{New texts}} on the Main page is currently limited to just seven items. These often seem to roll into the ether after about a week which is a shame as I’m sure many people don’t visit WS that often and hence would have no idea of whats new on this site (eg. Jim of the Hills was added on 22/12 and has gone as of 24/12). I’d like separate fiction and non-fiction lists with at least 810 items in each. For me, New texts is the most important feature on the main page but it doesn't get any prominence.

Implementation might require adjustment of main page component placements and widths eg. two columns and/or a smaller font and/or a scrollpane. New texts could be inside a full page width box. I’m hoping that we initially just discuss the merits of an expanded list and worry about the how-to-do-it afterwards. Moondyne (talk) 14:19, 24 December 2013 (UTC)

I very much agree. Hesperian 15:09, 24 December 2013 (UTC)
Also agree, though I feel the number of texts listed is only part of the under-utilization issue.

This page was last modified on February 28, 2013, at 15:52.

That is what it states at very bottom of our Main Page at the time this post was made. Is it possible that Google, Bing and the rest crawl through here, note the most important page on a site was last "updated" some 11 months ago and move on without giving us the depth, width & breath of their analytical search-engine's attention that we rightly deserve considering, as you stated, it seems we can clear new works off that list faster than we can open them some days?

The point I'm trying to make here is that the current approach to listing new or featured texts - one that edits a subpage of some other namespace on a near daily basis rather than the Main Page - may be super convenient and uber familiar to most of the regulars by now but it probably isn't the most optimal approach to achieving this when it comes to drawing attention to our site's "freshness" or constant additions on the balance.

So I'm all-in on the proposal's aim, just think adding another layer isn't going to help matters much. An overhauled approach with expanded/dynamic listings is really the way to go here. The method to adding texts shouldn't have to change all that much; only the template's mechanics & the target pages involved upon saving the added listing. -- George Orwell III (talk) 15:29, 24 December 2013 (UTC)

That last modified timestamp should be removed, a la w:Main page.
<chuckle>Hiding it from human eyes is not the same as hacking it out of the underlying HTML. It is still there...
<li id="footer-info-lastmod"> This page was last modified on September 26, 2013 at 22:10.<br /></li>
... but Wikipedia would be the worst example to compare us to in the first place. The sheer amount of traffic they enjoy surely negates the bot-like adventures in what was the last timestamp even when done by simple random selection of works. We just don't have those numbers & that's why every little bit helps imho. -- George Orwell III (talk) 16:05, 24 December 2013 (UTC)
Dynamic lists are gonna be problematic… {{Special:NewPages/4}} - Moondyne (talk) 15:51, 24 December 2013 (UTC)
Took me too literally there. There are other ways to be dynamic than just the built in extension, no? -- George Orwell III (talk) 16:05, 24 December 2013 (UTC)
Umm, guys: Has anybody really thought about these logs and the implications of (re)opening up Main Page to plebeian edits? I rather though the whole point in funnelling these kinds of updates into a sub-page was so that the Main Page could be left locked down? Viewer2 (talk) 23:43, 24 December 2013 (UTC)
Quick and dirty solution: Any passing admin makes a minor edit to the main page every so often, possibly immediately undoing the same or making it invisible. It isn't elegant but the datestamp will be updated and security will be preserved. - AdamBMorgan (talk) 20:29, 8 January 2014 (UTC)
It seems that by removing their timestamp, Wikipedia actually does avoid having Google display an equivalent timestamp next to search results. Google *does* however realize that the main page is changing more frequently - here is the most current cached version, dated Jan 6, 2014 (compare to WP: Jan 7, 2014). (Google updates their cache based on how often they think a page is changing.) I'm going to go ahead and hide that timestamp like WP does however. --Eliyak T·C 10:16, 9 January 2014 (UTC)
Moving back to the new texts idea rather than search engine optimisation: I like the fiction/non-fiction split. Poetry is often considered a separate category but I would imagine it coming under fiction in this context. Judging by Wikisource:Works/2013, we don't seem to have much new fiction or poetry anyway (it it doesn't get added to the list often), so that shouldn't be a problem. Non-fiction might still see a lot of churn, though; there might not be much change on that front. - AdamBMorgan (talk) 20:25, 8 January 2014 (UTC)
I think an expanded New Texts area is a great idea, since it's the area that updates the most frequently anyway, and is therefore more "current" than some of the other Main Page content. Actually there are also a few other points I'd like to see improved on the Main Page. I've broken this out into a new section below. --Eliyak T·C 10:16, 9 January 2014 (UTC)

BOT approval requests

Reconfirm User:MpaaBot

"Bot flag will be reconfirmed automatically unless; if at least three established users oppose with no users supporting, then the right will be removed; three or more oppose and one or more support this triggers a vote, with a decision by simple majority. Loss of flag does not prevent edits, only impacts recent change visibility."

Reconfirm:

Bot Username Tasks Last Confirmation Next Confirmation Status
User:MpaaBot
  • Categorisation of PSM main ns pages
  • Default sortkey in Category:PSM contriutors
  • Generation and monitoring of redirect for PSM articles
  • Insertion of wiki-links to multipart articles in notes field of header template of articles
 January 2012 granted bot flag 2014, January Active;

Bot flag for User:EmausBot

Hello! I'd like to run my bot to clear local interlanguge links that already moved to Wikidata. My bot has a global bot flag and does this task in many other projects, including some Wikisource projects. I already started my bot because I thought that English Wikisource allows the automatic aproval of the global bots and now you can check the correctess of the bot's edits. --Emaus (talk) 12:13, 18 January 2014 (UTC)

  Support I made some random checks and looks OK for me.--Mpaa (talk) 12:31, 18 January 2014 (UTC)
  Support — As long as the User: is aware of our BOT policy. In short, since Wikidata pretty much means the death of the interwiki bot exclusion from that policy, either folks will continue to contribute their BOT expertise to en.WS after migration is largely over or run the risk of being de-flagged at the next review. -- George Orwell III (talk) 12:42, 18 January 2014 (UTC)
Support - In this edit we had two links before the bot, after we have three. All the other random checks I made showed one for one replacements. Jeepday (talk) 11:11, 19 January 2014 (UTC)

Granted.[1] Hesperian 01:46, 25 January 2014 (UTC)

Help

Other discussions

Goals for 2014

Yeah, there is a real chance that they may never be met, but I think it might be useful to maybe identify some actually doable things we might hope to accomplish next year. Anyone have any ideas? A few which come to mind to me, maybe:

  • Over the years, there have been reservations expressed from various individuals that wikipedia isn't the best place for high-school age editors to contribute. Considering this site is more about proofreading than writing essays, though, the same might not hold here. Can anyone think of ways to perhaps draw more high-school level editors here, and, maybe, try to get some things to do here which might more directly appeal to them. I see "Weird Tales" started printing in 1923, maybe we could try to get pdfs of the first issues to include here. I tend to think such material might appeal to such editors. Maybe some early Sexton Blake stories might be available too.
  • As I've said elsewhere, I think new editors might feel they have accomplished more by maybe doing a whole, if shorter, piece themselves, like short stories, magazine articles, encyclopedia articles, NARA pieces, etc. Can anyone think of any ways to maybe make doing such easier and more appealing. Also, does anyone think they might be able to generate (if we don't already have one) a tutorial perhaps like wikipedia:Wikipedia/Tutorial to help guide users through early pages?
  • Many of the old Victoria histories of parts of England are now PD, and could be included here. I think in the eastern US, and probably Canada, counties and similar governmental entities will often have older "History of (County X)" books put out by local history societies for counties, and probably for counties in Canada, as well as for the maritime provinces.
  • Unlike, say, wikipedia, which is pretty much exclusively a reference work, we have poetry, fiction, essays, and god knows what all available here. Admittedly, we don't have a really huge number of active editors here, but would there maybe be any interest in getting some genre-specific collaborations or similar projects going?
  • One of the things which really helped get me started at wikipedia was the CD release, in cooperation with I think UNESCO, of some of our more important articles on CD, freely available to all schools anywhere in the world. Paul Theroux's "Dark Star Rising" drew my attention to some of the really poor educational system in parts of Africa, and I loved the idea of maybe being able to get something to some actively interested students in a form that other students wouldn't steal from the library to sell for money to buy a chicken dinner, as he indicated regularly happened in at least some of those schools. Does anyone think something similar, for perhaps literary works, might be workable and possibly worth purusing here?

Anyway, that's just a few ideas to open up. Most all of you actually know this site much better than I do, and I think any input you might have regarding matters of this sort would probably be more workable, and I would love to see any you might have. John Carter (talk) 16:54, 15 November 2013 (UTC)

Nice idea. Some thoguhts:
  • Early copies of Weird Tales are very expensive. I've already completed the majority of the issues I could find (just half of one and a few bits and pieces on some others left to do). I keep planning to start a big personal push on Amazing Stories. I've uploaded several to the Internet Archive already, and I have more to upload when/if I get a better internet connection. There's enough there to keep people going for a while if they are interested in that. (Early issues of Astonishing Stories are largely PD too but Project Gutenberg already has those and the scans on Internet Archive need to be reuploaded to be derived properly). (NB: The scans I have are from a set of CDs I bought on eBay years ago; I don't know who scanned them but I've been checking them for copyright with a view to uploading them all to the Archive over time).
  • I'm not in a good position to consider what stops people from editing here (other than not knowing we exist). I've had conversations with Wikipedians that I couldn't understand: they found Wikisource to be too complicated (or hard, convoluted, complex, peculiar, or similar terms). I find it almost ridiculously straight-forward. So it's hard to see what they mean. If someone can identify that, it might be something to work on.
  • We could make a project for entry-level short works. The problem would be letting people know it's there.
  • I've been making help pages but we don't have a tutorial per se. If someone has the time, equipment and inclination, a video might help too. (There has been work on this in the past, and Italian Wikisource has one on YouTube, but I don't know what is happening there.)
  • Our classics are not our best work at the moment. I think the problem is partly that a lot of them are widely available already, which can discourage volunteers from putting in time and effort to proofread them (even if the new version would be better in our terms). For literary works, you would need to find something that Project Gutenberg or another agency haven't already done. - AdamBMorgan (talk) 17:59, 15 November 2013 (UTC)
Adam, short feedback- I have briefly read the above and am anxious to get to my own project being History of the Aztec and Mayans. In reference to "Amazing Stories" and [[Portal:Weird Tales|Weird Tales] I state that I like them a lot but they don't carry enough illustrations, other than out-dated old advertisements while they do carry a fair amount of text. That is good for reading online. However, I love PDF files because they are compact, resizeable, and searchable. You cannot download .PDF files from en.ws as a book without getting a lot of extra materials about wikisource on the sides and elsewhere. Therefore a PDF from "Book Maker" is of no interest to me. Working on that text would probably be interesting so perhaps setting up a few works and watching others to see if they work on the text might be a worthy idea. As for the PDF Files you placed on Internet Archives, those are intact and are good .PDF Files without them being placed on wikisource. The eye-catcher covers are always good and usually involves something spooky and beautiful sexy women in distress which appeals to young and older males. Even the books I am working on have more illustrations than those comics under scary names. So, the cover is appealing and catches the eye and draws the on-looker to the text and the text carries the short story onward. and the end is filled with old typewriter ads, dishwasher ads &c &c which may be of interest to whom? Respectfully, —Maury (talk) 22:24, 15 November 2013 (UTC)
On the French WS, we had the project a few years back, now completed, to have a complete anthology of French literature. The idea was to publish this in a CD. Do we have anything like this here? I already see 2 projects here: 1, an anthology of English literature; 2, an anthology of the world literature in English. Yann (talk) 15:43, 17 November 2013 (UTC)
For purposes of clarification, I think I should say that I would expect the CD, if there is one, to only consist of shorter works. Most every longer work of worldwide significance, from Augustine's Confessions to Marx's Communist Manifesto and Macchiavelli's The Prince is already available as a separate pdf file, and there would be no necessary reason for us to duplicate it, although I think it would be very useful to perhaps work with Open Library or any similar entity which might already have a page dedicated to that effect. I guess I would be thinking of stuff like, perhaps, various shorter forms of fiction, including a lot of short stories, Poe's The Raven and some Browning and Byron and Goethe, various myths of various traditions, including hopefully some Arabian Nights and Oceanic and Native American, works of what might broadly be called philosophy, some travel narratives, shorter biographies, and the like, with the focus on particularly important works which don't yet necessarily have readily available separate files or pages at archive.org, Open Library, and the like. John Carter (talk) 16:09, 17 November 2013 (UTC)
I would love to have a CD from en.wikisource. I edit, edit, edit and only get to read what I edit. Otherwise, when I have time to edit I would be reading and then there is no editing being done. Basically all I read here are the books I edit and some I validate. I would not want any How-to CD. Just the books - which, if possible, I would like to use for listening to while driving on long trips. ("Imagine" - John Lennon) —Maury (talk) 02:12, 18 November 2013 (UTC)
I have not yet but intend to collect AdamBMorgan's works here on "Weird Tales" and "Amazing Stories" as well as those he mentions above from Project Gutenberg. These are unusual works that I have only briefed over and enough of Poe and the like that I have heard many times over. I seek the unusual not the usual. But then perhaps I am being unfair to Poe since I once lived 4 years in Richmond, Virginia and saw his house many times. Still, his life as an Editor of the Southern Literary Messenger (here on en.ws) is, I believe, unknown to most people. Therefore, AdamBMorgan's works added with Poe's works would be very interesting on a CD plus add other similar works. I also understand what he questions regarding people on wikipedia saying wikisource is convoluted.

I think it might help to divide goals into "infrastructure" and "content". For example, a friend's comment about coming here was that the navigation was tricky. It is easy to understand why the regulars would not see that. So there are issues to address about author pages, portals, and how to move about project space; also dab pages, categorisation and so on. More than can be addressed in 12 months, I guess, so that compiling a shortlist would be helpful.

And then there is the issue of attracting people here, by means of content that they would be glad to read if they actually found it. Again there is a kind of division: are they navigating, or are they arriving here by search? Navigation via citation, attribution and poster links from enWP offers quite a large field of endeavour. And it relates to the crude idea of SEO for enWS, via interwiki power. Mirroring content available elsewhere is known to entail negatives for SEO. That, partly, is why there is work to do in raising the profile of Wikisource. A concise plan of action might be effective here, too. Charles Matthews (talk) 11:30, 18 November 2013 (UTC)

I like these ideas. It seems to me personally kind of less than productive that the main page for a topic here seems to be "Portal:". With the exception of a few biographies and some other topics, the need for such disambiguation/separation isn't really obvious to me, as most of the works we include here won't have their title limited to those words, and the name itself is probably the thing most people would look for, and maybe most search engines as well. I would I guess welcome, maybe, as a first step addressing organization of the content.
Actually the construction of a system of portals here was a big step forward. One thing to understand is that the category system is primarily designed to classify texts, not topics of texts. Charles Matthews (talk) 07:46, 23 November 2013 (UTC)
On a maybe only marginally related point, I think, maybe, one of the other problems we might face here is the comparatively low profile of this entity. From what I remember, wikipedia got where it is in a lot of search engines because a lot of other pages, including wikipedia pages, linked to their individual articles. I would think that, if anything, if the group of general-interest reference works we have available were completed, we might, if anything, maybe have even more pages linking to the "Portal" or whatever else it might wind up being called pages than wikipedia does. In terms of a plan of action to raise the profile, as Charles proposes above, I'd love to see any ideas of what sort of steps to take to raise the site's profile, but I unfortunately am far from an expert on the internet, and wouldn't have a clue where to start. John Carter (talk) 15:13, 22 November 2013 (UTC)
What works, in fact, is to have links here from Wikipedia that use interwiki linking, rather than ordinary URLs. In effect that means placing templates on Wikipedia, where it is legitimate to do so. For example {{cite DNB}} on enWP has created over 10000 incoming links. There is more to do for the DNB, Catholic Encyclopedia and EB1911, to name just three reference works that have commonly been used to build up WP. I have been calling this aspect of WS "Reference Commons" for three years or so. I'm happy to go into more detail. It's a rather different approach from publicising single texts.
I have thought for a while that WP templates like {{wikisourceauthor}} look a bit dated: the "poster" style is a bit clunky by today's standards. Certainly a design drive on the poster templates, followed by a serious effort to place them properly, would yield results. (These ideas are not that new. Considering that the {{commons category}} poster says it is on 360K pages, there is probably plenty to do.) Charles Matthews (talk) 07:46, 23 November 2013 (UTC)
The first point is a very good one, although I can see a problem with, maybe, possible proliferation. I've seen at least the beginnings of the Encyclopedias Americana, Britannica, Catholic, Century, and Chambers here, along with, potentially, a huge number of more specific topical encyclopedia. And the Annual Register and other yearbooks have at least some starts as well. Also, FWIW, I wasn't objecting per se with the intention of having the portals eliminated, but rather the portal namespace perhaps having the word "portal" removed from it and the portal pages maybe integrated into the main namespace. For the few works which would have identical titles to the base topic or "portal" name, they could be added as for instance, "Abraham Lincoln (Sandburg)" or something similar, much like they are done in wikipedia itself. Again, I'm not an expert on the internet, but I think, maybe, that might make linking to them easier, and maybe, although I don't know search enginges, maybe increase the ranking in returns. Regarding proposed drives on templates, we could definitely work with wikipedia on some of them. And, although I'm not sure how important this is, I do want us to maybe recognize that building wikipedia is only one goal here. There are, and have been, a lot of pages with content in wikipedia which have been found, well, questionable for an encyclopedia. I'm thinking here of an older dispute about the individual articles in wikipedia on the wikipedia:Weekly Torah portion in Judaism, where the individual weekly pages were, basically, quotes from biblical interpreters used in the parscha readings by Jews, among others. They are certainly worth having somewhere, but probably not there. This would be a more reasonable location for a lot of them, but to make it a more acceptable one we would probably have to work to increase this particular site's own search return ranking in general, so that editors of wikipedia would not think, as I think they sometimes to, consigning content to wikisource is, basically, condemning it to comparative oblivion.
Maybe, and this is just a maybe, we might start something in earnest around the first of the year, after some discussion regarding what to do. I do think, maybe, getting content in the Signpost about what we are trying to do here would be useful, but I doubt the regular editors of it would necessarily see themselves as being the people to write such pieces. What would the rest of you think about, maybe, working together, somehow, to get together regular pieces from individuals here to offer for circulation in the Signpost? John Carter (talk) 16:25, 24 November 2013 (UTC)
Rather hard to comment on all that. I'll make a couple of points. (a) The point of having namespaces to sort different types of content, and portals are better than having an undifferentiated Wikisource: project space. I don't see what you are saying about SEO. (b) Wikisource is distinctive among text repositories in a few ways: close relationship to Wikipedia, and use of ProofReadPage being two of them. We should certainly work also on a closer relationship with Wikidata. We should explain in what ways we "add value" to texts, e.g. with author pages. Over at the DNB project we have just revised our idea on a DNB author, against the published reference work by Gillian Fenwick; a contribution to scholarship. It has even been mooted that we create a wikibook about the DNB, collating the research that has been done on authors. Charles Matthews (talk) 10:58, 27 November 2013 (UTC)

Just to throw in some ideas, in the Catalan Wikisource we have a list of 50 must-have works that are not on the net. Some of them were available, but without text or scans, others we really had to hunt them for years, because sometimes it is not that easy to get first editions scans that are not available in IA or GB. It takes time and effort, however this way we are sure that we are the only ones in the net that have that content, and we don't worry about SEO: if someone looks for it, we are the first ones to be found.--Micru (talk) 18:09, 19 November 2013 (UTC)

If we could increase the number of pages which link to us, I think that would achieve the same basic goal of increasing our appearance on search engines. With among others the older and larger Toronto Public Library, Boston Public Library and New York Public Library being involved in the Google program, I'm not surer how many English sources won't be on archive.org, or similar sites, with the possible exception of works from Canadian, Australian, New Zealander, and other English speaking countries publishers which might not have been a priority to those libraries. But if there are any such sources out there with which to compile a list of essential works here as well, that would be more than welcome. I've started on my user page here a list of the PD reference works included in an old 1980s guide to reference works, and I don't think all of them are necessarily easily available yet, but I haven't finished checking them all out individually yet. But it only lists reference works of interest to the largely US audience. If anyone here isn't from the US or UK, are there any really vital works for other English speaking countries which we should have here? John Carter (talk) 15:13, 22 November 2013 (UTC)
That depends on what you think is "vital". The idea of encyclopedias and "reference works" originated in west, there are very few public domain "Eastern" reference works! However I can refer you to [www.banglapedia.org/HT/V_0043.htm Encyclopaedia Bengalensis] by Krishna Mohan Banerjee, however it talks more about Rome and Egypt than Asia (presumably because Indus Valley Civilization was discovered in 1921–22, 37 years after death of Banerjee!). Solomon7968 (talk) 15:40, 22 November 2013 (UTC)
For the West, the Western canon is probably the "must haves" of the English language. The actual list is debated and most are probably easily accessible in the public domain anyway. Nevertheless, it could be a starting point. - AdamBMorgan (talk) 17:52, 22 November 2013 (UTC)
I know in India, more or less I think up to the period of PD ending?, about the only works printed were basically broadly "religious", so wikipedia:Sacred Books of the East might well include all the "basics" for that area, and at least a lot of the relevant works from China as well, although it is, admittedly, 50 long books. Let me drop another note over at Jimbo's English wikipedia talk page - if we could get UNESCO or some other group familiar with the culture of the world to maybe give us a list of "core" works to include in a CD release, and if we could get it publicized reasonably well by the foundation, I think that might definitely help. John Carter (talk) 18:59, 22 November 2013 (UTC)
And, if we wanted to be really optimistic, I think the various works mentioned in the Timetables of History would also be at least worth considering for inclusion here, terrifyingly huge number of works that would be. John Carter (talk) 16:25, 24 November 2013 (UTC)
Well, I agree with the "Western canon" and related ideas above, and agree that it would be a monumental task. However, we should think big and plan long-term. If we have a list of must-have works around, we are more likely to bring in someone to tackle a missing one for us.
I would also add that we should look for interpretive or summarizing works. As a specific example: It would be wonderful to have all the great works of Japanese literature here in translation (and in Japanese on jp:WS), but for an English reader, this content would be a heap of unsorted and unfamiliar volumes if we just put up all the works. Anticipating this problem, I've been working on W. G. Aston's A History of Japanese Literature, which is a broad survey of the major works in that language. So, although we currently are lacking most of these works as translations, we will at least have this survey to guide readers and assist future editors. So, again, we need not only the great works themselves, but secondary works which summarize, evaluate, interpret, and contextualize those great works. Such secondary works will necessarily be far less numerous, but can be of enormous importance to our readers. --EncycloPetey (talk) 22:49, 18 January 2014 (UTC)

WikiEditor button-groups overlap textarea

Well if the coming upgrade to wmf8 is any indication, I might actually get my toolbar and vector tabs back in the Page: namespace for Christmas.

In my adventures, however, I realized another WikiEditor toolbar issue is "not just me" but something adverse to Internet Explorer (release 7 on up) overall. If someone generally with the same setup as me (XP/ie8/vector/wikieditor) can check the linked pics...

... to see if something similar is take place there as well.

I know this is easily solved by creating "blanks" for . . .

... locally here on en.WS and that would do away with those labels that are forcing the buttons to wrap below instead of inline(?) with them - but that's a work-around, not a fix. Personally, I'd prefer a fix.

Its curious that the 'size group' (re-sizes text) in the advanced menu has no label like Format & Insert do; nor does it have a default value preset in MediaWiki:Wikieditor-toolbar-group-size settings. That just reaffirms my suspicions of there being a bug related to the WikiEditor toolbar scheme beyond something that is caused by the latest wmf upgrade or whatever.

Anyway, if Tpt or Phe miss this, at least someone can verify my observations in the interim. TIA. -- George Orwell III (talk) 16:53, 22 December 2013 (UTC)

Thanks for the report. I believe it's more a bug in the WikiEditor than a bug in ProofreadPage and, so, should be reported in bugzilla in "MediaWiki extension/WikiEditor" category. Tpt (talk) 18:25, 29 December 2013 (UTC)
I screwed up my account there so... anyone ? anyone ?

And I didn't think it was PR based since the 'Advanced' tab had it before the PR related stuff was ever added. I just mentioned it so any urge to mimic what they currently have in moving forward is done with caution. -- George Orwell III (talk) 18:33, 29 December 2013 (UTC)

Reminder: Wikidata coming on January 14th

(This is a message to all Wikisource editions. Sorry for writing in English. I hope someone can translate this for me on the non-English editions.)

Hi!

I am Wikidata's product manager. If you are unfamilar with Wikidata please have a look at d:Q3107329 for example.

As you might already have heard Wikisource will be the fourth project supported by Wikidata after Wikipedia, Wikivoyage and Commons. We are currently planning this for January 14th. From this point on you will be able to handle the links between projects in Wikidata. This means you will only have to maintain them once instead of having them duplicated in every article. However fear not: the local interwiki links will still continue to work and they will overwrite what comes from Wikidata.

This is the first step of Wikidata supporting Wikisource. In a second step we will enable access to the actual data on Wikidata like biographical data about authors. I do not have a date for that yet however.

The planning is happening at d:Wikidata:Wikisource. We are still looking for some more ambassadors who can help during the process and make sure everything goes smoothly for you. Please add your name to the list at d:Wikidata:Wikisource if you're willing to do this.

If you have questions please also post them on the discussion page of d:Wikidata:Wikisource.


Cheers Lydia Pintscher (WMDE) 19:34, 29 December 2013 (UTC)

Tech News: 2014-01

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

Recent software changes

  • You can now see the text of DjVu and PDF files in search results on wikis testing the new search tool (CirrusSearch). [2] [3]
  • With the new version of the Wikibase DataModel extension, you can install it outside Wikimedia wikis. [4]

VisualEditor news

  • Images are now shown inside VisualEditor as HTML5 <figure /> elements. Comments are welcome. [5]
  • You can now test a basic version of VisualEditor on mobile devices; see this article as an example.

Problems

Future software changes

  • CirrusSearch will be added as the second search method for Spanish (es), French (fr), Portuguese (pt) and Russian (ru) wikis on December 30. Wikimedia Commons, Wikispecies and Wikinews users will also be able to enable it in their Beta Features options.
  • AbuseFilter log entries will be visible in CheckUser tool reports. [7] [8]
  • It will soon be possible to search for log entries done by users without an account. [9] [10]
  • It will no longer be possible to globally hide users with more than 1,000 edits. [11] [12]

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

08:45, 30 December 2013 (UTC)

Category suggestions requested

I've been searching for categories which refer more specifically to conservation, preservation, resources management, (renewable and not), wild animal management, like culling wildlife etc. - Ecology and Environment are too general. Can anyone suggest a suitable category title? — Ineuw talk 11:15, 31 December 2013 (UTC) P.S: I have at least a dozen articles LIKE THIS ONE which should categorized more suitably. — Ineuw talk 11:18, 31 December 2013 (UTC)

My own suggestion which would cover all is: Category:Natural resource management
Happy New Year to all. — Ineuw talk 11:59, 31 December 2013 (UTC)
Sounds like a good suggestion. --EncycloPetey (talk) 04:41, 3 January 2014 (UTC)

Overlapping of text and image in Page: namespace

Is it just me, or are the text and the image overlapping each other on pages from this index? Curiously, other indices do not seem to be affected. —Clockery Fairfeld (talk) 11:32, 5 January 2014 (UTC)

Its not you; its a long-standing defect with sidenotes in general finally revealing itself after the recent ProofreadPage extension's overhaul. -- George Orwell III (talk) 11:43, 5 January 2014 (UTC)
I originally was not going to suggest this as it is in fact such a bodgy solution, however looking at the quality of the validations so far I really cannot think I am capable of doing much more damage to this work than its current state.

The default column widths (not very well documented, applying to Page: space only) for {{sidenotes begin}} happen to be 11em (each side) and 35em (central column). Obviously the total width of 57em is vastly wider than the rule-of-thumb 400px a normal scan approximates to. I have substituted {{sidenotes begin|16|7}} as a narrower compromise in the header on several of the pages of this work. The display is painfully narrow, but at least no longer overlaps the scanned image.

There are still a number of mainspace issues outstanding relating to consecutive side notes overlapping vertically which I am still trying to work through. I suspect judicious use of {{-}} between certain paragraphs may be the answer to this? Viewer2 (talk) 14:08, 5 January 2014 (UTC)

<sigh> part of the problem all along has been the use of "fixed" measurements. The other is this unexplainable need to digitally mirror some early 20th century symptom of print even in the main namespace. Depending on your settings, monitor DPI, font, etc. the sidenotes column (actually a margin) should be 1/5 to 1/6 of the total viewable width (again depending). You can push or pull all you like using 'em' - it will never resize with window resize, nor print as rendered and dozens of other things that will eventually come to mind. I'd be happy with recovering the "margin" opposite the actual side with the sidenotes at this point. -- George Orwell III (talk) 15:01, 5 January 2014 (UTC)
Here is a modern day example File:Sidenote.pdf that might help illustrate some of the Page: namespace nuances in play now. -- George Orwell III (talk) 15:20, 5 January 2014 (UTC)
Agree all points. Right at present I am sufficiently frustrated at this thing that if it were a physical object there would be a large dent in my office wall right now (or if my aim is bad there's a couple of windows might have broken.)

Oh, and your sample "pdf" would almost certainly break the current version of the {{sidenotes begin}} family. I shouldn't even bother trying to use it for that one? Viewer2 (talk) 16:33, 5 January 2014 (UTC)

Sorry if I wasn't clear - the PDF is for opening and viewing outside of wiki markup (so you can see the nuances dealing with margin to sidenote to text column). It wasn't meant to be Indexed:

I don't know how THIS willl come up on your systems but that is generally what is needed. The main column and sidenotes will stay in alignment if you re-size your browser window but the sidenote (being fixed in em w/ MATH no less) will not expand all the way right like it should (less line wrapping)

I hope that was more clear. -- George Orwell III (talk) 17:08, 5 January 2014 (UTC)

I thought I had read it that way the first time, so it must have been me that was not clear.

Perhaps one of the (many?) Lilypond tragics out there can express this more eloquently:

Tempo: strigendo poco a poco throughout…

Grunt—
—Thud—
(GRAMS/FX: comic ricochet)
—Tinkle—
Exit—stage left—accompanied by vigorous swearing‥‥
(GRAMS/FX: closing theme)

⁠Viewer2 (talk) 20:51, 5 January 2014 (UTC)

Viewer2, Try looking at the first page I did for that using {{sn-paragraph}} and {{p}} ;). So far it formats nicely. ShakespeareFan00 (talk) 16:35, 5 January 2014 (UTC)
Sure does. But when you go look at the raw text the Government Printing Office uses to regenerate that particular content, in all its different formats for all the different publications, your sidenote-to-target association is a bit off - specifically because you were more concerned about mirroring something that will never see the insides of a circa 1908 printing press never mind the quirks of the proofreadpage wiki extension. Stuff like sidenotes are done today more for the sake of tradition than anything else. -- George Orwell III (talk) 17:46, 5 January 2014 (UTC)

Index:The Book of the Homeless (New York, Charles Scribner's Sons, 1916).djvu

This is now ready for a second set of eyes, However I'd like someone to make a copyright check on some works I've blue-paged owing to them being works by European authors still in copyright in their origin countries. If needed scan redaction could be performed as has been done elsewhere. ShakespeareFan00 (talk) 15:46, 5 January 2014 (UTC)

The only reason any of these would be copyrighted in the US is if they are in a foreign language, were published first in a foreign country not in compliance with US formalities, and we're going by US 9th Judicial Circuit rulings, which I expect we are given there's a Wikimedia colo facility in San Francisco. The only one that raises any flags for me is Notre Héritage by Maurice Maeterlinck, as there's another work with that text published in France, with US registration, in the same year. Prosody (talk) 03:42, 6 January 2014 (UTC)
Well you can re-instate if you desire, I'd bluepaged as a precautionary measure.ShakespeareFan00 (talk) 09:14, 6 January 2014 (UTC)
All works published before 1923 are in the public domain in the United States. No exceptions.
Wikimedia's servers are in the U.S., so they may legally host any material that is in the public domain in the U.S., regardless of the status in the country of origin.
Wikimedia Commons has adopted a policy of not hosting material that is under copyright in the country of origin. But that's Commons' policy, not ours. If some of this book was shown to be under copyright in the country of origin, then we could simply move the DjVu file from Commons to Wikisource, and continue to host the work. Hesperian 03:46, 6 January 2014 (UTC)
I checked again and what I said was doubly inapplicable. This entire work should be public domain in the United States. It is worth noting for the future though that there is one exception to the 1923 rule, which I poorly explained above. It's described in the copyright term and public domain chart provided the Cornell Copyright Information Center here, the first item under Special Cases under Works First Published Outside the U.S. by Foreign Nationals or U.S. Citizens Living Abroad and in Footnote 12. In a nutshell:
  • The work has to be in a foreign language.
  • The work has to be first published outside the United States from 1 July 1909 through 1978.
  • The work has to have been published without following US copyright formalities.
  • The work has not to be have been subsequently republished following US copyright formalities.
  • We have to be under the jurisdiction of the US Court of Appeals for the Ninth Circuit.
Here, if this one piece was published originally in France, it was still published following US formalities, so it doesn't meet this exception. Furthermore, it is republished here in The Book of the Homeless which follows US formalities, so it doubly doesn't meet this exception. Works that do meet this exception are treated as if unpublished. Prosody (talk) 04:15, 6 January 2014 (UTC)
Jeepers, I didn't know about that exception, and I think I was happier not knowing. What a mess! "The decision has been harshly criticized in Nimmer on opyright, the leading treatise on copyright, as being incompatible with previous decisions and the intent of Congress when it restored foreign copyrights. The Copyright Office as well ignores the Twin Books decision in its circular on restored copyrights. Nevertheless, the decision is currently applicable in all of the 9th Judicial Circuit...." Wikimedia is headquartered in California, so that puts it squarely within 9th Circuit jurisdiction. We would have to play conservative and comply, unless advised otherwise by WMF lawyers. But of course this is all hypothetical: it's irrelevant to this particular situation. Hesperian 05:57, 6 January 2014 (UTC)
Take a breather & relax. Not only did that case have a whole host of unbelievable conditional caveats rooted-out then incorporated into either side's arguments/appeals prior to making the 9th Ct. ruling happen in 1996 but Congress has amended the supporting authority the ruling was primarily based on at the time (Sec. 104A) three times since then - pretty much making the entire "missing~starting" matter just academic fodder if not completely moot in real legal terms.

The chances of another case, at or above the district court level, meeting all those unusual conditions in play in the Disney case while also finding a shred of lawful standing under the revised statute is highly unlikely to put it politely. The lack of such affirmation by or within another ruling (or similar) since the 9th Ct. ruled in 1996 does not automatically make it a precedent or anything 'law-of-the-land'ish either - any new case or instance would need to revisit the ruling to [re]affirm its validity under the changes relevant to Sec. 104A c. 1996 (again, catch-22 - the chances of meeting that standing today and finding enough leftovers from the Disney precedent to 'build a case on' only grows more and more uber-unlikely [imo] with every passing day).

And if it wasn't for the tidbit about one of Congress' changes affecting prior practice(s) re: Presidential Proclamations getting me into looking at all this to begin with (some time ago), I might have believed there is something to all this as well. Documenting such legal 'loose-ends', however, is completely proper - even useful for the 'next-guy' - but sometimes a footnote is just a footnote folks. Again - I'm no lawyer but I do know enough about "the law" to get myself in trouble with one or two :) -- George Orwell III (talk) 07:47, 6 January 2014 (UTC)

Tech News: 2014-02

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

Recent software changes

  • The latest version of MediaWiki (1.23wmf9) was added to test wikis and MediaWiki.org on January 2. It will be enabled on non-Wikipedia wikis on January 7 and on all Wikipedia wikis on January 9 (calendar).
  • The old note-taking site (Etherpad) was removed on December 30, 2013. You can see most of the documents on the new site. [13]

Problems

  • On January 2, Wikimedia Commons, Wikidata and all Wikivoyage projects were broken for 2 hours due to language cache update issues.
  • On the same day, it was not possible to edit most wikis for about 30 minutes, due to a database replication problem.

Future software changes

  • The new search tool (CirrusSearch) will be added as the default search method for Italian Wikipedia, French Wikisource, Wikidata and all Wikivoyage sites, and as a second search method for the German Wikipedia and all Wikibooks sites on January 6. [14]
  • Spanish, French, Portuguese and Russian Wikipedia users will also be able to enable CirrusSearch in their Beta Features options. [15]
  • Plural form rules for some languages will be changed. Many translations of the user interface for Belarusian, Russian, Serbian, Ukrainian and other languages will need to be changed. [16] [17] [18]
  • You will see a warning when you try to delete a page linked to from other pages. [19] [20]
  • You will be able to hide redirect pages on the list of protected pages. [21] [22]
  • You will be able to use keyboard shortcuts in the Translate tool, by pressing Alt+1 and similar key groups. [23] [24]
  • E-mails sent by MediaWiki will include the name of the site in their From: line. You will be able to change this name on your wiki by editing the MediaWiki:Emailsender page. [25] [26]
  • Images viewed in the Beta Features media viewer will load faster. [27] [28]

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

08:34, 6 January 2014 (UTC)

Categorizations revisited

FMI. I noticed that the Category:United States. . . of the subcategory of Category:North America . . . of the subcategory of Category:Geography contains a lot of Government and other non Geography related documents. Is this acceptable categorization? Thanks in advance for any comment. — Ineuw talk 14:41, 6 January 2014 (UTC)

One "solution" to this epistemological issue would be to include the first two categories under Category:Topics by geographical area, which would be under Category:Geographical areas, which would be under Category:Geography. Even that would not really solve the underlying problem, which is that under a seemingly logical definition of categories, all items in a subcategory should be categorizable in the parent category as well. In practice, categories are really used more as "topical hierarchies," where the category subject fits well in the parent category, but its contents, which fit the category topic, do not necessarily fit the supercategory topic. --Eliyak T·C 16:37, 6 January 2014 (UTC)
Possibly we can create Category:Texts by location or Category:Texts by place, and put all the country categories under that, while creating a separate tree for purely geography texts. Either of those category names should be broad enough to cover the wide range of potential sub-categories, including "[PLACE] authors", "[PLACE] literature", "History of [PLACE]", "Law of [PLACE]" and, of course "Geography of [PLACE]". Extracting and constructing the semi-separate geography tree might be the hardest part. - AdamBMorgan (talk) 00:36, 7 January 2014 (UTC)
I agree with both of you. Have no plans to touch anything until I comprehensively studied existing and possibly related category structures. Then, I will present the findings to be discussed here. — Ineuw talk 05:09, 7 January 2014 (UTC)
"Geographical areas" would create the same problem: topics related to North America are not necessarily geographical areas. The same problem occurs all the time at Wikipedia. Hesperian 09:28, 7 January 2014 (UTC)
I realize that any change under the current scheme is meaningless because it's not a top down enforced hierarchical system like the Library of Congress categorization. Using the United States category as the focus of this discussion for analysis, when traversing the categories from a view other than Geography category, it makes sense within the context of the search. Then again, there are other subcategories which would/should not belong either. Thus, it's best that we leave this issue alone for the time being because this would require a comprehensive reorganization of the type which is not part of the Wikimedia culture. The only recommendation I would make is adding blue clarification notices with redirection as it's done on the Commons LIKE THIS.— Ineuw talk 01:19, 8 January 2014 (UTC)
We already have {{Category redirect}} in use here. For example, Category:United Kingdom Prime Ministers. - AdamBMorgan (talk) 11:18, 8 January 2014 (UTC)
Thanks, this is great. I didn't know about it because it was created only recently - in 2011. :-) — Ineuw talk 15:16, 8 January 2014 (UTC)

Year of publication

This is partly idle curiousity but what year do people use in the header? If it is not the first edition, do people use the year of the first publication or the year of the actual work we host? If it is a translation, do you use the year of the translation's publication or the date of the original? Personally, I use the year of publication of the actual edition in question. With translations, I sometimes add the original year as a category and only mention it in the header notes.

One thing that brought this to mind was The Origin of Species (1872). It didn't actually have a year in the header when I was cleaning up but it turns out to be an 1873 publication (clearly visible on the title page), which leaves it with an odd page title. Meanwhile A Christmas Carol (Dickens, 1843 facsimile) does already have a year, 1843, although that copy was published in 1920. The Laws of Hammurabi, King of Babylonia is a 1903 translation but the header says "c. 1772 BCE". Conversely, Organon (Owen) is an 1853 publication, which is reflected in the header, of a work written around 340 BC.

I can't find anything written down anywhere about this. Do we have a standard? - AdamBMorgan (talk) 17:39, 9 January 2014 (UTC)

I've never seen anything approaching a "standard" or policy on that either BUT there is sort of a guiding principle already in place & applied by commons as well as en.WS (among others). And its been put in play by our {{Book}} and {{Information}} templates for some time now.
  • {{int:wm-license-book-year-of-publication}} = Year of publication
Using the label Year of publication sort of makes sense on top of already being on its way to becoming a MediaWiki provided default standard if not one already. -- George Orwell III (talk) 23:50, 9 January 2014 (UTC)
Issues like this one are why I don't use the year field at all: better to leave it out than cause confusion.
In my experience the header template is broken — it bolds stuff I don't want bold and vice versa; it italicises the author instead of the title in contravention of the most basic and broadly accepted convention; in collective works it misattributes authorship to the work when I want to attribute authorship to the section; it doesn't really support inclusion of the edition, which is often needed to disambiguate. So I've given up using most fields; I just abuse the 'title', 'author' and 'section' field until it looks vaguely like what I want it to; e.g. The Atlantic Monthly/Volume 15/Number 89/The Story of a Year. </rant>
Hesperian 01:41, 10 January 2014 (UTC)
That is not the header, that is people's use. We have contributor = field for parts of works. The work at the top level would have author, and sections have contributors, easily done. — billinghurst sDrewth 06:12, 10 January 2014 (UTC)
I totally agree and have said as much for some time now. Right now, individual parameter fields are "fixed" as [table] cell-boxes & a series of such parameters are then fixed within [table] rows. Because everything is pretty much fixed within what amounts to an HTML table, once we get past the basics (title, author & chapter) into volume(s), issue(s), editor(s), contributor(s) and the like, we're stuck manipulating the locked-in fields as you've described - corrupting one project aim or another in the process. The solution is porting over to a dynamic div based header where fields and/or rows are interchangeable as the work dictates but are all still dedicated so accurate data retention is still possible. All we really need is the consensus to make that change and mutually agree upon the new parameters, their rendering and the overall defaults.
For major works we have customised version of {{header}} that manages this sort of thing fine until there is an improved methodology. — billinghurst sDrewth 06:15, 10 January 2014 (UTC)
I use the year of publication of the work. If it is a translation, I would use the year of the translation in the header, and manually add the year of publication as a separate category. We can always manually add the years so they categorise as required for that guidance. — billinghurst sDrewth 06:12, 10 January 2014 (UTC)

Header: wikidata field

Hi. I am going to add wikipedia links to CE1913 articles. Is there any point in adding also the wikidata= field? For example Catholic Encyclopedia (1913)/Ange de Saint Joseph corresponds to w:Ange de Saint Joseph and d:Q4762006.--Mpaa (talk) 22:39, 9 January 2014 (UTC)

Don't hold me to this because I'm not all that sure how Wikidata will ultimately interact with us but it would seem only the person (such as Author:Ange de Saint Joseph in our case) would be associated with that D:#. I would think a work about that person would have some other D:# (one that probably will be associated or listed under that primary D:#?). -- George Orwell III (talk) 23:37, 9 January 2014 (UTC)
That level of linking to WD is up to us, not up to Wikidata, and I wouldn't think that there is much value in that direction as it is not the entity, which is the CE1913. I would not be encouraging the reverse linking from WD to the biographical snippet, though we would for the work/entity. — billinghurst sDrewth 06:04, 10 January 2014 (UTC)
At WD, I see that the thinking is that each edition of a work is its own entity, which is pretty much how we treat works, and the version page would be its own entity and be a disambiguation type space. This allows the sister sites to link to where they wish, pretty much to what GOIII was stating above. — billinghurst sDrewth 06:27, 10 January 2014 (UTC)

Right, this whole business is apparently up for grabs still, and might be fruitful if looked at from certain angles.

We have this basic stratum of thinking, which is that Wikisource is about "objects" that are texts. I have been looking for a while for a way to superimpose on that my basic interest in reference material done into "articles".

Clearly then, some of the content here could be associated to two Wikidata items, one of which is descriptive of the text, and another which is descriptive of the topic of the text. The latter association could be really useful in what we call "disambiguation", though that is perhaps a stretch. Certainly, to take an example, biographies here from different works would benefit if each carried a Wikidata code that could be used to automate the process of gathering them up by the person involved. This does not exclude them as texts from being associated with a code for the work of which they are a part, for example. Charles Matthews (talk) 09:04, 10 January 2014 (UTC)

So, something like "object data item" for the book, article or whatever and "subject data item" for the person, topic, or whatever? Setting that up is easy (just an edit to a few templates) but populating it might take a while. It would need to avoid confusing the bots that will migrate and maintain our links Wikidata, assuming they even look at this information. Avoiding confusing readers is also an issue but I can't think of a better wording right now. - AdamBMorgan (talk) 14:16, 10 January 2014 (UTC)
might want to model on how the authority control librarians in VIAF do it: Ange de Saint Joseph; LOC. they might have a standard typology. Slowking4♡Farmbrough's revenge 01:11, 11 January 2014 (UTC)
My understanding is that due to the 1-1 nature of links, Charles' intention is not possible. But some WD expert might help here.--Mpaa (talk) 10:23, 11 January 2014 (UTC)

I'm thinking about different header fields here. I agree that interwiki links would be to a single specification. Charles Matthews (talk) 18:00, 11 January 2014 (UTC)

Having talked this over yesterday with Adam: I think the main point at the moment of such a field, from the "topic" perspective, would be to place a page in a category that was of those pages that were "non-fiction" and "can be assigned a definite topic". The Wikidata index would simply remain hidden for the present, but would be available for any future automated work on classification by topic. In other words its use would help isolate here our "reference section". Charles Matthews (talk) 05:25, 13 January 2014 (UTC)

Tech News: 2014-03

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

You can read a recent blog post about how Tech News is put together, translated and sent to you across wikis each week.

Recent software changes

  • The latest version of MediaWiki (1.23wmf10) was added to test wikis and MediaWiki.org on January 9. It will be added to non-Wikipedia wikis on January 14, and all Wikipedia wikis on January 16 (calendar).
  • Searching in the File: namespace on Wikimedia Commons may be slow due to a search engine issue. [29]

VisualEditor news

  • VisualEditor will be added for all users on several Wikipedias on January 13. [30]
  • You can now add and remove __NOTOC__, __FORCETOC__ and __NOEDITSECTION__ in the page metadata menu. [31] [32] [33]

Problems

  • For a few hours on January 6, it was not possible to edit pages using the Translate tool on Wikimedia Commons and the Wikimania 2013 wiki, due to a settings error. [34] [35]
  • For about 20 minutes on January 9, there were problems with CSS and JavaScript due to high server load.

Future software changes

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

09:33, 13 January 2014 (UTC)

Wikimania 2014

Wikimania 2014, the 10th annual international conference of the Wikimedia movement, is now accepting submissions for presentations, workshops, panels, and tutorials related to the Wikimedia projects or free content topics in general. The conference will be held from 6-10 August 2014 in London, UK.

The Wikimania 2014 Scholarships Programme is now open. The Wikimedia Foundation is offering a limited number of scholarships to offset the cost of selected individuals' attendance at Wikimania. Any active contributor, from anywhere in the world, is considered eligible.

Hope to see some of you there!

- Lawsonstu (talk) 13:41, 14 January 2014 (UTC) — (Open Access Community Liaison, Wikimania 2014)

Dynamic Layout Overriding restored

As discussed above, I've now added a gadget to toggle the behavior of dynamic layout overrides. That is, they now work by default (but do not get stored in the cookie, and do not carry over to the next viewed page). If anyone wants to disable this behavior (and always see the last selected Layout, without overrides on specific works), the setting is in the usual place (Preferences -> Gadgets).

I'd like to put another previously discussed idea out there: Should dynamic layouts also show up on texts not backed by scans? (This was probably originally not done for technical reasons, but should be possible now.) To me, this seems an obvious yes, but I'd like to get any disagreeing opinions if they exist. --Eliyak T·C 17:11, 14 January 2014 (UTC)

I would prefer dynamic layouts to be consistent. That is, applying to all texts, regardless of scans or not. (Followed by removing the forced div-based columns we have scattered aroung.) - AdamBMorgan (talk) 12:19, 20 January 2014 (UTC)

Index:Mrs. Beeton's Book of Household Management (Part 1).djvu

Well folks, why when linking from the TOC page am I seeing volume I pages when what I should be seeing is volume 2 pages?

I think the two volumes should be combined and then there isn't an issue.

I've marked bothe index pages as 'Source file needs checking" until this is resolved.

It's a shame as I wanted to make progress on this. ShakespeareFan00 (talk) 18:38, 14 January 2014 (UTC)

Very odd. This seems related at the moment to a SINGLE page! (page 61 in the Part 2 scans) ShakespeareFan00 (talk) 20:17, 14 January 2014 (UTC)
I can't see anything strange with the links in the TOC or I did not get what you mean. Page numbers > 1131 are linked to index part 2.--Mpaa (talk) 20:21, 14 January 2014 (UTC)
Try clicking on a redlink in the TOC (like page 1190) ShakespeareFan00 (talk) 20:34, 14 January 2014 (UTC)

It does not help that Part 1 has Mrs. and Part 2 doesn't. ShakespeareFan00 (talk) 20:36, 14 January 2014 (UTC)

https://en.wikisource.org/wiki/Page:Mrs_Beeton%27s_Book_of_Household_Management_%28Part_2%29.djvu/61

- This shows the scan of Djvu Page 61, in the Part 1 scans.. Not the part 2 scans..

Somewhere something has got confused.

Not happy. ShakespeareFan00 (talk) 20:40, 14 January 2014 (UTC)

Wild guess. I think this is due to how Proofread Ext. handles names internally. Try to create a page clicking on a red link in TOC. You obtain a "Page:...(Part 2).djvu/n". If you try to move one page ahead, you jump to "Page:...(Part 1).djvu/n+1". Weird.--Mpaa (talk) 22:33, 14 January 2014 (UTC)
I agree. After some experimentation, it definitely depends on the origin of the link. If you click a Part 2 link from the Part 1 DjVu (which is transcluded as the TOC to both index pages and the mainspace), then the first click will go to the Part 2 DjVu and the next click will go to the Part 1 DjVu. If you click from the page list of the Part 2 index page, then it stays in the Part 2 DjVu. I'm not sure how, but the software appears to assume a 1:1 link between Indexes and DjVus (which is true for 99% of the time, and it took me a few moments to realise this was not the case here). Presumably this is also why the links worked despite the typo (there is no dot after "Mrs" in the Part 2 filename). I can think of a few possible solutions. One would be to simply reintegrate the split DjVu into one file and upload that in one of the ways that evades the 100MB limit. A few already-proofread pages would need top be moved but it would eliminate all issues with having two separate files. - AdamBMorgan (talk) 12:39, 15 January 2014 (UTC)

Index:Bradshaw's Monthly (XVI).djvu

Requesting deletion unless anyone wants to adopt this. Page quality on the scan is variable and trying to get the table nicely formatted needs someone prepared to quite literally kick Mediawiki until it screams into compliance. :(

Delete current efforts, Nice good faith effort, but too complex. ShakespeareFan00 (talk) 18:41, 14 January 2014 (UTC)

Seems like a waste of effort to delete it. I'll try to see what I can do with it. --Wylve (talk) 08:35, 15 January 2014 (UTC)

Wikidata is here!

Hey everyone :)

As previously announced we have just enabled interwiki links via Wikidata for Wikisource. This means from now on you no longer have to maintain the links in the Wikitext but can maintain them together with the links for Wikipedia, Commons and Wikivoyage on Wikidata. You will still be able to keep them locally though if you want to. Local interwiki links will overwrite the ones from Wikidata. You do not yet have access to the other data on Wikidata like the date of birth of an author. That will come in a future deployment. I will let you know when I have a date for it.

If you have any questions d:Wikidata:Wikisource is a good first step. It also has a list of people familiar with both Wikisource and Wikidata who are able to help you out. That is also a good place for any issues or bugs you encounter.


I'm really excited to welcome you all to Wikidata! I hope it will become a great help for Wikisource.


Cheers Lydia Pintscher (WMDE) via MediaWiki message delivery (talk) 21:07, 14 January 2014 (UTC)

Page numbering is broken again

Page numbering is broken again. No idea how to fix it. Hesperian 07:29, 15 January 2014 (UTC)

Is no-one else experiencing this? — No page numbers next to transcluded pages in mainspace. Hesperian 06:33, 16 January 2014 (UTC)

on any transcluded page - side-bar 'Display options' menu, select 'Show page links'

Persistently affecting me, also. Charles Matthews (talk) 19:05, 16 January 2014 (UTC)
Not at the moment. You sure you didn't fall into the outdated local cache trap some others have fallen into? Sure you didn't toggle hide show page links to hide (remember it displays the opposite of what is selected so if it says show page links in the display options menu, click on it).

Maybe I should back up and start with the basics - what, if anything, is currently displayed under your Display Options menu? Does it also happen when you're not logged in? -- George Orwell III (talk) 07:23, 16 January 2014 (UTC)

I have the same problem and not only here but also in Ukrainian Wikisource. There is some Javascript error in the console: "TypeError: bilink.getAttribute(...).match(...) is null" --DixonD (talk) 07:25, 16 January 2014 (UTC)
Ok, that error is unrelated, but anyway, the problem with page numbers persists. --DixonD (talk) 07:31, 16 January 2014 (UTC)
The only thing that you two seem to have in common that leaps out at me (& my limited knowledge) is you both have scripts/calls-to-scripts modifying the left-hand sidebar menu(s) in some way. So I guess same question is appropriate - does it happen on transcluded mainspace pages when you are not logged in? -- George Orwell III (talk) 07:36, 16 January 2014 (UTC)
And fwiw.... the Ukrainian site is loading the oldWikisource copy of MediaWiki:PageNumbers.js while en.WS has it own version. -- George Orwell III (talk) 07:40, 16 January 2014 (UTC)
I found a problem - it was actually related to that error. The cause of the error was an old script for adding " ⇔" to interwiki links. This script was removed from enwikisource by you (btw, why?) so I guess Hesperian just needs to clear browser cache. In ukwikisource I rewrote the script, and it solved the problem with page numbers. --DixonD (talk) 08:08, 16 January 2014 (UTC)
I forget - probably the same - causing errors. It wasn't worth the trouble of keeping around plus nobody took over oversight of it after ThomasV left anyway. And imho it should have been a user applied Gadget to begin with -- George Orwell III (talk) 08:31, 16 January 2014 (UTC)


It was happening to me, but I didn't know about the "show page links" thingy. Having clicked that the page numbers have "miraculously" come back. I use scripts modifying the LH sidebar too. I've decided not to ask how long the "show page links" has been there, in case someone tells me its been there for some years and I've just never seen it. Beeswaxcandle (talk) 08:05, 16 January 2014 (UTC)
<chuckle> Its been "there" since the initial roll out of Dynamic Layouts a couple of years (or more?) ago. It only started working (for the first time ever ever ever) after Eliyak's recent overhaul of the original [super-flawed] PageNumbers javascript.

Do we need to review the other toggle (inline links vs margin links)? -- George Orwell III (talk) 08:14, 16 January 2014 (UTC)

The other toggle works for me. Beeswaxcandle (talk) 08:21, 16 January 2014 (UTC)
... yes except that it is inverted: clicking on "page links beside text" puts them inside, and clicking on "page links inside text" puts them beside. Hesperian 09:02, 16 January 2014 (UTC)
Hmmm... good catch. But I don't recall that always having been the case. Maybe something in the below linked recent fix for the Dynamic Layout Overrider feature forced that inversion in the process or something. Maybe it was always like that and I was too overjoyed to notice? Eliyak will be by sooner or later and hopefully he'll catch this without having to drop him a direct note. If not, I will. -- George Orwell III (talk) 10:00, 16 January 2014 (UTC)
Good - please note a related "enhancement" outlined just above. -- George Orwell III (talk) 08:31, 16 January 2014 (UTC)


Thanks folks. I was unaware of "show page links". All I knew was the page links had always been there and suddenly they were gone. Hesperian 08:59, 16 January 2014 (UTC)

Really. Since it never worked up until a few weeks ago, can it be true that most folks forgot all about this menu option/toggle (see any other WS domain still calling the "old" script for example altogether? I can't believe I was only one of maybe a handful still pissed off that whole time about an option promised to us with the roll-out of Dynamic Layouts but was one that never actually worked. -- George Orwell III (talk) 09:24, 16 January 2014 (UTC)
I will fix that on "other WS domain" but I think the proper thing would be to update the script on oldwikisource, as it is a kind of the central place for all wikisources. --DixonD (talk) 10:13, 16 January 2014 (UTC)
Do as you wish/must.

And as for "... a kind of central place for all wikisources" <-- thats how we got this mess in the first place. Its the politburo of forgotten innovation imho. -- George Orwell III (talk) 10:21, 16 January 2014 (UTC)

The page links should be back. They were "off" by default due to a coding error (mine) that was based on a documentation error. This cropped up when I fixed the problem of layout overrides carrying over to the next page. The other issue is related to the question of whether the page numbers within/beside the text should reflect the current status (like the layout toggle) or the desired status (like the show/hide toggle). --Eliyak T·C 15:20, 21 January 2014 (UTC)

Sourcing an archiving bot

I have found a user at another wiki who has set up an archiving bot on the tools service, and that person is willing to explore with us having it run here on talk pages, and others of relevance. So if you are an admin, please know that it is here by invitation to touch and try; all users please review its edits and report issues that you see here to WS:S. Thanks. — billinghurst sDrewth 09:19, 15 January 2014 (UTC)

Request for comment on Commons: Should Wikimedia support MP4 video?

I apologize for this message being only in English. Please translate it if needed to help your community.

The Wikimedia Foundation's multimedia team seeks community guidance on a proposal to support the MP4 video format. This digital video standard is used widely around the world to record, edit and watch videos on mobile phones, desktop computers and home video devices. It is also known as H.264/MPEG-4 or AVC.

Supporting the MP4 format would make it much easier for our users to view and contribute video on Wikipedia and Wikimedia projects -- and video files could be offered in dual formats on our sites, so we could continue to support current open formats (WebM and Ogg Theora).

However, MP4 is a patent-encumbered format, and using a proprietary format would be a departure from our current practice of only supporting open formats on our sites -- even though the licenses appear to have acceptable legal terms, with only a small fee required.

We would appreciate your guidance on whether or not to support MP4. Our Request for Comments presents views both in favor and against MP4 support, based on opinions we’ve heard in our discussions with community and team members.

Please join this RfC -- and share your advice.

All users are welcome to participate, whether you are active on Commons, Wikipedia, other Wikimedia project -- or any site that uses content from our free media repository.

You are also welcome to join tomorrow's Office hours chat on IRC, this Thursday, January 16, at 19:00 UTC, if you would like to discuss this project with our team and other community members.

We look forward to a constructive discussion with you, so we can make a more informed decision together on this important topic. Keegan (WMF) (talk) 06:47, 16 January 2014 (UTC)

support per w:User:Brion VIBBER [41], but more a matter for Commons. Slowking4♡Farmbrough's revenge 16:47, 16 January 2014 (UTC)

Index:Catalogue of books suitable for a popular library.djvu

Any offers on getting this done? The formatting is mostly done by a template.ShakespeareFan00 (talk) 10:46, 16 January 2014 (UTC)

Should we delete these redundant pages?

I was about to make a bunch of pages on Wikidata to link to pages in Category:Constitutional documents of Canada when I noticed something. We have five groups of documents that seem pretty redundant to me. Each of the statutes listed below has one page for the original version, one page for the amended version, and one page for the amended version with annotations. However, the only amendments ever made to these five Acts was a change of name. Do we really need all these pages for documents that only differ in one line, or may I start merging them? The groups are: the 1871 Act (1, 2, 3), 1886 Act (1, 2, 3), 1907 Act (1, 2, 3), 1915 Act (1, 2, 3), 1930 Act (1, 2, 3). --Arctic.gnome (talk) 05:48, 17 January 2014 (UTC)

In general, we like to avoid such measures for works created prior to the implementation of current guidelines and/or policies, such as these additions seem to be, unless they are usurped by scan-backed transcriptions instead. By this, I mean utilizing the Page: and Index: namespaces to carry out the ProofReading process.

An example of this process in the same vein as the works in question starts with Index:Constitution of the Republic of South Africa 1996 from Government Gazette.djvu for example. -- George Orwell III (talk) 22:58, 17 January 2014 (UTC)

If I wanted go scan paper copies of these documents to bring them in line with current policies, would you prefer the original turn-of-the-century versions or the the 1985 reprints with the minor amendment included? In either case, may I add a self-written footnote to explain the amendment? --Arctic.gnome (talk) 23:42, 17 January 2014 (UTC)
Its up to you to field how many unique editions you think should be backed by scans vs. the amount of time you can invest. Original prints (first editions) are always nice to have for historical purposes & later context, while an interim revision resulting in its own edition might be just as historically significant. Of course also having the very latest or currently in effect editions are popular for students, researchers and the like.

We like to remain as true as possible to the original format and published content as published (in general) so "adding" something that wasn't published to the same "space" as the published content is not acceptable (that is considered an annotation --> separate version). You can add basic "notes" in the notes field of the header template and as much as you like in the talk page's TextInfo box however.

I'd inspect the downloaded document before you decide one way or the other - frequently the "born digital" paper versions contain far more note, reference, index, appendix, etc. material than you'll ever find compared to the "online" versions of the same work in my experience. -- George Orwell III (talk) 00:41, 18 January 2014 (UTC)

Du gamla, du fria

Do you intend to save the Swedish versions in Du gamla, du fria? It looks a little out of scope for an English project. -- Lavallen (talk) 15:34, 18 January 2014 (UTC)

Formatting it as parallel texts is a possible option, so that the original and translation can be compared side-by-side. --EncycloPetey (talk) 23:31, 18 January 2014 (UTC)
Three pages with Swedish versions can now be found on svws. Two by Dybeck and one by Ahlén. Observe that we have not yet identified any deathdate of Ahlén. -- Lavallen (talk) 09:08, 19 January 2014 (UTC)

More strange formatting

So I was going to go read The Sources of Standard English/Chapter IV - The Inroad of French Words into England, but when I went to that page, the text was in a narrow column approximately 10 characters wide. (That is to say, much narrower than the expected narrow 'column' layout.) I thought maybe it was a browser caching problem, but a hard refresh did me no good. Here is a screenshot of my screen. Is anyone else seeing the same odd formatting? Mukkakukaku (talk) 03:58, 19 January 2014 (UTC)

So, this is using some complicated formatting through {{PageLayout}}, namely margin-left=50|margin-right=300 gives it 50pt left margin and 300pt right margin. This would look okay, except the typography refresh beta squishes the content into a div with a max width of 715px. All that margin whitespace inside that small container means there's barely any room for the text. Prosody (talk) 04:16, 19 January 2014 (UTC)
I removed the templates and let dynamic layouts takeover - seems ok but the rest of the chapters are the same. And its not the Beta at the core of the resizing but dynamic layouts - something that might not have been in place when the contributor came up with that "scheme" -- George Orwell III (talk) 04:23, 19 January 2014 (UTC)

Vandalism

The Corsair (Byron, 1814), our featured text, has been vandalized, if someone can please restore it to the last good edit. Thanks, Londonjackbooks (talk) 02:55, 20 January 2014 (UTC)

The 96.238.138.72 IP appears to be on a vandalism spree.... Mukkakukaku (talk) 03:09, 20 January 2014 (UTC)
Is there any reason not to semiprotect featured texts, preferably cascadingly so that the transcluded pages are also protected? Angr 08:41, 20 January 2014 (UTC)
We did do that in the past, dunno if the practice dropped off because it was decided to be undesirable or if it was just neglected. Prosody (talk) 11:45, 20 January 2014 (UTC)
It was a decision. Initially it was based on this very brief discussion, but it has come up elsewhere when small errors and other fixes have been needed to featured texts. Vandalism is fairly rare, even with main page items, so it is less of an impact to leave them unprotected rather than preventing maintenance and improvement. We can go back to protection if desired (it was full protection in the past but semi-protection might work). - AdamBMorgan (talk) 12:09, 20 January 2014 (UTC)

Tech News: 2014-04

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

Recent software changes

VisualEditor news

  • In the toolbar, the menu to edit the styles (like bold, italic, etc.) now has a down arrow (  ). The order of the Insert menu has also changed a little.
  • You can now edit <gallery /> tags with a very basic tool. [47]
  • You can now see a help page about keyboard shortcuts in the page menu. [48]
  • When you change categories, you will now see them when you save the page. [49]
  • When you edit templates, you will now see the parameters in the right order. The ones that you must add have a star (*). [50] [51]
  • The page will now be saved faster, thanks to a new way of coding the text that sends 40% less text to the servers. [52]
  • Your wiki can ask to test a new tool to edit TemplateData. [53]

Problems

  • There was a problem with search on the English and German Wikipedias between January 6 and January 14. You could not see new pages and changes in search results. [54]
  • There were "pool timeouts" errors on several wikis on January 13; it was caused by a code change that was made to fix another problem. [55]
  • On January 17, Bugzilla and Wikimedia Labs were broken for about 20 minutes due to network problems. IRC channels with recent changes (irc.wikimedia.org) were broken for about two hours. [56]

Future software changes

 
Orange bar with new messages
  • If you have removed JavaScript in your web browser, you will soon be able to see the orange bar saying that you have new messages. If you have changed how the bar looks with a gadget, you may need to change the gadget again. [57] [58]
  • You will soon be able to add a given Flickr user to a blacklist so that their files can't be uploaded using UploadWizard on Wikimedia Commons and other wikis. [59]
  • You will see a warning when you try to delete a page included in at least one other page. [60]
  • You will so longer see disambiguation pages in Special:LonelyPages. [61] [62]

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

10:21, 20 January 2014 (UTC)

WIKIPEDIA & JIM WALES ON SCIENCE CHANNEL JAN. 27th 2014

It is now yesterday that I spent most of the day watching History International(H2) and THE SCIENCE CHANNEL.

During a break in the program there was an announcement of all manner of sciences coming together for a program. A large sum of money was also announced. I think it was a competition of sciences and people.

I saw Jimmy Wales and I saw "Wikipedia" among other people but I was focused on "Wikipedia" shown on screen. I had walked away but came back to catch what I did.

This program will be on The Science Channel on the 27th of this month. This is presently all I know of that announcement but I will look for it on the Science Channel site to learn of the details. We who have worked on WikiPedia are a part of all that. I thought some or many of us here would be interested. I am! —Maury (talk) 08:56, 21 January 2014 (UTC)

Questions about duplicate articles

I came across this PSM article, which has also been posted as a standalone article HERE and this raised two questions.

  1. Do we keep the duplicate?
  2. Can I copy the proofread contents into the Page: namespace of the PSM article, or would this constitute plagiarism? — Ineuw talk 08:12, 24 January 2014 (UTC)
Normally there's nothing wrong with keeping two copies of the same text if they come from different editions, but in this case The Moral Equivalent of War doesn't have any identifiable source (no scans or even a link indicating where it came from) so I see no reason to keep it. If you want to proofread its contents against the scans, that's fine. No plagiarism since there's no original content, and no copyvio since it's public domain anyway. Angr 09:08, 24 January 2014 (UTC)
Thanks for the clarification.— Ineuw talk 11:15, 24 January 2014 (UTC)

Page namespace issues remain after the 1.23wmf6 (b2c0feb) of 2013-12-11

First I want to thank all who have rushed to correct problems caused by the previous update of a couple of days ago. I decided to re-list issues that still hamper proofreading productivity. The list is broken down to the read and edit modes of the Page: namespace. Editing refers to the "over/under" proofreading because that's what I use exclusively and am unfamiliar with the side by side method. Also, I use Firefox v 25.0.1 exclusively. Your comments under the appropriate subject is much appreciated.

Page namespace read mode

Header & footer displays

Both sections are too close and seem to be part of the main body of text.

Text layer display

The margins were increased and are unbalanced. The left margin is 70px wide (including the 25px wide gutter), and the right margin is 55px wide. A balanced margin width of 50px on each side is sufficient. This affects the following:

This is not directly related to the extension (that just give a width of 50% for the text and 49% for the image) but to en.wikisource own CSS that was optimize for the old crappy version of the extension. Just start a community discussion on it. Tpt (talk) 08:41, 14 December 2013 (UTC)

Scanned page display

The margins' increase of the text layer subtracts from the width of the scanned page display on the right. To compensate, the image was reduced. We also lost the magnifying feature where the page image could be enlarged. This was a convenient way to verify text instead of having to open the page in edit mode.

{{FreedImg}} behavior changed

One of the many advantages of the {{FI}} template was that left or right floating images could be inserted seamlessly into the surrounding text - without showing a break. Now, this feature is lost, AS CAN BE SEEN HERE, or in any other past use. — Ineuw talk 10:17, 13 December 2013 (UTC)

Additional: The text break occurs only at the top of the images, but not the bottom. This problem affected all floating images inserted prior to the updates as well. — Ineuw talk 16:24, 13 December 2013 (UTC)
As best as I can figure - given that I'm somewhat crippled at the moment - the previous behavior (auto insertion of both opening and closing paragraph tags in the underlying HTML upon a save) has been altered even further producing this new behavior. FreedImg hasn't been "touched" for several weeks now so it must be something introduced recently.

As an aside, "we" never really signed off on making the FreedImg scheme part of the default "standard" either. While a handful of folks did manage to apply FI numerous times with success & help work some of the kinks out in the process, there was still a lot left to be proven sound to insure it would "work" in every scenario we could come up with & test against. The alternative to FI (and now my preference moving forward) was the proposal to allow the IMG tag to be recognized by the Wiki mark-up & that went un-resolved as well; soooo... there is not much more I can do on my own on this front. -- George Orwell III (talk) 00:21, 14 December 2013 (UTC)

Umm, folks: It is not just {{FI}}, and it is not even just <div>s. This page uses {{float right}} (and that in turn generates a <span>). Funny thing about none of the floats lining up with their main text origins? They all currently appear a line lower than they should… Viewer2 (talk) 02:42, 14 December 2013 (UTC)
This still goes towards the previous automatic insertion of a closing paragraph tag upon a save when the specs say a closing tag is optional. I closed all the paragraph tags manually regardless of the save - what do you see SPAN wise now? -- George Orwell III (talk) 02:59, 14 December 2013 (UTC)
I agree that closing </p> tags is good practice and I was guilty of laziness here (wmf1.21 would not have tolerated this, but just about every release since that one seems to silently cope.) I am hoping your edits to the page fixed the issue for you, because Firefox renders it just the same as if the paragraphs had been terminated "correctly." (I just checked the generated code, and your careful closing paragraphs makes no difference at all to the HTML finally produced. Oh, and the floating span elements are being enclosed in their own private <p>/</p>s.)

I hope we are not talking at cross-purposes to one another? Viewer2 (talk) 04:34, 14 December 2013 (UTC)

Well the spans are within the P tags (save those around the image file) but {{float right}} [default display = block] vs. {{float right}} [force display=inline] seems like the more obvious solution? (Can't have a block within a block afaict)
Fwiw.... The following is exactly what view source gives me (ie8)...
<div id="mw-content-text" lang="en" dir="ltr" class="mw-content-ltr"><div class="prp-page-container"><div class="prp-page-content"><div class="prp-page-qualityheader quality4">This page has been <a href="/wiki/Help:Page_status" title="Help:Page status">validated</a>. <span id="corr-info"></span></div><div class="pagetext"><div style="clear:both; padding:1px;">
<div style="float:left;">60</div>
<div style="text-align:center;"><i>EUCLID'S ELEMENTS.</i></div>
</div>
<p class="pclass" style="text-align:center;clear:both;padding-bottom:1.0em;padding-top:1.0em;" lang="en" dir="ltr" xml:lang="en">PROPOSITION 8. <i>THEOREM</i>.</p>
<p class="pclass" style="text-align:justify;font-style:italic;" lang="en" dir="ltr" xml:lang="en">If a straight line be divided into any two parts, four times the rectangle contained by the whole line and one of the parts, together with the square on the other part, is equal to the square on the straight line which is made up of the whole and that part.</p>
<p class="pclass" style="text-align:justify;" lang="en" dir="ltr" xml:lang="en">Let the straight line <i>AB</i> be divided into any two parts at the point <i>C</i>: four times the rectangle <i>AB</i>, <i>BC</i>, together with the square on <i>AC</i> shall be equal to the square on the straight line made up of <i>AB</i> and <i>BC</i> together.</p>
<p class="pclass" style="text-align:justify;" lang="en" dir="ltr" xml:lang="en">Produce <i>AB</i> to <i>D</i>, so</p>
<div style="display:inline;float:right;margin-left:2em;margin-top:-2em;"><a href="/wiki/File:The_Elements_of_Euclid_for_the_Use_of_Schools_and_Colleges_-_1872_page_60.gif" class="image"><img alt="The Elements of Euclid for the Use of Schools and Colleges - 1872 page 60.gif" src="//upload.wikimedia.org/wikipedia/commons/thumb/9/98/The_Elements_of_Euclid_for_the_Use_of_Schools_and_Colleges_-_1872_page_60.gif/220px-The_Elements_of_Euclid_for_the_Use_of_Schools_and_Colleges_-_1872_page_60.gif" width="220" height="223" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/9/98/The_Elements_of_Euclid_for_the_Use_of_Schools_and_Colleges_-_1872_page_60.gif/330px-The_Elements_of_Euclid_for_the_Use_of_Schools_and_Colleges_-_1872_page_60.gif 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/9/98/The_Elements_of_Euclid_for_the_Use_of_Schools_and_Colleges_-_1872_page_60.gif/440px-The_Elements_of_Euclid_for_the_Use_of_Schools_and_Colleges_-_1872_page_60.gif 2x" /></a></div>
<p>that <i>BD</i> may be equal to <i>CB</i>;</p>
<p><span style="float:right; display:block; margin:0 0 0 1em;">[<i>Post</i>. 2. and I. 3.</span></p>
<p class="pclass" style="text-align:justify;margin:0 0 0 0;" lang="en" dir="ltr" xml:lang="en">on <i>AD</i> describe the square <i>AEFD</i>;</p>
<p class="pclass" style="text-align:justify;margin:0 0 0 0;" lang="en" dir="ltr" xml:lang="en">and construct two figures such as in the preceding propositions.</p>
<p class="pclass" style="text-align:justify;" lang="en" dir="ltr" xml:lang="en">Then, because <i>CB</i> is equal to <i>BD</i>, <span style="float:right; display:block; margin:0 0 0 1em;">[<i>Construction</i>.</span></p>
<p class="pclass" style="text-align:justify;margin:0 0 0 0;" lang="en" dir="ltr" xml:lang="en">and that <i>CB</i> is equal to <i>GK</i>, and <i>BD</i> to <i>KN</i>, <span style="float:right; display:block; margin:0 0 0 1em;">[I. 34.</span></p>
<p class="pclass" style="text-align:justify;margin:0 0 0 0;" lang="en" dir="ltr" xml:lang="en">therefore <i>GK</i> is equal to <i>KN</i>. <span style="float:right; display:block; margin:0 0 0 1em;">[<i>Axiom</i> 1.</span></p>
<p class="pclass" style="text-align:justify;margin:0 0 0 0;" lang="en" dir="ltr" xml:lang="en">For the same reason <i>PR</i> is equal to <i>RO</i>.</p>
<p class="pclass" style="text-align:justify;margin:0 0 0 0;" lang="en" dir="ltr" xml:lang="en">And because <i>CB</i> is equal to <i>BD</i>, and <i>GK</i> to <i>KN</i>, the rectangle <i>CK</i> is equal to the rectangle <i>BN</i>, and the rectangle <i>GR</i> to the rectangle <i>RN</i>. <span style="float:right; display:block; margin:0 0 0 1em;">[I. 36.</span></p>
<p class="pclass" style="text-align:justify;margin:0 0 0 0;" lang="en" dir="ltr" xml:lang="en">But <i>CK</i> is equal to <i>RN</i>, because they are the complements of the parallelogram <i>CO</i>; <span style="float:right; display:block; margin:0 0 0 1em;">[I. 43.</span></p>
<p class="pclass" style="text-align:justify;margin:0 0 0 0;" lang="en" dir="ltr" xml:lang="en">therefore also <i>BN</i> is equal to <i>GR</i>. <span style="float:right; display:block; margin:0 0 0 1em;">[<i>Axiom</i> 1.</span></p>
<p class="pclass" style="text-align:justify;margin:0 0 0 0;" lang="en" dir="ltr" xml:lang="en">Therefore the four rectangles <i>BN</i>, <i>CK</i>, <i>GR</i>, <i>RN</i> are equal to one another, and so the four are quadruple of one of them <i>CK</i>.</p>
<p class="pclass" style="text-align:justify;" lang="en" dir="ltr" xml:lang="en">Again, because <i>CB</i> is equal to <i>BD</i>, <span style="float:right; display:block; margin:0 0 0 1em;">[<i>Construction</i>.</span></p>
<p class="pclass" style="text-align:justify;margin:0 0 0 0;" lang="en" dir="ltr" xml:lang="en">and that <i>BD</i> is equal to <i>BK</i>, <span style="float:right; display:block; margin:0 0 0 1em;">[II. 4, <i>Corollary</i>.</span></p>
<p class="pclass" style="text-align:justify;margin:0 0 0 0;" lang="en" dir="ltr" xml:lang="en">that is to <i>CG</i>, <span style="float:right; display:block; margin:0 0 0 1em;">[I. 34.</span></p>
<p class="pclass" style="text-align:justify;margin:0 0 0 0;" lang="en" dir="ltr" xml:lang="en">and that CB is equal to GK, <span style="float:right; display:block; margin:0 0 0 1em;">[I. 34.</span></p>
Hope that helps... -- 05:15, 14 December 2013 (UTC)
Although you were quite right to say "look again," I still hold that mucking around with display values does not seem to influence the parse output. What I did not notice before is that the first float after the image (i.e.
<p class="pclass" style="text-align:justify;vertical-align:bottom;" lang="en" dir="ltr" xml:lang="en">Produce <i>AB</i> to <i>D</i>, so</p>
<div style="display:inline;float:right;margin-left:2em;margin-top:-2em;"><a href="/wiki/File:The_Elements_of_Euclid_for_the_Use_of_Schools_and_Colleges_-_1872_page_60.gif" class="image"><img alt="The Elements of Euclid for the Use of Schools and Colleges - 1872 page 60.gif" src="//upload.wikimedia.org/wikipedia/commons/thumb/9/98/The_Elements_of_Euclid_for_the_Use_of_Schools_and_Colleges_-_1872_page_60.gif/220px-The_Elements_of_Euclid_for_the_Use_of_Schools_and_Colleges_-_1872_page_60.gif" width="220" height="223" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/9/98/The_Elements_of_Euclid_for_the_Use_of_Schools_and_Colleges_-_1872_page_60.gif/330px-The_Elements_of_Euclid_for_the_Use_of_Schools_and_Colleges_-_1872_page_60.gif 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/9/98/The_Elements_of_Euclid_for_the_Use_of_Schools_and_Colleges_-_1872_page_60.gif/440px-The_Elements_of_Euclid_for_the_Use_of_Schools_and_Colleges_-_1872_page_60.gif 2x" /></a></div>
<p>that <i>BD</i> may be equal to <i>CB</i>;</p>
<p><span style="float:right; display:inline; margin:0 0 0 1em;">[<i>Post</i>. 2. and I. 3.</span></p>
- gets enclosed in its "own" <p></p>, but the subsequent ones, e.g.:
<p class="pclass" style="text-align:justify;vertical-align:bottom;" lang="en" dir="ltr" xml:lang="en">Then, because <i>CB</i> is equal to <i>BD</i>, <span style="float:right; display:inline; margin:0 0 0 1em;">[<i>Construction</i>.</span></p>
- are kept within the main text flow <p class="pclass"></p>. I am confused. I hope this makes sense to you.
Oh, and if anybody else spots this and gets confused as to fine differences between these and GOIII full capture, those last two captures were from FF's "view source" of this page revision. Viewer2 (talk) 06:20, 14 December 2013 (UTC)
That is exactly my point. Even though the DIV is set to inline wiki-markup is oblivious to this and presumes normal block, inserting the closing P tag before opening the DIV. As soon as I switch the DIV to a SPAN (a natural inline element) the issue goes away. The point is - the mark-up doesn't seem to care what the "forced" CSS stylings are for an element, it just assumes the default and treats it that way regardless of what is manually added or CSS defined (a huge problem if everything else is going to be affected this way) -- George Orwell III (talk) 07:20, 14 December 2013 (UTC)
O.K. I feel thoroughly humbled you have so comprehensively solved my little problem. Happy to take this discussion elsewhere if this is getting too tedious, but I have exactly three matters regarding your adjustments, viz:
  1. My original coding was far too complicated, mainly because I had somehow convinced myself embedding <br/>s within <p>s broke things. Thank you for so eloquently demonstrating this is false.
    Well I just "followed" the print in terms of HTML - nothing special but yer' welcome nevertheless. -- George Orwell III (talk) 09:17, 14 December 2013 (UTC)
  2. {{RunningHeader}} parameter 3 set to &#160;? I realise this is harmless but reasons/advantages elude me?
    Just me being overly anal during testing - no benefit save a slightly more accurate centering when all 3 params have values -- George Orwell III (talk) 09:17, 14 December 2013 (UTC)
  3. My understanding of "<span style="display:inline;" was that this was entirely equivalent to <span. Is this wrong?
    Just lazy - I should have removed it when I changed the element from DIV to SPAN. I just increased the left margin a bit too so I can better how "things wrap" at the end of the lines in question (still not thrilled about how vertical alignment is handled but until its transcluded, I can live with what it is rendering) -- George Orwell III (talk) 09:17, 14 December 2013 (UTC)
Now, is it premature to start thinking about back-porting some of these lessons into {{FI}} (e.g. converting the internal <div>s into <span>s), or is your feeling that this house of cards may fall next (or next, or next etc.) wmf revision? Or drop it altogether in hopes of your alternate <img> scheme gaining traction? Viewer2 (talk) 07:46, 14 December 2013 (UTC)
It's not premature. In fact User:Alex brollo has already brought it up and went his own way. The point is some images are block (full page or between paragraphs) and some are inline (text wrapped around it or floated, etc.). Ideally, the best thing would be if it could detect which instance the template is being applied and output block or inline (or inline-block) as needed. But if setting a DIV to inline or a SPAN to block no longer produces the expected behavior, then I'm not sure what do here re: FI except have one template for inline cases and another for block cases. That would make the existing classes for IMG related rendering (class=floatright is the basically the same as saying float:right for example) pretty much useless. Thoughts? -- 09:17, 14 December 2013 (UTC)
Thanks for explanations above. Much appreciated.
Regarding {{FI}}: why not treat everything as inline (span)? Full page or centered images always have the option of specifying clear=both to obtain block effect. Now what I don't know is whether the inner div (the class="freedImg" style="width:100%;" one) should remain a div or also become a span? Either choice has implications for "your" (well it is still in your user space) CSS. Viewer2 (talk) 09:54, 14 December 2013 (UTC)
Because true inline elements don't "seem" to properly hand down settings meant to be inherited (well not under wiki mark-up and it only got worse from one browser agent to the next). The only "reason" the IMG element (inline) is manipulated the way it is under FI is the "inherit" param actually takes when it is suppose to along the path to final rendering (DIV to P to A to IMG all wrapped within a container DIV). Trying to make that happen with a SPAN instead of a P never seemed to work unless the SPAN was set to display:block (see Alex's variant; a sub-page? to FI) and even then, thanks to the ever morphing wiki-markup, it didn't work 100% as expected.

I've become somewhat jaded over the entire thing and have other wmf upgrade issues to deal with to boot.... but feel free to rip/call/edit/sandbox the .css & the template as needed if you have a better idea/approach to all this. Again, even repeating previous mistakes validates the premise overall in the end. -- George Orwell III (talk) 10:19, 14 December 2013 (UTC)

Oh well I did ask. Currently preparing suitable sacraments prior to invoking the inspiration fairy. This may take some time. Viewer2 (talk) 11:00, 14 December 2013 (UTC)
This may be an extremely silly thought, but this behaviour is as if floating elements are no longer being given equal weighing to horizontal spacing allocation in the browser to normal text flow; i.e. they are being blocked in "afterwards." I don't even know how to express that kind of logic in CSS. Regrettably I recently updated this version of Firefox, so I can't really fairly test against former behaviour. Viewer2 (talk) 02:50, 14 December 2013 (UTC)
Something seems to be taking the specs too strictly now when it comes to DIVs. Even when typed "inline" as well as display: set to inline by CSS stylings, wiki-mark-up insists on detecting it like a block element and inserting the closing paragraph tag before it. -- George Orwell III (talk) 02:59, 14 December 2013 (UTC)

Page namespace edit mode

The tab order is incorrect

Scanned image top display height is reduced by at least 25px

This makes reading the original very difficult.

Mouse scrolling of the scanned image is counter intuitive

Please read this previous post for changes implemented with the software update of 1.23wmf5 Wikisource:Scriptorium#Scroll_Bar_on_Scanned_Image.

With this 1.23wmf6 software update, the mouse behaviour on a scanned image is useless. Before the 1.23wmf5 software update, the mouse pointer scrolled the page properly as if one used the right side scroll bar. This was very handy for a left handed person - not having to reach over to the screen's right edge. Magnifying or minimizing the image required double clicking and using the scroll wheel, then a single click to revert to scrolling as before. This worked perfectly well.

Now, instead of scrolling the image vertically, the image is magnified or minimized instantly, and it requires clicking and hold down the mouse button to move the scanned page and only in freestyle mode.. This, together with the reduced window size negates my ability to contribute. — Ineuw talk 14:25, 12 December 2013 (UTC)

Proofreading toolbar gone from WikiEditor

Lost the ability to resize/reset images, toggle between horizontal/side-by-side layout and toggle headers & footers to show or hide in edit mode in the Page: namespace. [IE8, XP-Pro]-- George Orwell III (talk) 01:40, 4 December 2013 (UTC)

I've still got this, but buttons are in a different order. [FF, XP-Pro, Monobook]. Used to be toggle header, toggle side-by-side, zoom out, original size, zoom in. Now, zoom in, zoom out, orignal size, toggle header, toggle side-by-side. Beeswaxcandle (talk) 06:51, 4 December 2013 (UTC)
A purge of browser cache should solve the issue. Tpt (talk) 07:36, 4 December 2013 (UTC)
I have cleared my entire cache and bypassed the cache when loading, and I still have no proofreading toolbar. - Htonl (talk) 11:54, 5 December 2013 (UTC)
I'm not affected by this issue. @Htonl what is your browser (it's maybe an IE specific issue)? It's also possible that it's an issue caused by a script or a gadget that have not be updated to work with the new version of the extension. Is the issue remaining when you disable all your gadgets? Tpt (talk) 21:01, 5 December 2013 (UTC)
Same thing when I'm logged in or not [IE8/xpPro] - no more Proofread tab (WikiEditor booklet) - so I don't believe it can be a Gadget (although our EditTools is much screwed up so I'm not 100% sure about that). Plus this was always "incomplete" in a sense even before the latest changes because the OCR button always appeared in the main insert tab (insert signature, insert link, insert file, insert citation) rather than somewhere under the Proofread(ing?) tab. -- George Orwell III (talk) 11:08, 7 December 2013 (UTC)


Fwiw.... Here's what the IE8 "debug" tool console says & points to right at the start of opening edit mode in Page: namespace...

Expected identifier, string or number
load.php?debug=false&lang=en&modules=ext.proofreadpage.page.edit%7Cjquery.prpZoom&skin=vector&version=20131208T025115Z&*, line 3 character 805

So [when line#, etc. is transposed] it's line 199 in ext.proofreadpage.page.edit.js that is causing the "first error" here. The line is

class: 'mw-toolbar-editbutton'

I don't see how that could affect me because in my case, WikiEditor is enabled (usebetatoolbar = 1 [or true]) so the "else" in that section of the .js shouldn't apply should it? -- 01:49, 8 December 2013 (UTC)

And while we're at, shouldn't line 216 be ext.wikiEditor.toolbar? -- George Orwell III (talk) 03:54, 8 December 2013 (UTC)
I've made a change that have been just deployed to solve this error. Does it works for you now? At line 216 it should be ext.wikiEditor because this function relies on the HTML tree created by VisualEditor around of textbox1 and not on the toolbar itself. Tpt (talk)

┌───────────────────┘
 Now I have the ability to set horizontal/side-by-side & show/hide header footer in my User preferences and have it take in Page: namespace edit mode but the WikiEditor toolbar is 'completely gone. No booklets, No groups, No tools - nothing. Its fine in other namespaces however.

It seems like the entire load order is out of whack now too because any extras I had load as gadgets before are no longer in the left-hand side menu in the Page-namespace when entering edit mode (w or without previewing in edit mode makes no difference - no WikiEditor Toolbar or gadgets). Also, the images for back, forward and Index are replaced by the fall-back text, not the arrow-head images.

I will try looking at things more closely in a bit & report back. -- George Orwell III (talk) 23:44, 12 December 2013 (UTC)

fwiw, now the on-board debug thing for IE8 first points to your recent change in jquery.prpZoom.js, putting single hash quote marks around the term 'default' (line 32). Again, I don't understand why the soon-to-be-dead-if-not-dead-already old button scheme (deprecated a couple of builds ago - just ask Krinkle?) is in there at all... never mind the fact I'm WikiEditor enabled anyway (usebetatoolbar=1 [kind of misleading because VISUALeditor is really the beta just about every place that counts & WikiEditor is the "default"]). Same story wether I'm logged in or not here as well edit mode in the Page namespace on old WikiSource btw. -- George Orwell III (talk) 04:26, 13 December 2013 (UTC)
Sorry, for the misswriting. I of course wanted to say "WikiEditor" and not "VisualEditor" that doesn't work at all currently for Page: pages. The issue in jquery.prpZoom.js that cause a JavaScript fatal error (and so a stop of all JavaScript execution in the page) have been solved and the correction should be deployed next Tuesday. There are ever a not negligible number of users that love the old toolbar and it's why the support for it is kept. Tpt (talk) 08:15, 14 December 2013 (UTC)
Thanks but I don't know why we have to wait until next Tuesday to apply it when patching it now would help insure Tuesday's build would be error free.
As for the toolbar - I'm sorry deprecated is deprecated. There shouldn't be any "wiggle" room on that and I'm surprised this is an acceptable attitude development-wise. If past history is any indicator here, one day Vector, or settings related to it, will shut it off / cripple it again (and again, and again, and again). The old-toolbar should be limited to monobook if anything and current application/customization should be ported over to fit WikiEditor (at least under Vector skin) -- and I know that isn't exactly the most User friendly utility to port over to either. Still, the window allowing for one or the other is only going to get smaller as time passes so I don't see the point of dragging out the inevitable (especially when efforts have been made to deprecate it). -- George Orwell III (talk) 09:51, 14 December 2013 (UTC)

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

Sorry to bring this up again but I'm afraid it will only lead to further problems down the road if it isn't resolved now.

Again, if you want "backwards" compatibility for the "old" toolbars & buttons, thats fine & I'll spare you the debate over why that might be a bad idea. Yet, you should insure the designed compatibility moving forward works properly before you make it possible to support that backwards compatibility. thats just not the case even under wmf9.

Again, in one's User preferences, Editing tab - deselecting Show edit toolbar while selecting Enable enhanced editing toolbar works fine everywhere & in every namespace except the Page: namespace.

Not only does WikiEditor not appear with those mentioned User preference settings (plus IE8/xpPro) but everything that existed in the "3" textbox areas are automatically blanked upon entering edit mode as well. The same thing happens to other Users with the same settings (non-IE), just see the screen grab that follows....

The specified image (New setting no longer show the scan or text in edit mode.jpg) does not exist

Putting the terminolgy used at the moment for the labels for those two User preference checkboxes aside, in reality one is for the "oldToolbar" (on its way out) and the other is for the "betaToolbar" (on its way up); I'm sure you know that by now regardless. All I'm asking for is if you insist on keeping backwards toolbar compatibility around longer than the rest of development does, please don't make the overall forward progress being made dependent on having that backward compatibility enabled.

Thanks for all your great work on this btw. Fixed in 1.23wmf16. -- George Orwell III (talk) 22:10, 28 February 2014 (UTC)

Retrieved from "https://en.wikisource.org/w/index.php?title=Wikisource:Scriptorium/Archives/2014-02&oldid=14010508"