Wikisource:Scriptorium/Archives/2009-12

From Wikisource
Jump to navigation Jump to search
Warning Please do not post any new comments on this page.
This is a discussion archive first created in , although the comments contained were likely posted before and after this date.
See current discussion or the archives index.

Announcements

November is Validation Month

At PotM we had a discussion and thought that it would be good to get some of our Proofread works up to the Validated. To add a bit of variety, we have eight texts that will loop through. If (as?) they progress to completed, we can add and subtract to the rotation. Hope that you will join us in getting a range of works completed. Cheers. -- billinghurst (talk) 22:31, 31 October 2009 (UTC)

Validation Count Hits 10,000 Pages

At some point during this afternoon, we passed the 10,000 page mark in Category:Validated! Many thanks to all who have taken part in this month’s special project. Onwards to 20,000!  :-) Tarmstro99 (talk) 01:46, 11 November 2009 (UTC)

WikiProjects replaces Song of the Day

To let the community know that in the {{Welcome}} banner we have replaced the quiescent {{Song of the day}} with {{Active projects}} (AP). We have identified five active WikiProjects, and each will feature (weekly rotation).

Background: Recently at {{Welcome}} talk page there was a discussion about revamping what was on offer to new visitors. Hopefully this will give a nice blend.

-- billinghurst (talk) 12:54, 7 November 2009 (UTC)

Fix of Index page status issue

ThomasV has had the fix of the Index: page status reset problem implemented into production. Woohoo Thomasv!

There is a little work that editors will need to undertake. Where the status on an index page is out of kilter with the respective Page: page status of the works, then each individual Page: page status need to be renewed by performing a null edit such pages, then undertaking a purge on the Index: page to renew its status. At some point we will look to get a bot to run through the pages, however, we cannot guarantee that we will get all pages, nor can we guarantee that it will be done soon.

[Easy purge -> click the clock top right if you have that gadget functioning] billinghurst (talk) 23:22, 16 November 2009 (UTC)

Proposals

New bot proposal

Please see older thread at #Bot extraction of text already in DjVu file. I'd like to set up a pywikipedia bot to go through the nonexistent pages at Index:Dramatic_Moments_in_American_Diplomacy_(1918).djvu and fill them in using the djvutext.py script. This is the only task I plan for the bot for now. --LarryGilbert (talk) 19:48, 1 November 2009 (UTC)

I have now done a brief trial run of the bot and had it add four pages. I confess I overlooked the guideline to throttle the updates back to 1 per minute, but I hope the restricted length of the run excuses that. I will be more careful with that in the future. Please let me know here or on my talk page if there are any problems. --LarryGilbert (talk) 21:58, 4 November 2009 (UTC)
Looks fine. Can you test it to see what it does if it is faced with the same pages again and that it doesn't hang or get confusled.-- billinghurst (talk) 22:38, 4 November 2009 (UTC)
I did another run using the same range of pages plus one. As expected, the bot skipped over the pages where text already existed, adding only the single new page. On this run, I neglected to run login.py first to have the bot log in to its account. I was asked for a password when I started up the bot, so I expected that it would log in at that point, but apparently it didn't (see history for Page:Dramatic Moments in American Diplomacy (1918).djvu/121). I take this to be a bug in the pywikipedia code, so I will have to take care to run login.py before any run of the bot. --LarryGilbert (talk) 01:58, 5 November 2009 (UTC)
If the bot was posting identical text over the top, MediaWiki would have treated it as a null edit, and it would look like no edit was made. You should apply some fixes to one of those pages, then run the bot over it again, and see if the bot reverts those fixes. Hesperian 03:02, 5 November 2009 (UTC)
I proofed Page:Dramatic Moments in American Diplomacy (1918).djvu/117 and ran the bot again with the same range of pages as the last run (the page I edited was the first in that range). It recognized that all five pages had text and skipped over them. --LarryGilbert (talk) 05:23, 5 November 2009 (UTC)
I ran djvutext.py as Schlep once more. I just had it add 4 more pages. All looks well from here. --LarryGilbert (talk) 18:53, 9 November 2009 (UTC)

I still don't understand why it is desirable to post uncorrected OCR, when the OCR is preloaded when you edit the page for the first time. Posting OCR doesn't help, and arguably it slows us down by giving us an extra link to click in order to edit the page. Hesperian 23:27, 4 November 2009 (UTC)

