Wikisource:Scriptorium/Archives/2011-11

Please do not post any new comments on this page. This is a discussion archive first created on 01 November 2011, although the comments contained were likely posted before and after this date.
See current discussion or the archives index.

From this news, it would seem that we are planned for the third stage. — billinghurstsDrewth 10:26, 16 September 2011 (UTC)

We were upgraded to 1.18 in Stage 3, second dig. Special:Version. Please note any discrepancies and issues either to bugzilla, the upgrade page at Meta (as per blogor if that is too hard, then to this page and someone will probably pick it and run. — billinghurstsDrewth 03:19, 6 October 2011 (UTC)

collapsible elements and the two codes class="mw-collapsible mw-collapsed. We should look to review where we collapse bits, and look to update as necessary.

AjaxCategories: Lookahead and provide suggestions, as per the previous gadget(?)

protocol-relative URLs in links, interwiki targets

I can see no mention of the setting of defaults for gadgets, so we can hope that the needed parts (see other discussions about recent gadgets) were in fact installed. — billinghurstsDrewth 05:44, 6 October 2011 (UTC)

As part of the mediawiki upgrade, I have removed some of the protocol specific (http://) parts of the gadgets. For those who have persistent web browser sessions they may wish to reload their gadget scripts. — billinghurstsDrewth 07:16, 2 October 2011 (UTC)

See the announcement at w:Wikipedia:Wikipedia Signpost/2011-10-31/In the news#In brief: "JSTOR, the pre-eminent online archiver of academic journals in the humanities and social sciences, has released that portion of its journal content first published prior to 1923 in the United States and prior to 1870 elsewhere, a haul comprising 500,000 articles from a broad swathe of disciplines, accounting for about 6% of its total archive." However, as far as I can tell, it's all available only in PDF or JPG, not in DjVu. I've already downloaded the relevant issues of the International Journal of American Linguistics in case I ever get around to uploading them here. Unfortunately, I have never succeeded in converting any other file type to DjVu. I don't know how many of these journals were not already available at the Internet Archive. Angr 18:33, 1 November 2011 (UTC)

Inductiveload stated that he had some success recently, and I saw he and Matt talking about a new version of tesseract that they were installing. Has JSTOR placed any restrictions on it being further uploaded, ie. can we therefore stick it up at Archive.org/Commons? Or has it just been released freely available? — billinghurstsDrewth 20:51, 1 November 2011 (UTC)

I went and looked, and they have conditions on the release

“

Permitted Uses of the Content.JSTOR encourages broad use of the Early Journal Content. Subject to these Terms and Conditions of Use for Early Journal Content and the JSTOR Terms and Conditions of Service, users are free to copy, use, and redistribute the Early Journal Content in part or in whole for non-commercial purposes.

Which means that it may be worthwhile for the community to look to build a specific discussion, and seek some direction from legal eagles at WMF. — billinghurstsDrewth 20:59, 1 November 2011 (UTC)

I don't think any such thing is necessary. The issue is one of mere copy-fraud and possibly a contractual issue for the downloader. The content is already free (as in Public Domain), it's just a matter of getting access to their databases, which they have now granted. They also don't appear to be using the term "commercial" in the same sense as the CC-NC term. Reading the entire usage terms would suggest that they don't want you to download for a commercial purpose but not that they restrict the further use of the content that you have lawfully downloaded (even if such restrictions were possible). It may, however, be worthwhile to contact JSTOR and ask them to clarify this, but we have no prohibition on using content that has contractual restrictions on it and JSTOR has no ability, except their technical barriers, to restrict the use of public domain material. My understanding is that the prior problems were encountered by attempting to circumvent the technical barriers, which JSTOR has now lifted for the relevant content.

As for the PDFs, the proofread page extension supports PDF, so why would we need to convert to DjVu generally? I know there are sometimes issues, but they aren't a reason to not use the pdfs. JPGs work too. There's nothing special about DjVu and it's generally of lower quality so we should be glad that they made these as something else. Conversion from jpg is not really that difficult either. --Doug.(talk•contribs) 21:28, 1 November 2011 (UTC)

From their website …26 October 2011 The Royal Society has today announced that its world-famous historical journal archive – which includes the first ever peer-reviewed scientific journal – has been made permanently free to access online read on — billinghurstsDrewth 09:41, 2 November 2011 (UTC)

I would like to request a bot flag for User:CandalBot. I'm using it for interwiki maintenance, running from the toolserver. I'm using pywikipedia with some subtle modifications, to avoid the "multiple interwiki" issue (details on the bot user page). As I've successfully tested this modified script, I think I'm finally ready to run it with the flag. Candalua (talk) 12:09, 28 August 2011 (UTC)

Support - Historically, I believe we (more or less alone among the source subdomains) have not flagged interwiki bots. I found this out when I made such a request earlier this year for my interwiki bot. However, CandalBot is very active and very good. The bot is accurate and well supervised and Candalua has done a lot to tweak the interwiki code to work better on works, to avoid dealing with works that have multiple interwiki links to the same place, and to use noincludes in template space. As Candalua notes above, they have tested the bot extensively on a large number of subdomains. The bot is also flooding recent changes; so I had to ask Candalua to slow it down and I gave the bot autopatroller status to make it a little easier on those looking at recent changes. Therefore, I support a granting a flag to Candalua. There is a lot of work to be done and this bot is finally doing it well. We should allow it to run full speed. If anyone notices significant issues that suggest closer supervision by others is required, the flag can always be removed/or we can just click the link to include bot edits and watch them.--Doug.(talk•contribs) 15:58, 29 August 2011 (UTC)

Support Seems accurate and it is indeed hitting RC. — billinghurstsDrewth 13:31, 5 September 2011 (UTC)

I made note of the following on Asquith's Author talk page, but thought I'd throw the question out here as well... I have a copy of this work (Poems: 1912-1933), signed by Mr. Asquith (to "Marie Belloc Lowndes")... I noted on Archive.org that one of his works (Moments of Memory from 1938) is in the public domain despite(?) it's copyright date... I was wondering if Poems might also be in the public domain (copyright not renewed, perhaps?), even while it's post-1922... I can't find it available anywhere online... It was published in London. Thanks, Londonjackbooks (talk) 18:41, 2 August 2011 (UTC)

Your provided external link does not say that it is in the public domain. If there are reasonable doubts to post this type of works here, the title here may be started with {{Wikilivres page|1947|1938}} to redirect to Canadian Wikilivres.--Jusjih (talk) 09:51, 27 September 2011 (UTC)

i believe it's life +70 years = 2017, per UK copyright, unlike US where it could be PD not renewed. many are the orphan works. Slowking4 (talk) 21:41, 12 October 2011 (UTC)

The Commons template {{creator}} has started to use person id, and they seem to have leveraged VIAF (Virtual International Authority File - http://viaf.org). Seems like a plan for authors and something that we should consider for our metadata. Anyone know more about it and care to explain the positives and negatives? — billinghurstsDrewth 14:00, 4 September 2011 (UTC)

I am working with an editor who would like to translate a book published in Spanish into English. It has a scan, but does not exist published in English. What kind of approach should he take? I had a few thoughts.

List es.wikisource link as the source in the talk page.

Template "cruft"; a parameter similar to the build of plain sister, so that when selected it opens up the interwiki for text comparison, or brings directly to the page in spanish

Denote that interwiki link (to Spanish) as being the one it is directly translated from, something other than ⇔, or with a star, differently colored, etc.

Use page link columns to link back to the Spanish pagespace when selected.

I see pros and cons in each, but I would like to get feedback. What do you think? - Theornamentalist (talk) 14:12, 9 September 2011 (UTC)

I'd like to pick one soon, any advice on a direction, ones I definitely shouldn't do? Translations have existed for awhile, but I feel like there is something we could do with the scan or iw link. - Theornamentalist (talk) 19:23, 12 September 2011 (UTC)

Well, my first thought was "I don't know either, so I'll wait and see." That said, I would use the ProofreadPage extension, with a Spanish DjVu but typing in English (include, if possible, a warning on each page and the index to explain this - an {{ambox}} in the header or footer should suffice); AND highlight the interwiki link; AND leave a note in the header and/or talk page. You don't necessarily need templates yet. See what works and template-ise it when you're done. That should cover everything. - AdamBMorgan (talk) 20:07, 12 September 2011 (UTC)

The approach that ABM suggested is one that sits well with me, and was my first thought on how we could proceed, and to have something verifiable/reproducible/reviewable. It would also transclude well, and then be commented well in the header notes. — billinghurstsDrewth 04:13, 13 September 2011 (UTC)

It would be helpful to know what work this is. At least so we could follow progress and see if this is turning out well.--Doug.(talk•contribs) 09:22, 18 September 2011 (UTC)

I made this template ({{Page translation}} which is set up on a handful of if statements, and can only direct to Spanish wikisource. I think that it could link to others, but I think the *if* statement I used are pretty much either/or. It uses the file extension to link to either the page or index space at the Spanish wiksisource.

I made this the other night (Los Cinco Cerditos) with the help of an editor who is fluent in both English and Spanish. Unfortunately, es.ws does not have the header/footer option in the index fields, and it can't handle the table in the index like en.ws can (see here).

The work that the editor had translated is Pedagogía Tolteca, and I've set up an index for them here. I let them know a few minutes ago, so I think they will begin working on it shortly. As a disclaimer, explanation and suggestion, I wrote this, and with your blessing, I was hoping we could introduce (some form of) it into Wikisource:Translations.

Where is the header/footer script is in the common, and how I could add it to es.ws? - Theornamentalist (talk) 21:11, 11 October 2011 (UTC)

I'm a contributor to the French Wikisource, and I just submitted a bug report and a patch on mediawiki's bugzilla. It's about using colons to indent verses inside the poem tag. Although this solution is quite handy to get an em space (which is the rule in verse typography), the generated html code contains definition list (<dl><dd></dd></dl>). When using several colons, you get nested definition lists, which is really ugly. My patch gives a simple solution : colons are replaced by em spaces (&emsp;) before any further processing by the parser. In a similar fashion, spaces at the beginning of verses are replaced by non-breaking spaces. Maybe it would be good if someone could confirm in the bug request that colons are indeed used inside the poem tag. This will ease the patch acceptance and then you will be able to use colons inside poems with a clear conscience. Zaran (talk) 15:07, 25 September 2011 (UTC)

Cannot say that I have seen the use of colons for quite a while, there has been a more recent use of {{gap}} or simply adding spaces. — billinghurstsDrewth 16:13, 25 September 2011 (UTC)

Yes, the {{gap}} solution is quite nice, being independent of the parser behavior. Simply adding spaces is not a good solution in my opinion, because it does not allow to insert an exact number of em spaces (the basic space is different from the em space). Anyway, a bit of improvement in the generated code when using colons does not hurt. Zaran (talk) 16:42, 25 September 2011 (UTC)

I saw them (colons) used here recently, and it took all my strength (not really) to not do/say something! ;)

Use the print/export links at left to see how the following render in print/pdf preview... Keeping in mind you'll include everything above in the Scriptorium as well... Or just go to my sandbox, where I've transferred the info. Londonjackbooks (talk) 17:47, 25 September 2011 (UTC)

Non-breaking space: I don't think you should use an un-formatted non-breaking space because I'm pretty sure the width of non-breaking spaces is font/css dependent. Also, according to at least one site, not all browsers recognize multiple non-breaking spaces.[1].

Colon: Colons cause problems and are noted as having possible accessibility issues at mw:Help:Formatting. I've never seen them used here for main/page space formatting and they've been deprecated on de.ws though they do show up from time to time there. Additionally, a colon represents a TAB stop, not an em and at least on my browser (FF6 for Mac), colons appear to create 2em indentation per colon: User:Doug/Sandbox12. The only positive about them is that they are actually intended for indentation but as LJB shows, they don't work well in copy/paste.

Gap template: A standard (default) {{gap}} is a 2 em width non-breaking space. It is a good solution but has the problem that the template has different names on every project (we don't even use the same name en.wp uses, let alone other language ws projects).

Em-spaces: This needs clarification, I presume the point of the bugzilla is to make the software not collapse these within a poem wrapper, is that right? As you can see on my sandbox (linked above) they do currently collapse to a single space even within the poem wrapper. The value would be that em-spaces are standard HTML and could be used across subdomains. However, it should be noted that neither {{gap}} nor em-spaces are intended for indentation.--Doug.(talk•contribs) 20:50, 25 September 2011 (UTC)

I never "got" that bit that {{gap}} was '[not] intended for indentation' (I think the statement is noted on the template page for gap, right?)... What does it mean exactly? Intended for what, and by whom?? Is it a technical 'consideration'—if you know what I mean by that? Londonjackbooks (talk) 04:37, 26 September 2011 (UTC)

From template page: "Please note: This template is not intended to produce a formatting preference, such as indented paragraphs or double spacing after full stops (periods)."

I think it is referring to indented paragraphs for regular text (i.e., as a TAB, which we don't seem to use when writing papers anymore, although I don't know why??)... But poetry would to me seem to be an exception, as they are not used for that purpose... Londonjackbooks (talk) 04:44, 26 September 2011 (UTC)

In texts that are laid out with paragraph indentation, the unused space between the left margin and the first letter of each paragraph is not actually part of the text; it is an artefact of a stylistic layout decision that constrains where and how the text is placed upon the page. If one were to use {{gap}} to represent it textually, one might just as well use {{gap}} to represent the page margins and gutters.

Thank you! I get it now... The word "artefact" helped too, which brought to mind "man-made" and "man-manipulated"—i.e., unnatural (so to speak—as in your offering of: "not actually part of the text") Londonjackbooks (talk) 05:25, 26 September 2011 (UTC)

You're right! That food-for-thought was so good this morning I could almost 'taste' it! :) Londonjackbooks (talk) 12:07, 26 September 2011 (UTC)

I'm not saying not to use {{gap}}, I think it's the best solution (though if em spaces within poem wrappers would not collapse, they would work better cross domain or {{gap}} could be substituted, if one doesn't mind the ugliness of the page in edit mode).

The point about not intended for is simply an observation that these weren't designed for initial spacing, nothing more. Yes, that was certainly primarily a reference to first line indentation of paragraphs but it's also a note that these things are not designed for page layout, they are typographic elements designed to control spacing between other elements. Using {{gap}} to space poems without poem markers, as I have seen done with colons, would probably work, but would not be nice and might stop working later.

LJB, regarding your comment on tabs for paragraph indentation, I think we should use them; I find large amounts of block text are a pain to read and paragraphs are much easier to distinguish and flow much nicer when indented on the first line. But this isn't easy to do because of the way the wiki interprets the first paragraph differently from succeeding paragraphs, because of the way css works (or doesn't) in transclusion, and because of the negative effects of things already in the common.css. It would be nice if we could easily and neatly apply custom formatting to the mainspace for an individual work.--Doug.(talk•contribs) 06:52, 26 September 2011 (UTC)

I'm just old-fashioned that way... I'm still in the habit of double-spacing after a period (that's 'problematic' technically speaking here too, isn't it?)! I make fun of my husband for still double-clicking every 'blue' link! Hopeless lower-cases are we! :) Londonjackbooks (talk) 12:07, 26 September 2011 (UTC)

@Hesperian : i totally agree, the indentation of paragraphs is a mere artefact, and I think everyone agrees on the fact that {{gap}} must not be used for normal indentation : this indentation should be obtained, if needed, using proper css classes and not be part of the text. However, in poetry, the boundary between the actual text and its layout is less clear and verses indentation are often chose by the poet, hence they are part of the text. I think the {{gap}} template was initially made for this purpose.

@Doug and LondonJackBooks : I agree that at the moment, {{gap}} is the best solution for indentation in poetry. non-breaking spaces (&nbsp;) or simple spaces (which is the same because simple spaces at the beginning of the line are converted to non-breaking spaces in poetry) are not good because their width is font-dependent and is wanted is an em space.

I also agree that colons are really bad, because they do not pass the copy-paste test and because the generated html code his really ugly and not accessible. But the point of my patch is exactly this : replace colons by em-spaces (&emsp). This way, it will not be a problem anymore if people use colons instead of {{gap}}, and they will pass the copy/paste test. As Doug noted, &emsp; is standard html, and the colon solution will work across every subdomains.

To make it clear, if you type this :

This is a test
:To see how the use of colons
::Renders in print preview
:::Or in pdf preview
::::This is only a test.

The result before and after the patch will be :

Before

After

This is a testTo see how the use of colonsRenders in print previewOr in pdf previewThis is only a test.

This is a test
To see how the use of colons
Renders in print preview
Or in pdf preview
This is only a test.

Note how the ugly extra space between verses vanishes. Also note, that this will be transparent for the user, and that he will never actually see the &emsp; characters : the replacement of the colons will be made after he clicks on the "Save page" button. Zaran (talk) 09:12, 26 September 2011 (UTC)

Yes, line indentations in poems are intrinsic to the text and should be preserved. No, this isn't why {{gap}} was initially made; it was initially made to handle inline inter-word gaps; I know because I authored it; and personally, I approve its use for indenting poems.

My issue with your patch is that I loathe the <poem> tag. It is a dirty hack that doesn't play nicely with other tags like <noinclude> and <ref>, causes all sorts of odd problems when spanning page transclusions, and generally can't be trusted to behave itself in any but the most trivial situations. Also, last time I checked, the code that implements it was truly horrendous. I have been advocating moving away from the <poem> tag for years, so a patch that makes it look a wee bit nicer doesn't have my support. Hesperian 11:09, 26 September 2011 (UTC)

No, I don't want to submit a bug report. I think <poem> should be deprecated, not fixed. Hesperian 04:03, 28 September 2011 (UTC)

Glad to hear that progress has been made. You're certainly entitled to your opinion, but I don't think spreading misinformation about other people's work is the best way to express it, especially if your unwilling to use the proper channels. The code has been reviewed by a lot of people, none of whom have found the vague quality problems you claim. It works fine with ref tags. Spanning pages can be challenging, although the problem you are seeing is caused by the malformed wiki syntax in the example, not by the transclusion. -Steve Sanbeg (talk) 01:46, 29 September 2011 (UTC)

I want to know why you need to <noinclude> the poem, two <poem>s butt up against each other (terminate one page and start the next) , they work well enough with regard to formatting, and I find that if I use {{subst:#tag:poem|Insert text here}} that it works well enough for pretty much all things that need to be subst and expanded, though I know that others may have issues getting it to work. Personally I have more issues with tag misbehaviour of <ref> — billinghurstsDrewth 12:32, 29 September 2011 (UTC)

Can someone present a real example (rather than the above hypotheticals) where it is necessary to user overlapping wrappers? I realize that could be the result if templates were used improperly but templates are not standard and need to be used with caution for the html/css they spit out. Where would you ever use <noinclude><poem></noinclude> and why? -- Now that I look further, I guess as Billinghurst seems to get, you were implying putting tags in the header and footer, but again, I don't understand why you'd want to do that.

@Billinghurst, I've never had any trouble with <poem> or <ref> in these contexts. Can you point to examples?

@Zaran, the issue though with having colons convert to em-spaces is that a series of em-spaces will collapse. {{gap}} solves this by setting a size for the non-breaking spaces, though I don't care for using templates like that as they lack portability. It is better than de:Vorlage:idt because that template doesn't set a fixed width and that can create strange results as the widths aren't necessarily even the same on a single page. Possibly within a poem all spaces should have a fixed/default size set in css - or at least all spaces that aren't ordinary breaking-spaces.

A larger problem, I think, is the amount of work involved in formatting a page of poetry in general. In the end, one can still never be sure that the title of a poem will be anywhere near the right place unless the margins are tightened up and then poem lines may wrap strangely in some browsers/screen sizes. {{block center}} is useful for solving this but I'm not comfortable with all the layers of code, some of which appears to be deprecated, though I can't tell for sure because I'm not tracking some of it. More templates and more css in the common.css just makes things harder to tweak on the user level and less suitable for sharing across subdomains.--Doug.(talk•contribs) 07:47, 17 October 2011 (UTC)

@Doug. It comes down to the issue that with wikis one needs to use {{subst:#tag:ref|}} rather than <ref></ref> if you want anything to happen inside a tag, eg. to substitute a template {{subst:a^}}, and if you try to Help:Pipe trick for an author [[Author:Charles Dickens|]] or [[w:Charles Dickens|]] they fail miserably. I have been using subst:#tags (ref & poem) for a while as it is gets around most of the limitations, but not all. — billinghurstsDrewth 11:14, 17 October 2011 (UTC)

I'm still not following, you seem to be saying you can't do this: Page:Complete works of Nietzsche vol 10.djvu/371 or it will fail. Though it seems to be working just fine, even in transclusion (see In the South), and that includes both <ref> and a piped author link within <poem>. Or are you saying that it only causes a problem if you try to subst a template inside? I'm not sure that I've ever had cause to do that, can you provide an example of where that would be necessary?--Doug.(talk•contribs) 11:38, 17 October 2011 (UTC)

Is there a correct way to link that works on both djvu pages and within the related main document.[edit]

I'm working on a chapter of a mathematics text [2]. I've used relative links to formulas within this chapter which works fine when viewed as a full chapter.

However when I match and split to the djvu pages [3] some links are broken in the resulting djuv pages since the target(anchor) for some relative links are now on different djvu pages to the anchors/targets of those links.

My question is am I doing something wrong with the way I'm specifying the links/anchors? If not what is the preference for when the links should work; when displayed as a full chapter, or when displayed as djvu pages?

Cheers, Paul

The important thing is that the links work when transcluded into the main namespace (which they appear to do). It isn't necessary for the links to work in the Page namespace as that's just a workspace to enable proofreading.

I do not know of an existing technical solution to allow a link to work in both namespaces but I could create a template for this if you want it. It would give you more work to do but you would be able to enter two targets for the wikilink and the software would pick the right one for the namespace. - AdamBMorgan (talk) 16:12, 29 September 2011 (UTC)

We do have both {{namespace link}} and {{DJVU page link}} that do relative linking tasks. You can even use relative links (..) and I have done so on occasions, though I don't really use them much any more, and as ABM says, our focus is having working links within the main ns (presentation space), rather than the work space. — billinghurstsDrewth 23:25, 29 September 2011 (UTC)

I would create based on the 1904 version, and include a note about the 1916 republish with the same name. This follows in logic with the way books are handled when the same book is republished with a different name. JeepdaySock (talk) 15:47, 29 September 2011 (UTC)

Create a single versions page to cover all versions of the work, regardless of title. Each title should be either a redirect to the versions page, or a disambiguation page with an entry for the versions page. Hesperian 23:29, 29 September 2011 (UTC)

Thanks both... So the Versions page title should then be... "As from Afar" (first instance)? or "Nature" (what she eventually decided she wanted it to be called)? or something crazy like the first line? :) Londonjackbooks (talk) 00:12, 30 September 2011 (UTC)

"Nature" is ambiguous, and so is "Nature (Coates)", so "As from Afar" is probably better on purely pragmatic grounds. Hesperian 00:48, 30 September 2011 (UTC)

Yup... that reminds me, she has another poem entitled "Nature" in the 1904 collection (which, by the way, is entitled "Natura Benigna" in the 1916 collection!)... Gotta love it! :) Thanks, Londonjackbooks (talk) 01:03, 30 September 2011 (UTC)

{{block center|{{drop initial|I}} {{sc|weave}} the beginning, I fashion the end;<br />
Life is my fellow, and Death is my friend...}}

I'm thinking that when you copy/paste, you should probably get "I weave the beginning..." (sc) instead of "I WEAVE the beginning..." (smaller) What do you think?? Londonjackbooks (talk) 14:21, 30 September 2011 (UTC)

That is how I usually approach it. Similarly, I will often use {{uc}} when I am transcribing newspaper headlines. — billinghurstsDrewth 15:04, 30 September 2011 (UTC)

Hmmm... Now begs the question, what would/could you do for case situations like here, where you might want the "THE" to copy/paste as "The" (without shrinking the "HE")? Londonjackbooks (talk) 15:41, 30 September 2011 (UTC)

{{dropinitial|T}}{{uc|he}}. I tend to use {{uc}} in all instances where the use of uppercase is a formatting choice, rather than semantic.--T. Mazzei (talk) 23:26, 30 September 2011 (UTC)

Where I can be bothered, that is how I have handled it, though for words starting chapters it is not something that I have done. I have done it in situations where I would prefer that the search engine not return a wad of uppercase text in a search return, rather than my being concerned about an issue around the cut and paste, eg. I would rather see "Death of Lord Moulton", rather than DEATH OF LORD MOULTON. Do note that using {{UC|text example}}text example is better than using {{UC:text example}} TEXT EXAMPLE [paste each to see the difference]. — billinghurstsDrewth 00:02, 1 October 2011 (UTC)

I guess what I'm trying to ask is, can I format the following:

THROUGH the rushes by the river

so that when I copy the text above, it will render as below upon pasting:

Through the rushes by the river

It's not really an imperative for me to be able to do this... the thought just crossed my mind to see if there was a 'solution' or not. Billinghurst, I copied/pasted your examples, but got the same output for both. I may not have understood your directions(?) Sorry if I keep beating a dead horse when it's a mere curiosity on my part... Londonjackbooks (talk) 02:17, 1 October 2011 (UTC)

Using {{dropinitial}} and {{uc}} as per above will do what you are asking, other than {{dropinitial}} causes an unwanted carriage return (I thought that had been fixed).--T. Mazzei (talk) 03:01, 1 October 2011 (UTC)

Not sure why you're not seeing the difference. Perhaps if you're pasting in an advanced word processor like MS Word, it is applying the character formatting from the source? (I don't have so I can't test). Try pasting in a simple word processor like Notepad.--T. Mazzei (talk) 03:11, 1 October 2011 (UTC)

I'll give it a try in a bit, thank you... Unexpected break from the computer... Londonjackbooks (talk) 03:13, 1 October 2011 (UTC)

Back for now... I'm not pasting in Word or elsewhere, but right here in edit mode. When I copy

{{dropinitial|T}}{{uc|hrough}} the rushes by the river below:

Through the rushes by the river,

—it pastes as "THROUGH the rushes by the river" (the text you just read was the result of the paste)... I would want it to render as "Through the rushes by the river". I feel like I'm in math class all over again not being able to explain to the teacher what it is that I don't understand (or something like that!)! :) I don't want to keep wasting you all's time, but I appreciate your being patient with me—even when trivial! Londonjackbooks (talk) 05:08, 1 October 2011 (UTC)

Interesting. What browser are you using? Also, could you try pasting to Notepad (assuming you're on a Windows machine) so we are comparing apples to apples? When I copy your text from Opera to Notepad, I get:

T
hrough the rushes by the river,

though I'm sure that carriage return wasn't there a year or two ago, but when I copy from IE to Notepad, I get

Yup... I still get CAPS pasting into Notepad... And I use Google Chrome & have a 'Windows machine'... A very old desktop, however...threatening to crash any day now! Got away from IE a few months ago, as it took close to a minute to open up a page in edit mode! :P Any other troubleshooting suggestions? I won't get them till the AM, however... It is now late! Thanks for all! Londonjackbooks (talk) 06:12, 1 October 2011 (UTC)

Tested with an old version of Chrome on my computer and the result was

THROUGH the rushes by the river

So the long and the short of it is that this is a browser issue. Am I the only one concerned that three different browsers gave three different outcomes? And even more disturbing, only IE got it right! T. Mazzei (talk) 06:23, 1 October 2011 (UTC)

I always preferred how things looked aesthetically using IE... It just never functioned very well for me. At least I know that there's a way to format what it is I'd like to do... For who(m?)ever it may work for! :) Londonjackbooks (talk) 10:59, 1 October 2011 (UTC)

AS a note, my first thought to have coded it would have been {{uc|{{dropinitial|T}}hrough}}, as I try to keep words together as much as possible. To also note that the way that drop initial codes, it can get ugly for a copy and paste. — billinghurstsDrewth 06:34, 1 October 2011 (UTC)

What do you suggest about using drop-initial... From "playing", I think I at least noted that setting the size of the drop-initial to 1.5em (but no greater) at least doesn't affect text wrapping as does the 'default' size... How close do we really need the drop-initial to be to the original text? What's worth it, what's not? Londonjackbooks (talk) 10:59, 1 October 2011 (UTC)

Looking for opinions. Using this page as a reference,—How 'concerned' should I be with keeping alignment as it is in the original. If the original renders the quotation mark aligned left, with the remaining poetry text indented one space, does it really matter if I follow suit (which would require that I add a space to each line of poetry not "wrapped" in a quotation)?? Or can I just align-left all of the text? I only ask, because some poems in the collection are rendered that way, but others are not... And I don't know enough about such things to know why it is done both ways... Thanks! Londonjackbooks (talk) 21:44, 2 October 2011 (UTC)

I wouldn't bother being concerned, personally. I think the typesetter was just trying to get the initial letters aligned, ignoring punctuation; although I don't know how standard that is in poetical typesetting. - AdamBMorgan (talk) 22:02, 2 October 2011 (UTC)

It's called w:Hanging punctuation and is a standard typesetting practice for poetry and pull-quotes. The punctuation is actually pulled back into the left margin. To do this use {{Left margin}} with a negative em value—a double quote mark is about 0.5 em in width. Personally, I find punctuation that isn't hung to be unsightly and it disturbs the flow of the text for me. As a result, I always try to hang it where practical. Beeswaxcandle (talk) 06:35, 3 October 2011 (UTC)

Actually, Beeswaxcandle is right, looking at their link to w:Hanging punctuation. When I originally used the <poem> tag for Coates' poems, it was easily remedied with a mere extra click of the space-bar. But now that I'm reformatting her poetry using breaks and {{gap}}, I had to rethink what to do. Londonjackbooks (talk) 13:55, 3 October 2011 (UTC) Revised: Oh... I didn't read thoroughly enough above, I guess... I'll look at both hanging indent and left margin to see where you're both coming from... Londonjackbooks (talk) 13:59, 3 October 2011 (UTC)

"All help were vain. Stay!—let me see your face!"
So plead the look; then, with a poignant grace,
Her form bent toward me, her white arms apart,
She gave me the veiled secret of her heart.

Both of them are problematic, actually—at least for poetry... While {{hanging indent}} probably comes closest to the desired effect, both templates render an undesirable line space that throws off the formatting of the poem (two instances of undesired line spaces in left margin; one with hanging indent), and hanging indent, I think, is mainly intended for lines of prose text... not several lines of poetry...?Londonjackbooks (talk) 14:13, 3 October 2011 (UTC)

My view is that the problem is to keep aligned the first letter after the quotation mark with the first letter of the following lines. Templates you have mentioned address the whole line or groups of lines but do not take care of the alignement of the inner part of the first line with the other lines. Do not know if I succeeded in explaining myself :-( --Mpaa (talk) 09:06, 3 October 2011 (UTC)

Yes, {{Hanging indent}} is a hack that approximates the desired layout rather than getting to the heart of the matter. I believe this advice was offered because CSS does not offer a better solution. It could be done with tables, but that is widely regarded as distasteful. Hesperian 09:15, 3 October 2011 (UTC)

Tables was the same conclusion I have drawn in the past thinking about this. But as you say, it is awful, so I just used a nbsp at the beginning of the following lines to align with the first one. I have seen the discussion on nbsp formatting and alignement but could not come with something better. --Mpaa (talk) 09:33, 3 October 2011 (UTC)

I was thinking single non-breaking spaces as well, but a daunting task for some of her more 'challenging' and longer pieces! But probably the way to go barring any other 'remedies'... Londonjackbooks (talk) 13:55, 3 October 2011 (UTC)

How about using relative positioning to offset the line left, like so:

You, who alone have loved me, could not go!"All help were vain. Stay!—let me see your face!"
So plead the look; then, with a poignant grace,
Her form bent toward me, her white arms apart,
She gave me the veiled secret of her heart.

It isn't exact like a table would be, but it's relatively clean T. Mazzei (talk) 15:43, 3 October 2011 (UTC)

(looking in edit mode) That would work (as far as my eyes can see, anyway)! It's simple, and causes no line breaking. Londonjackbooks (talk) 15:54, 3 October 2011 (UTC)

Looks good. Just one question about the amount of shift. Is that trial and error or is there a reason behind it? --Mpaa (talk) 16:14, 3 October 2011 (UTC)

Looking above at the hi/left-margin examples, (where 0.5em was used), it was "off" (tad bit too much indentation)—so I assume that was the adjustment. I may be wrong... Londonjackbooks (talk) 17:21, 3 October 2011 (UTC)

Yes, that was trial and error. I defaulted the template to 0.5em, then realized it was slightly "off". That number will also change depending on the font, but likely not by much. A possibly better method would be to use absolute positioning, but that might be getting a little complicated for what you want to do. The code is:

<div style="position:relative; margin:0 auto; width:25em;"><span style="font-size:83%">
You, who alone have loved me, ''could'' not go!<br />
<span style="position:absolute; width:1em; left:-1em; text-align:right;">"</span>All help were vain. Stay!—let me see your face!"<br />
So plead the look; then, with a poignant grace,<br />
Her form bent toward me, her white arms apart,<br />
She gave me the veiled secret of her heart.
</span></div>

You, who alone have loved me, could not go!"All help were vain. Stay!—let me see your face!"
So plead the look; then, with a poignant grace,
Her form bent toward me, her white arms apart,
She gave me the veiled secret of her heart.

Which could be templatized something to like:

{{center text|25em|{{smaller|
You, who alone have loved me, ''could'' not go!<br />
{{hanging punctuation|"}}All help were vain. Stay!—let me see your face!"<br />
So plead the look; then, with a poignant grace,<br />
Her form bent toward me, her white arms apart,<br />
She gave me the veiled secret of her heart.
}}}}

which I could set up for you. The advantages of this rather than relative positioning being you don't have to guestimate the left alignment of the text, it will always be properly aligned. The disadvantages are that you have to manually set the width of the main body of text which may cause unwanted wrapping if a line is too long, and will cause the main body to be slightly off-centered, and that it is two templates instead of one. Also, as written you can't have punctuation longer than one em, but that's easily corrected if needed. T. Mazzei (talk) 00:15, 4 October 2011 (UTC)

I like the simplicity of your original shift-left idea... Text wrapping with poetry (where drop-initial use is concerned in particular, if not exclusively) has been a pain in the neck as it is—and while there may be a 'perfect' solution somewhere out there that satisfies every browser and every pdf/print/copy/paste/formatting, etc. situation, I won't hold my breath for that solution to arrive! Shift-left can be easily tweaked for font size considerations—not so easily were a template to be made (I would imagine?)... I'd go with User-friendly! Londonjackbooks (talk) 02:35, 4 October 2011 (UTC)

font size is irrelevant, it's font style which may cause problems. For example, everything is lined up properly using the relative positioning when viewing the work in layout 1 (sans-serif font), but in layout 2 (serif font) the justification might be off again. That would not happen using absolute positioning, but then again it may not be an issue. Test a couple of pages and see if {{shift left}} works OK for your purposes. If so then good, if not we could try the other method. T. Mazzei (talk) 03:44, 4 October 2011 (UTC)

Do consider the use of &ensp; and &emsp; for those occasions when you want quick measured spacing that goes with relevant font-size. I generally find that a single quote is the same width as &nbsp;, a double quote as an &ensp; — billinghurstsDrewth 11:43, 4 October 2011 (UTC)

I'm not familiar with &ensp; and &emsp;, but will set about getting acquainted right now... Thanks! Londonjackbooks (talk) 12:54, 4 October 2011 (UTC)

Ok... I read here that "The character entities &ensp; and &emsp; denote an en space and an em space respectively, where an en space is half the point size and an em space is equal to the point size of the current font." So if I had a poem, I could either use T. Mazzei's shift-left, or else (ignore the 'code' part):

You, who alone have loved me, could not go!
"All help were vain. Stay!—let me see your face!"
So plead the look; then, with a poignant grace,
Her form bent toward me, her white arms apart,
She gave me the veiled secret of her heart.

Or something like that...? For long poems, I think the shift-left is less labor-intensive!? Londonjackbooks (talk) 14:08, 4 October 2011 (UTC)

I'm new here. As I was looking around, I came to this page, and expected to find a way to cite this book in en-wiki (i.e. fill out a {{Cite book}} template for me). But it's not there. Surely someone has wanted this before. What am I missing? --99of9 (talk) 03:08, 30 September 2011 (UTC)

You are missing nothing and that it should be there. and you would be very right to knock that against our heads (vigorously) ... there was a discussion a while back when there was change going on with the templates, and I think that it has dropped off our agenda. To note for the specific work that we wouldn't reference the Index: page itself, instead referencing the work in the main namespace, and I have yet to transclude the early chapters of that work. — billinghurstsDrewth 04:56, 30 September 2011 (UTC)

Though to note that we still don't yet have the metadata capability to properly fill out the fields in the template. — billinghurstsDrewth 05:11, 30 September 2011 (UTC)

There is enough in the average header for a very basic citation (title, author and year). It would output something on the lines of this: {{Cite wikisource| title={{{title|}}}| author={{{author|}}}| year={{{year|}}} }}. I'm not sure how we could add this, however. I assume something like Commons' "Use this file" link that appears on its file pages but I don't know how they do it (I think it's javascript but that's all) and I don't know how to accomplish something similar (The best I could do offhand would be adding copyable text to the header). - AdamBMorgan (talk) 21:58, 2 October 2011 (UTC)

I've looked at the documentation but I don't see any way for Special:Cite to pull appropriate data from the page (even if we had metadata available). The magic words are just the generic PAGENAME and CURRENTTIME style. It seems to cite the Wikisource page rather than the work on that page. A different, if potentially confusing, alternative would be to add something to the {{header}} itself, which would be able to pick up the existing parameters. Commons uses javascript for something similar, but I don't know javascript well enough to tell if it would work here or not. - AdamBMorgan (talk) 12:33, 4 October 2011 (UTC)

I was wondering if anyone had access to some sort of searchable database for issues of The Athenaeum (London) for dates between the 1880's and 1920's. I know Florence Earle Coates had some of her works published in the magazine, and I would love to get access to specifics: poem title/volume/no./month/year/page number/images!, etc. There are references to some of these works in other magazines, but they do not state specific Athenaeum publication info... A big missing piece in my searching... Thanks, Londonjackbooks (talk) 03:03, 4 October 2011 (UTC)

Here's "Le Grande Salut." I found the reference to "October," but if I'm looking at it correctly it seems to be in an advertisement for the October issue of Lippincott's. Unfortunately, the only database of The Athenaeum only covers reviews and scientific materials, and Google Books doesn't share scans of The Athenaeum later than ~1910. Prosody (talk) 23:03, 5 October 2011 (UTC)

I've mentioned this briefly further up but it may have been lost in the older threads. I've imported and merged three templates (one from Wikipedia, two from Commons) to create {{Authority control}}. It's still experimental but it should provide a range of appropriate links to library catalogues and databases for both authors and texts (and maybe subjects). I still have to amend the LCCN code (it was inherited from Wikipedia and doesn't seem to work for the full range of call numbers) and a few other instances where it tries to look up people instead of texts (two of the original templates were people-specific). Nevertheless, I've successfully tested it on three authors and two texts so far and I think this will work. If anyone wants to have a look at, test or tweak the template, go ahead. - AdamBMorgan (talk) 13:02, 4 October 2011 (UTC)

I'm not really familiar with non-classical latin, but I gave it a shot:

It is then clear, that in all things Nature is at work in a wonderous way, and not incidentally, but it anticipates provides all things from a will; and men, to whom God has given this gift, such that they might find the first Cause of things, share in that first Nature, and the Nature which establishes these things is not of a different sort, from the mind of those who are fully able to comprehend the cause of things, why they are so.

The file size limit technical limitation of the Wikimedia projects is well known and causes a major obstacle for uploading complete content in its full glory. I believe openly available primary sources are the way forward, but it would seem as though some authors have taken the approach of downgrading the quality of the source, to the point of being almost indiscernible gibberish, to meet the current 100MB limit. I believe these choices for inferior quality alternatives are poor decisions, and will have long lasting negative effects on Wikisource. I, for one, intend on upload the California Statutes, and I intend on splitting the files into multiple parts.

As this seems to be the best place for such advice (it seems to be the main help page mentioning "100MB"), I propose that a section be added on the subject, including the various methods editors have used to work around the technical limitation, and the pros and cons of such choices. Given the relatively intensive nature of the work involved for these things, I would like to benefits from other editors' experiences, and I would like other editors to benefit from my experience, before such items are uploaded. This will lessen the need for items to be re-uploaded en masse in the future should future editors find other editors' decisions substandard.

Addendum. This problem is also affecting the insertion of the {{smallrefs}} in the footer.— Ineuw talk 00:14, 7 October 2011 (UTC)

With the upgrade to 1.18 there seems to be issues with toolbars placing in the main body rather than in the header/footer space, and I have addressed this with Phe (talk • contribs) and he is looking through components of the code before we fully blame it on the 1.18 upgrade. [Qualify this that I have identified that it is an issue with monobook skin, and the old toolbar, I have not checked in other skins or the new toolbar].

If you can use the header/footer components of the Index: page to (pre)fill new pages, then that seems to be working fine, similarly, I am finding that Pathoschild's regex tool is still working okay, so if your .js is failing, it probably needs tweaking to get it to work under the current schema, though keep the older version (reversion copy) in case we do get a ready fix in place. Do note that you can still highlight and drag and drop (if your browser allows it). — billinghurstsDrewth 03:18, 7 October 2011 (UTC)

Addendum. If you turn on your regex gadget, you/we can put some of these tools into that sidebar capacity, rather than toolbar. — billinghurstsDrewth 03:20, 7 October 2011 (UTC)

Got it. I am using Vectra but it may not make a difference. Will try the regex tool. Thanks.— Ineuw talk 03:31, 7 October 2011 (UTC)

With the software upgrade, another issue is that there are two to three newlines (Carriage returns) precede the <reference /> in the footer of the Page: ns. — Ineuw talk 03:21, 8 October 2011 (UTC)

Not so sure it is a result of the upgrade - I believe its a result of changes made in an attempt to fix the 'addititional <noinclude/>s between the default Page: namespace header & footer defaults causes text content to be clipped under some versions of Internet Explorer upon save' [paraphrased] Bugzilla prior to the upgrade. I'm not 100% sure but the so-called "fix" was based upon a workaround forcing a read-ahead by browsers or something to that effect. (I don't think it worked btw but my bet is that those additional returns are a result of that fix and not a part of the upgrade). -- George Orwell III (talk) 03:40, 8 October 2011 (UTC)

Just thought to bring it to attention, and don't mind as long as it doesn't show up in the main namespace transclusion of the footer. . . . and now for something different (see next post) :) — Ineuw talk 04:18, 8 October 2011 (UTC)

It seems that I am making up for the lack of posting. The Wikisource:WikiProject Popular Science Monthly/Authors A to D and the subsequent three Author tables are defined as "prettytable sortable". Although they are still pretty, they are no longer sortable. Am I doing something wrong? — Ineuw talk 04:23, 8 October 2011 (UTC)

Actually, the ascending/descending arrow-heads are gone yet sorting still works for me - you just have to zero-in on where the arrow-heads are typically found in order to toggle it. -- George Orwell III (talk) 09:46, 8 October 2011 (UTC)

Good enough for me. I couldn't get it to sort, but can certainly wait for the rollout. Thanks.— Ineuw talk 15:28, 8 October 2011 (UTC)

Not that I don't already have my plate full, but I was wondering if anyone could upload a version of the above text from Archive.org for me? I don't know enough about the work to know/request which edition to choose from (there are several), so I'll leave that to your discretion. Thanks ahead of time, Londonjackbooks (talk) 12:23, 8 October 2011 (UTC)

Piggy-backing on my thread here, can someone please look over this page to make sure I reformatted it correctly and didn't accidentally remove any lettering/punctuation, etc? My eyes are bugging out on me! Thanks much, Londonjackbooks (talk) 18:16, 14 October 2011 (UTC)

Strictly regarding the PSM project, I am requesting the community's agreement to grant a variance to the rule of not posting incomplete articles in the main namespace.

There are two concerns: The first deals with the accumulated volume of work if it's not attended to after proofreading the article title pages of each volume since a volume contains approximately 120 articles. The second issue is of the greatest concern for my primary requirement which is the assignment of categories. This can only be done properly in the main namespace after perusing the article on a single page.

Numerous ancillary contributions are made after the completion of each volume which also depend on the main namespace display, but the lack of categorization is what most seriously affects my efforts. Looking forward to comments by all interested parties. — Ineuw talk 03:54, 10 October 2011 (UTC)

What rule are you talking about? I am unaware of any such rule. There is a general preference and certain editors are stricter about this than others but many works are set up in mainspace (even newly set up now) without being complete. If you are talking about complete articles within a work, I don't believe even the most conservative editors here would object. If you're talking about setting up articles where the article is not completed in pagespace, there is no rule so there is no need for any exception. Just do what is reasonable.--Doug.(talk•contribs) 04:06, 10 October 2011 (UTC)

Ineuw is talking about posting mainspace articles composed mostly of unproofed OCR text. His previous practice of proofing only the title page before transcluding articles into mainspace was challenged. He is seeking community approval to continue that practice. Hesperian 05:08, 10 October 2011 (UTC)

(ec*2)OH! In that case, I'd need further explanation of the reason. I don't understand why anyone would want to do that let alone why we'd want to allow it. But that's primarily because I don't understand what Ineuw sees as the problem.--Doug.(talk•contribs) 05:22, 10 October 2011 (UTC)

I don't understand what the problem is. It seems like Ineuw want to import PD works to WS, and set up the title page, then Ineew will move on to the next to import and set up while allow others to complete the proof reading works imported, is that correct? JeepdaySock (talk) 10:41, 10 October 2011 (UTC)

Yes, but as I understand it, Ineuw wants to transclude the entire work, not just the title page, even though only the title page is set up, so that many pages of unproofed text are transcluded into the mainspace. If I follow now, Ineuw will do this merely for categorization. I don't understand the value in this. I'm open to the idea but I don't track Ineuw's purpose.—unsigned comment byDoug (talk) 11:00, 10 October 2011.

The realization gained from the above discussion indicates that few of the community are aware of what I was doing and why I posted this request. Henceforth, I will gladly respond to any and all questions.

There are bits of info relating to my PSM proofreading strategy posted over the past two years on various talk pages, and as User:Hesperian so aptly put it, my approach was challenged by User:Cygnis insignis on several occasions. The two most recent posts which best summarize the issue are found in this post by Cygnis insignis and followed by my reply several weeks later here. — Ineuw talk 17:30, 10 October 2011 (UTC)

I too am open to the idea since the current winds are blowing to accomodate individuals who make sustained contributions rather than curtial or bring them into line with the so-called community vision.

For starters - I think a banner similar to {{Incomplete}} should be present on any transcluded works where Proofreading has not been validated. We had buttons that did once that but they were removed :-(

Would you be willing to modify your work-flow to include something like that? Such a banner would make it absolutely clear to the potential readers out there that the article is not "up to par" just yet. Of course, whether or not we benefit from their additional input at that point is something you should also consider. -- George Orwell III (talk) 19:01, 10 October 2011 (UTC)

Is it possible (or beneficial) to change the common.js to only translcude a page which has achieved proofread status? That way, we could transclude the whole index off the bat, and supress the uncorrected OCR (red). Or, if an uncorrected OCR page is translcuded, it automatically displays the banner at the top of the work? - Theornamentalist (talk) 19:28, 10 October 2011 (UTC)

I'm not sure how that would handle works where the pages are proofread out of sequence and sometimes a page is problematic for a very long time and yet may be suitable for use in mainspace. The banner automatically displayed is a nice idea. It would be really sweet if the status of pages could be indicated next to the page numbers.--Doug.(talk•contribs) 20:23, 10 October 2011 (UTC)

I'd focus on just an auto-status banner. The 'colors per page number' only serves those who are familar with the Proofreading process and I don't believe the potential reader who comes across such an "unfinished" work is going to understand all that jazz. -- George Orwell III (talk) 21:33, 10 October 2011 (UTC)

I would agree that the proofread ribbon is under developed, and I wonder whether simple hover text might say something that could be implemented,eg. a green/amber/red ribbon has meta text that reads … 40 pages transcluded: 10 validated, 20 proofread, 10 not proofread, 0 problematic, 0 without text. — billinghurstsDrewth 04:35, 11 October 2011 (UTC)

I have created {{transcluded OCR errors}}, in the same vein as {{incomplete}}, to mark out pages where unproofread text is being transcluded to the mainspace for a reason. You can specify a particular page, and the mainspace page will be categorised into the hidden Category:Mainspace pages with transcluded OCR errors so that we can see what is using it and if it is being misused. Ineuw, if you want to give me a quick run-down of the pages which this applies to, I'd be happy to bot it in for you (assuming others feel such a banner is a good idea). Cheers, Inductiveload—talk/contribs 22:51, 13 October 2011 (UTC)

"It is transcluded into the main namespace in this unfinished state to aid the organisation and accessibility of this work." How it aids the organisation is a mystery known only to the creator, increasing the accessibility is one of the most undesirable aspects of this proposal. CYGNIS INSIGNIS 23:40, 13 October 2011 (UTC)

re the edit summary "then change it, that's what wikis are for", wikis are for systematically going about things the wrong way, and hoping others will fix it? I'll do my best, but this template, and similar ones that already existed, shouldn't even need to be created. CYGNIS INSIGNIS 23:53, 13 October 2011 (UTC)

I see what you're doing now I think. The conversation you reference suggests relatively fast work. How long does an unproofread page generally stay up? Assuming it isn't problematic for images or drawings, etc.

Don't mean to speak for Ineuw here but as one who has gleamed project ideas from PSM/DNB over the months, I have some limited insight into the work flow there. I'd say the PSM process is more methodical than expedient. Everything does get addressed but it is time consuming. Sometimes a well intentioned passerby tries to help out by adding things that aren't exactly ready for prime time so Ineuw has to pause the works already in progress to address those instances in order to try and bring the User & article closer to the overall standards of the project. This, of course, makes for longer periods where works are still in a state of flux in the mainspace. I find this just fine but obviously others just cannot stand any mainspace works in any sort of state of flux no matter the rationale at the core. -- George Orwell III (talk) 21:33, 10 October 2011 (UTC)

Could this be done in project space? I'm not saying it has to be, I'm just asking if that would give the same result from the editor side.

Generally, I still hold that there is no rule and Ineuw should be encouraged to get these works to final in the most expedient (for him) way possible. Though some sort of warning to any end user who comes on the page knows that it may contain errors and stray characters would be a good thing.--Doug.(talk•contribs) 20:23, 10 October 2011 (UTC)

A project space might be a solution though I wouldn't want to double Inuew's workload in the process. -- George Orwell III (talk) 21:33, 10 October 2011 (UTC)

I am still not seeing why we should consider un-proof read works a problem, by Ineuw or anyone. I can see where GO3's idea of a template on items that have not been finished would be good, regardless of who is primary contributor. First thing that comes to mind is that every document here requires at least 2 editors to proof read it, and you can't do that if the work is hidden some place. Second thing that comes to mind is Personal Recollections of Joan of Arc, it was in the main space in less then optimal shape, I came along and adopted it, and now it finished. The incompleteness of Joan is what made me a contributor as WS.

I'm under the impression the problem is when within a bulk-transclusion of many pages, the varying degrees of OCR'd text quality per page can become an issue in the mainspace regardless. I've always found this logic a bit odd. If we are cattle-driven toward using DjVu's for proofreading (primarily prefered over PDFs) then the uploader should be considering the OCR'd text layer's quality before making an Index where there is nothing but chicken scratch for layer content. If the consensus is that text layer be damned as long we have page images to painstakingly create text content from manually - replacing the chicken scratch if anything is there at all - then an effort should made to standardize all these auto -population and -text correcting scripts I see floating around so all can use them and not just those few who make it part of the User profile's code. I'm beginning to feel this unbalanced approach concerning accessibility and capability is becoming an increasing and derisive divide among not only the "regular" contributors but to any possible newcomers yet to land on en.WS. -- George Orwell III (talk) 00:19, 11 October 2011 (UTC)

So what is the absolute worst that can happen? someone on Google sees a less then perfect version of a 150 year old magazine article, so what... Project Gutenberg tries to only publish finished works, and I have yet to see a perfect proofread from anything they publish, nor have I figured out how one might go about fixing it there. We are not them, her we have lots of unfinished work that we welcome anyone to proofread. So why are we discussing putting un-proofread works as a problem? They are why we are here, this is a community working on community projects, not a bunch of individuals who happen to share a server to publish their pet projects. Jeepday(talk) 23:32, 10 October 2011 (UTC)

I don't know that there is a problem. The same editor who challenged the work of Ineuw has summarily deleted other incomplete mainspace works, including my own projects that were even less incomplete, which makes be both cautious and biased (in opposing directions). The further this discussion has clarified what happened here the more annoyed I am that non-policies have been imposed upon an experienced and productive editor by a minority of the community - apparently a single editor. I agree that Ineuw should resume work in whatever way he finds best and that no restriction exists and no permission is necessary. I also agree that unfinished mainspace works are a fact of who we are and we should work to proofread the pages but that doesn't mean works can't go into mainspace before they are 100%; if they could the status bar at the top would be of no meaning to anyone, even us.--Doug.(talk•contribs) 10:05, 11 October 2011 (UTC)

I don't think that we actually have any such rule, and if someone can point to it, then that would be both interesting and useful, it definitely is not in Wikisource:Deletion policy. I know that we have a strong preference that users don't come and upload and transclude a large number of unproofread pages and depart; and especially not drop a lot of OCR'd text that is in a poor state. Our principle has always to present a quality proofread text to a user, and to indicate its stage of proofreading, and that should always be both the aim and the preference.

To Ineuw's request, I would think that if there was both a reasoned argument and a purpose to adding the unproofread pages, eg. subpages are being created that are proofread, etc., then that would seem to be both reasonable and practicable. Ineuw is an experience contributor to the project, and has been working solidly on PSM, and if they believe that there is good reason for doing something with regard to the project, then the power to their arm to do it. To any work that we add, especially where it has missing subpages, we should be labelling the top layer of the work with {{incomplete}}, and then let the coloured proofread status ribbon, explain from there on. — billinghurstsDrewth 04:30, 11 October 2011 (UTC)

I agree with Billinghurst's succinct conclusions. I think Ineuw should go back to work and we should close this thread.--Doug.(talk•contribs) 10:05, 11 October 2011 (UTC)

Concur, "Ineuw should go back to work and we should close this" JeepdaySock (talk) 10:55, 11 October 2011 (UTC)

I strongly agree with the first paragraph in billinghurst's last comment. The second contains two "ifs", read it again, then read the position stated after Hesperian clarified what was being proposed: "OH! In that case, I'd need further explanation of the reason. I don't understand why anyone would want to do that let alone why we'd want to allow it....--Doug. 05:22, 10 October 2011" The only 'reason' given is that I 'challenged' it, then there was a volte-face! The 'reason' is that this furthers the political agenda of those who have adopted an entrenched position, who gain satisfaction from "civil" edit warring, from politicking, pursuing vendettas, promoting others to admin, and themselves to bureaucrats (see, for example,la:Vicifons:Magistratus, and how this "lovely crazy idea" doubled the total edits for a short period in another "backwater" of wikimedia).

This is only the latest example of Ineuw's approach to this site, challenged not just by me (in what I said was my last post on his talk), but by many others, including billinghurst (who, if I assume any integrity, will confirm this). Users may have some form of aberration in their thinking that is not shared by the majority, probably most regulars at wiki-sites have some form of diagnosable disorder, or addiction, but it is not the purpose of the site to indulge this to its own detriment.

The conversation had meandered off into discussion of technical solution to showing how inadequate a page was, I'll note on this aside that the mysterious coloured ribbon only shows the status of the presented page, not the subpages. There was assertions that there was no "rule" so it must be okay. Similarly, there is no 'rule' that a user can't use the site to create an elaborate, parallel, yet empty, category system that reflects their personal view on how information should be compartmentalised, or any rule that says putting a baby-sick yellow background is not okay, nor one that forbids putting one's signature into main-space. The user has done all these things, and more, such as duplicating author pages and linking them to non-existent biographies at wikipedia. This has used up an inordinate amount of other user's time in stopping these unreasonable practices, countered by Ineuw's extended and elaborate 'reasoning' of the type ex post facto.

The user set about doing everything but proofreading, (which may be unobjectionable in our work-space Page:ns) then transcluding 25 volumes of unproofread text into the mainspace, greater than 10 000 pages of PSM. If the intention was to go back and proofread what they had wrought, there might be an argument for doing this, though this is invalidated by the very existence of the Page:ns (I have done many incomplete works, and there many ways this can be done without thrusting rubbish in the readers face). However, after completing the bits they were interested in, which is not proofreading (Users can do what they like, unless it interferes with the actual goal of this site, of any library, to provide legible and clean text) they set about doing the same for the rest of the volumes. PSM already exists on the web in an unproofread state elsewhere, in the same places it was obtained from, it is a pointless, or w:WP:POINTy, duplication of the same crud that google provides.

Billinghurst said above, "... we have a strong preference that users don't come and upload and transclude a large number of unproofread pages and depart" the example he had in mind might be the hostile and 'not-new' Special:Contributions/TheSkullOfRFBurton, it is quite reasonable to extrapolate this widely held postion to users who transclude a large number of unproofread pages and repeat; in fact this is worse.

I asked this question and it represented as a personal attack, it was not! everyone should ask themselves this: "why do I log into this site?" CYGNIS INSIGNIS 13:34, 11 October 2011 (UTC)

While this is largely a collateral response and attack, likely for matters elsewhere and I fail entirely to see how activity on the Latin Wikisource is relevant to this thread, my opinion, as Cyg rightly points out, has changed within this thread as I got what I thought was more clarity about the request. If I was right about that further clarity than as Billinghurst points out below, no request was necessary. If I was wrong, I also agree with Billinghurst that in that case the request is unclear.

I did not change my mind because Cyg was the one who challenged the practice and I never said that I did. I stated I was open to the idea before Ineuw posted that link (though apparently I forgot to sign that comment) and afterwards I made several comments about the nature of the work. There was a discussion actually taking place between Jeepday, GOIII, and me and I was influenced far more by that than by Cyg's involvement. It does bother me that Cyg continually presses this non-policy on people, and sometimes uses his tools to enforce it.

The clear impression I have gotten from Cyg in the past is that he believes that a work must have 100% of the pages validated to have any portion transcluded. This is neither policy nor practical on a rather small collaborative. I'm not talking about there not being a written policy page on this, I mean there is no evidence that it is now nor ever was the consensus of this community on this point. I tend to agree with Billinghurst that unvalidated pages in mainspace should be discouraged and that very large volumes of them might require discussion.--Doug.(talk•contribs) 15:50, 13 October 2011 (UTC)

... yet this comment was placed beneath my own, drops my damned name 5 times, and directly contradicts early comments on contibutors, not content, especially the one at 10:05, 11 October 2011 which announces his bias and accuses me of unilateral actions. Motivated more by pity for the user than anything else, as Doug digs his hole ever deeper, I will point out that the "clear impression" of what I think, said, and actually do, is completely wrong. CYGNIS INSIGNIS 23:40, 13 October 2011 (UTC)

I am flabbergasted as to how this properly presented request for a majority agreement by the community has evolved into an emotion laden discussion. I now ask to please end this thread because it's upsetting and damaging to the community, and this was not the purpose of this request. All I am asking is a majority agreement for the continuation of the methodology of proofreading as I outlined on numerous occasions and based on the value of my contributions of these past two years. Also, in my view, there is no need for additional effort to mark the work in a special manner, since as part of the same methodology, the pages will be proofread. Thank you. — Ineuw talk 21:52, 11 October 2011 (UTC)

I am trying very hard to not make any of this personal or about people. I am trying to make this about our principle and how to interpret this about principle, not to hand out "get out of jail free" cards, and to explain my reasoning to wit. I also didn't want to have a long conditional set of reasons on what is occurring or how, but relates to how I try to work within the principle, not to blackletter law. [Yes my quirks]

If you are looking for how I would say that this works in practice, and this is a quick brain dump only … Each volume can have a starting page that sets up a basic framework for the volume, and I would like to see incomplete volumes so tagged, and tagging at the volume level is sufficient to cover the whole volume. You would/could also set up any framework that helps to browse any existing part of the volume. Transclude subpages as required. Would I expect to see a whole volume of unproofread transcluded work, probably not for an extended period of time, especially if it is in a poor state of OCR, maybe yes if you are working through THAT volume, and it adds interest and brings volunteers and part of a collective basis for Commons and WP. Such external factors would give a positive bias and emphasis to why having something available and unproofread. I would consider such an approach within our principle, and both reasonable and practicable, and not something therefore that would need further community consultation, ie. a vote of the community.

If you are/were asking to transclude 10000 pages of PSM unproofread into the main namespace, especially untagged, then I don't think that it is fitting with our expected product/standard and hence I do not feel that such a request is reasonable and practicable. I would think that we would need consider a better way to how volunteers can find and access the work to proofread it. If it is the latter that you are requesting, then it is not clear from your request, and you can put a specific request to the community, and at this point, I do not see enough for me to support such a request. — billinghurstsDrewth 00:34, 12 October 2011 (UTC)

I don't believe there is enough sustained new contributor traffic that warrants curtailing Ineuw's work flow just because it might tempt those yet-to-materialize newbies to follow suit. Until folks star coming out of the woodwork and cite the PSM Project as justification for their own transgressions, I don't believe there is any serious issue here. I see no legitimate reason for forcing a change in Ineuw's case. I still feel, however, that some sort of notification clearly showing status, be it {{incomplete}} or something similar, be present just in case some Google search result manages to drive a reader or two to one of the PSM still in flux. -- George Orwell III (talk) 21:37, 13 October 2011 (UTC)

The reader might arrive from a google link, it is more likely they will reach an article from the thousands of links being placed at wikipedia. IL just created a new template that includes the contentious rationalisation, giving it the imprimatur of acceptance and standard practice. By the same contrary rationalisation above, Inuew could also return to the whimsical practice of adding a signature (~~~~) to this template. Should we create a new banner/disclaimer for use at wikipedia articles, to complement the above, "Wikisource has works by Jane Surname, but it duplicates the uncorrected OCR at archive.org, google and .com sites that repackage this annoying garbage as 'books'." CYGNIS INSIGNIS 23:40, 13 October 2011 (UTC)

According to Alexa [clickstream charts], the combined upstream traffic that originates from our sister sites roughly equals the combined amount of traffic originating from a Google domain (about a third or ~30% of total incoming traffic) so that rationale is a bit flawed IMHO. While we do have some say in what is or what is not present on Wikipedia and other sister sites that may or may not point back to en.WS articles, we have no control over Google search results - yet they still come & come in respectable numbers to boot - therefore I feel they must be addressed first and foremost.

If you are saying Ineuw has been placing pointers on Wikipedia to "unfinished" en.WS works, then I am of like mind and the practice should stop. However, I do not believe this is the case and hope Inuew can verify or dismiss the claim that this practice of "tagging/pointing" to unfinished WS works is actually taking place and/or is by his/her direct doing. -- George Orwell III (talk) 00:35, 14 October 2011 (UTC)

agreed, though as it is PotM and the work quickly fills, and is not the normal way that work is undertaken, so is just an example of the ugliness of what we don't want long term. At the end of the month, if it is incomplete I will take other measures.—unsigned comment byBillinghurst (talk) 07:12, 14 October 2011.

As I see it there are 3 topics here, dived below. JeepdaySock (talk) 15:27, 14 October 2011 (UTC)

"I am requesting the community's agreement to grant a variance to the rule of not posting incomplete articles in the main namespace" There is no rule to request a variance too, no variance request is needed. JeepdaySock (talk) 15:27, 14 October 2011 (UTC)

Suggestion above for template of simular to {{Incomplete}} and/or required suggested use of same when non-proof read works are in the main space, I don't see any objections to using {{Incomplete}} or creating something simular. As a community do we want require using of this or a simular template when un-proofread work is in the main-space? (clearly if yes there is the possibility of a technical solution, lets try and defer conversation on that until we decide if we want to require it)JeepdaySock (talk) 15:27, 14 October 2011 (UTC)

Should there be a guideline defining defining reasonable activities as it relates to non-proofread works in the main-space?[edit]

There is lots of talk about the edits of a single editor without any reference to an existing policy. I would suggest it might be better to focus if we need a guideline, if so what it might be, and leave the specific edits of that editor alone until/if the community reaches a consensus that would apply to all editors.JeepdaySock (talk) 15:27, 14 October 2011 (UTC)

I oppose any such guideline. We should address matters as they come up because the facts of each situation are different. As JeepdayBillinghurst notes regarding the link above posted by Hesperian, the POTM is in mainspace incomplete. Other than being the POTM it is very similar to Freedom of Information Act 2000 (permalink), though that fact makes a world of difference. We are a small community and we can address these matters as they arise. We also have greatly varying opinions on precisely what is permissible and the language of a guideline is likely to be even more contentious than any particular case. (I have taken the liberty of editing this heading to remove the code from it so the link becomes manageable in edit summaries and the TOC).--Doug.(talk•contribs) 10:48, 18 October 2011 (UTC)

The successes of POTM are invaluable, but what the link shows is someone taking a very small amount of time to transclude nothing. This deprives the person, or people who actually undertake the task, requiring a much greater amount of time and labour, the satisfaction of presenting something useful. Users (contributors) who focus on this (content) would appreciate the sense of satisfaction is proportional to the amount of time and labour; the buzz of doing 10–50 pages of an article, the ecstatic feeling of doing 100–500 pages of a complete book. This is a motivation for some at this site, it is not for everyone, but they continue to be addicted to this feeling and repeat it over and over; the benefit to the user (a reader) is obvious. Another unobjectionable motivation is annoyance, fixing a typo, the absence of significant formatting, or something that has long been incomplete, inadequate, unusable, unsourced, some 'travesty' against the published author's work; these users might repeat this once or twice, but if they have any sense they leave the site in despair and never return.

This site was a borstel, a sandbox, an opportunity to embroider some 'old and useless' copy-paste from proper content produced by DP/PG; the motivation was 'self-publishing', pointless mega-edit-counts, and the opportunity for 'promotion', affirming one's sense of self-importance. This is the legacy of wikisource 1.0.

The introduction of the Page namespace blew this apart, along with the convoluted self-serving rationalisation of the site's denizens. Transcluding crap has no justification, there are dozens of people eager to gain the satisfaction of showing those willing to listen how to produce useful content. This is wikisource 2.0.

Users (transcribers) serve the users (readers) in the 'main' namespace, it is that bloody simple. CYGNIS INSIGNIS 15:05, 18 October 2011 (UTC)

I tried to help proofread a section of 1911 Encyclopædia Britannica/Washington. I clicked on the redlink and got a helpful looking preload template, but I was looking for some kind of side-by-side OCR proofreading interface. I spent a lot of time digging around and going to Wikimedia Commons and back before I could find it. It would be quite helpful if the redlink would help me find the relevant material in the page namespace. That would give Wikisouce a lot of momentum. Heyzeuss (talk) 08:28, 13 October 2011 (UTC)

Some books (e.g. Cinderella, or the Little Glass Slipper (Dalziel)) are transcluded from the page namespace, while others are not. When they are, there is a Source tab to click on. In the case of the 1911 Encyclopædia Britannica, the pages are not transcluded. I assume that this is so that the Encyclopedia can be organized by articles, rather than by pages, and because we wouldn't want to put the un-proofread pages in the main namespace. The question remains, how does a newcomer find the un-proofread page? Maybe there could be a link next to the redlink in the table of contents that says "You can help by proofreading the OCR scan" Heyzeuss (talk) 09:42, 13 October 2011 (UTC)

Most of the major works in this space have project pages, and for EB1911 it is at Wikisource:WikiProject 1911 Encyclopædia Britannica, with links to the Index: files. Other ways that I add links to works is via author pages where I utilise {{small scan link}}, or from Portal pages. Another way to find works is to include the Index: namespace in your search criteria (add via your Special:Preferences). Unfortunately having a redlink that finds the respective pages and parts of the Page namespace is not readily possible as one needs to know the relevant file link, and for such a work the pages in the file and the section names that will be used, and if we did that we would be able to transclude them already.<shrug> — billinghurstsDrewth 13:17, 13 October 2011 (UTC)

I think the lack of transclusion may be because the Britannica pages pre-date the ProofreadPage extension (with which we proofread new works). It looks as though a lot of the Britannica articles should be matched and split (or just moved and edited) from the mainspace to the page namespace and transcluded back again (which would provide the links). That is probably going to be a lot of work, however, as it would need to be done for each article and mergers would be necessary for multiple articles on one page. Link-wise, we could use {{small scan link}} as a temporary measure on the first page (1911 Encyclopædia Britannica). I'm not currently sure which indexes are original to Wikisource and which are part of the scans; so they might end up transcluded as well or more links could be added in the header (as with the first set of subpages). - AdamBMorgan (talk) 13:27, 13 October 2011 (UTC)

I'll note some idle thoughts on this subject. The 1911 edition is first of the two greatest encyclopædias in English, a true classic that in many ways is superior to subsequent editions. Adding a few articles on topics that interested me was amongst my earliest contribs to en.ws, when I felt like a break from the other great encyclopædia, but finding a way to do that was very difficult and I thought there was better ways to invest my time. This decision was partly based on the fact that it is already found at several sites on the web; though hosting it here would be desirable, it is perhaps less of a priority than creating transcripts which are currently pay-walled, poorly presented, or otherwise unavailable. The project documentation is confusing, though it is interesting, from a historical perspective, as this site was making the transition to scan-based transcript. Setting up the sub-project properly could be a good entry point for new users, but revamping all this would be a lot of work; perhaps this should wait until routines and work-flows are better developed before attempting to undertake this. CYGNIS INSIGNIS 14:52, 13 October 2011 (UTC)

This has been a major barrier to entry for years. Our processes are utterly obscure to newbs.

"This page does not exist yet; you can create it by typing in the box below and saving."

It would be great if it could be updated to make newbs aware of the existence of our proof-and-transclude processes. It would be superb if it could be updated to detect whether or not the page is part of a transclusion project, point at the relevant index, and explain the proofing and transclusion procedure. But that may be too much to ask from a technical point of view.

I intended to say more on one of these points: I think that finding and adapting what was done in an existing article, from the same work, is how many would do it. For the red-linked Washington example, getting the code and clicking the source tab from another 1911 article beginning Wa. Putting "1911 Encyclopædia Britannica/Wa" into the search box gives a selection in the drop-down. This doesn't work as well for DNB (because the title is a suffix), but the volume pages are well maintained and I still use these to create a new article. CYGNIS INSIGNIS 00:44, 14 October 2011 (UTC)

The approach from the WikiProject DNB has been to better facilitate the project and to link to the relevant source files from each of the 63 volumes of the work, as a respective link to an article is most likely to come from that page, though it could come from one of the author pages. At the same time, through wikis, a red link usually doesn't mean other content at the link. It would be great to have some context sensitive links for the projects that we have to be able to hotlink in the relevant text for red links, and actually it wouldn't be too horrid to look to do something through that space for our projects as long as we have a good naming hierarchy. Which works/projects would people think that this would be helpful? We may even be able to work something for a general work that if instructions are on the Index talk: page that it looks for that and displays a link there too. Great thinking. The one difficulty that I see is that as the Page: ns pages are NOT subpages but each distinctive, it was tricky to grab the {{PAGENAME}} component for the filename.djvu aspect. — billinghurstsDrewth 06:28, 14 October 2011 (UTC)

"This story thus encourages others to consider the long-term consequences of their own inventions with great care, lest those inventions do more harm than good." Londonjackbooks (talk) 06:51, 14 October 2011 (UTC)

Re Hesperian's comment, it should at least be possible to incorporate something like what de.ws does by linking to their style guide from the index (see e.g. de:Index:Nietzsche's Werke, VIII.djvu - the section headed Editionsrichtlinien (the line under the link is an exception to the style guide for this work based on the primary editor (yours truly) deciding to deviate from the rule - de.ws is full of rules and standards and all exceptions must be declared)). Additionally, at the bottom of a page in Page space, they have certain information there always (e.g. de:Seite:Nietzsche's Werke, VIII.djvu/420), it's in the css, I believe, (I haven't looked) as it is not a template that the editor adds, that information does not link to any help/guide but it easily could. As you can see, it is work specific without any action by the editor. Finally, in the mainspace following the same example, de:Dionysos-Dithyramben, you can see that there is a block of instructions in the textdaten template (the de substitute for a header) below the word "fertig" (lit. "done/ready" = validated). It translates roughly to: "Done! This text was checked twice against the source scans. The text here follows the original text. // To edit a page, you just need to click the corresponding [page number]. Further information can be found here: Help" (I've omitted the links but you can follow them yourself if you can read German). I'm not suggesting we should have the sort of rules that exist on de.ws by any means. I don't support such a thing at all. But they're use of the index, page, and mainspaces to provide potentially useful information where we provide none seems instructive.--Doug.(talk•contribs) 07:16, 14 October 2011 (UTC)

Scan index / scanned pages <shrug> yep, though to be accurate it should be "scanned pages index", and whatever, it is terminology, and just a step in improvement. — billinghurstsDrewth 05:37, 15 October 2011 (UTC)

Update previous component is not the complete picture I have since discovered. There is also alternative information at Commons:Editnotice and I am still trying to work it out <shrug>. — billinghurstsDrewth 04:48, 20 October 2011 (UTC)

That looks like the right direction. Even if it can't warp the editor straight to the page in the djvu file, a link to an index or list of indexes should be just fine. Heyzeuss (talk) 18:13, 22 October 2011 (UTC)

Hi, I just filed a bug that may be of particular interest on Wikisource. It is sometimes frustrating that the default (and only?) MediaWiki rendering behavior provides section numbers in the Table of Contents, but not on the sections themselves. There are documents (particularly legal documents) where it is important to have numbers in the section headers themselves. Having to do this manually is both silly for a computer-aided rendering, and causes an irritating side-effect of duplicate (and perhaps conflicting) numbers in the Table of Contents itself.

I'm not sure I understand the distinction you're drawing between published and codified. Could you expand on that?

Sorry... published should have been published as enacted or passed by a legislative body and frequently uses the abbrv. of the word section to divide up the various sub-divisions that follow. The section symbol ( § ) is typically used only for an ongoing series or collection of subdivisions (like the U.S. code). So Title III, Sect. 4 as passed by Congress may become Chap. III § 304 when codified to the U.S.C.

The real point I was trying to make was that you could wind up with something like 2.1 § 2.1 for your entries if not careful. Turning this off and letting the actual text in the section title dictate what you "see" in the TOC is more flexible IMHO than toggling the feature on/off. -- George Orwell III (talk) 19:15, 15 October 2011 (UTC)

I had searched for the "turning off numbering" feature in MediaWiki documentation, and come up short; this is a very helpful link, thank you! I see it's accomplished by <div> codes around __TOC__. I'll try that out, and maybe add a note about that in the Magic Words documentation. -Pete (talk) 18:51, 15 October 2011 (UTC)

Doesn't seem to work over there -- TOC numbering does not get suppressed when I copy/paste that div/TOC line. I wonder if Meta has different CSS than Wikisource, and doesn't support that syntax the same? I'm really out of my depth on this. -Pete (talk) 18:56, 15 October 2011 (UTC)

Any Wiki sister site needs to have the following code added to their Common.css file....

#hideTOCnumbers .tocnumber { display: none; }

... in order for the DIV wrapping line to work as desired. -- George Orwell III (talk) 19:16, 15 October 2011 (UTC)

Success!! meta:Terms of use I will update the MediaWiki documentation of magic words, and also the bugzilla report. Thanks again! (And, good point about enacted/codified. I see what you're saying now.) -Pete (talk) 19:38, 15 October 2011 (UTC)

That's great. If anything, this really should be a formal magic-word of some kind. Its not the perfect solution re: sectionalizing but half-way is better than nothing! -- George Orwell III (talk) 19:52, 15 October 2011 (UTC)

Yes, introducing a magic word for section headers was what I proposed in the bug. But I think I'm going to replace that with the suggestion, based on this, of having a magic word that simply suppresses the numbering in the way you showed me here. I'll link this discussion, too. -Pete (talk) 19:54, 15 October 2011 (UTC)

Since most of the larger wikis want a uniform format, I doubt it would be feasible to have a feature like this available globally. Maybe it could be done as an extension, although the CSS solution seems reasonable. It should also be possible to add section numbers with CSS, put putting a div around the whole content with a class to invoke the appropriate CSS rules. -Steve Sanbeg (talk) 02:08, 29 October 2011 (UTC)

┌───────────────────────┘ I had sensed that would be the sticking-point to developing something like that. Still, it would be nice to have some flexibility regarding sections (or headers?). Retaining the built-in hierarchy of the header/section scheme while doing away with the imposed font-sizes and associated styling would make much more sense for Wikisource since we are more concerned with staying true to the published text than we are with utilizing the typical Wikipedia-like article outline based on sections/headers for example. -- George Orwell III (talk) 02:49, 29 October 2011 (UTC)

Is it just happening to me or is it happening to others? The 8 pages I've proofread today from Index:Tracts for the Times Vol 1.djvu (this one forwards) have had a linebreak inserted at the end of Page Body section, this has meant that the transclusion Tracts for the Times/Tract 3 has got mid-paragraph linebreaks. I've gone back and removed one of the linebreaks and re-saved the page. The linebreak was restored, so I know it wasn't me who did it by accident.

Up until yesterday an extra linebreak was turning up at the beginning of the Footer every time a Pagespace page was edited (or previewed). This behaviour has stopped, but I wonder if in the fixing of it, the new problem has been created. Thoughts or solutions? Beeswaxcandle (talk) 08:25, 17 October 2011 (UTC)

I can confirm what you are saying, though know what if anything has changed. I can see that it only seems to effect recent pages, and not an effect on existing saved pages. It is going to be problematic for every page edited since the change (wherever it is) was made. Minor error, that is going to have a major issue that we may need to go back and edit broadly across the system. :-( — billinghurstsDrewth 11:32, 17 October 2011 (UTC)

this isn't the only issue showing up, I had trouble yesterday with page numbering not showing and headers being all messed up as well as no layout options on the sidebar. Phe checked and said it was a js conflict caused by a non-relative link in the common.js (one had slipped through) but the problem appeared suddenly yesterday afternoon and appeared to only affect new pages and the problem had existed since the 4th when Billinghurst changed all the others. Strange things are afoot.--Doug.(talk•contribs) 11:44, 17 October 2011 (UTC)

Phe has identifed the code change and I have update bugzilla:26028 and done a virtual streak through the requisite IRC channel, though to no effect when no when is watching. We wait and hope. @Doug re your issue, I am not seeing it, or not noticing the minutæ that you mention. — billinghurstsDrewth 11:53, 17 October 2011 (UTC)

Phe confirmed the problem and identified the cause noted above. It seemed to resolve after Phe removed the remaining relative link but how it suddenly occurred when the problem had existed for a week and a half was what was so odd.--Doug.(talk•contribs) 12:04, 17 October 2011 (UTC)

As it is clear that ABF has been, for a long time, applied to everything I say, I'll preface this comment with a categorical statement: I am not blaming anyone, just making some observations, some clarification [?] and suggestions in the hope this is resolved quickly. The problem emerged between 15:25, 16 October 2011 and 02:18, 17 October 2011, I will attempt to narrow that time frame.,

Extra lines have been appearing in the Page namespace for the last couple of weeks. Wouldn't rolling the Common.js back to a stable version resolve this problem?

Can someone who knows how put up a site wide notice that Pages will need to be edited again. The last time this happened I was finding them for months afterward. CYGNIS INSIGNIS 12:30, 17 October 2011 (UTC)

Actually, it was the edit before by Phe that showed the one that was missed. The edit by me that CI points to was unrelated; although the import line I edited there and which refers to a script in my userspace (that creates the oldwikisource sidebar link) did have a non-relative link at one point during the last couple weeks to try to debug a problem and that stayed there longer than intended, the non-relative part of that link was not there during the time the error I mention was noticed. I have no problem with rolling back to a "stable version"; however, I'm not at all confident that would solve the problem; the sidebar link that my script creates disappeared (in FF only) right after the upgrade to 1.18 - but only on some wikisources, not all (la.ws was unaffected).

If we can identify precisely when the issue began, we could run a bot to eliminate the extra spaces, couldn't we? We could even do that now if it's a js issue as the bot should be unaffected. Also, editors who know how could eliminate the space by turning off their js and re-editing the page. At the same time, CI's suggestion of a site-wide notice sounds appropriate. At least one that shows up in edit mode in pagespace.--Doug.(talk•contribs) 13:16, 17 October 2011 (UTC)

Extra lines in the footer came about in the rollover to 1.18, the issue was identified and put into the noted bugzilla with a solution. It seems (to this non-coder) that the fix wasn't undertaken as recommended and fixed one bit and broke another, hence my updating the bugzilla and making a (lite-)pest of myself in IRC. I will look to see if we can more closely identify when the (fix|break) took place. — billinghurstsDrewth 13:24, 17 October 2011 (UTC)

[ec] Try it and see if it helps [the usual solution with new software is to use the stable version, in this case 1.17]. I hope it is not the case that 'we' are sticking with it for the sake of it, that bug fixing is taking precedence over proofreading/validating. Is someone offering to do those bot actions, and create the notice? If not, I will continue notifying users that they are unintentionally breaking transclusions. Re-editing pages is a drag, the greatest expense for contributors at this site is the time it takes to load a page. Do you mean switching off javascript in your browser? Suppressing the images would also help, if the browser has that capability, but any workarounds should be evaluated by the total amount of time of many users working out how to do these things [and explaining how to do that]. CYGNIS INSIGNIS 13:34, 17 October 2011 (UTC)

Does this mean we should stop proofreading/validating pages until this is fixed and we are notified that everything is OK again? Thanks, Mattisse (talk) 13:39, 17 October 2011 (UTC)

(ec)I have identified the "when and where" RecentChanges and all edits from

inclusive are busted. It shouldn't be a hard thing to bot to remove. I just cannot seem to develop a criteria for AWB to select all the relevant pages and in a suitable order. I have done a trial to bot a page, and that works fine, so the issue is selection of the pages. — billinghurstsDrewth 13:50, 17 October 2011 (UTC)

Okay, I have determine a query to grab the pages api query so we can work on that somehow to grab a bot'able list. In short, you can continue to edit, and we will be able to recover adequately once there is a fix in place. — billinghurstsDrewth 14:03, 17 October 2011 (UTC)

Have to leave it for now, I will hope that a fix will be put in place during the day (coin toss on our chances) and that being so, I may be able to run a fix through tomorrow, also seeking other info to try to make this easier on me. <grin> — billinghurstsDrewth 14:31, 17 October 2011 (UTC)

@Cygnis insignis, I will look into the notice when I'm at home tonight (after 1600 UTC) if someone else doesn't do it first. Yes, I meant switching off js in one's browser; I only meant for those who know how it would be a way to fix the problem since the initial post Beeswaxcandle said they had tried to remove the space and it hadn't worked. I agree, it's not a general solution nor even viable for most users without detailed instructions and probably installation of a add-on to their browser.

Jowinix and I just created some poems in page and mainspace over the weekend (see Songs of Prince Free-as-a-Bird) and have seen nothing of this problem, does it only affect works that pre-date the upgrade when the pages are edited again?--Doug.(talk•contribs) 14:18, 17 October 2011 (UTC)

Switching off .js would, I presume, mean not being able to use any script in your workflow, this is not a good solution for users who do many pages. This problem only occurs in pages created after the time frame I identified, narrowed down to a precise edit by Billinghurst (23:13 16 October); that is how it was identified: by opening the page in edit mode (and not saving, of course). The upgrade is not known to be the cause, it might be anything in our [bloated] Common.js or another issue identified at the bug report. CYGNIS INSIGNIS 14:37, 17 October 2011 (UTC)

That's my point, I don't see it. I created pages over the weekend, some as late as last night and I edited some this morning. I had noticed, but I ignored, the creation of spaces in the footer. When I check now, I still see those, but nothing created at the bottom of the page proper, i.e. nothing that affects the page in transclusion. Again, I know it isn't a good solution for most users to turn off their js, I was suggesting it as a way to manually fix individual pages since Beeswaxcandle said removing it didn't work.--Doug.(talk•contribs) 14:52, 17 October 2011 (UTC)

I can see the one pointed to by Beeswaxcandle and that it can't be removed. I just don't see new ones being created.--Doug.(talk•contribs) 14:58, 17 October 2011 (UTC)

As I said above, though obviously not clearly enough, there has been applied an update to the Proofread Page extension. That was a fix for the footer line feed (LF) addition, however, it has now created a LF above the footer; and now we await a fix. <shrug> Both effects will take place from the indicated edit, and neither will be retrospective. We need to fix the edits that are in the body, the edits that affect the footer are just ugly in the Page: ns, and presumably we can just clean up in any further proofreading. — billinghurstsDrewth 20:53, 17 October 2011 (UTC)

I see... So until this is fixed, we need to merely edit Index pages twice in order to remove the unwanted spaces? I had noticed before the added line spaces in the footers of Index pages, but not in the body...? Londonjackbooks (talk) 21:42, 17 October 2011 (UTC)

I guess I don't fully understand the problem because I don't see it except in footers. If someone else writes the site-wide message, I can see about putting it up but I'd better not write a message about something I can't even see the effect of.--Doug.(talk•contribs) 21:47, 17 October 2011 (UTC)

I don't see a little need for a site-wide message, though happy for people to demonstrate otherwise. At the moment, we just continue to have people to edit and proofread pages as normal and in that we have the knowledge that we have a line feed being added at the end of the pages, though it doesn't affect the text. We will run a bot after for the fix for all the edits from the above identified edit, problem solved. If need be we can start running that bot right away knowing that it will fix the issue, we just need to notate when a bot runs from when to when (or where to where) and just keep picking up from where the bot left off until the script is fixed. — billinghurstsDrewth 11:03, 18 October 2011 (UTC)

The need for a site notice is that contributors will waste their time trying to fix this, if they notice it, and wondering why their all Pages are bot-edited with the summary "remove trailing LF, replaced: <noinclude> → <noinclude>" Even the summary links here, they have to wade through discussion that includes a repeated assertion that there is no problem. The solution is to link the page to be edited, and the notice can be added and refined. The text would be something like, "a bug has appeared in the site's software, [rather than rolling back to a stable version] a bot will repair this until it is fixed." CYGNIS INSIGNIS 16:16, 18 October 2011 (UTC)

So you would like a watchlist notice? For the bot edits, I will create a specific page at the bot, and link to it with a summary of what it is for and about. — billinghurstsDrewth 21:21, 18 October 2011 (UTC)

No news from WMF and there is no indication that the bugzilla report has been addressed, though do note that many of the WMF staff and vols are on their way to a Hackathon at New Orleans and they said that they would have less availability. When? <shrug>

When it has been solved, will the bot roll-back of linebreaks be applied on all Wikisource subdomains? V85 (talk) 16:31, 20 October 2011 (UTC)

I only have a bot that is approved for enWS. If other xxWS would like me to run it on their sites, then happy to do so upon request. Alternatively if these sites have users who use Wikipedia:AutoWikiBrowser they can look at what I have done and replicate that or contact me for assistance. — billinghurstsDrewth 21:14, 20 October 2011 (UTC)

Got it a little better organised, and getting close to running it nightly, except when I go to sleep at my desk. I am keeping a log on the run on the explanation request. Still no comment about the fix in bugzilla. — billinghurstsDrewth 13:03, 26 October 2011 (UTC)

billinghurst, we are discussing on the Multilingual Wikisource about running your fix on every subdomain, without waiting for a request from each one (on smaller sources, it's possible that no one is even aware of the bug). Also, I have a bot that is flagged on many subdomains, and it also can be scheduled to run automatically from the Toolserver... so if you give me istructions, I can help you with this task. Candalua (talk) 16:18, 27 October 2011 (UTC)

Bugzilla has been resolved and rolled out to the Wikisources. I did a run last night, so I have less than half a days edits to fix and will get that done shortly. I think that we can put this to bed and considered Done — billinghurstsDrewth 21:12, 28 October 2011 (UTC)

If it does happen again, then by adding <noinclude></div></noinclude> to the end of such pages where a blank line afterwards is not needed, the issue is resolved. --Angelprincess72 (talk) 19:06, 30 October 2011 (UTC)

Dictionaries use accents or apostrophes to indicate which syllable to stress, e.g. PATent (English) or paTENT (German) can be printed as Pa'tent, Pat'ent and even Patént. Is it correct to transcribe the latter as e-acute (é), or does Unicode have any other way to indicate stress accents? Will a dictionary headword Pat'ent be searchable as the word "patent" or as two words "pat ent"? Does Wiktionary have methods, templates or guidelines for these cases? --LA2 (talk) 13:49, 17 October 2011 (UTC)

Very useful question, and I am waiting for a solution too. One more way to indicate a stress accent is this one: Patent, and one more is Patent. If these spellings, bold or underlined, could be searchable too it would be interesting, wouldn’t it? Do you think it will be possible? --Zyephyrus (talk) 16:59, 20 October 2011 (UTC)

I understand that the marks have overlapping histories. Acutes and similar marks (as well as dissimilar marks like macrons) were used to mark the sounds of vowels in Latin and Greek and they evolved into different usages in different languages. For example, in English a grave is occasionally used to show an unusual or archaic stress or that unpronounced vowel is pronounced such as in the word "belovèd" (sometimes written using an acute, thus: "belovéd"), particularly in poetry where the stress may be important to the foot. There is a separate stress character in unicode: U+02C8 (&#712;), which give: ˈ but as you can see it's not very distinct. Acutes are often used in poetry scansion in place of slashes or macrons to mark stressed syllables (traditionally macrons were used, for the very reason that they also mark long vowels, since those are normally stressed) and in some works acutes mark primary stress and graves mark secondary stress. I would recommend trying to model on the original scans as best you can.

I have tested some accents in Google and can tell you that ordinarily they will break, i.e. the accent will only find the accent, the bare letter will only find the bare letter. This is true of ligatures as well and most characters that have a separate IPA/html value, with the notable exception of long-s. For this reason, if you are going to show it, I would try to make the unaccented word searchable. You may also want to look at some of our discussion on technical solutions to annotations (e.g. Wikisource talk:Annotations#Technical solution to the mess) to find ideas how to make the marked up text searchable and maybe discuss that further with Inductiveload (talk • contribs)--Doug.(talk•contribs) 13:34, 21 October 2011 (UTC)

Yes, it's true that these will affect searchability. In general, Wiktionary skirts this issue by keeping the headword plain and then putting things like pronunciation, hyphenation, and syllabification in separate subsections. It also has an advantage over us and most traditional dictionaries in that each entry has a page name, as well as a headword, and the page name is certainly going to be the bare word, making it findable even if you mess with the headword.

As for the specific character here, I think it is a fair assumption that these are simply acute accents marks. The other stress mark Doug mentions isn't an accent, and it is used in IPA, which does not use diacritics over characters to indicate stress. There is actually a "ˌ" for secondary stress along with "ˈ". Ideally, we should transcribe the characters faithfully using the accent marks from the original, while finding some technical solution to make them searchable. I'm not sure what the technical solution is, to be honest. Dominic (talk) 13:03, 22 October 2011 (UTC)

Edit window, in "Other diacritics" the "caron" for G and i are linked together as Ğǐ, you click on one you get both. I am not sure where they live, could someone go in and separate them? JeepdaySock (talk) 16:33, 21 October 2011 (UTC)

Hello I read your wiki article on sigmund freud. Is the goverment of the united states classifying documents written by Sigmund Freud which are now a part of the freud estate? Where did you get your info? And if this is true, what does this mean in psychiatry and public health? I am doing a presentation on mapp working in San Antonio on Tuesday. —unsigned comment by66.229.239.128 (talk) .

And we have nothing to do with the Government of the United States and no knowledge of any project by them to "classify[ ] documents written by Sigmund Freud which are now a part of the freud estate" nor any idea why they would want to do such a thing.--Doug.(talk•contribs) 13:00, 22 October 2011 (UTC)

You might be referring to copyright. Freud's works are out of copyright in all "70 years from author death" regions (which includes Austria and the UK). However, Wikisource operates under United States law. Copyright in this case is complicated but it can mean many of Freud's works are still under copyright in the US (and so on Wikisource and many similar sites); for example, under a term of 95 years from publication if copyright was renewed. So, Freud's works may be in the public domain in his home countries but not in the USA. On the other hand, Wikilivres:Sigmund Freud operates under Canadian law, which has a "50 years from author death" term, so they were all in the public domain there before they were in Austria or the UK. - AdamBMorgan (talk) 17:11, 22 October 2011 (UTC)

It's kind of a silly question, since the work in general is public domain, but are there any specific issues with publishers and newer editions that I should know before moving it over? Heyzeuss (talk) 12:36, 23 October 2011 (UTC)

Yes, most are from that source. I will get it done for you. — billinghurstsDrewth 13:41, 23 October 2011 (UTC)

Oh there are six volumes of the work, and I can see 1828 edition and 1860 edition. I can import them to Commons, though would need to know which set is better. I am ignoring the undated 9 volume series as it missing volume 7. — billinghurstsDrewth 13:45, 23 October 2011 (UTC)

The 1828 edition has more transparent pages, which might have affected the OCR. The 1860 edition should be just fine, but neither are proofread. There are other proofread sources on the internet, and I wonder if there is a quick and dirty way to exploit them. Heyzeuss (talk) 17:25, 23 October 2011 (UTC)

I've been putting off doing this as I've been trying find a copy of the 1811 first edition (of the complete work), which has fewer editorial emendations. Ideally we would also have a copy of Henry's 1706 edition, but locating a scanned copy of this is difficult. In the meantime a copy of any edition would be useful.

With respect to your question about copy/pasting from other proofread sources: there are a few questions to ask. 1) Is the edition identical? 2) How good is the proofreading at that source? 3) How complete is that source? If the answers to these questions are Yes; good to excellent; and 100%, then by all means bring it across. If any one of the answers is negative, then the requirement of proofreading and validating is not removed and it would be better to do it from scratch. Beeswaxcandle (talk) 21:15, 23 October 2011 (UTC)

It is complete and well proofread, but the 1860 edition may or may not be the version going around the internet. The work is the public domain standard of English bible commentaries, in use at places like biblegateway.com, so it is important that we have it here, where it can be verified. It sure would be nice to have the oldest editions, but lets take what we can get. I'm unfamiliar with the match and split process. Is that what you use to compare proofread text with raw OCR, and would it be useful in this situation? Heyzeuss (talk) 08:20, 24 October 2011 (UTC)

If we don't know for sure that it's the same edition, then doing a Match&Split is not a good idea. I know this from personal experience. The result was a lot of work to undo the mess I had created. We already have some of the work here at Matthew Henry's Commentary on the Whole Bible, which is a copy/paste of the CCEL text. But, in typical fashion, they don't give the colophon and so we don't know which edition this is. So in the end, we're going to need a replacement version in DjVu format anyway, so might as well start now with what we can get. If the 1860 edition is going to be easier to manage because of the scanning in the 1828, then let's do it. Beeswaxcandle (talk) 07:51, 25 October 2011 (UTC)

These are the DjVu files, but one of them is missing. I think it just needs to be converted or unpacked from one of the other files.

I am now using pdf2djvu to convert the 3rd volume. It is slow, and I'm not sure if it's gonna keep the text. Heyzeuss (talk) 16:47, 25 October 2011 (UTC)

Is there a problem with the pdfs? are they too large?--Doug.(talk•contribs) 21:32, 25 October 2011 (UTC)

They are not too large, about 122MB. I am converting to DjVu because I just thought that is what you use here. Does the proofreading interface at English Wikisource support pdf? Heyzeuss (talk) 05:56, 26 October 2011 (UTC)

It does support pdf, but those are too large. There is a file size limit of 100MB across WMF projects. The use of PDF isn't common because for a long time it wasn't allowed and although proofreadpage support for pdf was developed in 2009 it didn't work for some reason until earlier this year. People became sort of attached to djvu. Both have their advantages and disadvantages. For file sizes under 100MB, pdf from the Internet Archive can often provide greater quality without much more size but see the discussion below for a situation where the image separation of the pdf caused problems with thumbnailing, which is critical to display on commons and here, including in page view. PDFs also sometimes have imbedded images that can really foul things up. On the other hand, they can have a much higher quality image and the text layer can be relatively easily edited so that the file has a proofread text layer rather than raw OCR output (though they won't come this way from IA usually). DjVu can be heavily compressed making it rather easy to make a very large book fit under 100MB; however, that can also lose a lot of resolution so that commas look like periods ("full stops" if you prefer) and periods disappear, etc. I've often had to go back to an upstream image, sometimes a pdf, to find the quality needed to see the details of text, particularly with old works. Given a work X1.tiff-X50.tiff from which I knew had been created two other files X.pdf and X.djvu, each under 100MB, I would generally prefer the pdf, all other things being equal - which they never are. ;-)--Doug.(talk•contribs) 07:21, 26 October 2011 (UTC)

The existing DjVu files are under 100MB. Is there a way to move them from archive.org without first downloading to my computer? Heyzeuss (talk) 09:53, 26 October 2011 (UTC)

Yes, or at least there was, last time I tried to use it there was a problem but that was a while ago. Try: [Url2Commons], it's not particularly intuitive and like all of the upload methods you need to swap out the {{information}} for {{book}} (use the version at commons:template:book to make sure you have the most current one), don't worry if you can't fill in all the items, we'll update it more afterwards, but most of the data comes off the first couple pages of the book. --Doug.(talk•contribs) 10:13, 26 October 2011 (UTC)

To use url2Commons, one needs to have created a [account] and have the details loaded at Commons as per the instructions. Very useful means to do direct transfers, though one needs to watch out for the times that Toolserver is busy as can try for ages before an uninformative failure.— billinghurstsDrewth 11:49, 26 October 2011 (UTC)

Right, I thought about mentioning that but I noticed Heyzeuss has or attempted to get a TUSC account based on his en.wp user talk page. Still, like I said it's not very intuitive, so if you want help walking through it, pop into IRC (#wikisource) for real time assistance, usually one of us is around.--Doug.(talk•contribs) 12:55, 26 October 2011 (UTC)

And as we speak AdamBMorgan has set up Help:URL2Commons, with screen shots of the process. Excellent! With that you should be able to do without IRC, but we're still there if you have trouble.--Doug.(talk•contribs) 12:58, 26 October 2011 (UTC)

I was just coming here to mention it. I had most of it done already but this thread inspired me to get it finished. I think it covers everything but feel free to add anything I might have missed out. - AdamBMorgan (talk) 13:01, 26 October 2011 (UTC)

I'm not familiar with that error message. Which upload method did you use and what was the step that resulted in that error? I haven't used pdf2djvu, so I can't help there, but you could try the Any2Djvu website as an alternative. - AdamBMorgan (talk) 09:45, 27 October 2011 (UTC)

I have previously (successfully) contacted IA and asked for them to rederive a file in such circumstances. — billinghurstsDrewth 13:20, 27 October 2011 (UTC)

The error message was in url2commons...except it wasn't really an error message. It was just generic text. Some of Magnus' tools seem to be down at the moment. As for pdf2djvu my command-line window had simply closed before I came back to my computer, without leaving any output. Inductiveload is converting to djvu for me. Heyzeuss (talk) 09:56, 27 October 2011 (UTC)

Hi. Is there some bot that adds new Authors to these lists (e.g. Wikisource:Authors-Mo)? To bot the update would avoid manual work. Moreover, not everyone does it, so the lists are probably incomplete. Bye --Mpaa (talk) 16:35, 23 October 2011 (UTC)

Phe generated the lists last time, though it had a lot of manual components to it, hence why it hasn't been done again. This sort of thing might be something that would be worth asking over at m:Tech as a useful tool to have so we can get a more automated process. To get it done best it would need someone with either a Toolserver account, or someone with a data dump. The first being better. — billinghurstsDrewth 09:32, 24 October 2011 (UTC)

So we have the scans of the law passed for starters; just needs some proofreading & you are welcome to mix and match from the various sources as needed in order to add all the pieces if you like -- George Orwell III (talk) 18:00, 23 October 2011 (UTC).

Well, thank you. But I don't know what I'm really looking at, by what you have linked. I hope you understand I have never added anything to Wikisource, so if this seems odd...what would happen if I just cut and pasted the thing from the Oklahoma University site, and then formatted to Wikisource standards? Better to ask the question, than to try and post something I shouldn' t have. Maile66 (talk) 18:09, 23 October 2011 (UTC)

Needs some cleaning but the closer you get the content to match what is in the scans, the easier it will be to start explaining the whole proofreading process desired here.

As an additional note, I got carried away and started following the legislative history It appears this specific agreement didn't go into full effect until 1900 mostly due to do other agreements with other tribes not being in place in time to combine them all into one. -- George Orwell III (talk) 19:08, 23 October 2011 (UTC)

Thanks. Yeah, this whole Jerome Agreement is a big thing, as far as the history. So, what you have there is what I was looking for. But, new like I am to Wikisource, I take it that what you are showing me is the basic, but it needs the tweaks and jiggles ( matching and proofing) to make it correct. Over on Wikipedia:Comanche,and a couple of other articles, there is a reference to this agreement. It's but one of many areas where the Comanche article needs cleaning up. I considered just creating a Jerome Agreement for the red link. But it would seem more professional to me if there was a Wikisource document to reference to in any such article . Over the next few days, let me compare the scan and what you set up. I have some learning to do here. Is there a way to do a side-by-side comparison, or do I have to just flip back and forth? Maile66 (talk) 21:31, 23 October 2011 (UTC)

Matched: I have completed matching the text of Jerome agreement of 1892 against the scan. Please advise as to what needs to happen next. Maile66 (talk) 14:01, 25 October 2011 (UTC)

I'm not sure what you mean by "matched". Matching is a special process we have here (see Help:Match and Split), which won't work for this work as there is apparently no OCR text layer in the djvu. You could manually match the text and then "split" so that the text you have would replace the text in the pagespace. Then it could be compared side-by side. Side-by-side comparison is the ideal and the most effective way to use the scans. An example of what a manually matched page would look like is User:Doug/Sandbox13, though I've only done the second and third pages (the first page is partial), and I already see material differences from the scans; so you may want to compare a scan of the actual agreement with the US code as the Revisor of Statutes may have made some "revisions". If after reviewing the situation you still want to match this text to these scans, then simply continue on as I have started.--Doug.(talk•contribs) 15:01, 25 October 2011 (UTC)

Well, as I said in the beginning of this thread, I've never participated in Wikisource before. George Orwell III set up the Jerome Agreement and above "the closer you get the content to match what is in the scans". Not knowing Wikisource, I visually went word by word, space by space, to match it with the the scan that Orwell did reference at the beginning of this thread. It was slow and tedious, manually flipping between two open browsers to do this. So, yes, I may have gone the long way around, but I did match it to the existing Wikisource scan that is part of a larger document. Maile66 (talk) 15:36, 25 October 2011 (UTC)

OK, no problem. I was going to explain M&S two days ago when you asked but couldn't figure out why these appeared to have OCR text but it wasn't being recognized by the toolserver bot that does the Match & Split. We really should still match this up the way I showed and split it so that the page numbers will show on the sides and it can be be proofread to compare it, as - like I said - there are some differences. If you want me to do that for you, I can. Or you can learn it by continuing what I started - you can do it in my userspace if you wish, though it can be undone.--Doug.(talk•contribs) 15:43, 25 October 2011 (UTC)

I would be very grateful if you would do this for me. Maile66 (talk) 19:59, 25 October 2011 (UTC)

Done I matched it and it looked like this then I split it, which causes User:Phe-Bot to move the text from my userspace to the respective pages and replace the text on my user page with the appropriate code to transclude the pages. I then moved that code to the mainspace where the text had been copied from and place a labeled section near the bottom of the first page: Page:United States Statutes at Large Volume 26.djvu/802. As you can see, on Jerome agreement of 1892 there are now page numbers off to the left in blue. If you hover over one, it will show you the portion of the text that comes from that page. If you click on it, you will go to the page.

You should now do all your editing in the page space on the relevant pages. You will now be able to do so with a side-by-side view so you can make sure that every word is precisely correct. :) --Doug.(talk•contribs) 22:42, 25 October 2011 (UTC)

I am having a tough time uploading a book a Ammianus' Roman History. It indexed well, but the pages don't have good clarity. Can anyone fix this for please? I need it soon though. Tannertsf (talk) 19:29, 25 October 2011 (UTC)

There is a problem with the pdf file on commons. I'm taking a look at the pdf's on internet archive. If they are better then I will try uploading over it. I'll also upload the djvu which has good quality. Possibly there was a problem with the creation of the pdfs at IA.--Doug.(talk•contribs) 20:06, 25 October 2011 (UTC)

There is something wrong with that pdf, it cannot generate a proper thumbnail as it's only thumbnailing the background image. As you can see the file is fine if you download it from IA or even click "Full resolution" on Commons. I don't think we can work with it but I've never run into this before and I'm not exactly sure what the problem is. In any case, I am uploading the djvu now. It will take a little while, it's a big file and I don't have much bandwidth. For future reference you should give your uploads a more meaningful name and use {{book}} instead of the default {{information}} template (copy the most current version from commons:template:book. I am uploading to the filename: File:Roman History of Ammianus Marcellinus.djvu. When you can see it there, the upload is done. ;-) You will need to set up a new index with the same base name (i.e. Index:Roman History of Ammianus Marcellinus.djvu). Good luck, it looks like an interesting work!--Doug.(talk•contribs) 21:27, 25 October 2011 (UTC)

Deleted at Doug's request, following replacement with a djvu. — billinghurstsDrewth 13:18, 27 October 2011 (UTC)

Thank you very much Doug. - Tannertsf (talk) 23:07, 25 October 2011 (UTC)

Don't mean to be a fly in the ointment but text seems to be missing from the first few pages I looked at.— Ineuw talk 20:37, 27 October 2011 (UTC)

Uh, yah, it was there, check the diffs. I've mentioned this to Tannertsf on his talk page. He has a unique proofreading method apparently that is probably not really suited to using on a work that is being matched and split against text we already have in mainspace. The text we have is great, the OCR is good, plenty good for M&S, there is just a proofreading needed and although the old formatting using mediawiki section headers isn't ideal, it stays with the split so the text is barely changed during the M&S, so after the M&S we have basically as good as we had before but with links to the scans. Instead he's proofing pages using this unusual method where he does a couple lines at a time. Not efficient and not the right way to do this work. I've asked him to please pick another one that we don't already have up to experiment with.--Doug.(talk•contribs) 10:57, 28 October 2011 (UTC)

I apologize that you are receiving this message in English. Please help translate it.

Hello,

The Wikimedia Foundation is discussing changes to its Terms of Use. The discussion can be found at Talk:Terms of use. Everyone is invited to join in. Because the new version of Terms of use is not in final form, we are not able to present official translations of it. Volunteers are welcome to translate it, as German volunteers have done at m:Terms of use/de, but we ask that you note at the top that the translation is unofficial and may become outdated as the English version is changed. The translation request can be found at m:Translation requests/WMF/Terms of Use 2 -- Maggie Dennis, Community Liaison 00:42, 27 October 2011 (UTC)

Can someone point me to a main main namespace page where there are multiple authors for the same article? I have several in PSM and with multiple collaborations. — Ineuw talk 20:39, 27 October 2011 (UTC)

It's happening because of the noinclude tags in the body. I've moved the end table stuff into the footer on /887 and the beginning table stuff into the header on /888 and the problem has resolved itself there. However, you'll need to do the same for the rest of the pages. Beeswaxcandle (talk) 06:28, 28 October 2011 (UTC)

Thanks for this as well, but why is there an {{nop}} at the top? Just curious. — Ineuw talk 06:55, 28 October 2011 (UTC)

The {{nop}} is there to force the table to behave when running across multiple pages. Otherwise the first bit of the line gets treated as characters rather than table formatting. I'm sure there's a more complex explanation, but this is the way Billinghurst explained it at WS:RFA. Beeswaxcandle (talk) 07:06, 28 October 2011 (UTC)

I left it out on one page and saw the results exactly as you described it. TY.— Ineuw talk 07:43, 28 October 2011 (UTC)

Returned to my earlier work in the project where I use noincludes in the content index pages and there seems to be no problem with the transclusions. Just curious what makes the difference. — Ineuw talk 19:20, 28 October 2011 (UTC)

The previous use of <noinlude> for split tables VS. placing table definitions in page headers of the Page ns., to improve their transclusion display has become an issue of some concern to me: In the content index table of Volume 42, I placed the table definition and closing in the header and footer of the page to get proper display in the main .ns transclusion. This is eminently clear and logical, however, in the same sections of volumes 2 to 41, I used <noinlude> and I see no negative effects. For what's it worth, I would be most grateful for an explanation to this mystery, before having to redo 100's of pages of some 40 volumes unnecessarily. Thanks. — Ineuw talk 03:02, 30 October 2011 (UTC)

The header and footer are pretty much just automatic <noinlude> sections. I don't think the server can see any difference between the approaches you have tried. Future editors might be a little confused but I doubt it will be too difficult for them to understand. - AdamBMorgan (talk) 16:17, 30 October 2011 (UTC)

The only "negative" in using noinclude tags in addition to the the default ones present in the header & footer fields is that some folks (primarily IE users) won't be able to edit those Pages: without making a mess (BugZilla#26881). This may be a moot point since they say there is a fix waiting to be implemented however. -- George Orwell III (talk) 16:43, 30 October 2011 (UTC)

The morning after a late night post, after close examination, it seems that transcluded pages created before the 1.18 upgrade seemed to have improved. Earlier, I could always tell the seam and now it looks seamless with <noinclude>. However, in my scheme of things, <noinclude> no longer works on newly created pages. It leaves a major gap, and breaks two columns of the same row.— Ineuw talk 17:42, 30 October 2011 (UTC)

I think that there should be a better way to categorize and list public documents such as state laws and other documents related. I am very new to wikisource so if I become a veteran I might disagree with my newbie self, but it really feels sloppy and hard to find anything in here. Pulmonological (talk) 21:47, 29 October 2011 (UTC)

We have a topical index system in the Portal: namsepace. It is a relatively new system and has a long way to go before it is laid out into a sensible system with full coverage. I would suggest that you take a look at Portal:Law as a starting place. If you have enough works to add, you could even start a new portal using an existing page as a template. We welcome efforts to improve our indexing system! Inductiveload—talk/contribs 22:54, 29 October 2011 (UTC)

It just occurred to me that I haven't mentioned this anywhere, so I just wanted to make a quick note of this template. The idea is to enable perusers looking at an image, who may have never used Wikisource before to be guided through transcription. Maybe someone will be inspired to take the idea and run with it. Try clicking on the "Transcribe this document!" button in this one, as an example.

I made that National Archives-specific edit intro on Wikisource, but it's being invoked with {{transcribe|NARA}}, so that, in theory, we can make a default one, or anyone can make one for another project or work. (Note right now, this only works with documents that are uploaded with a different JPG for each page (so {{PAGENAME}} names the Page: pages right), but it could probably work for DjVu with JavaScript if anyone is so inclined). Dominic (talk) 13:40, 31 October 2011 (UTC)

Do we have a children's category, like they have at Wikibooks? Heyzeuss (talk) 16:28, 1 November 2011 (UTC)

There's Portal:Children's literature. It surprised me a little that that's tucked away: well developed portals (author pages too, come to think of it) should probably get a bigger billing. Maybe something like en.Wikipedia's Main Page header with links to the root portals, and in addition rotated featured content? Prosody (talk) 16:58, 1 November 2011 (UTC)

Sure, but are you thinking of using your particular proofreading method for it? That isn't really suitable for Match and Split texts as we just saw with the Roman History. Also, a Match and Split is only suitable for the above if we can find the same edition of the same C.D. Yonge translation. We probably can but I just wanted to point that out since you said "find an English translation". Any other edition would not be a candidate for match and split.--Doug.(talk•contribs) 06:41, 2 November 2011 (UTC)

I'm seeing the same question in other languages WS over and over again. When will EPubExport be ready? Why is the development frozen since 2010 and WMF is not allocating resources for this important extension? I was wondering if we could call for some more attention, because that is an important tool for everyone using this site.--Micru (talk) 00:48, 2 November 2011 (UTC)

I've seen there is an open bug, bugzilla:29023. If you think it should be prioritized, please cast your vote (1. register on bugzilla, 2. click on "vote" on the bug page, 3. select tickbox, 4. press button "change my vote"). Thank you!--Micru (talk) 01:00, 2 November 2011 (UTC)

Getting Wikisource's projects prioritised is a perennial problem, and a number of us who have asked and pushed have just been are like fleas on an elephant. Basically the message is if we want something developed, then we need to find a developer, most of what we are pushing is not core business. <shrug> — billinghurstsDrewth 02:36, 2 November 2011 (UTC)

Disambiguation page for two authors with multiple collaborations?[edit]

Is it the proper procedure to create a disambiguation page for a pair of authors who collaborated on several articles, as [[:Author:A. Binet and C. Féré]]? — Ineuw talk 03:56, 3 November 2011 (UTC)

I've added code to the header to call {{locked}} for all mainspace pages with protection. This should work with no problems but if something does appear to have gone wrong, can you please tell me. Based on the first time I tried this, the main potential problem will be multiple redundant padlock icons in the top right. Note that this will happen if the locked template is already used on the page. I'll remove those if and when this seems to be working.

Also, I've mostly just made up which padlock icons to use for this template: red for full protection, yellow/plain for semi-protection and green for move protection only. After putting this in place, I've recently noticed that these do not line up with Wikipedia's use of icons; they use plain for full protection and dark silver for semi-protection. Is the current colour selection OK, should we match Wikipedia or should another set be used? - AdamBMorgan (talk) 00:07, 5 November 2011 (UTC)

I lean towards matching Commons unless they don't have it then match Wikipedia, constancy is good. Jeepday(talk) 13:59, 5 November 2011 (UTC)

This is interesting. Can share how you got this (a script?)? --Mpaa (talk) 09:41, 5 November 2011 (UTC)

Here's the basic code: User:Visviva/authors.py. (Could certainly benefit from some fine-tuning.) Hopefully it does not qualify as API abuse; if it does, one could do pretty much the same thing with the DB dump. The script was intended to generate a wiki-formatted list, so to get the TSV, I just ran something like this:

As we have authors sorted by lastname/familyname there is still some difficulty and identifying duplicates with visual inspection based upon {{PAGENAME}}. There is probably scope for doing things based upon subcategories of Category:Authors by alphabetical order, even visual checks work at times. Maybe even by some queries we can look to use DynamicPageList — billinghurstsDrewth 22:36, 5 November 2011 (UTC)

I've recently added the WhatLeavesHere tool to my custom settings and have found it to be useful and stable to date.

I did notice, however, that I also get that tool listed in the Page tools group at the bottom of the main Special pages list. I'm wondering if thiis tool was there all along and everybody has it listed or is it the result of adding the .js pointer to my settings? I'm thinking it might not be a good idea to add it to my personal stuff since it seems it was meant for Common.js. Advice? Insight? -- George Orwell III (talk) 23:36, 5 November 2011 (UTC)

It's supposed to add the page to your Special pages list and the link in the tool box. The reason for putting it in your common.js is so that it's not skin specific and doesn't need adding to each skin a user uses over time. Beeswaxcandle (talk) 23:45, 5 November 2011 (UTC)

Thanks. I see now that the link was not to the site-wide main Common.js. Makes me wonder why some of the other tools/scripts/gadgets floating around can't be formalized and made to appear on Special Pages though. -- George Orwell III (talk) 23:57, 5 November 2011 (UTC)

Maybe this is not for Scriptorium, but I don't see the equivalent of Village Pump over here. It's minor, but I'm wondering why my Login isn't remembered for 30 days - from the same computer - even though I've checked the box for that. It logs me out when I shut down my computer. I've checked my Preferences, but I don't see anything not as it should be. Maile66 (talk) 14:59, 6 November 2011 (UTC)

Have you set any special cookie settings (whitelist, no third-party domains, etc.)? Looking at the cookies I have stored on my browser it seems that a session cookie (enwikisource_session) is set for the domain en.wikisource.org and a 30-day cookie (centralauth_Token) is set for the domain .wikisource.org. If your browser is blocking the latter and accepting the former, then results similar to what you are experiencing would occur. Prosody (talk) 15:11, 6 November 2011 (UTC)

Doesn't seem to be cookies. I do have NoScript, but it has Wikisource enabled. I am only having this issue on Wikisource. Wikipedia and Commons are OK. Maile66 (talk) 16:13, 6 November 2011 (UTC)

It appears that the page status radio buttons are suppressed when editing while logged out (at least on IE8 and Windows XP). Is this purposeful, or is it a bug? I could find no mention of the fact at the obvious places like Help:Page status, which is what leads me to believe it may be an error. If not, I'm not entirely sure I agree with that choice, but we at least be should be sure to explain this properly in the help pages, since many of the readers of those pages will not have created accounts yet. Dominic (talk) 17:36, 7 November 2011 (UTC)

I read "somewhere", "sometime", that this is not a bug; it has been done on purpose. The reason is that proofreading is meant to be done by unique users. Therefore, a user cannot proofread while logged in, and then validate his/her own pages while logged off (or vice versa). Whether or not that's a good idea, is a completely different question... V85 (talk) 20:07, 7 November 2011 (UTC)

It is purposeful. The logic went along the lines of the initial ability to "test" the quality of the edit. In that namespace it is a qualitative decision to say that a work is proofread or validated, and by different people, and that should be applied by an identified account to develop a "trust" in the decision-making process so we can move the editor to a patrolled status. We encourage users to be logged in at enWS, and there are benefits from editing for doing so. The ability to edit is no different logged in or logged out. If our help/descriptive pages in this regard are not currently reflecting that, then we should definitely be updating such pages. — billinghurstsDrewth 20:59, 7 November 2011 (UTC)