Wikisource:Scriptorium/Archives/2013-08

Announcements

Vote of confidence in sysop ResidentScholar

Three established community members have opposed User:ResidentScholar retaining the sysop tools, which means that a vote of confidence has been called at WS:ADMIN#ResidentScholar. See Wikisource:Restricted access policy#Votes of confidence for the policy. Beeswaxcandle (talk) 22:03, 7 July 2013 (UTC)

Proposals

Mark Wikisource:Translations as Policy

Wikisource:Translations has been in place since 2005, it has been marked as a proposed policy since 2006. During an extensive discussion at Wikisource:Requests for comment/Annotations and derivative works significant details about community expectations where worked out. As these expectations govern a new name space, I believe it is only fitting to officially mark it as a policy.

On a related note, I am also beginning updates to the page based on the above mentioned discussion. I would expect those updates to be completed prior to marking the change from proposed to policy. JeepdaySock (AKA, Jeepday) 10:46, 31 May 2013 (UTC)

I believe I have captured all the consensus updates to Wikisource:Translations. Please feel free to Copy edit, or start a discussion at Wikisource talk:Translations if you believe the consensus from Wikisource:Requests for comment/Annotations and derivative works is not adequately addressed. Additionally a discussion about how to create the new name space is occurring at Wikisource:Administrators'_noticeboard#New_Name_Space. JeepdaySock (AKA, Jeepday) 10:56, 5 June 2013 (UTC)

I agree. I'm not sure if we need to vote after having the discussion but, if so, I support this policy. - AdamBMorgan (talk) 21:03, 21 June 2013 (UTC)

The page still needs some serious editing before I'd support making it policy. The recent discussions seem to have resulted in edits that make the page more about original Wikisource translations, even at the outset. I'll see what I can do for the opening sections. . . --EncycloPetey (talk) 21:11, 21 June 2013 (UTC)

OK, I've restructured the page for clarity, and have added (or at least started) the missing bits that came to mind. There still are a few incomplete notes (in bold italics) that will need to be filled in. --EncycloPetey (talk) 21:53, 21 June 2013 (UTC)

I have reviewed the changes by EncycloPetey and George Orwell III, I listed my praises and concerns at Wikisource_talk:Translations#Most_recent_changes. Jeepday (talk) 11:54, 4 July 2013 (UTC)

We could use another perspective on the content as it currently reads. Most seems pretty straight forward but the two main contributors EncycloPetey & Jeepday, have a couple of difference of opinion and would appreciate other thoughts at Wikisource_talk:Translations#Most_recent_changes. JeepdaySock (AKA, Jeepday) 10:25, 11 July 2013 (UTC)

BOT approval requests

Bot Confirmation July 2013

This is the first semi annual Bot confirmation in accordance with Bot Confirmation Policy. All the bots up for confirmation are eligible for auto confirm, as either they or their owner have been active on Wikisource in the last two years.

• Value of "Inactive" or "Active" under status, represents value of {{Bot}} on User:FooBot, generally set by the bot owner and does not correlate with status for auto confirmation. Jeepday (talk) 23:43, 27 June 2013 (UTC)

User:DougBot

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.

Bot Username	Tasks	Last Confirmation	Next Confirmation	Status	Owner
User:DougBot	Custom jobs in the pagespace or mainspace	Feb 2011 granted bot flag	2013, July	Active; Last bot edit August 2011, Last Owner edit May 2013	User:Doug

• Support, meets the community expectation Jeepday (talk) 11:59, 20 July 2013 (UTC)

User:Spangineer's bot

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.

Bot Username	Tasks	Last Confirmation	Next Confirmation	Status	Owner
User:Spangineer's bot	Move pages and perform related cleanup	Feb 2011 granted bot flag	2013, July	Active; Last bot edit April 2012, Last Owner edit May 2013	User:Spangineer

• Support, meets the community expectation Jeepday (talk) 11:59, 20 July 2013 (UTC)

Other discussions

Width option to {{Hanging indent}}

I often use {{Hanging indent}} for image descriptions, and was wondering if an optional |width = nnn| can be added to the template. To achieve this currently, I combine it with the {{justify}} template and this modification would make this combination unnecessary. My knowledge of template design is too limited, and in any case I would need community approval. — Ineuw talk 21:21, 22 June 2013 (UTC)

Would the image + title here be a reasonable example of the sort of thing you are hoping to templatise? If so, this constitutes a fairly frightening stacking of templates, and I am sure some severe pruning (note: prepare an axe!) may be justified.

For―and assuming the above―example, would the following:

Fig. 7.—Head of a very young Amblyopsis before all the yolk is absorbed.

-be an acceptable rendering? I am sure further style paring may still be achieved, though I am certainly no expert. MODCHK (talk) 00:00, 23 June 2013 (UTC)

Thanks MODCHK, and yes. This is exactly what I need it for. The caption should be the width of the image, following the original layout editors’ rule which is: 1 or 2 row captions are centered, and longer than 2 rows are justified with a hanging indent. However, I could also use a two row table to achieve the same, as I have been using for offset and multi-column images with multiple captions. I thought that the width parameter option can be added to the existing {{Hanging indent}} template without having to create a new one. I don’t wish to make a major issue of this.— Ineuw talk 00:50, 23 June 2013 (UTC)

I'm not sure that amending {{hi}} for this purpose is appropriate. Tweaking non-text block templates to have text-block functions is not a good idea. The hanging indent template has a single focus on the first line of a paragraph. The justify template is designed to manage a text block and thus the width parameter is appropriate. I would also note that the hanging indent template doesn't justify and, as this is something you desire, you would still have to use both templates. Beeswaxcandle (talk) 01:20, 23 June 2013 (UTC)

Two additional notes:

1. @Ineuw: the line-height:110% you amended to 95% was originally "lifted" from the hard-coding in {{fs85}} (No kidding: check if you want!)
2. @General: I completely agree with Beeswaxcandle that there are at least two levels of abstraction required here Please note: I could not achieve the layout with less than two nested <div>s, although I have visions of George Orwell III quietly being ill at the very concept…

In short, although there are clearly possibilities here; lets not be too hasty about changing anything until the various cognants (is that is a real word?) provide their views. MODCHK (talk) 02:20, 23 June 2013 (UTC)

I got it, thanks for the explanation. Please consider this issue closed, since I can easily combine templates or better yet use a table.— Ineuw talk 03:25, 23 June 2013 (UTC)

O.K. This below produces the same result pretty closely and is existing-template-pure:

[[File:PSM V57 D415 Head of a very young amblyiopsis.png|frameless|center|200px|]]

{{block centre|width=200px|align=justify|{{hi|{{fs85|{{sc|Fig. 7.}}—Head of a very young ''Amblyopsis'' before all the yolk is absorbed.}}}}}}

Anybody got a simpler version than this? MODCHK (talk) 04:32, 23 June 2013 (UTC)

I don't know about it being just as simple if not more so, but I'm impartial to:

{{FI
 | file    = PSM V57 D415 Head of a very young amblyiopsis.png
 | width   = 200px
 | caption = {{sc|Fig. 7.}}—Head of a very young ''Amblyopsis'' before all the yolk is absorbed.
 | talign  = justify
 | tstyle  = font-size:90%; line-height:110%
 | indent  = -2em
 | mleft   = 2em
}}

Fig. 7.—Head of a very young Amblyopsis before all the yolk is absorbed.

-- George Orwell III (talk) 23:53, 23 June 2013 (UTC)

This is great. Thanks GOIII. Is this a template??? — Ineuw talk 07:47, 24 June 2013 (UTC)