In this case, there was uncorrected OCR text already existing for this book, no better than what is in the DjVu file; in fact, I suspect the original uploader just took the text straight out of the same DjVu file and uploaded it as one big long page (this at a time when the ProofreadPage extension didn't exist). Replacing the existing text with text divided across the Page namespace is effectively making an improvement. --LarryGilbert (talk) 00:25, 5 November 2009 (UTC)
"I still don't understand why it is desirable to post uncorrected OCR, when the OCR is preloaded when you edit the page for the first time.", because that way we can set up a text using the PAGEs; even if it's not corrected. A badly-parsed text is better than no text at all, for the next 18 months until it gets proofread. Sherurcij Collaboration of the Week: Author:Khwaja Kamal-ud-Din. 00:38, 5 November 2009 (UTC)
I agree with Sherurcij. A further benefit of having even the raw OCR text online is that it enables semi-automated proofing and correction of the OCR’ed text (as User:TarmstroBot is presently doing with the United States Statutes at Large), leaving less work for human editors when they do eventually turn their attention to the page. Tarmstro99 (talk) 01:34, 5 November 2009 (UTC)

After several runs of the bot, I'm feeling confident that it's doing what it's supposed to do. Could that account be given a bot flag, or is that still premature? --LarryGilbert (talk) 06:49, 12 November 2009 (UTC)

I've granted its flag. There was no opposition and after almost two weeks.—Zhaladshar (Talk) 14:28, 12 November 2009 (UTC)
Thank you! --LarryGilbert (talk) 01:22, 13 November 2009 (UTC)

Remote nomination of English texts at Canadian Wikilivres

In addition to my initiative to discuss the moving of speeches tagged as "PD-manifesto" to Canadian Wikilivres since 15 October 2009, I would also like to propose allowing users right here to remotely nominate deletion of English texts at Canadian Wikilivres because Wikilivres pages, including Wikilivres:Wikilivres:Possible_copyright_violations and Wikilivres:Wikilivres:Delete corresponding to our WS:COPYVIO and WS:DEL, forbid IP edits without logging in with usernames after excessive vandalism. Unless exception can be allowed there, I consider allowing remote control possibly needed to discuss if any English texts at Canadian Wikilivres should be deleted. Even if exception is granted there, I see 1,506 registered users, of which 10 (or 0.66%) have Sysops rights, with unknown number of "active" users, so I doubt if sufficient community exists. In case a work tagged PD-manifesto here is moved there but found without any permission to reproduce, remote control can discuss. Please discuss if we should start my proposed remote control as I also plans to propose this at Chinese Wikisource due to extremely limited Chinese users at Wikilivres.--Jusjih (talk) 03:57, 14 November 2009 (UTC)

I'm uncomfortable with entangling the two, for legal reasons and because it makes things more complex. They run on different copyright laws and policy than we do and it would be confusing to handle both. Also, it would be help Wikilivres itself if they did this instead of depending on us; figure out how to get the sysops and get things done.--Prosfilaes (talk) 04:11, 14 November 2009 (UTC)
If no consensus to do this here, I am willing to close this discussion, but I am waiting for Wikilivres response. For English pages, If anything hosted there was unacceptable here but is now acceptable here with evidence, where should the request to move the page in be posted? Perhaps there, but until any change, only if logged in with username. After all, I would like to ask any users interested in Wikilivres, especially administrators, to consider registering usernames there, before yours are already taken by someone else. User:Yann is the webmaster, bureaucrat, and checkuser there. Even if you are not interested in editing there, all nine administrators including myself speak English with different skill levels, then whether something should be deleted there can be decided with limited comments.--Jusjih (talk) 02:07, 15 November 2009 (UTC)
Wikilivres:Wikilivres:Community_Portal/en#Allowing IPs to edit deletion requests? reports that exceptionally allowing IPs to edit its deletion request is not feasible, so once again, say you do not consider remote deletion nomination feasible here, please consider registering Wikilivres usernames before someone else takes yours.--Jusjih (talk) 04:32, 16 November 2009 (UTC)

Flagging obscure words, names, etc. for further research

I was working on the proofread of the month, and on a page from the Transactions of the Geological Society I found an interesting word: "contre." It's so interesting that I can't find a reference to it in the OED, even though it seems plainly to be in English usage here. It occurred to me that it might be nice to have a special template for flagging obscure words, phrases, names, or what have you; this would allow making them available in one spot for interested parties to see whether they can find more information on them, and if necessary add that information to one of the Wikimedia projects. Good idea or a waste of time? --LarryGilbert (talk) 19:17, 14 November 2009 (UTC)

I cheat. I wikilink to wikt:, and if it doesn't exist, I create the request there, and then add in the page reference so that they can find it and utilise it. Then I run away very quickly.smiley -- billinghurst (talk) 23:09, 14 November 2009 (UTC)

Category tree for Special:Categories

To be honest, I would like to put <categorytree mode=all depth=0 showcount=on>Categories</categorytree> at the top of Special:Categories on all wikis. For example, on this wiki it would result in this:

Categories(7 C)

-- Chucky (UTC 12/9/09, 22:19)

Other discussions

Video transcripts

Apparently, Commons is going to start doing transcripts on the audio of videos. It's a tech thing, so the feature is inevitable and who knows when anyone is going to start working out where to put the metadata and the rules on translations, much less working with us on it.--Prosfilaes (talk) 00:30, 10 November 2009 (UTC)

Questions

Stale page link coloring on index page?

I recently finished proofreading Index:Scheme - An interpreter for extended lambda calculus.djvu, but a seemingly random selection of page links that used to be colored yellow have become red again. (Viewing the actual pages confirms that they are still proofread/yellow.)

I thought it might be a caching issue, but i have edited some of the pages in the mean time, and the problem seems to erratically persist. Does anyone know what's going on? --Piet Delport (talk) 00:24, 13 October 2009 (UTC)

This is a known issue; all we can tell you about it is at User talk:ThomasV#Another problem?. Hesperian 00:40, 13 October 2009 (UTC)
Ah, thank you for the pointer. I guess i'll wait for a fix; please let me know if i can assist in debugging in some way. --Piet Delport (talk) 01:43, 13 October 2009 (UTC)
I do know that a null edit of individual pages fixes the issue, and for me doing it with AWB was easiest, though somewhat manual. There is also the sporadic nature of Related changes that come and go, and again are fixed with a null edit of the Index: page.-- billinghurst (talk) 04:56, 13 October 2009 (UTC)

This problem got worse, not better, over this past weekend. Today a large number of pages in Index:United States Statutes at Large Volume 1.djvu that are in fact validated (such as this one), and which were showing up as green links last Friday, have reverted to the red “not-proofread” background on the index page (which, in the case of the above-cited example, means that the index is now more than a year behind the actual current page status). Problems of this sort really need to be ironed out before, not after, the site launches a special campaign to get users involved in validating pages; it makes us look foolish otherwise. The solution can’t just be “make null edits to the pages to update the status,” because even that fails to make the new status “stick” in the index (and certainly new users would have no reason to know that they must check back in at random intervals to “re-validate” a page they had previously marked as validated). Tarmstro99 (talk) 14:24, 9 November 2009 (UTC)

According to the Bug filed on Bugzilla, the problem is resolved. I would imagine in a couple days everything will go back to normal.—Zhaladshar (Talk) 15:07, 10 November 2009 (UTC)
It hasn't stopped, and it is ... a waste of time. Can we have the link to the report on bugzilla please. Cygnis insignis (talk) 18:22, 14 November 2009 (UTC)
Resolved in the coding, and now in SVN. Awaiting next code update to be implemented. As usual ThomasV has to wait for their window of opportunity for launch. billinghurst (talk) 23:03, 14 November 2009 (UTC)
As discussed on my talk page, ThomasV and Phe indicated that this is due to a deeper change, which in this case it was due to our modifying some underlying templates. I am talking to AWB programmers to help me out so I can null edit the affected pages. (Takes time as it is not a std implementation, and in fact railed against for WP implementation of AWB) billinghurst (talk)

Indexes and TOC

I completed formatting the indexes of Popular Science Monthly Volume 1, and in the process, I also created a page number ordered Table of Contents, although I have to edit the description column for the proper wording order. I placed it in Ineuw/TOC. Could someone let me know if it's of any use? Ineuw (talk) 02:38, 26 October 2009 (UTC)

To note that
  • I would suggest that you make them subpages of the volume, so to do that with relative links, add a '/' like [[Wikisource:Scriptorium/...
  • one does not have to slavishly align page and document pagename with or header text, especially if it starts to make urls butt ugly. I try to maintain a balance between usability, reasonability and any future need to disambiguate within the nomenclature, e.g. I would not have linked the words (Illustrated); and instead of something like [["The To-morrow of Death" (by Louis Figuier), Notice of]] may simply be sufficient to label as "[[/The To-morrow of Death /]]" (by Louis Figuier), Notice of . No need for the " " in the wikilinks unless absolutely necessary. Also note the '/' used at the end of the relative link to pipe the output differently.
  • Titles like "Sociology, the Study of" would be better as "The Study of Sociology", and use {{DEFAULTSORT:Sociology, the Study of}}
billinghurst (talk) 05:17, 26 October 2009 (UTC)
  • Many of these suggestions are matters of opinion. Indexing a work under "The" or "A" makes no sense at all. Who would look for these works there? In the short term, as long as these pages only exist individually as part of the broader publication the suggested the suggested method is reasonable, but eventually, when the articles get split out as separate works they would do better linking to the works themselves. Eclecticology - the offended (talk) 19:06, 26 October 2009 (UTC)
  • Another view, stay flexible with 'naming rules' , but defer to the publisher's text; for example, abbreviating titles may be misleading. In billinghurst's example, someone searching for the "work" would find a single paragraph 'notice of'. I have to use exact match in searches when I'm looking for articles on the web, to sift out the similar titles, reviews, or citations.You may find a half title in the text, but otherwise put what you see and change it only if makes it more accessible. Users read pages, not urls, our title is insignificant unless it interferes with access. Get the full title as a redirect at least, there are millions of titles and it doesn't take long to find problems when you cutting corners. You don't need to put a 150 characters into the header template display, a subpage only needs to be distinguished from other parts of the work. As they say, redirects are cheap and default sorts can drop 'the' and 'A' for indexing (which are sometimes sensible titles).

    What is meant by 'eventually split out'; some things may justify multiple transclusions of the same page: namespace, but this seems to imply the larger work would eventually be disassembled. Cygnis insignis (talk) 20:23, 26 October 2009 (UTC)

    • Flexibility, by all means! - beginning with the meaning of "a work". The second article in the first volume of Popular Science is "The Recent Eclipse of the Sun" by R. A. Proctor, Author:Richard Anthony Proctor. It was not an original publication, but was copied from an unspecified issue of Cassell's Magazine where it may or may not have had the same title. Later in the same volume his "A Giant Planet" was taken from Cornhill Magazine. The articles here are what would be the works, and not the magazine. Splitting out would put emphasis on Proctor's work rather than on the magazine. On the other hand, the "Notes" page may be better treated as a sub-element of the magazine. Certain "Review" publications such as Quarterly Review don't really give titles to the articles, and one long article frequently reviews a number of other publications together. Many 17th and 18th century works have titles that amount to whole paragraphs; many of these should likely be reduced. Displacing a leading "a" or "the" is a matter of established bibliographic conventions. Yes, there are exceptional cases where it would be important to retain the article in place, but not all searching should be electronic; we need to allow for browsing by humans. In a library the experience of browsing the shelves is qualitatively different from the experience of finding something in the card catalogue. Eclecticology - the offended (talk) 19:52, 27 October 2009 (UTC)
    • The same thing can be created with a redirect. The publication is the work we are dealing with, so as we don't necessarily know any exact earlier source, or if it is an exact copy, I would propose that we keep it in situ with the published work, and create a link from the root level in the main namespace to the article. This also assists disambiguation. billinghurst (talk) 21:03, 27 October 2009 (UTC)
    • I think the best way to handle works that have seen publication in multiple meta-works is like this. Hesperian 23:33, 27 October 2009 (UTC)
  • Definitely agree with Hesperian on the matter. That {{versions}} should be used when we have more than one copy of an article, or where we know that more than one copy exists. And to do that, I do feel that we need to have the works as subpages to manage their locality and provenance. billinghurst (talk) 02:32, 28 October 2009 (UTC)
  • That seems excessive. For every British novel we host, I can find distinct editions in British and American spelling. Quite a few of our major novels have abridgments and variant editions in the PD. Preemptively creating versions pages when we have but one version is a lot of work for little to no gain.--Prosfilaes (talk) 13:52, 28 October 2009 (UTC)
Let me modify my statement to more reflect my brain thoughts {{versions}} should be used when we have more than one copy of an article, or where we know that more than one copy exists and need to disambiguate it.
To illustrate the extent of the problem, I've provisionally added Popular Science/Volume 1#Table of Contents for the first number. For now we need only concern ourselves with material where copyright is not an problem. A significant number of the articles in that number first appeared elsewhere. In the nineteenth century it was very common for American publications to copy from European ones (especially British) without any permission or payment whatsoever, and often without credit. In theory, using the Wiki-is-not-paper principle, we could host them all, but it may not be practical to document the small variations that distinguish two or more versions. The risk is that we can too easily oversimplify the problems. For a play like Macbeth, how important is it to have an expurgated school-boy version that omits the scene with the porter? Eclecticology - the offended (talk) 00:56, 29 October 2009 (UTC)
I don't see a problem. Posting of multiple versions will be mediated by user enthusiasm. We will have (if we don't already) users who see value in posting Thomas Bowdler's expurgated versions of Shakespeare alongside the originals. We will have (if we don't already) users who see value in posting different versions, with different provenances, of important manuscripts and speeches. We will have (if we don't already) users who see value in posting every single public domain version of the Bible. But I doubt we'll ever have users who are willing to waste their time posting and proofreading multiple versions of the same document, where the differences are trivial and entirely lacking in scholarly importance and interest. It is only in this last case that any problems arise. Why structure our work around the anticipation of a problem that has never happened and probably never will? Hesperian 02:34, 29 October 2009 (UTC)
True enough, but in that last case we can't know if there are any differences until the two are compared, and that's as much work as proofreading. The problem is not as unlikely as you believe. It has come up in the comparison of the original Dictionary of National Biography and its first reprint. A large number of changes were made in the reprint. This was primarily to correct errors, but that often necessitated other changes to avoid having the corrections spill over onto another page. An added sentence required removing material elsewhere on that page. Probably a majority of articles did not require changes at all; what benefit is there to duplicating these? Eclecticology - the offended (talk) 08:24, 29 October 2009 (UTC)
I use a text editor to compare documents, by proof-reading a few random pages or using the machine read text in the page scan to get an indication of whether it is worthwhile. If a user was interested in a particular entry in DNB, or an article in the above, they may get around to comparing the available editions. If another work gave special reference to these versions, for what they think is a notable reason, they can be linked in someway. This is perhaps less work than annotating the trivial to the substantial variants in the notes (or worse, the text), which may be subjective, unknown or incomplete. The versions can only increase the integrity of works projected for completion, it doesn't detract from them. Placing similar versions in their context is good for that browsing factor mentioned above, it is qualitatively different. That references given in works like DNB use these details surely indicates is not always trivial. This sort of thing is actually and potentially useful, or harmless. (On the subject of displacing or omitting the article in the title, I still reckon that is not always appropriate; the need to retain them is more than rare and it sometimes ungainly. It is good for bibliographies ... ) Cygnis insignis (talk) 21:09, 29 October 2009 (UTC)
The most practical way to show changes, which are most often short, is right in the text. Thus old text new text. Previously, I was putting the new text in square brackets, but that led to some ambiguous situations when square brackets were already used in the original. Another point to be made about magazine titles is that many with a long history such as Popular Science or National Geographic dropped the article somewhere along the way. Eclecticology - the offended (talk) 10:04, 2 November 2009 (UTC)

What is the go with Template:Indent?

I see that Template:Indent is still on the books and used, though is noted as deprecated with people being pushed other ways. Not knowing the history of the deprecation, is anyone able to provide further information? Are we looking to better retire such templates? -- billinghurst (talk) 05:51, 26 October 2009 (UTC)

A chequered history. It was invented to handle line staggering in poems. This functionality became redundant when the <poem> tag was invented. Nonetheless the template was retained because it had found a new and unanticipated use: preservation of paragraph indentation. For that purpose it was implemented very badly indeed, and so it was updated to support indentation via css styling. This latter functionality was called in a slightly different way, so that it was not necessary to remove the old, crappy implementation in order to bring on board the new implementation. Keeping the old functionality meant that it would still be possible to view old versions of pages that use the old version of the template. Thus we ended up with a template that does two different things; or rather, the same thing in two different ways. Meanwhile, I became irritated that Template:Indent required the indentation size to be the second parameter rather than the first; i.e. {indent|Blah blah blah|1em}<nowiki> I felt that <nowiki>{indent|1em|Blah blah blah} was much more intuitive, especially when wrapping large blocks of text; plus the latter was in keeping with {{hanging indent}} which I had created to use the latter calling order. Therefore I forked Template:indent to {{text-indent}}, with the latter using the better calling order, and which I recommend as a replacement. Hesperian 07:10, 26 October 2009 (UTC)
As there is no further comment, I propose that all the works using the template get converted to {{text-indent}} and Template:Indent is sent to the great template retirement home in the sky. billinghurst (talk) 01:02, 4 November 2009 (UTC)
I support this, but (in case he doesn't turn up to say so himself) I think JV does not. He has a point: once you delete a template, old revisions that use that template don't render properly any more. That argument doesn't carry much weight with me, because that line of thinking tell us that every time we modify a template we are falsifying the history of every article that has ever used it; but that has never stopped us improving our templates. Nonetheless that point of view exists, so I thought I should report it. Hesperian 06:18, 21 November 2009 (UTC)

IRC channel?

Do we have a dedicated IRC channel? Ineuw (talk) 17:53, 27 October 2009 (UTC)

We have the one IRC channel for WS, and it is not too crowded and a reasonable place to be. There is a link at the top of this page, and also at Special:RecentChanges. billinghurst (talk) 20:57, 27 October 2009 (UTC)

Portals

I'm trying to formulate (as are others) a good way to handle reference material that is naturally divided into "topics" texts (e.g. discrete encyclopedia articles or biographies). One thing that has come up is that the Portal namespace is not so used here; and so maybe it should be, to organise such topic-related material by topic. Before speculating too much about that, I thought I should check out what exists. Three kinds of things: Portal:French literature looks like a traditional portal; Portal:Australia redirects to Wikisource:Australia; and Portal:Speeches is a kind of preamble to Portal:Speeches. Evidently this is all very top-down, while the problem needing a solution for "topics" is that where there are several texts relating to the same topic, there is a need to present to the reader a choice or menu. Considered as a disambiguation issue, you disambiguate the titles somehow: but this leaves the real issue, which is that everything is now nice and distinct, but not more findable than before. If there is a dab page, how are people going to find it?

Anyway, the theory of portals is that they are about user-friendly ways in. There seems to be some tension with the Wikisource: namespace and its function(s). I'm really angling for some discussion of a way in which Microportal:Napoleon (say) could exist and perform more like an Author page, collecting various internal and other links, without having to be a page about an author, and could coexist with Microportal:Duke of Wellington and other such material. All without prejudice to anything anybody else would wish to have in Portal space. Charles Matthews (talk) 09:41, 30 October 2009 (UTC)

I 100% agree with you that the Wikisource: namespace should be for project management and other meta- issues, and we are misusing it by putting topic indices (i.e. the contents of Category:Wikisource index pages in there. I also agree that these are not portals. Methinks we need a Topic: namespace. Hesperian 11:37, 30 October 2009 (UTC)
If we do. I would like to see whatever we do have a close link to other wikis so that there is an opportunity to x-wiki between Portals. That plays on the strength of wikis, and helps to align and drive traffic. billinghurst (talk) 11:48, 30 October 2009 (UTC)
After a brief look around, it doesn't look as if many Wikisources use portals a lot. French Wikisource seems to have more than most, and organised in a fairly clear way. Others are similar to English Wikisource, including Portuguese Wikisource or Italian Wikisource, in that they have few portals which don't seem that coherent at the moment. - AdamBMorgan (talk) 12:33, 30 October 2009 (UTC)
Portals are strange creatures, quite unlike our current Wikisource Index pages; they mash together templates of "Did you know...", "Recent additions..." and such. Not really something into which we should change our Portal:Mermaids, Wikisource:Wars, Portal:Islam or Wikisource:Education in my opinion. As ABM says, Portals aren't used a whole lot, especially in Wikisources - and the idea of having a Portal:Napoleon Bonaparte in addition to a Portal:Duke of Wellington seems to strain the limits of my vision for Wikisource. Works about a person go on that person's author page (even when, like some of our authors, they wrote no works themselves). To be honest, I'd be in favour of nixing "Portal" namespace altogether, and just adding "Index", and then we could have Index:Education and Index:Islam -- but that's probably a much larger decision than just en. can handle. Sherurcij Collaboration of the Week: Author:Khwaja Kamal-ud-Din. 13:02, 30 October 2009 (UTC)
In this regard, I was thinking Portals at Wikipedia:, more like those listed at w:Portal:Contents/Portals billinghurst (talk) 13:03, 30 October 2009 (UTC)
I too believe that 'Wikisource' should be used for project management. A 'Portal' namespace is a good way to separate source texts (content transcribed at wikisource) from pages covering a topic, which is content created by the project itself ThomasV (talk) 13:10, 30 October 2009 (UTC)

It looks as if there is a strong preference for namespaces with clear functional boundaries (kind of content both in terms of how generated and for what purpose). Which is to be expected. Perhaps the point to make next is that a portal implies a page looking for relevant content, while what I'm really talking about is a bunch of topic texts looking for relevant indexation.

One schematic would be to note that we already have a category system, so that the way a Topic namespace might fit in would be in a layer cake: Portal pages, over categories dedicated to topic pages, over pages in Topic space itself. This provides an odd definition, in that Topic pages would be potential orphans except that they should be clearly categorised in relevant ways by a special part of the category system, and would exist to index texts of factual and reference value. And so they are really there because you can't annotate entries on a category page?

Perhaps there is an idea here trying to get out, that Topic pages should be by intention "atoms" designed to transclude into bigger "molecular" pages. That at least expresses the notion that while Portal pages are naturally top-down, there is some missing notion of bottom-up indexation driven by the fact that we may have five texts on the same topic and currently just juggle them. Charles Matthews (talk) 14:21, 30 October 2009 (UTC)

There was some discussion of the problem with the Index: namespace at Wikisource:Scriptorium/Archives/2008-08#Standardize index linking. One underlying problem is that Wikisource undertook an idiosyncratic use of "Index" to organize the Page: namespaces. This is contrary to what most people would normally expect from indexes as a way of finding information within works. I would very much agree that some repurposing is in order here, and that much of the existing idiosyncrasies should be moved to the Page: namespace in the format "Page:Name of publication/Contents". This should not conflict with existing material in the Page: namespace since these are already distinguished by page numbers.
From my limited understanding of the coding, there are specific differences in how Index: and Page: work, and that is handled by different templates and javascript. I think that we have to accept that they retain their own namespaces. Trying to move from Index: at this point does not represent a value proposition IMNSHO. This discussion would be better targeted at what we can reasonably and practicably, and what alternate terms exist for what we want.
Perhaps so. If these must be separate namespaces, can the Index: namespace be renamed? But if traditional indexing needs to be in a new and different namespace this is not going to be the most important aspect of what we are addressing. Eclecticology - the offended (talk) 10:03, 3 November 2009 (UTC)
The broader question here is to the general purposing of all namespaces and how they might best be utilized. I agree that the Wikisource namespace should be limited to broad issues of project management, and anything there that guides the reader through works or helps a person to find content should be moved elsewhere. The non-contributing reader is not likely to have any interest in project management issues.
A word of definition about what we mean by "bottom-up" and "top-down". Categories are bottom-up because they start from individual articles and look to place those articles in a topical home. Portals or Wikipedia's "List of ..." pages are top-down because they begin from a topical home and look for content to live there. Both are valid approaches to organizing knowledge. Curently we have both author categories and author wikisource pages. The problem with the latter is its need for maintenance. Unless a person goes there to add a new author it doesn't happen. As a top-down scheme it could just as easily include red links to authors for whom we do not yet have pages.
The Portal: namespace is indeed underutilized. In the short term it's use would be better restricted to major topic areas, but that could be expanded at a later stage. Well done as it may be, Portal:French literature may still be too specific for a top level portal; Portal:Literature would certainly be a better top level portal that guides us to the literatures of various languages and/or countries. I reserve opinion on a possible Topic: namespace; it may be a good idea, but where it goes depends on how we see it as related to the other namespaces. Eclecticology - the offended (talk) 18:09, 2 November 2009 (UTC)
For me part of the discussion resides with searchability and findability. I think that many people never get out of the main namespace, and don't understand other aspects of namespaces and how they are used. We don't help. I am open for the discussion, it should be good. billinghurst (talk) 23:35, 2 November 2009 (UTC)
To sharpen one of the main points being made, navigation is good, but need it be through the part of the site devoted to project management? This would seem to take you immediately backstage. And the demarcation of projects is not the same as any natural division by subject area. The granularity appropriate to such a division is what really needs to be addressed. If the Portal namespace is to remain the main tool, then the thinking on granularity has to be more flexible; if not, then we need need another namespace and spec. Charles Matthews (talk) 08:08, 3 November 2009 (UTC)
First, let me make sure that we understand the word "granularity" in the same way. I read it as the ability to classify data into progressively more specific topics.
I agree that [wiki]projects are not the same as topical divisions, but again let's define our terms clearly. There is an ambiguity to the term "project management" My first inclination was to refer to that term as relating to the overall management of Wikisource as a project in itself. That approach would result in the Wikisource: namespace being used for such things as policy development and operational issues. I was concerned that you could be referring to the management of wikiprojects such as those for DNB and EB. The management of wikiprojects could merit a portal in its own right.
"Findability" and "flexibility" could be important features of a portal based systems. "Searchability" is primarily a machine function, and may be more related to software development than portals. I think that mediawiki search functions are seriously underdeveloped for such large databases as are found in Wikimedia. Solving that problem is well out of the scope if what we can do.
Rather than calling portals a "main tool" I would prefer to see them as top-level classifications. If one or more new namespaces need to be developed, that's fine, but I would avoid acting prematurely on this. For any top down classification system it is important to consider what might be the optimum number of divisions at any stage in the process. Too few, and we haven't divided things at all; too many and readers get tired before they can get through the whole list. When someone is Google searching how does he set the default for the number of hits on a page, and how many Google pages does he look through before giving up? What are the hazards of search terms that are either too broad or too specific? The problems that we need to address are not too different from those in Google searches. Eclecticology - the offended (talk) 10:03, 3 November 2009 (UTC)
Checking out Category:Categories, I think I see one end of the problem that needs discussion: none of the top-level categories within it addresses the idea that someone might come to Wikisource to research some given area of content. And being conscious that this all started from the idea that the same topic may be treated in the ED and DNB and other reference works, I feel that the comments before about indexation have merit: there are things needing to be indexed. Category:Portals is now a subcategory of Category:Wikisource, but it would be the work of a moment to change that. Would it be a good idea to place it as a subcategory of Category:Topical classification, as a psychological step in differentiating portals from project management, and suggesting that some work at least should be done within the category system on findability by topic? Charles Matthews (talk) 14:53, 3 November 2009 (UTC)
That could be a positive step, or even a name that suggests that this is a temporary category for only those things that we want moved out of the Wikisource namespace, and into something more meaningful. The more I look into some of this the more convoluted the problem appears. In part there seems to be a great unwillingness to clean out old ad hoc concepts that never got very far, and were effectively abandoned when their creators got bored with Wikisource. The detailed discussion required before these can be cleaned up discourages any serious efforts. Take Portal:Influential Books as an example. It may have been a good idea when it started but it doesn't contain a lot of material and hasn't had a substantive edit since January 2007. Could it be deleted without a lot of drama?
Of course, marking pages in the Wikisource namespace for moving, or efforts to delete abandoned ideas does not address the more positive question about what we want. I think we still need both an organized bottom-up category system, and a more or less parallel top-down system with portals at its top.
We can argue that some system of indexation should be available to link the appearances of the same person in various encyclopedic works, but the theory is more powerful than the practice. Looking to see if the individual DNB biography has a counterpart in EB or some other encyclopedic work is not an intuitive process for the editor who happens to be focused on DNB at the moment. How is he to know which other encyclopedic works also contain biographical material about the same person? Eclecticology - the offended (talk) 01:06, 4 November 2009 (UTC)
Concrete suggestion: a category like Category:Topical classification (don't mind the precise name) to be created, to house at least Category:Portals, to be an over-category of Category:Works by subject which obviously remains a subcategory of Category:Works too — and to have some other pages in it. Those other pages would be the pages in the notional Topic namespace, so defining what that namespace would be for ought to be the same debate as what further classification pages are required. It seems clear that there is a tendency for the Wikisource: namespace to act as a sort of Bermuda Triangle of projectspace, drawing in organisational material. So some work probably should go on, looking at which pages could be recategorised or moved around or split up in some way that would make their place clearer to those readers who are not active project members. Charles Matthews (talk) 11:26, 4 November 2009 (UTC)
Sounds like the beginning of a plan.
  1. At this stage perhaps a more ephemeral sounding name like Category:WS pages to be moved would emphasize that this category will eventually no longer be needed. This will start rescuing material from the Bermuda Triangle.
  2. Unless there is a reasonable chance that the Index namespace could be repurposed, I would propose a "Topic" namespace. It would be a top down parallel to categories. It would include red links for things to be done, and provide additional information about its separate elements that cannot be included in the Categories. In the short term this could be a pseudonamespace until we can be sure that people will use it.
  3. I would also propose a "Project" namespace that could be used to marshal the various wikiprojects. Many of these are too easily forgotten once the initiator loses interest. By making these more visible we may be able to convince new people to work on completing these projects.
  4. The "Portal" namespace needs further development. It should operate to bring together topics, categories and projects related to top level concepts. There may be some differences of opinion about which concepts are top level. I am willing to put some effort on developing these, beginning with the most obvious. Eclecticology - the offended (talk) 08:29, 5 November 2009 (UTC)

I rather like the idea of moving all "Index" (DJVU) pages to the PAGE namespace, then moving the WS:Works pages to the Index: namespace. But this shouldn't be attempted by a single user anxious to see this issue concluded, we have thousands of backlinks that will need changing, etc. Sherurcij Collaboration of the Week: Author:Khwaja Kamal-ud-Din. 12:52, 4 November 2009 (UTC)

While I support this in principle, I'm conscious of the possible technical difficulties raised by Billinghurst. If you think that this can work try moving the Index (DJVU) pages of one or two books to see what glitches arise. If they are too serious we may have to accept that it won't work. Eclecticology - the offended (talk) 08:29, 5 November 2009 (UTC)
Just to get the desired end result straight, do you intend to end up with a hierarchy the looks something like this?:
  1. Portal:Religious texts
  2. a) Topic:Baha'ism, Topic:Buddhism, Topic:Christianity, Topic:Hinduism, Topic:Islam, Topic:Judaism, Topic:Wicca, etc.;
    b) Project:Wiki Bible, Project:Hinduism etc. (from Wikisource:WikiProject Wiki Bible and Wikisource:WikiProject Hinduism);
    c) Category:Religion and sub-categories
  3. The actual texts (ie. The Bible, Qur'an etc.)
(Using Religious texts from Wikisource:Works as an example because it is a convenient size.) - AdamBMorgan (talk) 12:37, 5 November 2009 (UTC)
  • Essentially, yes. Still I would prefer the simpler, Portal:Religion. "Texts" is somewhat of a redundancy, since the whole of Wikisource is about texts. When editors need to link to something they are probably happier when it can be expressed in one word. I'll see if I can start developing the idea at Wikisource:Portal. (Probably more intuitive to have this named "Portals" in the plural.) That's the sort of page that should stay in the Wikisource namespace because it's about portals ... unless somebody can make a convincing argument that it belongs in the Help namespace. Eclecticology - the offended (talk) 17:41, 5 November 2009 (UTC)

Bot extraction of text already in DjVu file

I am having trouble finding an answer to this. There is a DjVu file Index:Dramatic Moments in American Diplomacy (1918).djvu that already has OCR'd text in it, but it hasn't all been extracted and put into the "Pages" namespace yet. Is there a bot that can do this while leaving the already-placed pages intact? (billinghurst, is this what you were trying to do with it before?) --LarryGilbert (talk) 18:40, 30 October 2009 (UTC)

Yes, the djvutext.py script for the pywikipedia bot enables this sort of functionality, although I believe it would be necessary to supply the script with a list of pages to be uploaded manually to avoid clobbering those that are already there. At the moment my little bot is fully occupied autocorrecting the United States Statutes at Large scans, but I would be happy to queue this job up for it after it has completed its current run (unless somebody else does it for you first). Tarmstro99 (talk) 19:38, 30 October 2009 (UTC)
I think I'd heard of pywikipedia somewhere, but I'd forgotten about it. This may be a good opportunity for me to learn it and put it through some paces. Thanks for the suggestion! --LarryGilbert (talk) 20:29, 30 October 2009 (UTC)
There is no need for that now. The text layer is automatically imported if it exists when the page is created. This avoids creating 1000s of pages which won't be proofreaded before ages. See where I look? ;o) Yann (talk) 21:46, 30 October 2009 (UTC)
In this case, though, the text is already on the site, just not linked to any scanned pages. The easiest way to connect the two seems to be to replace the existing text with what's in the DjVu file. --LarryGilbert (talk) 00:27, 31 October 2009 (UTC)
When I looked at that work, it was not proofread, nor sorted to chapters, it was an flat long file of not proofread. Given that, it was preferable to do the work in the Page: namespace where we can work with the text to do side by side proofreading.
BTW I did ask JV about whether he was going to update his script and he said he would put it into the queue for 2011. :-/ billinghurst (talk) 03:27, 31 October 2009 (UTC)

Indexes and TOC for The Popular Science Monthly

Created several variations for a proposed page hierarchy for TPSM. Please look look here at my proposals. Which naming style is best suited for Wikisource? Your input is much appreciated. Ineuw (talk) 19:10, 30 October 2009 (UTC)

Thanks for providing those mockups! Your proposal #4 (full name of publication (not abbreviated) / volume number / issues within volume / works listed within that issue) looks the most consistent with what I have seen done with other works here. Tarmstro99 (talk) 19:45, 30 October 2009 (UTC)
I vote for number four as well. It most confirms to our standards. -Mattwj2002 (talk) 03:58, 31 October 2009 (UTC)
Number 4 it is. I will complete the month of May first and let you know. Ineuw (talk) 19:31, 31 October 2009 (UTC)
I disagree to the actual proposition, I'm unsure if people liking this idea noticed the Page: prefix before a title or took it as a generic name for main:, Ineuw proposition consists of moving the hierarchy for the TPSM to the Page: namespace, which is really a bad idea imho. Ineuw proposition #4 is the best but must be done in main:, not in Page:*. Phe (talk) 15:20, 1 November 2009 (UTC)

Page structure for The Popular Science Monthly

Phe, thanks for your input. I had some problems trying to define a page (not a Page:), as you have suggested. I will test it again and will post here. In the meanwhile, the current structure I am using is here. Ineuw (talk) 02:10, 2 November 2009 (UTC)

Hi, can an admin change this template to allow direct links to a page number ? It requires insertion of <span id="{{{num}}}"></span> between <span id="zzz" style="display:none;"></span> and the <nowiki>. This is used by <pages >, the old template:Page do this but not the new. Example of use : Transactions of the Geological Society, 1st_series, vol. 1/Index (to test it, change the template, do a dummy edit of the target page and try the link) Phe (talk) 17:54, 31 October 2009 (UTC)

Done billinghurst (talk) 22:58, 31 October 2009 (UTC)
Thanks, for people interested in linking from a TOC, I created an helper template, {{TOC link}}. The intent is to to provide a way to link from a djvu page to a page inside the same book but when transcluded to link to a subpage of the same book, in the shortest possible way. Phe (talk) 15:08, 1 November 2009 (UTC)
I have found that {{TOC link}} is for use when the main namespace TOC is used a subpage, so I have semi-forked the code for {{TOC mainlink}}. If there is someone clever who can work out how to amalgamate the two functions into the one template, then go for it. billinghurst (talk) 02:09, 22 November 2009 (UTC)
Both template can be merged using something ala (simplified code) {{#ifexist: ../{{{2}}} | [[../{{{2}}}]] | [[/{{{2}}}]]}} but it exists probably a better way to do it, I don't see exactly how but I suspect we can get the needed information by a clever comparison of {{PAGENAME}} {{SUBPAGENAME}} and {{#titleparts}} without adding any parameter. One case that must be handled is book structure as book_name/Val_1/Chapter 1 where the TOC can be transcluded either in book_name or in book_name/Vol1 Phe (talk) 10:55, 23 November 2009 (UTC)
I'd much prefer these templates were substituted. It is hard enough for newbs to make sense of this place without piling on esoterica like this. Hesperian 11:41, 23 November 2009 (UTC)
They can't, their expansion depend on the transclusion context, and {{TOC link|13|Account of Guernsey, and the other channel island|1}} is a lot of easier to read than the alternate way [[<noinclude>Page:Transactions of the Geological Society, 1st series, vol. 1.djvu/49</noinclude><includeonly>../Account of Guernsey, and the other channel island</includeonly>|1]]. Anyway only simple template should be substed. Phe (talk) 11:58, 23 November 2009 (UTC)

Template help is sought

I need a template to raise the caps of words like THE, and I created a copy of the dropcap named raisecap. Raising the first character works OK, but it inserts a line break immediately afterwards. Don't know enough about HTML to find the problem. Would someone please look at it? Thanks. Ineuw (talk) 19:47, 31 October 2009 (UTC)

Hi, see the edit comment [1] Phe (talk) 20:28, 31 October 2009 (UTC)
We do already have Template:Largeinitial. That doesn't do the job? billinghurst (talk) 22:54, 31 October 2009 (UTC)
Thanks to all. Template:Largeinitial is fine. Phe, thanks for the correction. — Ineuw (talk) 01:18, 1 November 2009 (UTC)

Proper placement of copyright tags/boxes

Is there a guideline or best practice for placing a copyright box? I'm afraid I've searched for an answer without any luck. Does it belong on the main page of a text or on its discussion page? Near the top or the bottom? Anything else? --LarryGilbert (talk) 02:52, 4 November 2009 (UTC)

I stick it on the front page of the work and at the bottom. That is what I saw done, and I want I now do. So there will be quite a few done that way. :-) billinghurst (talk) 03:06, 4 November 2009 (UTC)
Same as Billinghurst; it's an important part of the metadata we need to present, so it has to be on the main page, but the big box doesn't really need to be at the top of the page. I wouldn't mind putting it in normal size type in header; "This is a US work that wasn't renewed {tiny image to link to full text}", "This was published before 1923 {tiny link}", "and this was published by an author who died 57 years ago", etc. But the current big boxes should go to the bottom.--Prosfilaes (talk) 15:03, 4 November 2009 (UTC)
For once I generally agree with you. Whatever the notice says the boxes are butt-ugly. Many sites place their copyright notice discretely at the bottom without increasing or decreasing whatever rights they have. The important thing is that the information is available. Eclecticology - the offended (talk) 19:03, 6 November 2009 (UTC)

Problem with interface

In the Page namespace I am having trouble using the drop-down controls. I can navigate every symbol except ^ . When I move my cursor down the list, the whole list disappears at "image" when the pop-up image appears to the left. The list also disappear if I move my cursor off of the list and attempt to get at ^ sideways. Does any one else have this issues or know of a fix?--BirgitteSB 19:18, 6 November 2009 (UTC)

I am not quite sure to what you are referring. Are you referring to Mediawiki:Edittools that is appended to the bottom of all pages when in edit mode? Is it that you want the circumflex in symbols, or that you cannot navigate to the Circumflexes drop down mode? Or something different? billinghurst (talk) 13:23, 7 November 2009 (UTC)
No I am talking about the navigation for Page:Foo to Index:Foo. There is a tab witch is a drop-down list and and the last item is listed as ^ which signifies the navigation to the associated index page.--BirgitteSB 01:02, 9 November 2009 (UTC)
Which skin are you using? I don't have those options in my monobook version, I just have the tabs across the top and have a tab at the end with the ^. No dropdown boxes to be seen. billinghurst (talk) 02:04, 9 November 2009 (UTC)

Understanding <section> tags and their use with <pages> tags

I'm adding a book by Michael Faraday and I'm having trouble understanding the proper use of the <section> and <pages> tags.

Let's take the first "chapter" from the book. It starts on page 1 and finishes a short way down page 5. I thought it would be enough to put <section begin="chapter1"/> at the start (p. 1) and <section end="chapter1"/> at the end (p. 5), then use something like this to put the whole article on its own page:

 <pages index="Experimental_researches_in_chemistry_and.djvu" from=16 to=20
     fromsection="chapter1" tosection="chapter1"/>

But this does not work, so either I'm misunderstanding <pages> or I'm expecting too much from it, I fear. By experimenting with including or omitting the "tosection" parameter, the only thing I can change is whether all of page 5 is included or not. I can't get just the relevant portion to be included and leave the rest out.

I imagine I could work around this by using multiple {{Page}} templates, but I thought that was the sort of thing the <pages> tag was designed to avoid.

--LarryGilbert (talk) 00:11, 9 November 2009 (UTC)

Off the top of my head, I suggest you try it without the quotes aroudn the section titles. I have a vague memory of having the same problem myself a while back. Hesperian 00:27, 9 November 2009 (UTC)
On re-reading, I see the problem. Section tags are used to demarcate an individual page into sections; it doesn't work across pages. What you want to transclude is:
  • Just the chapter one part of page 1
  • all of page 2
  • all of page 3
  • all of page 4
  • just the chapter one part of page 5
In order to do the first of these, you need to define the chapter one part of page 1; to do that you wrap the chapter one part of page 1 in <section begin="chapter1"/> and <section end="chapter1"/>. Then you do the same thing on page 5. That should get you what you want. Hesperian 00:32, 9 November 2009 (UTC)
That's exactly what was needed. Thanks! --LarryGilbert (talk) 00:39, 9 November 2009 (UTC)

Fundraiser banner

At w: there's an option in My preferences|Gadgets to "Suppress display of the fundraiser banner". Can this be given here also? Moondyne (talk) 06:54, 11 November 2009 (UTC)

Odd problem with transclusion of footnote

ProofreadPage gurus, any hints on why the content of the footnote at the bottom of this page gets mangled when it gets transcluded to here? It looks like some boldfacing is added that isn’t present in the original, and one of the internal wikilinks vanishes entirely. Tarmstro99 (talk) 16:26, 12 November 2009 (UTC)

It's because the links in the Footnote point to the same page that it's being transcluded in. For example, I'm linking to the Scriptorium: Wikisource:Scriptorium (notice how it's in bold, but the source is typical wiki-markup). If you want to to be fixed, the only way I can think of is to remove the links altogether, because all you're doing is linking a page to itself.—Zhaladshar (Talk) 16:33, 12 November 2009 (UTC)
Aha! Thanks. Tarmstro99 (talk) 18:34, 12 November 2009 (UTC)

DJVU Viewer App Available for the iPod Touch/iPhone Now

I just wanted to let everyone that there is a DJVU viewer app available for the iPod touch/iPhone now. The app is called Heru. It cost $1.99 usd. You have to manually copy and paste the URL of the file to download. I just thought you guys would be interested since we use DJVU so much with Wikisource. This makes the iPod Touch and iPhone a nice eBook reader. :) Anyways, what do you guys think? I just thought I would spread the word. --Mattwj2002 (talk) 06:02, 13 November 2009 (UTC)

Batch-moving pages

I had Commons rename File:1960 FBI primer on Nation of Islam.djvu to File:1965 FBI monograph on Nation of Islam.djvu due to the incorrect year in the file name itself. Now I am in the middle of moving all of the pages formerly under Index:1965 FBI monograph on Nation of Islam.djvu to Index:1965 FBI monograph on Nation of Islam.djvu--obviously a tedious task. It occurred to me that there must be an existing tool I can use to do a "batch" move like this without having to fire up a bot to do the task. Does anyone know of such a thing, or should I just dust off my own bot to do the work? --LarryGilbert (talk) 18:50, 14 November 2009 (UTC)

I will have a go and see how it works out. billinghurst (talk) 23:26, 14 November 2009 (UTC)
Done was manually with the bot application, but not horrific. billinghurst (talk) 23:50, 14 November 2009 (UTC)

Formating when proofreading

Hi, I would like to ask if it is necessary to take car of text format when proofreading? Look at this example: [2]. I was trying to figure out how to format the text to look simmilar to the text from scan, but I have found no way.--Juan de Vojníkov (talk) 08:48, 17 November 2009 (UTC)

You could either use {{text-indent}} or the <poem>...</poem> tags. I've edited the page using the latter (and validated the page). The text between the poem flags is formated as it is presented, leading spaces and all.- AdamBMorgan (talk) 17:34, 17 November 2009 (UTC)

Is there any easy way to upload external OCR?

I'm looking at Index:A grammar of the Bohemian or Cech language.djvu which has Tessaract OCR. But one of the most tedious things for some of us is entering all those Czech letters. I could take the images and dump them through my local copy of ABBYY Finereader, which will handle the Czech OCR just fine, but I have no way to quickly upload the OCRed pages.--Prosfilaes (talk) 23:17, 18 November 2009 (UTC)

If you e-mail the (good) OCR output to me as a set of zipped text files, I can have User:TarmstroBot replace the existing text with the amended versions en masse. (I assume you do not wish to replace any pages that have already progressed to Proofread or Validated status.) Tarmstro99 (talk) 02:25, 19 November 2009 (UTC)

complete. Tarmstro99 (talk) 19:53, 20 November 2009 (UTC)

Something weird happening

This morning when I click on the links to scans button I see this:

You are looking at the HTML representation of the XML format.
HTML is good for debugging, but probably is not suitable for your application.
See complete documentation, or API help for more information.
<?xml version="1.0"?>
<api />

Any ideas? Is it just me? Moondyne (talk) 01:16, 19 November 2009 (UTC)

The similar links to scanned pages gives can’t run the script “displayOptionText("links to scanned pages","display:none;"” blah blah, ... Cygnis insignis (talk) 02:19, 19 November 2009 (UTC)


{{Option}} is doing it too, so it is clearly a problem with handling of the "OptionText" class—the mechanism by which it is made possible to turn the page links on and off. No-one has edited Mediawiki:Common.js recently, nor even Mediawiki:Common.css, so it would seem to be a backend issue.

There has been talk at Template talk:Page#Missing page numbers? about how the disappearance of page numbers only causes confusion, and to no advantage, and therefore the "links to scanned pages" display option would be better off removed. Since there was no opposition there after quite a while, and since this functionality is broken at present anyhow, it seems like there is no better time than the present to implement it. Done.[3][4] Hesperian 03:26, 19 November 2009 (UTC)


See also Wikipedia:Wikipedia:Village pump (technical)#Scripts are down. Hesperian 03:31, 19 November 2009 (UTC)

Unvalidating a Page

Can someone please undo my edit to Page:Fair Circumvention.djvu/1? I read and validated the page but this blanked it for some reason. I can't undo my own edit because that would involve changing the proof reading status of the page. Thanks, AdamBMorgan (talk) 20:31, 19 November 2009 (UTC)

done Sherurcij Collaboration of the Week: Author:Khwaja Kamal-ud-Din. 20:52, 19 November 2009 (UTC)

Question about Corriegenda and Addenda

I have been working on proofreading A Dictionary of Music and Musicians, volume 1. Today I transcluded the Beethoven article to mainspace. However, in volume 4 of the dictionary there is an Appendix which contains Addenda and Corriegenda (for the Beethoven article this is on page 533 through to 542). Should the corrections be made to the original article? Should the addenda be transcluded to the end of the original article? Or should they be transcluded separately? Beeswaxcandle (talk) 09:06, 20 November 2009 (UTC)

I like to maintain the errors, but make a note of anything corrected in the Errata; e.g. see An introduction to physiological and systematical botany/Chapter 10. Hesperian 11:14, 20 November 2009 (UTC)

Ancient Greek?

Hi, I think I have completed A Highland Poem... which is part of the collaboration of the week. Its the first book Ive done, so I'm not sure if I can do anything more. Specific help is required with one of the poems as it has a non A-Z title ... I think it is ancient Greek (its rendered OK in the DjVU version). Anyone good at converting this to HTML? At present I have included it as "???" and its halfway down the table of contents. Thanks Victuallers (talk) 17:22, 21 November 2009 (UTC)

There are a lot of poems there; which one is it in? Angr 17:27, 21 November 2009 (UTC)
Never mind, I found it. I've moved the page to τέτλαθι δὴ κραδίη. Angr 17:34, 21 November 2009 (UTC)
I also corrected Miserrere to Miserere. Angr 17:40, 21 November 2009 (UTC)
Thanks, for both corrections, Angr Victuallers (talk) 20:03, 21 November 2009 (UTC)

New texts

Who are the Ausralians?

I think that they are related to the Ancient Geeks ;-)

Does "New texts" have an age requirement? (Maybe we can rate it "R".)

An inquiring mind 05:07, 25 November 2009 (UTC) (ResScholar)

Thanks, fixed. Hesperian 05:18, 25 November 2009 (UTC)
Lest I be accused of insensitivity to Alcee Hastings' indignant complaints as entitled with one of Cirt's typographical errors, I would direct other inquiring minds to w:Keith Windschuttle for example. ResScholar (talk) 05:36, 25 November 2009 (UTC)
Thanks for the correction, much appreciated. Cirt (talk) 09:01, 25 November 2009 (UTC)