I guess you missed the whole Freed Image bus? (See Wikisource:Scriptorium/Archives/2013-07#More on unlocking images above). Yes, its a template (the short-cut to it, {{FI}} is prefered) and we've been trying to get folks more interested in using/testing/accepting it. If you find yourself constantly using the same bunch of templates and settings to get images & their captions to render/re-size like you'd want them to, a FreedImg customized subpage might be a better option for you.

Still, fully "rolling it out" depends on wide community acceptance and so far there hasn't been much interest so any input, comment, etc. is greatly appreciated. -- George Orwell III (talk) 08:03, 24 June 2013 (UTC)

I missed a lot more than that bus. Looked at it at the beginning, decided to wait until everything was resolved, returned to my nook and didn’t look in on the Scriptorium until this post. I already began to use it, but so far all my images have a short description at the moment. But no worry, there’ll be more to come.— Ineuw talk 09:03, 24 June 2013 (UTC)

I haven't had need for a template like this yet, but it looks like a remarkably good idea to me. I can imagine making extensive use of it, were I editing a heavily illustrated work. I just haven't worked on a volume like that yet, except perhaps for January's Punch volume. I did discover and started using {{img float}} today for a volume that needed it. How similar/different are the two? What are the pros/cons? Or is that still to be determined as part of the template testing that was requested? --EncycloPetey (talk) 22:42, 26 June 2013 (UTC)

pagenum

Tracked in PhabricatorTask T52215

The {{{pagenum}}} isn't working for me right now. (The one placed in headers and footers to automagically insert the page number based on the Index page) Is anyone else having this problem? --EncycloPetey (talk) 05:08, 26 June 2013 (UTC)

Verified - it no longer pulls the pagelist assignments to the Page: namespace. Must be the result of the latest patch to the PR'ding extension that I happened to link to in the last tech-news above. I had a feeling something would be off after it's roll-out. -- George Orwell III (talk) 05:54, 26 June 2013 (UTC)

Yes, it's a regression introduced by the latest patch. I'll try to fix it before the next deployment (next monday). Tpt (talk) 07:34, 26 June 2013 (UTC)

Seems to be functioning again -- George Orwell III (talk) 00:26, 10 July 2013 (UTC)

Music and project scope

Open question: Do we consider works like "Funeral march" to be within our project's scope, and if not, then where should they go? I don't mean to question the inclusion of music itself, but only cases like this particular one. In this instance, the work was published originally in Polish, with a Polish poem, and this is the music alone, with nothing on the page that is in English or in Polish; the only words on the page are the usual pseudo-Italian musical annotations. So, is it possible that a work that contains no English at all could still be within our scope? If a musical work with no words doesn't belong here, then where would it belong? --EncycloPetey (talk) 07:24, 26 June 2013 (UTC)

(In my opinion) language-free score could be placed on multilingual wikisource, unless it is part of a larger English work or directly intended for an English-reading audience. In this case, it looks like a job for multilingual wikisource (it should also be converted to an index page and rendered with Score once that is up and running properly). Polish wikisource might be an option too. - AdamBMorgan (talk) 10:47, 26 June 2013 (UTC)

btw there is RfC for this matter: m:Requests for comment/Musical score transcription project proposal. As far I can see, it's gonna be on multilingual wikisource as you said. --DixonD (talk) 11:43, 26 June 2013 (UTC)

It isn't wrong to have it here, though I would say that the proposal about mulWS to host such works does seem more right to me. So while I would never propose that works uploaded here were removed, I would always encourage the preference of mulWS. — billinghurst sDrewth 13:41, 26 June 2013 (UTC)

@DixonD: Thanks for that RfC link, and I've posted a follow-up question there. The problem I see with putting content on the multilingual Wikisource is that there's no way to find it from the main page. Everything on that main page is a language link to a Wikisource specific to that language, except for a few languages like Zulu that point instead to a confusing page on the multilingual Wikisource. There's no option there for "Music", nor indeed any way to find something that's in more than one language. --EncycloPetey (talk) 16:24, 26 June 2013 (UTC)

But isn't that the problem with trying to squeeze any non-language dependent, free-of-form "vehicle" under or into a formalized, language-specific framework {never mind that particular faux framework which is anything but multi-lingual/language-neutral )? The way I see it, you're overly worried about how to get from the main-page down to the sheet-music in a logical manner, etc, when you're faced with the same problem(s) in coming up with a way of just organizing & navigating from one language-less composition to the next.

Sorry folks - don't know how else to put it but. . . sheet music without lyrics amounts to nothing more than an image file; a song-less media file without any formal transcription to sheet music amounts, again, to little more than any media file currently does; imho, both should be handled in a Commons-like fashion and pulled into as many or as few sister sites or projects as needed (or as copyright law dictates).

Your sheet music has lyrics/lines associated with the notation? Composer scribbled himself a note or two in the margins? Well then any language questions are answered for you in those instances aren't they? -- George Orwell III (talk) 17:57, 26 June 2013 (UTC)

I would prefer to see language-neutral scores (such as this one) on IMSLP (i.e. off-Wiki). It's the first place I look when I need a score of something PD that isn't in my library already. That said, if a score is a part of an English language work that we are hosting then it stays here (e.g. the score to the second movement of Haydn's Surprise symphony is an appendix to Index:Essentials in Conducting.djvu. And, as George says, songs in English or American belong here. Beeswaxcandle (talk) 21:32, 26 June 2013 (UTC)

Addendum suggestion: songs in English or American from any English speaking country belong here. JeepdaySock (AKA, Jeepday)

That criterion isn't so easily applied. Would it allow all the music of India, regardless of culture? Would it allow Handel, who wrote in London but who was German? And if an English-speaker in the UK normally writes his operas in Italian, would that mean we host only his music that lacks words? --EncycloPetey (talk) 16:34, 27 June 2013 (UTC)

All good points that are legitimate concerns here as well. I don't think our "book-ish" criteria of as long as its in English can be applied the same when it comes to "music" because, as EP infers, the differences involved do not align well with our current attribution and categorization practices. Had en.WS been subdivided into it's "English" speaking nations-of-origin from it's inception, this probably wouldn't be an issue (but that is not what we have to operate under today). Formulating any guideline on this needs further debate/discussion. -- George Orwell III (talk) 20:57, 27 June 2013 (UTC)

@G.O. III: I'm not overly concerned about the music per se, as I don't have any plans to edit or work with such items in the foreseeable future. But, some of the issues could affect how others work on music, and I want to know what advice I might give newcomers who start on such projects. Also, some of the concerns with regard to the multilingual WS will also apply to text projects that I have a desire to work on (at some point in the future) . . . but that's a different thread. --EncycloPetey (talk) 22:33, 26 June 2013 (UTC)

Well after spending some time at BWC's suggestion, IMSLP, the wisdom of refering all PD, language nuetral sheet music to them rather than trying to build our own library pretty much from scratch is clear. So I amend my previous and concur with BWC not to host that class of sheet-music/score/etc. at all while proactively defering to IMSLP instead if & when en.WS is confronted with the possibility of such contributions taking place here. In a nut-shell, doing so would be a far more logical and more efficient approach (imho) than any of our current options seem to be. -- George Orwell III (talk) 20:57, 27 June 2013 (UTC)

I don't see any reason not to host sheet music prints or collections on its own site, similar to species.wikimedia.org When it appears in a publication like something Beeswax is working on, it of course makes sense to be hosted on a specific language wikisource. If it is just the transcription of scores, even scores with printed lyrics in a given language, we would want a Species-like situation where there was no language domains, just language preference for navigation. There definitely is a technical overlap with Wikisource. If the goal is to be able to transcribe, export or listen to the scores, this can all be free of language, only the navigation must change. And why not allow translations of the lyrics if needed? Sourced, annotated, editor created? Wikisource is a great model for this project.

I'd be surprised if they created a separate site for this; can't say it wouldn't be redundant to others or that it would have enough of an interest or core community. But I don't think that sheet music belongs on any language specific wikisource. - Theornamentalist (talk) 16:55, 27 June 2013 (UTC)

Index pages for works with more than 1K of pagelist assignments

Anyone having trouble opening or editing something like that lately?

I can't put my finger on what exactly is causing my browser to politely stop responding everytime I try to do something within an Index that is for a work with a page count well into the thousands. Sometimes I can get right up to editing & previewing changes but it flat-lines before I can save them; at other times I can't completely open such an Index: page to view it at all.

Anyway - I'd like to know if its just me or have others run into something like that in the past 8 to 12 days or so? To date, the Index: that follows seems to be a reliable candidate to produce this effect sooner rather than later. Please click-in, open/preview it once or twice and report back either way (include your browser. etc.) TIA. -- George Orwell III (talk) 15:29, 26 June 2013 (UTC)

Index:United_States_Statutes_at_Large_Volume_123.djvu

No such bad behaviour for me on Firefox 21.0 (or, just updated: 22.0). Header pre-fill does not work (does nothing) if I tentatively open a sub-page as if I am going to create it (presumably this is related to the {{{pagenum}}} issue referred to by EncycloPetey above?) MODCHK (talk) 01:44, 28 June 2013 (UTC)

Weird editing behavior

Did someone fundamentally mess with the code that manages proofreading and validation? Look at Index:Laws of Hammurabi, King of Babylonia.djvu, where, until I proofread one of the pages, all the pages were validated, proofread, or problematic (green, yellow, or purple). I proofread one page and everything now shows up as unproofread (pink). I made another page edit, and everythgin went normal (sort of), then made another edit and all was unproofed again. Until this problem is fixed, I can't continue working. --EncycloPetey (talk) 04:30, 28 June 2013 (UTC)

Note:This may be a wider problem, as I've just started having problems on Commons accessing my Watchlist and Contributions. I get "Fatal exception of type MWException", which doesn't help me at all. ...and now the Main page on the English Wiktionary and for Wikispecies give the same error. Anyone else experiencing this? --EncycloPetey (talk) 04:33, 28 June 2013 (UTC)

Yes, same here and I'm using an iMac --kathleen wright5 (talk) 04:55, 28 June 2013 (UTC)

It is probably a hemispheric thing. Aren't we just used to being the underdogs? [Probably somebody assumed nobody would be awake over (their) night-time?] MODCHK (talk) 04:59, 28 June 2013 (UTC)

Oi! Who's been fiddling with the Proofread extension?

Suddenly all the pages in an Index are showing pink and the transcluded pages have a pink stripe where a green or yellow one was a couple of minutes ago. Also the tab for "source" has just changed to "<proofreadpage_source>". Can this be undone pronto? Beeswaxcandle (talk) 04:37, 28 June 2013 (UTC)

See previous section. --EncycloPetey (talk) 04:38, 28 June 2013 (UTC)

Yep, I saved this and then saw yours. enWP is giving the same error to me and Groupuscle is having the error on Commons too. Beeswaxcandle (talk) 04:40, 28 June 2013 (UTC)

Well, at least WikiBooks is working :) --EncycloPetey (talk) 04:42, 28 June 2013 (UTC)

I think there may be some refactoring going on as part of a Google summer of code project. If this is being caused by that, then I must say the participants need a stern talking to about the inappropriateness of fiddling around with deployed code. Hesperian 04:59, 28 June 2013 (UTC)

The below was posted to the wikisource-l mailing list on Wednesday:

---

Hi!

As part of the Google Summer of Code 2013, <name redacted> (User:Rtdwivedi), <name redacted> (User:Zaran) and I are working on a refactoring of the Proofread Page extension that will allow us to add the ability to edit Page: pages using the Visual Editor. For more information, see https://www.mediawiki.org/wiki/User:Rtdwivedi

We are currently rewriting a lot of code inside of the extension, changes that may cause bugs, like the {{{pagenum}}} one that will be fixed next monday. We are trying to do our best to avoid bugs by increasing the test coverage of the extension but some other ones may occur. Sorry in advance for the inconvenience.

<name redacted>
User:Tpt

PS: We have changed last monday the canonical namespaces names for Page: and Index: namespaces from internationalized ones to English ones ("Page" and "Index") in order to be consistent with MediaWiki core and the other extensions. This allows a more easily sharing of JavaScript gadgets (to test if a page is a Page: page, you just have now to do mw.config.get( "wgCanonicalNamespace" ) === "Index", test that will work in every wikis) but breaks some scripts that are based on the internationalized namespaces names. This change add also "Page" and "Index" as aliases for the Page: and Index: namespaces in every wikis.

---

Hesperian 05:05, 28 June 2013 (UTC)

Sorry folks - it seems my desk-chair was partially crushing the cord for the internet. It's pretty much unrepairable and the bad news is I'm out of tedramegapiconano patch cords. You folks should go do something in meatspace until my local Office Max opens tomorrow morning. -- George Orwell III (talk) 05:12, 28 June 2013 (UTC)

It seems to be back to "normal" now. Phew, I thought for a while there I would have to communicate with my family this evening! Beeswaxcandle (talk) 05:28, 28 June 2013 (UTC)

Well. . . mostly. The little color progress bar that shows up at the top of pages in the main namespace showing the status of transcluded content isn't around, and there are no left-margin page number links in transcluded content. --EncycloPetey (talk) 06:09, 28 June 2013 (UTC)

Oh, and pages in the Main namespace aren't reflecting changes in the transcluded Page namespace yet. So, pages like The Laws of Hammurabi, King of Babylonia show the raw image from before the latest edits to their component pages, even though the images are now on Commons and the Page namespace has been edited to include those images. This may be an unusually slow server lag rather than code related. But a dummy edit to the page fixed the above problems. --EncycloPetey (talk) 06:19, 28 June 2013 (UTC)

Hmm. I'm not seeing these behaviours. It might be a cache issue. Have you tried purging the pages? Beeswaxcandle (talk) 06:52, 28 June 2013 (UTC)

People always tell me about purging, but most of the time, a purge doesn't do anything for me and my Mac. As I said, though, a dummy edit to the page corrected the issue, so it was apparently something like lag or caching, but at the server end, not mine. May have been caused by the problems in editing some of the pages that were transcluded while the Great Problem of 2013 was happening. --EncycloPetey (talk) 07:29, 28 June 2013 (UTC)

I meant purging the pages on the server. That's what the purge button does. It's in the gadgets somewhere. Beeswaxcandle (talk) 08:05, 28 June 2013 (UTC)

Links in tables not working for anyone else?

I just filed bugzilla:50367 after the "Court Documents" links in United States v. Windsor and the TOC links in Constitution of the United States decided they didn't feel like taking me anywhere. (I'm sure there's some political joke to be had there.) If anyone else has been seeing this behavior (and/or the even-weirder Internet Explorer behavior I mention in the bug), and thinks they have anything useful they could add, please do comment. Thanks. — PinkAmpers&^{(Je vous invite à me parler)} 11:39, 28 June 2013 (UTC)

I am ashamed to say that was me. Please check is all now as you expected? MODCHK (talk) 12:13, 28 June 2013 (UTC)

On second thoughts maybe this is not my bug after all. Your page links work sometimes (every second access?) for me (Firefox), and sometimes give me the Greek ("η σελίδα δεν υπάρχει") popup you described in your bugzilla entry, and very occasionally simply do nothing at all. I am at a loss. MODCHK (talk)

I don't know enough about Lua to confidently exhonerate you , but I'm skeptical that a change like that could cause something so bizarre and so arbitrary. I think it's much more likely something completely server-side. Guess we'll just have to wait for one of the bug wranglers to come along and chime in. — PinkAmpers&^{(Je vous invite à me parler)} 20:16, 28 June 2013 (UTC)

I just looked at Constitution of the United States; that has a

<div style=position:relative>

on top of the TOC, so it seems like you need to remove that attribute to click the links; although it could depend on browser, window width, etc... -Steve Sanbeg (talk) 21:17, 28 June 2013 (UTC)

That's not causing the problems. I tried removing that bit in my browser (Safari) and it had no discernable effect. However, the edit you made seems to have fixed the problem. --EncycloPetey (talk) 21:37, 28 June 2013 (UTC)

On my browser (chrome) disabling the position:relative seems to enable the links, although I don't know where that is coming from. For now I just positioned those table above the other content, which is a bit kludgy but works for me. -Steve Sanbeg (talk) 21:42, 28 June 2013 (UTC)

Works OK for me, I'm using Firefox on Mac. --kathleen wright5 (talk) 23:08, 28 June 2013 (UTC)

Also working for Safari in Mac.--kathleen wright5 (talk) 23:16, 28 June 2013 (UTC)

Working for me in IE8 and I was the one porting the previous non-scan-backed version to one that is backed by scans. The ToC was suppose to be elimated (since the original doesn't have a ToC -duh) but was told to hold off on eliminating for the sake of previous vistors (i.e. COTUS is one of the most popular pages constantly visted).

The Court Documents for Windsor isn't working because nobody created those sub-pages yet and forgot to put a 'work-in-progress' banner or note to let folks know the Opinion is incomplete. -- George Orwell III (talk) 23:45, 28 June 2013 (UTC)

The issue wasn't that the pages were empty (sorry for not putting up a "Work in Progress" banner, though). The issue was that when people were mousing over the links, nothing was happening: Their cursors weren't changing, and clicking the links didn't take you to the standard redlink pages. This happened for me and several other people, but Sanbeg's z-index hack seems to have fixed things. — PinkAmpers&^{(Je vous invite à me parler)} 00:26, 29 June 2013 (UTC)

I.e., I still can't click on the now-blue links in the old version, before Sanbeg's hack. — PinkAmpers&^{(Je vous invite à me parler)} 00:27, 29 June 2013 (UTC)

It was working here before and after Sanbeg's "hack" so it is fairly clear whatever it is that is causing the loss of functionality is something between the last Wmf upgrade and some specific agents (browser versions). I added the "hack" to the USSC templates so you can work around it for now. I wouldn't be overly concerned with that particular NavBox much anyway since the last general agreement in this class felt it best to phase it out for something more "standard"-ish. What exactly that would be was never nailed down (at least not yet). -- George Orwell III (talk) 01:14, 29 June 2013 (UTC)

---

Folks, after the recent adventures of the Google Summer of Code thingy, most pages using the PR extension in some way or are transcluding pages from the Page: namespace might need to be refreshed (iow - the cached copy out-of-synch with actual copy) and that is why some features are acting flakey. Easiest thing to do is add the Purge Tab in your gadgets / User prefrences settings. This adds an option to purge the cache under the same Vector tab that holds Move, Protect, Delete and similar. -- George Orwell III (talk) 23:51, 28 June 2013 (UTC)

This issue is occurring in the edit previews, which aren't cached, so purging won't help. What I saw what that one div is using a different rendering model to render it out of the normal flow, which is causing most browsers to render it above another interactive part of the page, blocking any interaction with the obscured part. -Steve Sanbeg (talk) 03:36, 29 June 2013 (UTC)

That div (

<div style=position:relative>

) was a manual addition at some point for some reason (most likely to preserve the unobstructed aligning to the right). This can be accomplished in a more HTML5 compliant way without the div element or at least its positioning. If you can just tell me in plain English if this is occuring on ANY prettytable/wikitable class html table or just that one with the div & its relative position. If the later, I'll just get rid of the damn thing and put an end to this dog-chasing-its-tail type of issue. -- George Orwell III (talk) 06:44, 29 June 2013 (UTC)

I think that will happen anywhere you have a floating element and a relative position element together. The relative position elements aren't in the normal flow, so they don't flow around floating elements; the elements just stack on top of one another. So you generally don't want to mix them; either use floating elements and have text float around them, or have relative or absolute positioned elements arranged by z-index. -Steve Sanbeg (talk) 01:03, 3 July 2013 (UTC)

Tech news: 2013-27

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

Recent software changes

(Not all changes will affect you.)

• The latest version of MediaWiki (1.22/wmf9) was added to test wikis on June 27. It will be enabled on non–Wikipedia sites on July 8, and on all Wikipedias on July 11.
• On Wikisource, the canonical names of the "Index" and "Page" namespaces in the Proofread Page extension are no longer localized (bug #47596). Please check scripts that depend on $wgCanonicalNamespace. [1]
• A JavaScript problem caused the "View history" and "Add topic" tabs in the Vector skin to be moved into the drop-down menu on right-to-left wikis. The issue is now fixed and links are visible as before (bug #50196). [2]
• There was a short site outage on June 28.
• The automated Category:Project pages with missing files now includes broken file links inserted inside the <gallery /> tag (bug #50119). [3]
• The Nearby feature is now enabled on Commons and shows images in a user's area. [4]
• There is now a special page listing disambiguation pages for wikis that use the Disambiguator extension (bug #44040). [5]
• The old version of the Article feedback tool (version 4) was removed from wikis that still used it. [6]
• VisualEditor news:
  • Many bugs that caused text to be removed or damaged have been fixed, including one related to copy-paste (bug #49816).
  • VisualEditor now offers a visual interface to edit references.
  • In preparation for enabling the VisualEditor on a wider scale, new documentation has been created, including a list of frequently-asked questions and a user guide with many images. Please help with translations.
  • Several problems related to overlapping of elements with the VisualEditor toolbar have been fixed (bug #50096, #50159, #50324).
  • TemplateData information is now displayed for templates that are added to a page (bug #49778).
  • Section edit links now show links to both VisualEditor and the old (source) editor (bug #49666).
  • Images are now loaded securely when using HTTPS (bug #43015). [7]

Future software changes

• VisualEditor will be enabled for all logged-in English Wikipedia users on July 1, and for all users on July 8.
• From July 8, it will be possible to upload WAV and native FLAC files to Commons, and use them directly on wiki pages ([[<tvar|bug-49505>bugzilla:49505</>|bug #49505]]). [8]
• The Universal Language Selector will be added to the English Wikipedia on July 2, and to remaining wikis on July 9. [9]

Erratum

• Tech news #26 incorrectly reported that audio transcoding was added to TimedMediaHandler; it was actually statistics about audio transcoding that were added. [10]

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

14:22, 1 July 2013 (UTC)

Vandalism to Jim Wales, &c. on Proofread of the Month page

Index:Maury's_New_Elements_of_Geography,_1907.djvu

Two places: Profanity at bottom left to Jim Wales and "blah, blah, blah" located at top left—Maury (talk) 02:14, 2 July 2013 (UTC)

Seems to have been managed, marking as Done — billinghurst sDrewth 11:00, 7 July 2013 (UTC)

It was done a day or more ago. AdamBMorgan corrected it fastest and others joined in. I was online when it started and stopped. Kind regards, —Maury (talk) 13:27, 7 July 2013 (UTC)

WikiProject SLQ

Hi everyone, in a few days the State Library of Queensland (SLQ) will be doing a bit of PR about Wikisource:WikiProject SLQ, which will be part of the launch of a larger SLQ project (i.e. Wikisource + some other online collaboration/communication). I've set up one of the four initial projects (Index:Australian enquiry book of household and general information.djvu) and will be setting the other three projects over the next day or two. I would appreciate any help, and am happy to answer questions, or relay questions to the SLQ staff.

Very cool. Seeing as Wikiproject NARA's about petered out, could we make this the Community Collaboration on the front page? Prosody (talk) 02:43, 7 July 2013 (UTC)

I am very biased and COI-ed here (being WMAU's President), but that would be wonderful if it could be arranged. Lankiveil (talk) 08:40, 8 July 2013 (UTC).

I would agree that it is time for a change and I think that this is quite a reasonable suggestion. HOWEVER, it needs someone to coordinate the project, including answering questions at the project page, some preparative work for {{active projects}} and to be added to Template:Collaboration/COTW (community collaboration) — billinghurst sDrewth 10:36, 8 July 2013 (UTC)

Support.--Erasmo Barresi (talk) 20:10, 11 July 2013 (UTC)

The second project is set up; it is a seven page handwritten letter, and I'd much appreciate some guidance on Index:Eleanor Elizabeth Bourne Papers as I havent done a collection of images like that using the new Index tool. John Vandenberg ^(chat) 00:00, 8 July 2013 (UTC)

SLQ has launched 'Pitch in!' https://twitter.com/slqld/status/354154206590025728 https://www.facebook.com/photo.php?fbid=599312000089058 http://www.slq.qld.gov.au/about-us/pitch-in (which is on the front page of http://www.slq.qld.gov.au/ ), which goes to http://www.slq.qld.gov.au/about-us/pitch-in/transcribe . The transcribe page includes a ' sign up' link to oldwikisource instead of enws; they will fix that first thing tomorrow morning. John Vandenberg ^(chat) 09:06, 8 July 2013 (UTC)

SLQ had a transcription of one of these works, and they have provided it as a basis for Index:George Green - 2nd Light Horse Regiment Gallipoli Volume 1.djvu. I've split the text into the pages and marked the pages as proofread, except where I noticed obvious problems. If that isnt acceptable, I'll be happy to push them back down to not-proofread. John Vandenberg ^(chat) 03:57, 11 July 2013 (UTC)

Tech news: 2013-28

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

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

• VisualEditor news:
  • VisualEditor deployment has been delayed by a week. It is now planned to enable the editor for logged–in editors on chosen Wikipedias on July 22, and on all Wikipedias on July 29.
  • A bug that made it impossible to save VisualEditor edits that triggered a CAPTCHA has been fixed. [11]
  • Several bugs that occurred on right–to–left wikis have been fixed last week (bug #49416, bug #49613, bug #50543).
• Uploading files has been restricted on Meta Wiki to administrators and the newly created uploader group. An exemption doctrine policy is being developed (bug #50287). [12]
• Emergency priority CentralNotice banners will always be shown unless users have hidden them, ignoring cookies set for lower priority banners. [13]

Future software changes

• MediaWiki will allow choosing a specific page of a PDF document or a thumbnail of a video file to show up inside the <gallery /> tag (bug #8480). [14]
• It will now be possible to create empty MediaWiki: messages, for instance in order to disable them (bug #50124). [15]
• The Nearby feature will soon be enabled on Wikivoyage wikis again. [16]
• The Notifications extension messages will now include a direct link to diffs on wiki as well as in notification e-mails (bug #48183). [17]
• Table of contents will now use the HTML <div /> element instead of <table />, fixing a nine–year–old bug #658. [18]
• First mock–ups of a mobile Wikidata application have been published by Pragun Bhutani as part of his Google Summer of Code project. [19]
• A discussion on minimum documentation practices in MediaWiki code has been started and awaits comments from the community.

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

18:33, 8 July 2013 (UTC)

EPUB/HTML to Wikitext

Hi all. As some of you have may seen, yesterday the Wikimedia blog published a blogpost around Wikisource and Open Access (and other things). In the blogpost I'm talking about a CC-BY licensed book that I'm uploading here on en.source: Oral Literature in the Digital Age: Archiving Orality and Connecting with Communities. I have several questions, on this:

• (I've been bold and just started doing things, but) are you generally OK with people uploading CC BY licensed new books and texts on en.source (for ex., I know that de.source like to just proofread scans)
• what do you think of the overall thing between open access and Wikisource? Do you think it's worth to follow possible partnerships/collaborations?
• do you know any tools for semi-automatic conversion between HTML/EPUB to wikitext?

The last is a very important issue, I think.
I know there are efforts from some user, as Daniel Mietchen, to work on XML files and automatically convert them in Wikitext (in the future, this would be very interesting for uploading articles from scientific journasl as PubMed Central, for example). And I'm also sure that in the past, before Proofread Extension, there have been tools and script for uploading texts into Wikisource (form the Gutenberg project, maybe?)

of course, creating a tool that would work for *all* possible HTML encodings would be almost impossible. But what about tools for single projects/publishers? For example, there are good contacts with Open Book Publishers, which publishes open access, high quality, CC-BY licensed books. We could develope together a conversion tool, at least for the 3 major pain-in-the-ass Wikisource action:

• creation of pages and subpages, according to the logic structure of the book (i.e. TOC)
  • [OPTIONAL] pre-load the header template with all the metadata
• ref footnotes in their position

Tpt created simple script, which works fine given that:

• all footnote anchors are converted in the form

<a href="#1" class="note-call"></a> 
 <a href="#2" class="note-call"></a>

• all footnotes are converted in the form

<ref id="1">Footnote 1</ref>
 <ref id="2">Footnote 2</ref>

The script is the following:

<?php
$fileName = 'test.html';
$dom = new DOMDocument( '1.0', 'UTF-8' );
$dom->loadHTMLFile( $fileName );
$xPath = new DOMXPath( $dom );

$calls = $xPath->query( '//*[contains( @class, "note-call" )]' ); //TODO: choose the right class
foreach( $calls as $call ) {
	$parts = explode( '#', $call->getAttribute( 'href' ) ); //Get the id of the note content
	if( isset( $parts[1] ) ) {
		$oldRef = $dom->getElementById( $parts[1] );

		//Creation of the <ref> node
		$ref = $dom->createElement( 'ref' ); //TODO: will the converter support this element?
		while( $oldRef->firstChild ) {
			$ref->appendChild( $oldRef->firstChild );
		}

		//Replace the call by the <ref> node
		$call->parentNode->replaceChild( $ref, $call );

		//Remove old note content
		$oldRef->parentNode->removeChild( $oldRef );
	}
}

$dom->saveHTMLFile( $fileName );

• images

Daniel is working on automatic extraction and uploading of images from XML articles, but right now is quite doable using regex for converting <img> tags in Files, and then uploading everything on Commons with the Upload Wizard or Commonist.

What do you think? --Aubrey (talk) 13:17, 11 July 2013 (UTC)

Open CC-BY works are fine. I haven't actually researched the publisher but my first impression is that this is legit and I'm willing to take it on faith that they pass Wikisource:What is Wikisource? & Wikisource:What Wikisource includes (unless someone can show that they do not).

It isn't necessary, but I would prefer that the work was backed by a scan, especially because a PDF already exists. For example, it's clear that you omitted some front matter when you added this work (the title page, the copyright page etc), which means you've used some creative judgement in doing so, and there's no proof you haven't done so again elsewhere. A digital file would help to prove that this is both a real and a faithful version of the text, now and potentially later if vandalism becomes a problem. Adding a "digital first" page status to Proofread Page (which was mentioned somewhere in June on wikisource-l) would help with that but I doubt it will be possible in the near future. (Additionally, without an Index page, the ePub export tool won't work, which is a deal-breaker for some users.)

I don't know anything about HTML-to-wiki converters but I expect they exist; wikicode is just a cut down version of XML. Conversion the other way exists (otherwise none of this is visible), so the opposite is at least possible. - AdamBMorgan (talk) 20:54, 11 July 2013 (UTC)

Well, fwiw, I know of one semi-useful HTML-to-Wiki converter (See HERE & select "MediaWiki" from the list of wiki dialects). It's not going to accomplish a whole lot of the intensive conversion w/images, etc. that was talked about above, but it can handle simple conversions rather reliably.

As for conversions of Wikicode to other formats go - its pretty much a huge waste of time right now even if all the programming needed was in place and worked flawlessly. We don't practice making lists true HTML lists. We don't make chapter or section headings true HTML headings. In general, we don't do a lot of the normal things expected to be found in a vast majority of document trees that conversion is based on - making these conversions "sloppy" to put it mildly.

When a conversion routine detects nothing but DIVs, Ps and TABLEs throughout the underlying HTML wiki-output, with no way to discern things like chapter headings from mere centered text for example, the resulting output will always be a poor reflection of the original author's intent, again, to put it mildly. Unless the approach to current practices evolves to something nearing what a typical document tree typically contains, conversions will remain problematic regardless of any scripting or coding. -- George Orwell III (talk) 22:02, 11 July 2013 (UTC)

I agree that the lack of semantic markup is a massive issue. No idea what to do about it. One thing I've noticed recently however, reading Wikisource documents on an ereader, is that actually it doesn't seem to matter! The epub output of WS looks good! (I know that's not the only goal here, though.) — Sam Wilson ( Talk • Contribs ) … 04:26, 12 July 2013 (UTC)

I expected as much ...the dumbed-down, primarily plain-text based platforms have no trouble in interpreting & then rendering our dumbed-down, primarily plain-text based content - nothing to be bragging about there imho - and that really wasn't the issue being mentioned. Conversions from one format to another should work when they are "complex-to-complex" {like wiki to .pdf-A) as well as when they are "complex-to-simple" (like wiki to your EPub). Only when those are both "successful" can one hope to engineer the reverse (e.g. .doc to wiki).

The lack of semantic "markup" (specifically here on Wikisource) is a product of the auto-wikicoding of the most basic of HTML tags. For example, you can't apply <h2> for a chapter heading without it inheriting the defaults for all headings under the wikicode - which generates the unwanted [edit] ability to the right & the standard article table of contents. So its not so much that contributors are intentionally circumventing or avoiding the typical usage of the most basic of HTML tags, but are forced to do so just to get around the automated default handling of those tags by the wiki code & its user-friendly, short-hand based on any combination of symbol(s).

Until those tags are allowed to stand alone at least when they are applied as inputs using the proper HTML tag schema and without the wikicode usurping their normal function/parameters in the process, any exercise in "forcing" the generation of proper HTML layout here on WS is kind of pointless. It would be a gigantic leap forward just have those tags returned to "normal" in the Index:, Page: and main namespaces. Short of that happening, folks just won't be willing to change their current editing practices no matter how many ways to Sunday somebody tries to explain all this. -- George Orwell III (talk) 06:49, 12 July 2013 (UTC)

@AdamBMorgan: my personal opinion is that it's a waste of time to proofread a digital-born document. I do think it's good to have a clear, evident link to the original PDF though. My point is that Wikisource it's not only a transcribing platform, a wiki version of Project Gutenberg: I see it as a connected, integrated digital library, curated by a community. We can put cross-links to Wikipedia, wikilinks to other texts and authors present in Wikisource, and in some sources we can even annotate (dare you doing it in en-source).

This is for me very important, but I know not everyone thinks about WS this way. I would see as a major step forward the possibility to embed HTML/EPUB files on Wikisource, without re-writing them all. This could inject very valuable content in Wikisource (eg open access books), that then could be easily used as source for Wikipedia and other project. We could even transclude exerptes and quotes in Wikipedia and Wikiquote, within MediaWiki... I always think about inter- and cross-project implementation, and we are far from reaching our potential.

Now, I don't know if Wikisource communities share the dreams I have :-), but in that case we can probably have multiple paths.

In my ignorance, when I see a HTML TOC, or a EPUB index, I see a list of links and a bunch of pages which have IDs. I wonder it would not be soo difficult to develop a tool/workflo/regex procedure to represent that in Wikicode, and then upload all chapters as subpages. (I can probably ask GorillaWarfare, she's working on a Book Manager extension and she's maybe thinking about that).

Moreover, VE could be of help in copy and paste of formatted text... --Aubrey (talk) 10:13, 12 July 2013 (UTC)

Proofreading a digital-born document to remove OCR errors is pointless. However, the PDF or DjVu "scan" provides more than that. They are the equivalent of Wikipedia references. They back up the wiki text and prove that it is a faithful and accurate reproduction. If you want Wikipedias to use Wikisource as citations, something like this needs to be present; otherwise Wikipedian will remove them again becasue they don't understand Wikisource and don't think we count as a "reliable source" (being a wiki and all). More importantly, within Wikisource, the digital copy is our own point of reference. If the pages get vandalised, we can check that against the original "scan", especially with subtle vandalism like just adjusting numbers and deleting words. If we suspect that an error was introduced by accident when pasting the text to Wikisource, we can check that against the original. The same goes for potentially missing elements or individual users' interpretations/creative choices. This has already happened: I corrected some rogue HTML in Oral Literature in the Digital Age (which was not present in the external HTML version, which is more work to do to check something than it needs to be). Separate to this point about references and validation, the Index pages are used for the ePub generator and could end up being used for a lot more (you are involved with Tpt and Wikidata, so you'd know more about that). Hosting pre-generated ePubs would work but could create confusion if the wiki-version has been altered and this does not appear in the download. In the future, if we ever get additional format options, will you be creating new files for every work added in this way? We don't need a digital copy but it does make everything work a little better than not having a digital copy.- AdamBMorgan (talk) 12:27, 12 July 2013 (UTC)

Hi Adam. I understand your points, and I perfectly agree that the back up scan is an added value. But I don't know how to have the digital copy without having to re-proofread that all over again. This is my problem: maybe there is something that I'm missing ( a different workflow/procedure, a tool). What would you suggest? If I take the PDF and upload it for the book, I would have to re-transcribe it. or do you suggest some Match & Split or simlilar? --Aubrey (talk) 08:36, 15 July 2013 (UTC)

Fwiw... what you seek is indeed possible - the reason it never materialized is the initial "dump" to the Page: namespace is nothing more than a simple plain-text extraction of the source file. So regardless of the source document being "born-digital" or a product of OCR being run on the images produced from scanning paper pages, all you're ever going to get under the current approach is plain-text with the carriage returns & their line feeds (think of a typewriter here) at best. In order to preserve the complex formatting found in such complex file formats as .doc, .ps or .pdf, we'd need to extract the content to its own complex format/form or standard first (e.g. some sort of DOM or XML based interim file) and then "dump" as needed from that separate, complex file instead. Corrected content would be able to go "the other way" and get [re]inserted into the source file as well.

Right now, it seems we're pretty much treating any embedded text the same as file [or image} meta-data would be treated just to get around one wiki-coded induced nonsense or another. -- George Orwell III (talk) 10:45, 12 July 2013 (UTC)

This raises another huge issue... Last year I presented a simple draft of a possible "layer system" for Wikisource (fwiw, it was one of the result of my master thesis in digital libraries). Of course, mine is an idea, and very difficult to implement, but I think it would go in the right direction. The community would have different layers where to collaborate, with different tasks. Anyway, this is for the future, but I thought it was worth showing it.

Alex Brollo did some test regarding the abbyy.xml file which is generated by Internet Archive. As this files mantians a lot of info about the OCR (as the problematic words), he managed to color them in red via HTML, and this is mantained also by the Visual Editor. Alex told Aarti, whio is working on the ProofRead Extension, and this hopefully some good will come :-) --Aubrey (talk) 11:33, 12 July 2013 (UTC)

The IA model is close to what I was trying to illustrate in that it generates a complex XML file from the uploaded file early on and uses that to help generate all the other derivative file types; all of which include some degree of embedded, complex content (not plain-text). But the IA model is still only "one-way" - currently there is no on-site way to "proofread & format" that complex XML file and [re]insert it back into the uploaded source file. Not that having this capability is a must for us here on WS; it is, however, the only way I can think of to build new relationships with other, currently "closed-off", library-ish entities.

Alex seems to have been on the right track; any XML is better than what we're dealing with now (straight dumps). -- George Orwell III (talk) 14:11, 12 July 2013 (UTC)

Wikimedia and IA workflow

Hi George, I perfectly agree with you. Me and David (within our Wikisource grant project) spent some time with Open Library and IA folks, trying to understand a possible relationship (look at the chart). It is very difficult, though, to have a two-way relationship between our text and the djvu: the Djvu itself it's not easy to handle, and the main issue is that we lose "mapping coordinates" when we extract the text layer. The very same Alex made some tests 8some of them succesful) and e could put back text and even HTML and wikicode inside the Djvu. The only problem is that it's not mapped anymore, there is no corrispondence between the word and the location in the image/scan. Seb35 was willing to work on that, but I lost track of his work, don't know if he ever carried on. --Aubrey (talk) 08:36, 15 July 2013 (UTC)

We/you are losing the X-min, Y-min, X-Max & Y-max (mapping coordinates) because the original PHP contributing a-hole for the DjVu routine on our servers never bothered to finish the part where the internal DjVu text layer is converted to a (coordinate rich) XML file using the existing DjVuLibre software package because, at the time, the software had issues.

That faulty DjVuLibre version was the equivalent of 4,317 versions ago and the issue has been long fixed now EXCEPT that the .DTD file needed to base the plain-text to XML conversion on still has the wrong 'folder path' on local DjVuLibre installs (if this is true on server installs as well, I cannot say for sure). Once I copied the folder to the [wrong] folder path, I was able to generate the XMLs all day long. These XMLs are just like the ones IA generates during their process (in addition to the XML that AABBY generates for them).

So its not that we as a community decided not to follow through with (coordinate rich) XML generation but got stuck with the plain-text dump workaround due to a DjVuLibre problem that no longer exists. Plus, the guy who created the beginnings of this fabulous disaster was like tick with an attention span deficit and moved on to conjuring up some other blasted thing or another instead of following up on his own workaround & finish the XML coding portion once DjVuLibre glitch was fixed. -- 15:16, 15 July 2013 (UTC)

Hi George, thanks for the precoius info. If you don't mind I'm gonna link your message to Aarti, who is working on refactoring proofread Extension: she's probably *the* person to speak to for these issues. --Aubrey (talk) 14:17, 16 July 2013 (UTC)

That's fine but I'm not sure if I was clear enough before - the [missing] DjVu-to-XML routine has little to with the Proofread extension until later on in the "workflow". The part about skipping it altogether because of the DjVuLibre software issue at the time has been [poorly] documented out in the open for quite some time now -- at least since November 2007 -- see Manual:$wgDjvuToXML specifically. Again, that was several DjVuLibre versions ago.

Whatever that so-called "efficiency problem" was back then has most likely been resolved since (not that it could be any worse than the current meme of treating the DjVu embedded text layer practically like one long metadata string or entry mind you).

The only remaining issue (that I know of) that might be "preventing" the creation of coordinate-rich XML files, again - at least on local hard-drive, Microsoft-Windows installs of DjVuLibre, has to do with the helper .DTD file installed by default here on my 'pooter to C:\Program Files\DjVuLibre\share\djvu\pubtext\DjVuXML-s.dtd. Sometimes the DjVuToXML.EXE file looked for that needed .DTD file to reside in C:\Program Files\DjVuLibre\pubtext\DjVuXML-s.dtd instead; sometimes not. To cut right to the crux of that problem, I just copied the default folder to the sought-after alternative folder-path and haven't had a problem since; don't know if this is even an issue when it comes to server installs of the DjVuLibre software package however.

Hope that helped clarify things. -- George Orwell III (talk) 21:28, 20 July 2013 (UTC)

Upload of Encyclopedia of Religion and Ethics required, if already available at archive.org?

The pdf of the first volume of the old Encyclopedia of Religion and Ethics is about 115M. There are also 12 additional volumes, all of which are, roughly 80M or more. I am in the process of proofreading articles from it for inclusion here, basically because, in reviews of more recent reference works on religion, this source in general, and some of the articles in it in particular, are still considered some of the best works out there, and in several cases the English wikipedia doesn't even have basic articles on them. Is it really necessary to upload the archive.org files, or is their ready availability offsite sufficient for the purposes here? John Carter (talk) 16:59, 11 July 2013 (UTC)

It is strongly preferred to upload the files to Wikimedia Commons and proofread them from the Index and Page namespaces. It is not strictly necessary on this project, however (although it is on German Wikisource and I suspect other language subdomains will head in that direction as well). With the first volume, you will need to a chunked upload (or something similar) as the limit is 100MB for normal uploads. - AdamBMorgan (talk) 17:29, 11 July 2013 (UTC)

Parallel texts

• Wikisource:Translations#Parallel_texts - "We need some guidance on community sentiment over how parallel published texts are to be handled." - not sure how this is a problem, they are previously published works, nothing new or different from any other previously published work.
  • Propose removal Jeepday (talk) 11:51, 4 July 2013 (UTC)

    No, we need to have a decision of some kind on this, and include it here. I've gotten various differing answers regarding this issue, and we have nothing definitive. As a result, I haven't started any of these sorts of works even though I'd very much like to. --EncycloPetey (talk) 21:35, 5 July 2013 (UTC)

    I don't know if it should necessarily be part of this policy but, here or on another page, I would like to see some sort of guideline. Wikisource:What Wikisource includes currently states "English Wikisource does collect English translations of non-English texts, as well as bilingual editions in which the target language of the translation is English" (my emphasis). However, this is not always applied. As an example, off-and-on I've been working on Wiltshire, Extracted from Domesday Book, which shows the original Latin parallel to the English translation (the original alternates pages). Meanwhile, in The Statutes at Large, the French portions of the text have been eliminated (I think they might be planned for, or already on, French Wikisource) to leave only the English translation. I think having both in one place, as WS:WWI allows, is best but I'd like a little confirmation. - AdamBMorgan (talk) 14:28, 11 July 2013 (UTC)

    As this would apply to translations, I'd like to see the issue addressed here. If there's already an applicable statement in policy elsewhere, then copying it here with a pointer of some kind back might be enough. I agree with you about hosting published parallel texts (the text of both languages presented here), and would like to do some Latin/English works, especially since some of them (even important ones) can be very hard to find even on the internet. The follow-up would then be to have one done as an example, and link it from the policy so that people can see how it's done. Displaying text side-by-side isn't quite as straightforward when the original has the two languages on facing pages. --EncycloPetey (talk) 18:41, 11 July 2013 (UTC)

    I think the "percentage" or "ratio" of the secondary language (the language other than the one the work was originally published in) to the primary language should help to dictate whether or not we host those portions here.

    If the bulk of the entire work is in one language and only the occasional or excerpts are translated into another language then it makes sense to host both the original & the translation here since hosting excerpts is frowned upon (I believe) no matter what language wikisource you are calling home.

    If the bulk of the entire work consists of roughly 1:1 (or approx. half of which is) a translation vs. the original base [published] language, then it does not make sense to host both portions here -- e.g. the secondary language portion can stand pretty much on its own and cannot be considered merely an excerpt. Each portion should be hosted under each language's WS domain in these cases.

    And as far as Displaying text side-by-side isn't quite as straightforward when the original has the two languages on facing pages goes; just don't DoubleWiki the pre-transcluded Page: namespace versions but the finished post-transcluded mainspace versions (assuming the latter ~50%/50% scenario is in play of course). It seems to me if the content is such that one cannot "neatly" separate the primary language from the translated, we're going to wind up hosting one entire copy under each WS language domain anyway.

    Regardless, imho the existing guideline(s) of avoiding the hosting of excerpts plus the objective assessment of the ratio between original and translated portions should be governing the practices in the majority of these cases if not made [part of a] formal guideline itself. -- George Orwell III (talk) 21:32, 11 July 2013 (UTC)

    Well, Wiltshire, Extracted from Domesday Book is close to 1:1 Latin:English and was printed with the two languages on facing pages. The latter was easy to solve (transclude with a step of 2 and transclude twice, with an offset of just one page). As for the former, 1:1, aspect: the purpose of the book would be completely invalidated if it were split. It isn't just a translation; it was intended as a translation with a comparison to the original (or a version of the original without the contractions and shorthand). Not to mention that, if it were split, neither would be a faithful transcription without the other half.

    If there were two separate versions of the Domesday Book (and that is an eventual goal) then using double wiki on those to show English alongside Latin would be great. There would also be potential for showing other translations alongside each other. But with Wiltshire, Extracted from Domesday Book, the original combined both languages, so any future version of this book (rather than its source material) should do the same. If not here, it should be transcribed complete on mul.ws. However, the book was intended for an English-reading audience. I think it should be hosted here, per the existing policy but mostly because it is an English book that happens to include a large amount of non-English text (call it 49% Latin). The same would be true of other bilingual works in my opinion. If I were to make a guideline, I would say the presence of an English preface/introduction and additional material, like the index of ancient-to-modern place names, puts it into the scope of en.ws.

    It's not very difficult to import it into mul.ws and finish it there if the consensus goes against my point of view but I do think en.ws is the most appropriate place for the book within the Wikisource project. - AdamBMorgan (talk) 22:28, 11 July 2013 (UTC)

    Umm... If that is the way the work was formally published (in the "English" of 1788 via the publishing house located in city of London) - then that is the over-riding consideration to proofreading and transcribing the work in its entirety here on en.WS in the Page: namespace only. Your decision to transclude the proofread qualified content with a step of two to mimic a side-by-side presentation was your subjective choice and your choice alone. It doesn't matter (in my opinion) that the "left" page is in Latin and the "right" is in English; this is the English language specific Wikisource domain and such methods of presentation are contrary to our norms - not to mention pointless under dynamic layouts other than layout one anyway.

    Again, & also in my opinion, you also have made the assumption the potential en.WS visitor somehow benefits from presenting the Latin along with the English. For example, I personally find including the Latin distracting and much rather DoubleWiki-in these portions if I wanted to compare one language to the other. And since entire sections of the work typically spans several pages that are being trascluded in as a whole, the page by page synchronization of content inevitably becomes "lost", making some aspects of any meaningful side-by-side comparison pretty much moot in the process.

    So, imho, both the Latin and the English Page: namespaces should contain the entire proofread content, have each language transcluded to each WS language domain's mainspace and then have the ability to DoubleWiki these in on-the-fly if the reader wishes to compare the two. Otherwise, I think we'd need to come up with a new way to toggle the current presentation to default to 'show just the English' portions maybe???? -- George Orwell III (talk) 03:23, 12 July 2013 (UTC)

    The format isn't the important part. The English/Latin sections can be in series instead of parallel, or even on separate subpages. My point is that the Latin is part of the complete book. By eliminating it from the copy on Wikisource we are no longer hosting a faithful version of the book. Hosting just the Latin on la.ws is also not a faithful version of the complete book. If we are no longer accepting bilingual texts, we need to change our policy (which is part of the reason I moved the thread here). I'm fine with moving this book to mul.ws but it is unfair on new users to make a claim in our agreed policy pages but to do the opposite in practice. I've heard we can transclude across language sub-domains, so we could transclude extracts from mul.ws to en.ws (and possible la.ws); although even then I would like some notice on the page to indicate to the reader what is happening and were to find the unabridged version. - AdamBMorgan (talk) 12:04, 12 July 2013 (UTC)

    RE GO3 "such methods of presentation are contrary to our norms - not to mention pointless": I disagree quite strongly. Consider our recent POTM Balthasar Hübmaier, where one of the appendices is a hymn of his, presented in the German and translated into English. I don't see how we could faithfully present this material any other way than side-by-side. Look at "Casey at the Bat", an entirely English poem whose presentation in the original work practically mandates a similar arrangement. Side-by-side arrangement cannot be dismissed as pointless, and while it may not be the norm, that doesn't mean that it doesn't serve a vital role. There are lots of expedient deviations from our "norms" across Wikisource. Maybe we need to rethink our norms. --EncycloPetey (talk) 20:41, 12 July 2013 (UTC)

    You haven't disagreed with what I actually hoped to get across at all. Nevertheless; your examples were a simple translated excerpt (the hymn) within a much larger body of work (so that's a false comparison) and illustrations facing it's corresponding text (so that is not relevant in a discussion of translated text comparison at all). I thought I was talking about examples when large swaths of several transcluded pages for each language -- comprising entire sections or chapters & not just a couple of lines or paragraphs -- were being presented side-by-side in the mainspace.

    Specifically, instances where one column's content becomes so offset from the other's, that any benefit from once having the [forced] ability to glance from a left-facing page to the right-facing page translation for an ease of comparison found in printed versions is completely lost by the need to re-adjust & re-align for that eventual offset for each glance from left column to right column made in viewing the webified version. Again, this is not so much an issue when we are talking about wee-bitty excerpts but when the majority of an entire book is nothing but divisions by chapter, section or their equivalent. I saw a larger benefit from dropping this approach for one that separated (or sub-paged?) the two languages with both amounting to being a derivative rather than 'faithful' as the justification. Adam did not. Better? -- George Orwell III (talk) 21:24, 13 July 2013 (UTC)

    • NB: To prevent the subject even further derailing Wikisource:Translations, I have started a guideline at Wikisource:Multilingual texts. Whatever we come up with can go there, even if it just explains Multilingual Wikisource. - AdamBMorgan (talk) 12:04, 12 July 2013 (UTC)

Clarifications

Well if some folks felt any of this somehow deviated from previous guidelines then I suppose parsing the guidline(s) for clarity would be in order. Things that probably first need clarification are (feel free to add): -- George Orwell III (talk) 12:43, 12 July 2013 (UTC)

• What is meant exactly by the term collect under the Translations section under What Wikisource Includes ?
  • QUOTE: "The English Wikisource only collects texts written in the English language. Texts in other languages should be placed in the appropriate language subdomain, or at the general multi-language website. However, English Wikisource does collect English translations of non-English texts, as well as bilingual editions in which the target language of the translation is English."

    I've always read the "collect" in that sentence in the sense of "host" or "include". Wikisource "collects" texts; for example, it collects executive orders, it collects novels, etc. Assuming I'm right: given the page title, replacing this with "include" might make more sense. eg. "The English Wikisource only includes texts written in the English language. Texts in other languages should be placed in the appropriate language subdomain, or at the general multi-language website. However, English Wikisource does include English translations of non-English texts, as well as bilingual editions in which the target language of the translation is English." - AdamBMorgan (talk) 13:07, 12 July 2013 (UTC)

    Include is just as vague imo. I've never thought that creating/facilitating an Index:, transcribing and proofreading the Pages equated to the presentation (or the hosting?) of a work in the mainspace - merely steps taken along the path. Any post-presentation disambiguation or categorization that takes place only makes the path more direct for others after the fact. Clearly we present (or host?) supposed faithful reproductions of well-sourced copy & pastes in the mainspace without the Index: ns, the Page: ns, proofreading and transclusion being involved one bit. And we now permit the Page: namespace to be used in translating other language based works instead of just for transcribing purposes.

    It seems to me that it is the mainspace presentation (or hosting?) that is paramount to us no matter the steps involved or the type of work in question. Being the English based WS, I see all other iterations or deviations as secondary to that paramount goal. The considerations for translations, be they formally published or user generated, should not usurp the basic premise that this site is primarily geared for an audience fluent in reading & editing in English. I'm not so concerned with 'remaining faithful' to a work 'as published' when doing so puts "English" somewhere on the list outlining the order of things around here other than at the very top (paramount). -- George Orwell III (talk) 13:41, 12 July 2013 (UTC)

CASE in point: Would we host and display in the main namespace a Loeb edition of a Latin or Greek Classic (provided it's PD), where the text is Latin-English or Greek-English parallel on facing pages, with a short introduction in English, and the Index in English, but nearly 1:1 for the text in two languages? Would we display all parts of the text in the Main namespace, or would an editor be required to strip out the non-English text? An English-only edited version could certainly be allowed as well, but that would count as a user-generated annotated edition, and we've been frowning on that kind of annotation unless the original work exists, right? Or would we condemn a work like this to obscurity in the mutlilingual WS that no one ever visits or indexes? I would hope and expect that we would allow such a work here in its entirety. --EncycloPetey (talk) 20:35, 12 July 2013 (UTC)

It doesn't matter - if the work was formally published and majority of the content is in English -- if not a translation into English in itself -- we can create, transcribe, proofread & transclude the entire work as always & as stated in the guideline(s). The "striping of text" only came up when the issue moved strictly to the manner in which the work in question was ultimately being presented. So if on one hand the justification for presentation in the main namespace is 'to faithfully reproduce the original as near as possible' the other can't hand claim stepping the pages by two for side-by-side, chapter-by-chapter comparison is actually staying faithful to that original - that should logically be construed as being a value added benefit (i.e. is a derivative of the original and, thus, any striping of one language or the other for mainspace presentation would be just as acceptable also as a derivative). Forcing the Latin here, although a value added benefit by any measure, still isn't the optimal solution in my view either because this simply is not the Latin based domain - end of story. It seems the only reason things like this turn into an issue is because hosting a, b or c on la.WS, mul.WS, etc, is considered less than desirable or something by some. As unfortunate as that may be; its still not a justification to lobby en.WS to pick up the slack. -- George Orwell III (talk) 00:11, 13 July 2013 (UTC)

If the problem is that these works end up sequestered on mul.WS, then we construct our Author/Portal/versions pages to point there as well as to the English only versions that we host. In other words wherever a work with a large proportion of English can be found on one of the Wikisources, then we should point to it. Personally, I don't care where these "parallel" language editions end up as long as I can sit down and read for enjoyment an English only version AND I can also study the text with aid of a gloss (the parallel English translation). Beeswaxcandle (talk) 01:42, 13 July 2013 (UTC)

Here I'm again....

Hi all, much time from the last time I worked here, where my personal wikisource trip (thanks again John!) began. I just uploaded a very interesting book, Index:De re metallica (1912).djvu, first English translation of by Georgius Agricola. I'll use this opportunity to see and learn news and to test here my preferred personale editing tools; I'll put a little bit of doc about them into User:Alex brollo/Editing tools for anyone would like to take a look.

Please review the work I'm loading - De re metallica - for any mistake - this would be my second learning opportunity :-)

There's a copyright issue perhaps - the book have been published in 1912, so it should be PD in US, but its translator Author:Herbert Hoover died in 1964. Can en.source host the book? --Alex brollo (talk) 16:22, 13 July 2013 (UTC)

Hi, welcome back. Copyright is OK. Just use the {{pd/1923|1964}} licence. - AdamBMorgan (talk) 16:35, 13 July 2013 (UTC)

Thanks, done! In meantime, I successfully imported my personal edit tools; any of you can try them (consider that so far there's no doc… :-( ) simply adding into his vector.js:

importScript("User:Alex brollo/vector.js");

--Alex brollo (talk) 19:35, 13 July 2013 (UTC)

Brief translation questions

There are probably going to be more of these as we go along but for now I wanted to ask the community about two translation namespace things:

1. Header colours: Take a look at the new {{translation header}}. Is the colour scheme OK? It is meant to be visibly distinct from the other namespace headers, so you can tell at a glance which namespace you are in. In terms of the traditional rainbow of colours, we already use red (author), orange (process, sort of), green (main) and blue/purple (portal). Yellow seemed to be the most obvious gap in the sequence. - AdamBMorgan (talk) 17:08, 13 July 2013 (UTC)
2. Redirects: How should redirect work between the main namespace and the translation namespace? Usually, we do not have redirects between namespaces. Moved pages are replaced with {{dated soft redirect}}, which is itself deleted after a few months. However, this might mean that a lot of incoming links from other websites (or offline sources) no longer work. People will be able to search for the documents but most won't bother and we don't need to make them do this. There is an experimental {{translation redirect}}, which does not contain any reference to the namespace and is meant to be permanent. As alternative to these two options, we have the additional options of hard redirects and {{soft redirect}}s. - AdamBMorgan (talk) 17:08, 13 July 2013 (UTC)

   The current {{translation redirect}} has a good premise to overcome the cross-namespace questions without technically usurping our policy on avoiding cross-namespace redirects altogether -- but it is only a starting point. Without the addition of what amounts to an overkill in manually- and/or template-added categorization and the like, there is no current way to track the usage of this class of redirects (e.g. its not gonna come up in any 'What Links Here' or 'Special:redirects' list; that much is certain).

   The premise (substituting the mainspace article's curid=) really needs to be further developed before "fully" rolled-out so things such as normal accounting, tracking, etc. are no different than any other type of redirect for Users. I'm guessing that can be accomplished through some combination of API/Lua/templatization, but stuff like that really remains a bridge-too-far for my limited skill sets. Somebody who really knows the ins & outs of such coding needs to pick up my initial fumble and continue to run with it before this approach is truly worth following as a formal practice. -- George Orwell III (talk) 20:49, 13 July 2013 (UTC)

There isn't a lot in the translation namespace yet but that should change as soon as these, and a few other, issues are resolved. - AdamBMorgan (talk) 17:08, 13 July 2013 (UTC)

Color-wise, I think yellow is fine. And I suggest doing something like a dated soft redirect, except one that won't be purged after a few months. I think the redirect template should encourage users to find a free, published version of the translation as well, so we can fill WS with peer-reviewed, edited content whenever possible. That way, in the meantime, we can refer users to our own translation while indicating our need for a free one and encouraging users to find one.—Zhaladshar ^(Talk) 17:50, 13 July 2013 (UTC)

Finally... a voice of reason re: translations. I think that wording ...[we] encourage readers to to find s [copyright] free, [formally] published version ... in the meantime ... so we can fill WS with peer-reviewed, edited content whenever possible. should be worked into the translation policy if that goal isn't somehow made clear enough already. -- George Orwell III (talk) 20:49, 13 July 2013 (UTC)

As an alternative to redirect templates, I've recently thought we could just use {{translations}} disambiguation pages to do the job. With only one item, it stretches the use of disambiguation pages, but no more so than stretching the use of redirects. Zhaladshar's encouragement message could be in the form of a maintenance template on the disambiguation page (either part of the header, a separate template, or both). - AdamBMorgan (talk) 21:43, 15 July 2013 (UTC)

Besides a minor concern on exactly what header-template color will be appearing for such {{translations}} disambiguation pages if that is the route we ultimately make into policy, that seems like a reasonable alternative - especially if my "fumble" remains unworkable. I don't mean mean to be pain re: colors; its just that I don't want even the LCD of potential visitors/contributors to become remotely uncertain about the differences between and/or any expectations under each of the primarly classes of "finished presentations" we will be hosting from this point (final implementation) forward.

However, if the eventual application of such T-DAB pages starts to morph into something that a.) begins to "compete" with the overall premise of the Portal: namespace and/or specifically with its ability to provide person, place or thing inclusive "mixed-listings" on a single page or section(s); or worse b.) becomes a christmas tree of intra- or inter-wiki links of various type and/or multiple purpose (e.g. "competes" with the current application of the 'Plain-Sister' class of template parameters/stand-alone templates), then by no means would I support such a solution utilizing T-DABs. -- George Orwell III (talk) 23:00, 15 July 2013 (UTC)

Question/proposal 1

There's a template Pg running into it.source (it has been briefly mentioned into wikisource-l some weeks ago); it accepts the book page number - just as it is written in original text; as a roman or arabic number or any kind of string) and, given a well-compiled pagelist tag and chapter list into Index page, it converts book page number into a "double-face" link: to nsPage when displayed in nsPage or nsIndex, to ns0 when transcluded into ns0. It is based on Lua, as doesn't use javascript at all, so it's output comes from server and is regularly wrapped into original html from server. I'd like to try to implement this "magic link builder" here as {{Pag}}, since Pg is already in use; can I? Or - am I rediscovering the wheel once more :-) ? --Alex brollo (talk) 19:48, 13 July 2013 (UTC)

We can benefit from as many Lua examples as possible so I say go for it.

EDIT: <chuckle> can we try to convert as much as possible into English while you're at it - it hard enough to try and pick some of this Lua stuff up when its not based in a completely different language. Thanks. George Orwell III (talk) 22:05, 13 July 2013 (UTC)

Sure… I'll try to document it… tomorrow. ;-) --Alex brollo (talk) 23:58, 13 July 2013 (UTC)

The only thing that I can remotely think of that might ever become an issue some time in the distant future is the template's usage of BASEPAGENAME over ROOTPAGENAME (made a formal magic-word a few Wmf upgrades back) -- not that I see much chance of indirect .DjVu files ever taking up hundreds of sub-pages in the Page: namespace or something.... but you never know for sure. :) George Orwell III (talk) 20:14, 13 July 2013 (UTC)

OK: {{Pag}} running. As you can see from my contributions, that whole think needs Template:Pag (general), Module:Pag (general), and Module:Data/De re metallica (1912).djvu (work specific), and a draft test De re metallica (1912)/I to test result; the Module:Data/De re metallica (1912).djvu being built/edited by a js script when needed in it.source; here I wrote manually a section of it… and did a mistake needing a unpleasant Lua debugging. --Alex brollo (talk) 23:54, 13 July 2013 (UTC)

My apologies for stepping on your toes (edit conflicts) as well - I'm sure that did not help matters.

Now that I fully understand the concept in action (making "in-work" citations easier to link to regardless of editing/viewing in the pre-transcluded [Page: namespace] stage or post-transcluded [main namespace] stage), I think a more descriptive Template/Module name might be in order. We can debate what that new name might be somepoint later on.

In addition, I can see an opening here to expand something like this to "work" across multiple volumes where the core Index: naming is pretty much static throughout the entire series of volumes. For example, in one of the side-notes of this Index:volume and Page:, there is a citation that should be linked to it's associated Index:volume and Page:. I'm thinking something like that could be accomplished based on your invention with a little tweaking.

Finally, if I may make a suggestion to the current schema... rather than "poluting" the Module namespace with Module:Data/DjVu or PDF specific page-list information and mainspace titles - I think there a more organized way to make this information part of the workspace already being used in the proofreading of the work in question instead. See the bullet that follows #location, location, location section below. -- George Orwell III (talk) 00:40, 14 July 2013 (UTC)

┌─────────────┘
I'd prefer to finish-up one aspect so others can [hopefully] start building interest in using something like this and even further its development before moving on to something else, That said, I think there is still something that needs tweaking for PAG to completely function.

In your testcase, all the Page: namespace stuff seems to be fine but in the main namespace, the anchor portion of the derived mainspace link doesn't seem to be as intended See p. 70 in the first footnote of De re metallica (1912)/I.

I believe that link from the footnote in ns-0 Book I is suppose to link to ns-0 'Book III, p. 70. The part landing on De re metallica (1912)/III base URL (or ns-0 sub-page) is fine but the page anchor is giving back ' 112 ' as the URL anchor -- which btw is the true /DjVu position in the source file before it is assigned the offset (or your delta) -- instead of ' 70 ' (as in De re metallica (1912)/III#70 ).

Please note that since our last, I took it upon myself to start converting most of the terms in It. into Eng. in both of the Module: related parts. This pagelist assigned anchor to true DjVu position mis-match was discovered prior to my fooling around with the translating so I don't believe I was the one who broke anything.

Anyway, I'm guessing the root of the problem starts with the line building an URL anchor using the ' # ' symbol in the Module scripting but damn if I know how to get it to substitute the pagelist assigned number instead of the true DjVu position number. Can you look into it? Then we can pick up the other discussion on 'Location' -- George Orwell III (talk) 10:47, 14 July 2013 (UTC)

About anchor: you're right, simply in it.source the a href html tag pointing back to nsPage has been wrapped into span tags, one containing the pagenum anchor. Here there isn't anything similar so anchors point to nothing. :-( Alex brollo (talk) 12:44, 14 July 2013 (UTC)

Wait a minute.... You mean to tell me that in spite of the fact we've already compiled useful information such as

cap[9].delta="42"

and

d2b[112]="70"

we can't apply either to modify

           return v.name.."#pagename"..pageDjvu

to resolve the situation exampled above in the footnote of Book I (p. 70 link)?????

No way to simply drop the pagename from the above Module: line and then subtract the delta value (42) from the current /DjVu position number alrady being generated (112), giving us the needed #anchor number of 70 (112 minus 42 equals 70)???

No way to apply the already defined conversion of [112] = " 70 " either??? C'mon... the 2nd one is defined outright as 112 = 70. No subtraction needed!

Forgive my disbelief but that seems quite possible - I just don't know the syntax needed to make it happen. real frowny face. -- George Orwell III (talk) 13:52, 14 July 2013 (UTC)

Really, the it.source idea is useful, since it allows a direct backlink from nsPage to ns0; tag span with its id being the trick for backlink to point exactly into transcluded text of the page. This comes from settings of it:MediaWiki:Proofreadpage pagenum template; your MediaWiki:Proofreadpage pagenum template is different and probably it is not used (I don't find any output from it into html source of ns0). I can't imagine easy solutions… but adding (just to test purpouses) an id tag to div class="pagenumber noprint". I suppose, that editing your MediaWiki:Proofreadpage pagenum template could hurt such a big project. --Alex brollo (talk) 12:44, 14 July 2013 (UTC)

No thank you. We are too fat in the belly with code stuff as it is. I'm looking to streamline downward -- not add to the excess. -- George Orwell III (talk) 13:52, 14 July 2013 (UTC)

:-)

The problem is MediaWiki:PageNumbers.js, that replaces original pagenum links with something better but… ID-less. Yes I agree - sometimes too much js code makes things confusing. In it.source we didn't activate PageNumbers.js, so links are the original ones from server (and from MediaWiki:Proofreadpage pagenum template); and we have the needed ID for pages, while here you don't. In fact, the problem is the lacking anchor… It should not be so painful to add an ID to new div created by MediaWiki:PageNumbers.js; just one - perhaps two - rows of js code. From Module:Pag point of view, it's very simple to write an anchor pointing to a ID containing the book page or the djvu page; but no anchor can run if there's no matching ID. ;-). --Alex brollo (talk) 14:32, 14 July 2013 (UTC)

Ahhh.... " The problem is MediaWiki:PageNumbers.js " <--- that's all you have to say and everything instantly becomes crystal clear.

I am familar with many of the issues caused by this file and all the unrelated crap bundled together within it just so the implementation of Dynamic Layouts could be accomplished without question or care (and the answer is Yes, I literally curse the very air ThomasV is currently breathing for pulling that off before vanishing like a smelly fart in the wind).

So this was a nice little adventure in Lua at least, too bad it will never go anywhere. Until that file is deconstructed back into the individual functions that can stand on their own (or superseded by something better), there is not much chance of anything like position-to-page intralinking becoming automated or whatever we'd call that. And, as you explained, the lack of an id= attribute to call upon in general won't be put in place any time soon either.

As for the specific anchor issue exampled above (p.70 thing), its not that big of a deal in the grand scheme of things. I'd much rather see the day when the real pageid (or Article id) is used to make working intralinks as well as pipe the output with the given/real titles as needed - all on the fly - finally arrives (so this http://en.wikisource.org/?curid=1521399 becomes this De re metallica (1912)/I or Book I) regardless of whatever namespace you happen to be in, leaving from or landing on).

Again, thanks for the insights & your time. Prost. -- George Orwell III (talk) 15:55, 14 July 2013 (UTC)

I'd say that before but… I didn't know nothing about that script, I found it with a nightly furious effort as soon as you told me that anchor didn't run. As I told you, it.source didn't use it, since we love original MediaWiki:Proofreadpage pagenum template (so easy to custom, so useful for anchors). Nevertheless, don't be so pessimistic about fixing it and adding a ID where needed; I feel, that it can be done (I'll try with a personal clone of it, then I'll share my results). --Alex brollo (talk) 16:37, 14 July 2013 (UTC)

My friend, the issue is not so much with the idea of possible changes to theMediaWiki:Proofreadpage pagenum template itself; its the template's inter-action with the .js as it relates to Dynamic Layouts (two separate basic 'things' married along with mouseover highlighting, inline pagenum and I forget what else) that is the "problem" here. Just because I'd like to see our code lose some weight does not mean everyone else shares that view mind you.

And I'd be careful when messing with anything to do with Dynamic Layouts. Losing that function - even temporarily - is much like an infant losing its pacifier (or is that called a dummy by you too?) -- George Orwell III (talk) 17:00, 14 July 2013 (UTC)

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

OK, the alternate-URL's broken-anchor thing appears to be working as advertised now, so the next question is. . .

Just what generated the formated info saved in Module:Data/De_re_metallica_(1912).djvu exactly? Seems like you just copy/paste'd it from the existing one hosted on it.WS (but I've been wrong before). -- George Orwell III (talk) 06:17, 16 July 2013 (UTC)

Good question :-)

Into it.source it is generated (or updated) both

• by a js tool (appearing under "Edit tools"); it reads parsed Index page (so catching current pag-num pairs) and reads too the contents Index page wiki code, using data wrapped into Indice sommario template;
• by a python script, that can be run by a bot, does exactly the same. I’m waiting for the it.source community comments, then I activate Alebot to build Data page for all indexes; it’s a #irc bot, so it can "see" Index page edits and update Data as soon as they change.

As you imagine, I’ll edit as soon as possible our it.source scripts from your unvaluable assistence and contributions here (thanks!!!); so that anchors and IDs will be the same into en.source and it.source, and I’ll edit the js script (it is "parseIndice.js", but has many dependencies…) so that it can be run here too with a click. --Alex brollo (talk) 08:18, 16 July 2013 (UTC)

location, location, location

• Rather than building what amounts to "PDF bookmarks", "DjVu outlines" or some similar internal, metadata-ish needed by-product in the Module: namespace, such as where Module:Data/De_re_metallica_(1912).djvu currently resides, why not generate the same in Page:De_re_metallica_(1912).djvu/0 instead? That 'Zero' [sub]page is never part of any Proofreading or namespace specific routine as far as I can tell and things would start to better align with -- at the very least -- a true indirect-DjVu file breakdown in the process.

  If we can quickly exclude it from detection by the Proofreading Extension [like it once was not too long ago] I think that is a better, unobstrusive, newbie-free way to store this information. -- George Orwell III (talk) 00:40, 14 July 2013 (UTC)

Thanks for interest. Consider that I' thinking about "the algorithm" from years, so as soon as I saw the Lua loadData() trick, I understood that that was the solution and I could implement it with some pain, since I'm a DIY "programmer", but I had a clear idea of needed data and of desired result.

About place for data: I didn't know if server sees as "Lua scripts" pages in other namespaces than nsModule; if it do, I think that the best, less-hurting location is a Data subpage of Index talk (in the case of De re metallica, in Index talk:De re metallica (1912).djvu/Data. Perhaps a small edit of that "thing" that produces the alert on the top of Index page, about formatting conventions into Index talk page, would produce an alert too about existence of a Data subpage.

About the name of template Pag: consider that one can imagine a lot of different uses of Module:Pag as a "data query engine", and you can imagine different templates to invoke different functions into Module:Pag to return any kind of result from any kind of Data module; I think that Pag is a good name for template related to page stuff, and other functions should be called from templates named intuitively (you can imagine a Template:AutoNs0 to build from scratch both the header, and the complete pages tag with no parameters; presently fromsection and tosection tag haven't their data but in future…)

So, resuming, IMHO:

Template:Pag is a good name to manage page numbers;

At face value I competely agree but when considering the community as a whole, we are really dealing with taking a digitized source file's page positions, [re]assigning them to mirror the pagnation as found in the paper published edition (creating a delta or offset) and pluging any combinition of both to work in one manner or another across one namespace or more. Its somewhat of a struggle already at times to help get people to realize that a position number & a page number might be the same numerical number in one scenario and complete different or offset in another scenario. Throw in internal indirect .Djvu file numbering with PDF intelligent object numbering etc. etc. and we begin to get lost in a forest of numbering. I like the notion of 'managing page numbers' as a task but not for a title - especially when its an abbreviated one.

Lets leave this alone and let it boil over before moving to rename it from what it is now {PAG). -- George Orwell III (talk) 11:38, 14 July 2013 (UTC)

Module:Pag probably could be renamed as Module:Query or something similar suggesting its role is to query data;

If you say so - I'm not one who can speak with any authority on such [Lua based] matters. -- George Orwell III (talk)

Module:Data/De re metallica (1912).djvu could me moved into Index talk:De re metallica (1912).djvu/Data.

Not going to happen. I will not be willing party to what would clearly be the misuse/abuse of a namespace, even a talk-page associated one, merely because it is the easiest way to further one thing or another at any given moment in time. Sorry. -- George Orwell III (talk) 11:38, 14 July 2013 (UTC)

While waiting for your opinion, I'm going to import another, mostly useful template: it:Template:Indice sommario and to test it into the poor Index:De re metallica (1912).djvu. :-) --Alex brollo (talk) 09:31, 14 July 2013 (UTC)

First, please return to the previous above discussion and return to this academic non-critical portion afterwards. In progress.... George Orwell III (talk) 10:47, 14 July 2013 (UTC)

Returning to the points directly above . . .

Well the current location for hosting the various Module: dependent data, Module:Data/base pagename of Index: or File: is not going to go over very well either. I may be wrong in that assumtion but I really believe most folks (given the time to absorb events) would not look kindly upon launching a new approach to page & position management based on reusing the same root page-name over & over again with each work getting its own sub-page in the process just to host what amounts to static data. I'd like to find a better way -- I'd even rather lobby the community to activate sub-pages for the Index: namespace properly (if doing still works for the Lua stuff of course) -- than continue down the current road of Module sub-pages. -- George Orwell III (talk) 11:38, 14 July 2013 (UTC)

Wouldn't be the best location for structured data (too granular/project-specific/preliminary to be hosted into Wikidata) a new Data namespace? --Alex brollo (talk) 14:49, 17 July 2013 (UTC)

Absolutely..... especially If the information was static. The problem I can forsee is that we don't really uniquely number everything in a pagelist tag (every blank page is assigned the term Blk and every full page image is designated simply Img more often than not). This probably means PAG (or its data would eventually trip over itself because of the duplicate use of the same pagename assignments.

As for location in general, you'd first need to verify the Lua scripts can indeed use such data mining saved in namespaces other than the Module: namespace otherwise we are just speculating here (and I've speculated ahead of reality a bit too: SEE HERE). -- George Orwell III (talk) 20:08, 18 July 2013 (UTC)

Again, the damned "rediscovering the wheel" :-)

But.... where it comes it from? Where is it? How can we access to it? I don't know anything about o_O! Please, a link to doc! Fastly please.... or... I'll go mad! :-D --Alex brollo (talk) 15:22, 20 July 2013 (UTC)

It is setup in the MediaWiki message system just like pagenum template, etc. are (p.s. MediaWiki message system not designed to be called upon to "act" like normal template in template namespace does - this is another evil doing started by ThomasV & accepted by lemmings [including me] because nobody knew any better/mis-placed trust at that point in time). It is only a 'proof of concept' placeholder and not a workable solution right now - especially because maybe you still mis-understand me & what is needed to move forward.

Number One: We need to prove Lua script can use data stored in other namespaces beside Module: or all this is a BIG waste of time & effort. I tried to switch data path to Index talk:De_re_metallica_(1912).djvu but again, I do not know the proper syntax to point to that location without script error. Please take a look and modify as needed. Either way - work or no-work - this "option" needs to be proven or disproven asap. -- George Orwell III (talk) 22:05, 20 July 2013 (UTC)

Proposal 2: template Content

Don't alarm too much - in a brief time I'll return home in my beloved it.source and I'll stop for some months/for some years to annoy you :-P. But in the meantime, I'd like to test here an useful template: it:Template:Indice sommario. The only location for it, is "Contents" section of Index page; so, given that template stores and displays data for contents of transcluded book, one by one, I'll try to import it as Template:Content.

Its parameters are (I apologyze for Italian names, you'll change them if you like)

{{Content
|nome= full name of the page
|titolo= title as will be displayed
|from= from parameter for pages tag (a djvu page number)
|to= to parameter for pages tag (a djvu page number)
|delta= difference djvu page number - book page number
}}

If you browse the code of Module:Data/De re metallica (1912).djvu you'll see the same parameters for various chapters: this means that given one of them you can build the other one. :-)

Well, the best is, to see it into action. I'll use my current "test index" to test it and to show you the result. --Alex brollo (talk) 14:52, 14 July 2013 (UTC)

Tech News: 2013-29

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

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

• The latest version of MediaWiki (1.22/wmf10) was added to test wikis on July 11. It will be enabled on non–Wikipedia sites on July 15, and on all Wikipedias on July 18. [20]
• The Disambiguator extension was enabled on all Wikimedia wikis on July 9 (bug #50174). To use it, add the __DISAMBIG__ code to disambiguation templates (see example). [21]
• The Universal Language Selector was added to all remaining wikis on July 9, finishing the process of replacing the Narayam and WebFonts extensions. [22]
• The CommonsDelinker bot is now on-line and operating again, after a password problem was fixed (bug #51016).
• VisualEditor news:
  • According to the schedule, VisualEditor will be available to all users on the English Wikipedia on July 15.
  • Users should add TemplateData to templates to prepare for VisualEditor. A tutorial is available.
  • Parameters marked as "required" in TemplateData are now auto-added when you add a template (bug #50747).
  • Warnings are now displayed in VisualEditor when users edit pages that are protected or have edit notices (bug #50415).
  • Many other bugs have been fixed in VisualEditor during the past two weeks.
• The Wikimedia technical report for June has been published, with a summary that can be translated.

Future software changes

• A new version of the Single User Login system for global accounts will be enabled on July 17. Users will now automatically go back to the previous page instead of seeing the "Login success" page with logos. [23]
• The software that resizes images on all wikis will change on July 18. Resizing of big images will be faster and more reliable, and the resolution limit for GIF, PNG and TIFF files (currently set at 50 megapixels) will be removed. [24]
• Edit tags (mostly used by AbuseFilter) will now also be on diff pages. They include a link to Special:Tags before the edit summary. Wikis that use links in tag messages should remove them. [25] [26]
• Global edit filters are currently in testing and will be added to wikis later. [27]
• Wikivoyage wikis will start to use Wikidata for interwiki links on July 22. [28]
• A new image gallery design has been proposed by Brian Wolff; comments and feedback are welcome.
• An IRC discussion about Bugzilla is planned for July 16, at 16:00 (UTC) on the IRC channel #wikimedia-office on Freenode (time conversion). [29]

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

17:32, 14 July 2013 (UTC)

WMF intends for Only VisualEditor to be usable on Talk pages; representative states he would "dearly love to kill off Wikitext".

Jorm is a representative of the Wikimedia Foundation, who are in charge of all of us. He's responsible for developing "Flow", the new talk page system. And he's saying some things that no member of the WMF should be saying.

""You should strive to achieve Zen acceptance that the only editor for Flow will be the VisualEditor. If, by the time Flow is released, the VisualEditor supports a native code editor, it will likely be there. But nothing is promised - nor can it be." - Jorn (WMF)"

He went on to add "It is entirely possible that the data for each post will not be saved as wikitext because there are considerable performance issues that arise when doing so. If this is the case, things like templates will simply be unable to be supported." and further added "I would dearly love to kill off Wikitext."

I apologise if the links are a bit weird - they use LiquidThreads there, and linking to individual threads is buggy.

Is Jorm acting in a rogue manner? Perhaps. But until the WMF denies it, we need to presume this is true. Adam Cuerden (talk) 00:39, 15 July 2013 (UTC)

This was posted in a number of places and unfortunately did not point to a central place to discuss this. It would be helpful if everybody interested in interpreting these words would respond in one central place at w:Wikipedia talk:Flow instead of a number of different wikis. --AKlapper (WMF) (talk) 14:50, 15 July 2013 (UTC)

Well, I'm far from scandalized from such a vision. We all have been painfully trained to use wiki markup; and we learned it, more or less; perhaps we are suffering from the "Stockolm syndrome" and we love it but… it's absolutely not a "well formed" markup language, and has inside some terrible conceptual mistakes (thing only to apostrophes for italic and bold!) which obviously cause "considerable performance issues"; this is precisely why well-formed markup languages have been developed and used. I can't imagine the terrible pain of Tpt while developing VisualEditor. Thanks Tpt! --Alex brollo (talk) 15:06, 15 July 2013 (UTC)

So how can I help kill off Wikitext too?

Its great for Wikipedia-type collaborative efforts both for generating articles as well as facilitating talk-page discussions about them but for those of us working on Wikisource, where the overall mission is to ... faithfully reproduce source documents as close to the original published versions as possible... (e.g. where content is more static than collaborative and facilitating ease of editing is not critical to article mainspace developmen)t, I'd much rather have the wikicode-usurped HTML tags for headings, lists, tables and similar on back under our control, And with their overall expected behavior restored without infringement by the "wikicode". -- George Orwell III (talk) 15:28, 15 July 2013 (UTC)

I presume, that the worst of wikicode is something related to templates: the fact that usual templates mix into their parameter list content text and "other". You - or a script - can't imagine what is text and what is other simply reading the wiitext; you must go to template code, and decode it. There's a solution for templates that have inside one piece of text only, and that can be converted 1:1 with html tags; it has been largely applied here in source projects splitting templates in a "well formed version", cutting them in a begin and in an end part, the text staying outside the template; I think that and effort should be done, to consider this the default template structure in any case where it is possible, as a first step towards a "almost well-strucured wiki markup". Sometimes it is not possible (i.e. IMHO when template contains multiple alternative content texts); in those cases, I'd like that parameters accepting text contents would be clearly recognizable from other by some "convention" (could be, that they should always be named parameters & their name should be prefixed with "text"). In the meantime, some of it.source editing tools (as postOCR) "code" and then "decode" wikitext when needed removing from it any template and any other tag (leaving bookmarks obviously) as "code" action, changing what needs to be changed into the pure text by regex replaces, then putting again templates & tags into their original position as "decode" action; this is safe, but obvioulsy text contents wrapped into templates can't be edited. :-( --Alex brollo (talk) 04:42, 16 July 2013 (UTC)

That's not it - I just always really hated symbols... even when I was child and didn't know what they stood for. <grin> -- George Orwell III (talk) 06:05, 16 July 2013 (UTC)

Scripts

Is anyone else who uses scripts experiencing a loss of the ability to open up the list of scripts in the sidebar? Suddenly the word "Scripts" has become big bold unlinked text. Hesperian 02:47, 17 July 2013 (UTC)

The problem appears to be that the regex menu framework inserts "Scripts" into the sidebar as a level 5 heading, and this update to the Vector skin has removed h5 selectors from the collapsible nav style sheet. The solution appears to be for Pathoschild to update the framework to put "Scripts" into a level 3 heading instead. I have emailed him to that effect. Hesperian 03:09, 17 July 2013 (UTC)

I am so glad you made that observation, because I very much feared I had broken something on my system/browser. I might also point out a similar fault shows up if the UserMessages gadget is enabled in Preferences; this time on the top menu bar (only on user talk pages―manifests itself to me as an over-large "Notify" tab.) MODCHK (talk) 07:16, 17 July 2013 (UTC)

That too is marked up as a level 5 heading, and possibly the solution is the same: change "h5" to "h3" in MediaWiki:Gadget-UserMessages.js. But I don't use that gadget so I'll leave it to someone else to fix and test. Hesperian 08:16, 17 July 2013 (UTC)

Well, having been forcibly educated that having such a gadget enabled is apparently no longer officially sanctioned, no longer have I! (Or am I reading too much into clearly untested (irrational?) changes? My former incarnation as a professional software (so-called “engineer”) is grossly offended… I kid―but not very much.

For our nord-Americani friends, the above is known as sarcasmé (Anybody reading into this that my meat-space day has badly failed it's E. Coli test limits…understands correctly!) MODCHK (talk) 10:34, 17 July 2013 (UTC)

Hmm, it's not just in Vector, as both headings are large in Monobook as well. Beeswaxcandle (talk) 09:35, 17 July 2013 (UTC)

Well I just changed all the H5 instances to H3 in MediaWiki:Gadget-UserMessages.js - for those using the gadget, please report back. I don't see how that makes anything appear "smaller" at the end of the day unless that particular H3 heading behavior is also modified by CSS definition or similar at the same time. I guess we will find out if that is done in something on the servers or if we will have to add the equivalent(s) locally soon enough. -- George Orwell III (talk) 20:20, 18 July 2013 (UTC)

Thank you. I confirm that is one issue addressed - at least for now. MODCHK (talk) 20:40, 18 July 2013 (UTC)

Pathoschild has patched. Clear your cache and all should be well. Hesperian 01:31, 19 July 2013 (UTC)

Some questions regarding the completed works list

While adding Index:Picture Posters.djvu to the list of validated works, some questions came to mind about the list and its placement on the Wikisource:Proofread of the Month/validation works page.

1. Unless I am wrong, in my mind there is no relationship between finished works and the Proofread of the Month and I am guessing that it is placed there due to the lack of a dedicated page?
2. Is it necessary to list completed works of prior years, rather than archiving them?
3. Is there a way to know which of the listed Proofread/Validated works have not yet been transcluded in the main namespace?

I realize that these issues involve additional time, and I am proposing to set up the pages dedicated to the various lists as I prepared on THIS PAGE, and archiving previous years in subpages. — Ineuw talk 13:20, 17 July 2013 (UTC)

This list is of the works that have been completed through the PotM pages. For the dated sections, they are works that were completed during the annual Validation Month. The other section lists works that were completed through having been on WS:PotM in the section Works requiring validation (which is why I didn't put Picture Posters on the list). I haven't seen a need yet to archive this page as it's not that long. However, I won't object if someone else decides that it should be. I would be concerned though, if this ends up being a manually created fork of Category:Index Validated.

With respect to transclusion, I have assumed that all works added to the Queued list have already been transcluded at the time of listing. This assumption is because it's the way I work. Beeswaxcandle (talk) 22:00, 17 July 2013 (UTC)

Then it’s a mixed list (and a confusing one) because the completed PSM volumes are also there for validations . . . most of which have been completed. The list also contains works requiring only a few pages to be proofread/validated.— Ineuw talk 02:05, 18 July 2013 (UTC)

The PSM volumes have been done via the Works requiring validation section. The queue has a variety of works and lengths, so that a variety can be presented to the casual validator. Beeswaxcandle (talk) 03:19, 18 July 2013 (UTC)

Beeswaxcandle, clarity comes with your explanation. :-) The subtlety of the differences between PotM vs validated works confused me at first. From the beginning I realised that a separate, manually maintained page just adds to the workload. Thus, adding the validated Picture Posters was superfluous. I will just keep adding proofread works. Thanks for your time. — Ineuw talk 11:21, 18 July 2013 (UTC)

Local analogue of fr:Template:Table

Is there an analogue of fr:Template:Table, a very elegant and customable Lua-based template particularly useful to render original index pages of books (with default dotted lines)? If there isn't, can I try to import it here? --Alex brollo (talk) 07:19, 19 July 2013 (UTC)

No Need. We have enough of these typr of templates already imho. -- George Orwell III (talk) 08:03, 19 July 2013 (UTC)

I couldn't find the best of your templates: I tryed to browse (fastly) help & categories pages with no success. Can anyone help me (or link a page where a good template is used)? Thanks! --Alex brollo (talk) 09:00, 19 July 2013 (UTC)

Try the set of templates that start with {{TOC begin}}. However, I've stopped using these in favour of creating tables directly and ignoring the dotted lines, which are a print artefact that doesn't need to be reproduced on the web. Beeswaxcandle (talk) 09:40, 19 July 2013 (UTC)

Thanks! I browsed a little bit the root one {{TOC begin}}, and I found this reasonable suggestion into its doc: "If you have a new circumstance to format, perhaps the best option is to make a new template, rather than hack an old one to fit.". I'll make a new template (without dots, given that they are optional: KISS): I've some hundreds - perhaps thousands! - of items to manage.... :-) --Alex brollo (talk) 10:25, 19 July 2013 (UTC)

Two Years' Vacation

This mainspace [frame]work is coming up on a month since first started and barely a page of content has been added. What we do have is some 100-odd pages of a header and TOC nav links - which makes for a lot of upset searchers when they eventually land on what is suppose to be content not just a framework.

Can someone with ties to the French WS find out if this bunch are regulars over there and what they plan to do with all those pre-set, content-less mainspace pages?

If not, I'm probably going to nominate it for deletion (without restoration until some content starts appearing along with the framework that is). -- George Orwell III (talk) 15:45, 19 July 2013 (UTC)

I would add that the content that is there is not from the edition that has been set up, but is from the abridged edtion Adrift on the Pacific. Beeswaxcandle (talk) 21:20, 19 July 2013 (UTC)

Right. I located that version early on in hopes it would suffice as a replacement for whatever it is this current monster is suppose to accomplish without much luck. This being one of Jules Vernes "lesser" works, there aren't any readily available online versions to build PR scanned backups from either (at least not here in the U.S. & to the best that I could find that is). -- George Orwell III (talk) 21:28, 19 July 2013 (UTC)

Wiki Stack Exchange

There is a Stack Exchange Network being proposed at http://area51.stackexchange.com/proposals/49276/wikis the proposal reads

"Proposed Q&A site for users and editors of wikis around the world that want to find out more on editing, installing and developing wikis. This site will cover every aspect of wikis, from editing Wikipedia, to installing MediaWiki and writing new features for wiki systems."

Given the kinds of questions we ask each other here, some of us may be interested in the site. Jeepday (talk) 12:11, 20 July 2013 (UTC)