Wikisource:Scriptorium/Archives/2012-07

Announcements

Update on IPv6

(Apologies if this message isn't in your language. Please consider translating it, as well as the full version of this announcement on Meta)

The Wikimedia Foundation is planning to do limited testing of IPv6 on June 2-3. If there are not too many problems, we may fully enable IPv6 on World IPv6 day (June 6), and keep it enabled.

What this means for your project:

• At least on June 2-3, 2012, you may see a small number of edits from IPv6 addresses, which are in the form "2001:0db8:85a3:0000:0000:8a2e:0370:7334". See e.g. w:en:IPv6 address. These addresses should behave like any other IP address: You can leave messages on their talk pages; you can track their contributions; you can block them. (See the full version of this announcement for notes on range blocks.)

• In the mid term, some user scripts and tools will need to be adapted for IPv6.

• We suspect that IPv6 usage is going to be very low initially, meaning that abuse should be manageable, and we will assist in the monitoring of the situation.

Read the full version of this announcement on how to test the behavior of IPv6 with various tools and how to leave bug reports, and to find a fuller analysis of the implications of the IPv6 migration.

--Erik Möller, VP of Engineering and Product Development, Wikimedia Foundation 00:53, 2 June 2012 (UTC)

Distributed via Global message delivery. (Wrong page? Fix here.)

2011 Picture of the Year competition

македонски • norsk • polski

Dear Wikimedians,

Wikimedia Commons is happy to announce that the 2011 Picture of the Year competition is now open. We are interested in your opinion as to which images qualify to be the Picture of the Year 2011. Any user registered at Commons or a Wikimedia wiki SUL-related to Commons with more than 75 edits before 1 April 2012 (UTC) is welcome to vote and, of course everyone is welcome to view!

Detailed information about the contest can be found at the introductory page.

About 600 of the best of Wikimedia Common's photos, animations, movies and graphics were chosen –by the international Wikimedia Commons community– out of 12 million files during 2011 and are now called Featured Pictures.

From professional animal and plant shots to breathtaking panoramas and skylines, restorations of historically relevant images, images portraying the world's best architecture, maps, emblems, diagrams created with the most modern technology, and impressive human portraits, Commons Features Pictures of all flavors.

For your convenience, we have sorted the images into topic categories.

We regret that you receive this message in English; we intended to use banners to notify you in your native language but there was both, human and technical resistance.

See you on Commons! --Picture of the Year 2011 Committee 18:13, 5 June 2012 (UTC)

Distributed via Global message delivery. (Wrong page? Fix here.)

Mobile view as default view coming soon

(Apologies if this message isn't in your language. Please consider translating it, as well as the instructions on Meta)

The mobile view of this project and others will soon become the default view on mobile devices (except tablets). Some language versions of these projects currently show no content on the mobile home page, and it is a good time to do a little formatting so users get a mobile-friendly view, or to add to existing mobile content if some already exists.

If you are an administrator, please consider helping with this change. There are instructions which are being translated. The proposed date of switching the default view is June 21.

To contact the mobile team, email mobile-feedback-llists.wikimedia.org.

--Phil Inje Chang, Product Manager, Mobile, Wikimedia Foundation 08:27, 16 June 2012 (UTC)

Distributed via Global message delivery. (Wrong page? Fix here.)

Proposals

Wikisource:Alternate accounts

The following discussion is closed:

Closed as guideline - AdamBMorgan (talk) 13:02, 20 June 2012 (UTC)

I would like to propose that Wikisource:Alternate accounts be formally recognized as a policy or guideline (one or the other). It has been in draft form since 2009. I believe it accurately expresses the expectations of the community in regards to multiple accounts, as has been seen in several discussions. Giving formal status to WS:ALT offers clarify for those editors who are accidentally coming in conflict with these expectations of the community. Please indicate your desire to elevate to Policy, Guideline or other disposition. JeepdaySock (talk) 16:12, 23 January 2012 (UTC)

Policy

• The third paragraph has the explicit "do not sock" and described potential blocking/banning. If it is going to be strong enough to be the basis for blocking, I think it should be considered a policy. Perhaps the softer, guidance elements can be spun off into a separate page or the wording in this one can be hardened? - AdamBMorgan (talk) 12:46, 24 January 2012 (UTC)

Guideline

• guidance the document has should in the first line, which automatically makes it procedural or guidance. I have no issue with the overarching premise or the text. That said, the pertinentn guidance seems to be para 1 and 3, with the remainder information about how to comply. My question then becomes can para 1 and 3 be extracted and put elsewhere to keep the clear guidance separate, either as a lead in to this document, or separating guidelines from the instruction. — billinghurst sDrewth 06:52, 24 January 2012 (UTC)
• Concur with billinghurst, the bits about verboten behavior can be lifted and reinserted into blocking policy, with a reference, and the remainder promoted to guideline. Prosody (talk) 02:08, 25 January 2012 (UTC)
• Agree with the above. Things that lead to blocking belong on the blocking policy page (but should be mentioned here too). Things which are merely best practice belong here. Being made into a guideline offers clear information to readers on the expectation that they follow at least the spirit, but doesn't rise to introducing a new set of hard policy rules. Inductiveload—talk/contribs 06:03, 25 January 2012 (UTC)
• Assuming the elements regarding blocking are moved (or summarised here with reference to the blocking policy), I change my choice to guideline in line with the above. - AdamBMorgan (talk) 13:24, 25 January 2012 (UTC)
• I support making this a guideline. I'm a bit reluctant to make it a policy (I think users should have more freedom for account usage than making it a policy would grant), and with the fact we've got checkusers we can catch many of the devious uses of alternate accounts. But I do think making it a guideline would express our opinion that it's generally best practice to use one account, etc.—Zhaladshar ^(Talk) 21:01, 26 January 2012 (UTC)
• I have moved paragraph 1 and 3 to WS:BP, I also move paragraph 4 to the top position as it seemed to make a better opening with the other two gone. Support for making this a guideline. Jeepday (talk) 21:13, 11 February 2012 (UTC)
• Support guideline status. --Aplomb (talk) 16:31, 25 March 2012 (UTC)
• Support becoming a guideline. I consider making it a policy unneeded.--Jusjih (talk) 18:10, 5 June 2012 (UTC)

Other

• unnecessary - I don't think our editor base is large enough to make any level of formality necessary. Make it a help page, we ought to have one on user accounts anyway, we currently don't have a page on creating an account that I know of and {{welcomeip}} links to en.wp.--Doug.^{(talk • contribs)} 18:47, 10 April 2012 (UTC)

Moments ago I was looking at a welcome page and it states that there are many benefits to having an account. I am aware of the IP addres showing but really, what difference does that make if someone uses a traceroute? It seems as though someone fears something. What would that something be? An IPS has many accounts on it and several IP addresses. What are the other "benefits"? I saw no other benefits aside from one's IP address not showing with an account. My take on it is that a person gets credit for the work they do with an account although that would probably only matter if the person's real name is used on the account. I do understand that some may fear for their job but what would they be doing that is wrong of them to cause a fear of their job? I think the people who just use IP addresses as opposed to accounts are the ones hiding behind the IP address. A question; is not Wikisource like the old Bulletin Board Systems, like I used to run, whereby people typing can be seen by the system administrator when logging in, watched where they go, and what they do? I expect WS does work that way. --Maury, (—William Maury Morris II ^Talk 19:43, 10 April 2012 (UTC)

Well, with an account, you can sign your name easily, be recognizable and social with other users. You can be nominated for adminship. You can adjust various preferences such as appearance of pages and the time zone shown on "history" pages. Noone should be able to trace your actual identity, unless they have access to the actual website logs, or tools which are reserved for "checkusers". You don't seem to feel that's an issue, but many people like to remain anonymous, for one to avoid random people harassing them at their phone number or personal email address. I have been harrassed onwiki when I reverted vandalism, and if that user could have, they might have harassed me otherwise. --Eliyak T·C 20:11, 10 April 2012 (UTC)

Good points all, Eliyak. I was just curious as to what the author/s of that article considered as what constituted "benefits" plural. I have rarely had any problem with anyone harrassing me in that manner but then I have never reverted any vandalism that I can recall. I have seen Billinghurst and Beeswaxcandle having problems with vandalism and I wonder to myself why the heck would anyone want to destroy anything on wikisource. Apparently there is a lot of that destructiveness. My entire concept is to create and build and not to destroy. I've used my real name since about 1992. I have a book on internet now that has been there 19 years and that still shows my real name, the university I attended and the state that university is located in. Emails are easily changed and I personally use sub-accounts so I never get junk mails through my ISP. Too, I suppose some crazy person would stalk someone in real life but good luck to them with me. These works on wikipedia and wikisource are to be archived for future generations. Since I have brought no fame to my family names I make sure that those who did great deeds are known again so therefore I use my real name. My descendants may, or may not care. If they care then information is there. This is a genealogical aspect but it is also like the caveman leaving his mark (handprint actually) on cave walls. The benefits I see are friendships and preserving books. I have always loved reading all kinds of books. History is basically 20 years new to me because science was always my turf. Genealogies have been with me since I was a little boy with my grand-mother teaching me family in history -- old Virginia families and she talked as though they were still living. There is a lot of history in any state's First Families and all states do have First Families. Much of it is amusing, some boring, some fascinating and all in all it comes down to, "What did you do with your life, was it worth anything"? People come, people go, what did they do for others and what did the leave behind to benefit others whether family or not. Kind regards, Maury (—William Maury Morris II ^Talk 05:13, 11 April 2012 (UTC)

One significant benefit to the Wikisource community when a person registers and contributes under a user name, is recognition. This recognition benefit, allows the community to identify that a given contributor who will begin to build a reputation for quality of edits. There are significant resources (volunteer hours) spent monitoring the edits of contributors without a known familiarity with Wikisource expectations. User who contributes under static (unchanging) IP will soon be recognized, but will always be subject to a higher level of review by default as IPs are never promoted off the "need a higher level of review" list. Contributors who have IPs that change, edit with some experience that is obvious to those who monitor contributions, and usually consume a larger percentage of scarce volunteer hours until they are recognized by all involved as returning experienced and trusted contributor. So in short; registration benefits the project and the community by decreases volunteer hours required for the monitoring and training of new editors, which increases the availability of those volunteer hours to contribute value added edits to the project. Jeepday (talk) 11:22, 11 April 2012 (UTC)

Proposal concerning pagequality class

alpha - pagequality class

Ok ok ok. Let's wipe the slate clean and restart from scratch.

My proposal is:

to add a css class so that every wiki-link to an individual page in the Page: namespace reflect the current pagequality level (color status) of that individual page. This class must have a name that is not currently used by any element of Proofreadpage extension. Every subdomain will decide if they want to use this class. If they do, they have to change their common.css as appropriate. If they don't, they get the same situation as before.

Can we agree on this proposal? Candalua (talk) 21:19, 19 April 2012 (UTC) Some initial questions/thoughts....

• Why every wikilink within every namespace? For arguments sake, let's put aside the notion that works not completely proofread are not typically desired in the mainspace by transclusion with a handful of exceptions.

  I cannot come up with any logical reason, save maybe the User's namespace/sandbox for testing purposes, etc., where colored links are useful or a positive addition to the current frame work. From what I can gather, the only possible place where this feature may have some added value is when the <pages> command line is used in the mainspace to transclude a range of pages into one body of text from the Page: namespace. Other than that, reflecting the color status ProofReading level for every instance in every namespace is just annoying (imho). In addition, I imagine that such an across the board behavior would be confusing & hard to explain to the unfamilar newbie too. What other reasons are there to activate colored status across all namespaces besides the obvious main namespace? -- George Orwell III (talk) 23:26, 19 April 2012 (UTC)

Activating classes is not the same thing as enabling colours, so: why not? As shown above, CSS can be used to ignore it except where it is explicitly desired. This is (IMO) how it should work. The classes are merely markers to say which links have which status. The local CSS rules "choose" when to express this as colours. Having the classes does not means having the colours (unless the CSS says so). Furthermore, you can do all sorts of interesting things, such as colour-on-mouseover, statused-pagenumbers, in-order status-bars or list the number of validated pages divided by the proofread ones times by the number of words if you have this info to hand. All of that can be gadgetised, separately. Inductiveload—talk/contribs 02:14, 20 April 2012 (UTC)

I don't know about activating vs. enabling. All I'm asking is if the <pagequality level="#" ...> translates to a class name of quality# in the <pagelist> on the Index: page when assigned by the level of proofreading accomplished on a particular page in the Page: namespace why can't that class-name come along with pagenumber offset to the main namespace? I understand there is corresponding lines in the CSS that translate the quality# class name to a background color & it would be a matter of adding ns-0 those lines to achieve the same in the main IF that class name came along from the Index:'s <pagelist> with the manually assigned page number. You seem to be saying that's impossible; I just don't understand why. If I understood recent advances correctly - its possible to pull attributes and their values such as "name", "img" or "title" from things like full expanded external URLs so I just don't get why we need to fiddle with enabling or activating things across every namespace when it seems we should take advantage of the class-name already in the Index:'s <pagelist> or duplicate the conversion to a class name from the <pagequality level="#" ...> set in the Page: namespace. -- George Orwell III (talk) 03:03, 20 April 2012 (UTC)

OK, I'll go though it very slowly, it's not that hard:

1. The server constructs the HTML for a page on this wiki out of wikitext
2. When it comes across a link to the page namespace, it currently goes "hmm, a pagespace link! what fun! Is the page I am rendering in the Index space? If yes, I shall add information about the proofread status. If no, I won't."
3. You get the index page, and all the pagelinks have the classes applied
4. The CSS, which is local to each wiki says "Ooh, status classes! That one goes red, this one goes green, and these are all yellow!"
5. In the other namespaces, the CSS goes "Oh, no status classes, better move on then"

What Candalua is proposing is that the second step is skipped, all pages get the data, and the CSS makes the decision about when and where it applies the the colours. Currently it slaps colour everywhere, and that is not good. The change that would stop that has already been presented and ignored.

If you want that data elsewhere currently, you currently have to troll off, load up all relevant index pages and parse out the data with regular expressions, or construct a big API call and interpret the returned data. Either one is a complex hack when you can just get the data handed to you, in place, for free, by the server, which has all this data sitting in a vast, fast, efficient database. Inductiveload—talk/contribs 03:45, 20 April 2012 (UTC)

What elsewhere??? Where else would having the color status be useful?? Sorry I just don't buy that the intent is anything but for the pagenumbering alongside/inline with transcluded content in the mainspace. I get that to achieve this, every page namespace based link must inherit the class name indicating quality level from the server and then canceled out via CSS locally if need be. What I don't get is the argument to set the possibilities free so any and all can manipulate this feature when it boils down to doing the same thing pagenum does now plus indicating the PR staus by color. Can't we add the pagenum class along with the quality class at the server level and modify things so that the span actually formats the way it currently does via the same css namespace specific inclusions/exclusions? -- George Orwell III (talk) 04:47, 20 April 2012 (UTC)

The proposal is to add the quality class at the server level. The CSS doesn't cancel out anything, it just ignores the class except when it is told to colour it (index space). Classes and colours are not the same thing. Inductiveload—talk/contribs 15:21, 20 April 2012 (UTC)

• If the above holds true, why add a new class for this? Forgive me if I botch things here - I am not an expert coder.

  The pagenum span class already handles the transclusion of the Index: assigned page number and a given range of Pages:. The <pagelist> command found on every main Index: template not only handles the conversion of individual .DjVu positions to assigned scanned page numbers but also inherits the Proofreading status' quality class & associated color from each of those pages as well. So if the <pagelist> command in one namespace can inherit the color status of individual pages in the Page: namespace why is it so hard to mimic the behavior <pagelist> normally exhibits but in the mainspace somehow?

  The previous implementation prior to the correction (if I'm not mistaken) required something up to 4 or 5 spans to achieve what currently takes two at the most; one of them being the existing pagenum class. Is this because some domains are stuck on dynamic layouts while others no longer use it? -- George Orwell III (talk) 23:26, 19 April 2012 (UTC)

The code that was damaged was the code which applied these classes, at the server end, only to the index namespace. With that code damaged, it was applied to all pages, which the CSS wasn't written to handle, hence colours everywhere. The information is now simply not given for the other namespaces. Because this info is very easy for the sever to give, and very hard to do at the client end without at least a complex API call (which gets a bit problematic when the number of links exceeds the API call limit, which happens, especially in index pages), it makes more sense (again IMO) to add the data to all pages, and let the client side (your brower) figure out what to do with the information. In many cases, the answer would be "nothing", but people on all Wikisources have the option to use it as they see fit, both at a site level (for example, IIRC, noWS and svWS used it to colour the pagenumbers), and at a personal level (gadgets that use the information). Without it, all you can do is not have it.

Pagenumbers are a different matter. I previously proposed splitting the pagenumber and dynamic layout code, as it is not the same thing, and either or both could theoretically be gadgetised. Inductiveload—talk/contribs 02:14, 20 April 2012 (UTC)

I beg to differ - nobody has shown any useful example of anything this color coding could or would provide other than possibly having pagenums behave the same way as found on sister domains but with text-progress boxes instead of colors once transcluded into the main namespace. Describe it however one wishes to - THE issue at hand here is the tiny embedded page number(s) along the margin of a body of transcluded text in the mainspace linking back to their base Page: in the Page: namespace. To say otherwise feels disengenous.

If you say its easier for the server to "dump" this info everywhere rather than selectively envoke it when need or selected via a preference option, then I don't think this is worth it. Again, how many pages are being transclused max. under one mainspace title? 100? 200? Our POS 'pooter can't handle ~200 pages at a time? -- George Orwell III (talk) 03:03, 20 April 2012 (UTC)

What is the negative that you consider to be "not worth it" from adding more information to the served data, given that the data is invisible unless you ask to see it? Plus, consider that some sister domains seem to like having the option, and stripping the classes removes that, for all subdomains.

And no, actually, our dynamic page numbers would not get the classes, as they are added client-side, without the server feeding it the necessary information, hence no colours! That could be added if people wish, but it is in the pagenumbers.js code, and would not even notice the classes being added without someone writing a function into the code to take notice of the classes. Therefore: different matter. Plus, even if it was added, it could be, drumroll, made optional, as you are free to ignore the classes.

The API limit is large, but not as large as some of our books. Making AJAX call(s) for the data (over the API or by scraping the index pages) are more HTTP requests when you could just be handed the data for free along with the page. Inductiveload—talk/contribs 03:45, 20 April 2012 (UTC)

The "negative" seems to me is that this movement is forking the designated function of the pagenum span and its "class/settings" (i.e to display alongside/inline transcluded content linking back to to its orginator pagebreak in the Page: namespace) with some other span and its class that will do the same thing and bastardize the assigned page numbering along the way somehow (back to 4 or 5 spans, some of them hidden or with null values, that will function like the one or two max already in place. I get it, sites not forking the embedded page numbers-to-transcluded-content schem will not be hampered by the other fork (pagenums and its related .js's ) because those portions have been dumped for the new approach but sites stuck with old way of doing things will have the additional bloat of the original regime plus the option to hide most if not all of the new scheme. Either dump the existing convoluted setup for a single new way of displaying embedded page numbers along the margins of transcluded content or fix the existing setup & designations to re-use the already utilized portions. The only way I'd support the change would be for one fork (old pagenum scheme) or the other (new free for all mode for lack of a better term) not both being present or capable on en.WS at the same time. Of course it costs nothing if you're a domain lucky enough to be dealing with just one fork of a single embedded page linking function development, & then templatize or localize or gadgetize as desired without the burden of the still keeping current regime already in place. I don't get the sense we're one of the lucky domains given the current state of things. Would all that be a fair assesment regardless? -- George Orwell III (talk) 04:47, 20 April 2012 (UTC)

Not really, no. At least it is not an assessment of this proposal. This proposal is about adding semantic information to links to the page namespace. Whatever people do with it, in this subdomain or others, from optional link-colouring to adding gadgets that feed on the hidden information, is a different matter. As I said, our pagenumbers won't even be affected, since they are not server-generated links and wouldn't get the classes anyway. If you don't like the pagenumber code, that is another matter. Entirely. The only connection is that page numbers happen to be links to the page namespace. Inductiveload—talk/contribs 15:18, 20 April 2012 (UTC)

• I think it could be useful to indicate to the user the status of a given page of text that has been transcluded to mainspace but not fully proofread. An alternative would be to get the background of the transcluded text itself to be slightly shaded (not proofread, proofread but not validated, etc.) Validated background would remain plain white. --Eliyak T·C 23:46, 19 April 2012 (UTC)

If the classes are present, that can probably be arranged using a gadget that uses them as an information source. Inductiveload—talk/contribs 02:14, 20 April 2012 (UTC)

• Support, as extra information can only be useful. If people don't want to see it, they can just not be used. You can't, however, get at what isn't there, so if people did want it, they are out of luck without it. This change affects all Wikisources, some of which already used the colours to their satisfaction, and no longer have them. However, I don't think we need to create new classes. Applying the old ones to all page NS links and enabling only in specific cases with CSS (example in the 1.19 bug section) is exactly the same, less complex, less breakable and more understandable. The code change is simple: remove two lines, and then every WS is free to implement whichever JS/CSS things they like at the site and personal level. Inductiveload—talk/contribs 02:14, 20 April 2012 (UTC)
• Comment - I am yet to understand the purpose of colouring links to the Page namespace from other namespaces (other than Index - of course). Until I can understand the benefits to WS and the community of doing so, I can't support this proposal. Beeswaxcandle (talk) 06:30, 20 April 2012 (UTC)

This isn't about colouring the links. It's about making the status information available to the browser (so CSS and JS can act on it). At present all this information does is provide a marker for the CSS to colour the links, but if available universally, could be used for client-side processing of the statuses. The colours do not necessarily follow the classes, that is up to the local CSS rules, which can easily be written to colour only in the index space (code has been given for this). This is a discussion about the classes, not the colours. They aren't the same thing at all. Inductiveload—talk/contribs 14:45, 20 April 2012 (UTC)

• comment well I am close to completely lost in all your battle with jargon, and when the conversation gets buried in technical detail. So let us bring this back to a principle, and then let the technical variations flow from there, or be discussed and proposed to the community. So please start again again, and talk in what is the principle of what you are proposing. My basic request is that the outcome of any changes is that the default look for our public-oriented namespaces is default normal text. Any customisation that flows from adding class to the links can then be implemented by gadgets or the applications in their respective namespace. — billinghurst sDrewth 03:25, 21 April 2012 (UTC)

• Exactly. The "classes" are an invisible source of information, nothing more. The proposal allows all page NS links to have an invisible little tag in their HTML which says "this link points to a proofread/validated/etc page". This can then be used for whatever people like. Subdomains can apply site-wide "CSS rules" (which are nothing more than a browser directive to say "hey, you see all those "classes"? If they are in this place in that situation, do something the user can see!") to, say, make their page-numbered coloured (svWS, noWS and itWS all had this system to my knowledge, enWS did not), or individual users can have "gadgets" (tiny, optional, browser-based programs which "feed" on the class information) to do things like Eliyak suggested above. I am not advocating having the status colours in any new places, least of all the mainspace. If the proposal is enacted and the Common.css tweaked to match, there would be no visible change to any page on enWS. I'm sorry if this is still too technical but I'm struggling to explain how it all plugs together without using the names. Inductiveload—talk/contribs 03:47, 21 April 2012 (UTC)
• The claim that this change will make for additional data or information to become available for further manipulation across a site on down to the individual contributor, with little to no difference in appearance, behavior or cost in resources, seems to be 100% accurate. Logic dictates the more the available choices the more the possibile outcomes - I can't argue with that (especially at the technical level). The factor not calculated in with that train of logic, however, is the fact that not all the WS domains are currently building upon the same measurable baseline or standardized frame-work. Yes, every domain should have some level or degree of normal differences from one to the next, but I'm talking about differences that go beyond what one would normally expect from site-to-site; ones that make any assesment of the pros & cons involved here skewed enough to invalidate the typical perception or assumption that a net benefit for us specifically as the result of implementation would be on parity with others generally. That chasm between the foundations from one sister-domain to the next is also the reason behind why nobody has presented any serious ideas or examples for what to do with this new found data in spite of fact that the logic behind supporting the proposal is spot-on overall. Sadly for us, the truth is many choices will never materialize in full, if in any way, shape or form at all.

  Here is briefly why: We still nurse on oldwiksource's teat for importing the supplemental scripts & junk to the "stuff" being used universally by everybody currently on the servers for some reason; other sites import only some of that supplemental stuff if any of it whatsoever. We have a standing policy that promotes proofreading be completed prior to mainspace transclusion with few exceptions; other sites beg to differ with us policy & practice wise on that same point. We wouldn't be able to color code our embedded Page: links with the PR status level even if it wasn't contrary to our local policy - couldn't do it even if the majority of our community demanded it; other sites, however, don't use the pagenum class and MediaWiki template as we are forced to & still more don't deal with full blown dynamic layouts the way we have to. Those sites falling into that kind of starting baseline, ones so different from our's currently, will of course be able instantly utilize the new data rather easily. End of story.

  That said, I'm more inclined to toss "principle" in the trash at this point and support the proposal even if it only serves to further drive a wedge into the notion that old wikisource is still some sort of community hub for overall positive development for all the Wikisource domains out there, big or small. Quite the opposite has been slowly taking place in my view and this particular conflict for or against implementation is just another unintended consequence born from its continued utilization (development wise that is). Anything universally salvagable that is currently hosted on old wikisource should be formally made part of the "stuff" already up on the servers whenever possible and any remaining bits & pieces folks are absolutely hooked on having should be made into gadgets for optional and/or local use only. Taking these few initial steps won't resolve the current divide between the sister domains and en.WS but it sure will lessen the gap from that point on. -- George Orwell III (talk) 11:11, 22 April 2012 (UTC)

• comment: sorry for not replying, but I just don't have the time to read all this. Thanks to Inductiveload for his constancy in replying to all comments. Candalua (talk) 20:39, 21 April 2012 (UTC)

(BTW, I see that my original message was slightly changed by someone else - look in the history to find who did it. Maybe it was done with the intent of clarifying things, but I think it's not polite to change other people's messages.) Candalua (talk) 20:46, 21 April 2012 (UTC)

• It appears to me that GO3 has lifted his opposition and that this discussion (which I rather think should've taken place at the multilingual wikisource) can be closed with a bugzilla to activate the class. The local css will be modified as necessary to maintain the status quo as far as the appearance of non-index space pages (i.e. en.ws will not enable the colors), as local enabling has not been directly discussed and there would be clear opposition. It has been less than 24 hours since the last post by GO3 on this matter and he's not currently active, so I will wait until a reasonable time after he is next active before filing the bugzilla, in case I've misinterpreted him.--Doug.^{(talk • contribs)} 08:03, 23 April 2012 (UTC)
• Oppose -- Address the stuff about the pagenum class & div containers (on the ToDo list) before adding more crap to the extension to achieve uniformity throughout our sister language WS sites first. -- George Orwell III (talk) 18:47, 7 June 2012 (UTC)

bug 36979. Candalua (talk) 21:01, 19 May 2012 (UTC)

Proposal to implement account registration for editing and posting

I propose that users of en.wikisource should be registered to edit pages and post messages. This would eliminate this blanking nonsense.— Ineuw talk 20:20, 17 June 2012 (UTC)

I totally agree with Ineuw's proposal. —William Maury Morris II ^Talk 20:30, 17 June 2012 (UTC)

I looked at recent changes for anonymous editors. 4/37 were disruptive. Some of those 33 likely will not make the transition to an account. Is it worth it? Not a rhetorical question, I'm not sure how to weigh the utility of anonymous contributions vs. the disutility of admin time wasted. Prosody (talk) 20:36, 17 June 2012 (UTC)

It doesn't appear that it is worth it when looking at those stats but then again how disruptive are those 4 out of 37? You can have 33 people contributing very little and four of those 37 disrupting a lot. So, there is yet another point to consider. I cannot see the stats nor count the disruptions or the degree of disruptions. Too, why is anyone reluctant to create an account even with an alias? By posting without an account their ISP (IP) shows.—William Maury Morris II ^Talk 20:51, 17 June 2012 (UTC)

I don't know the psychology around it but it's a truism of UX that any sort of hurdle reduces the conversion rate. Prosody (talk) 21:09, 17 June 2012 (UTC)

UX is an interesting topic that I have not read before today but it is also certainly about psychology. It reminds me of TA. Your points are certainly valid and important. Like you, I don't know what to do either and I do not think Ineuw talk can figure all of these variables out -- nor anybody else here. Perhaps those who just post are reactionists. When they spot something they immediately post without having to bother with registering and signing in. I wonder if they know they can post with an alias as opposed to their real name but that should be obvious to them. I think those who do not register and post with an alias or real name just don't want to bother logging in and/or being tracked. Too, they could be using a computer in a library. It appears that the situation is too complex for a reasonable answer. Respectfully, —William Maury Morris II ^Talk 21:30, 17 June 2012 (UTC)

Prior to creating this proposal, I considered the legitimate contributions of anonymous users, but they not really are to the powers that be. Correct me if I am wrong, there are some with user pages. I respect anyone's wish not to be contacted or be "known", but let them sign up with their IP number if that's possible. Personally, I think it's an oxymoron to participate in a community effort anonymously.

As for the disrupters, they really do disrupt. With some past repeat offenders, I looked up their IP and sent a simple email, ask their ISP to pass on the the message to stop from blanking pages. It stopped. This works in Western countries, but not with formerly Iron curtain countries like the Ukraine or Moldova, where this last disruption originated. 21:32, 17 June 2012 (UTC)

Who is the most destructive and offending, the Western nations where you can contact their IP, or the former Iron curtain countries? Can you have the former iron curtain countries sign up and not do the same with the Western nations? (Probably not) Respects, —William Maury Morris II ^Talk 21:45, 17 June 2012 (UTC)

I can't tell you, but it's probably an even breakdown. These are kids who do this, as they surf the web. I would write to formerly iron curtain ISPs but they have no abuse or any email address listed, and doubt if they care, (or even speak English). EU countries' ISP's seem to care, since none of the "blankers" (3 - 4) to whom I sent a message returned to WS. I used RIPE, but there are many IP lookup services. If you look up this last address, it's blocked and it seems to be a "private" ISP with the domain suffix .md, which is Moldova. Finally, I didn't, and don't want to be a policeman, I just wondered whether sending a simple note to their listed abuse@ email address helps (all of the western ISPs have one). — Ineuw talk 22:29, 17 June 2012 (UTC)

I regret that you and others have this problem. I also understand not wanting to be a policeman although I was one (and later a P.I.) for a few of years after Vietnam. Good laws need to be enforced, the good people must be protected, especially the women and children. Since you state that they are kids I don't see where you have any options other than what you already do. Some kids like to explore what they can do and get away with. I sincerely do hope that correcting what they try to destroy is not too difficult to repair for our administrators here. Personally, I would want everyone to register but Prosody made some good points with his ratio stats he posted. I regret any of you have to go through nonsense when with your wonderful expertise you are side-tracked by destructive foolishness. It is because of these things that I write, "Respectfully", because I know you fellows go way beyond what the rest of us see and do. FWIW, if you can find a way through the situation and your proposal I fully support your idea regardless of the other 33 people because they can either register as we here have or leave. Only then there will be Peace for our WS administrators to work constructively without that particular aggravation. Imagine how much good work could be done if you were not side-tracked by someone blanking pages and whatever else they do to destroy what others endeavor to build. I wish I could help. I have tried that here. Most respectfully, —William Maury Morris II ^Talk 23:11, 17 June 2012 (UTC)

Reverting the occasional vandalism we see here is not solely an administrator's function. If you see it happen, revert. If it is happening repeatedly to the same article, then let the administrators know on the Noticeboard (WS:AN) and one of us will deal with it with appropriate blocks and/or article protection.

The vast majority of IP contributions are useful and appropriate. They include fixing spelling and OCR errors. The fact that many of these are "drive-by" contributors who may never become members of the WS community is not important, what they have done is contribute to the accuracy of the works we hold—and that is a good thing. Restricting access based on signing in is against the ethos of the Wikimedia sites, at the same time this is why some of us do patrol recent changes. Also, signing in doesn't guarantee good behaviour. We have more problems with signed in accounts that turn out to be cross-wiki spammers or spambots, then we ever do with IPs.

In summary, I don't support this proposal. Beeswaxcandle (talk) 01:27, 18 June 2012 (UTC)

I echo Beeswaxcandle's comments wholeheartedly - though I wouldn't go as far as to say a vast majority are useful and appropriate. A majority are indeed useful and appropriate, a noteworthy number are simply beyond determination since they are made to works that are not backed by scans never mind easy-to-verify sources and the rest are pure spam or pointless drivel. Hesperian's comment below is also an unshakable fact.

If one wants to make a difference - get involved like Bees said. A tightly run ship is hard to sink. Contribute to policy discussions, voice your opinions and hold management accountable whenever the opportunity or situation to do so presents itself.

As far as these recent blankings here go, there is little we can do to pevent them. Its obvious that English is not their first language so they are probably being pointed here through some inter-language-busybody johnson who thought it would be good idea to link languages that are listed but not actually fluent in and left it up to up to fate, not diligence, to monitor the activity resulting from such connections. Next time someone wants to bot the the Earth with inter-language links, I say keep this fact in mind before making your decision to support or oppose the flag. -- George Orwell III (talk) 05:31, 18 June 2012 (UTC)

"A tightly run ship is hard to sink." So true, George Orwell III, I was on a ship (Destroyer) that took me all the way to Vietnam and storms at sea are beyond imagination! and we were totally underwater at times. When we bobbed to the surface the destroyer in front of us was gone and the ocean was leveled off. But the weather was calm for HMS Titanic and how fast was it that "tightly run ship" sank? Lots of situations can destroy a tightly run ship. Hesperian has the proposal covered below in his statement. Aside from that, "It was the schooner Hesperus, that sailed the wintery sea; and the captain had taken his little daughter, to bear him company..." But like those on the HMS Titanic, they also froze to death. Respects, —William Maury Morris II ^Talk 06:18, 18 June 2012 (UTC)

Forget it; it ain't gonna happen. Local sites don't have standing to overturn one of Wikimedia's founding principles. Hesperian 01:40, 18 June 2012 (UTC)

• FYI - this idea gets brought regularly at Wikipedia, we have something we want to protect and forced sign up seems like a good idea at first... So aside from the fact that it "ain't gonna happen", you did good bringing the idea here, and discussing it and considering it! Don't let those of us with many miles on us discourage you from trying out ideas on the community. The discussion by those here who are not admins, shows the expectations of admin in the community. Keep up the good work, and if any of you decide you would like the extra tools, let me know I would be glad to nominate any of you. JeepdaySock (talk) 15:34, 18 June 2012 (UTC)

Really thanks for all the comments. It's important that such issues get aired out on occasion. I respect the founding principles, otherwise I wouldn't be contributing. But, I also know from life experience that nothing is written in stone, and a more realistic opinion is that the people who wrote the founding principles are not the ones who are being disrupted, since they are not the editors, unless of course, they are the anonymous contributors. :-) — Ineuw talk 16:47, 18 June 2012 (UTC)

Special:Tags is used to label blanking edits, and it is pretty easy to recover pages, especially when we have edit patrolling in place and looking functional. Locking down the site to prevent anonymous edits, or slight vandalism would be deleterious and clearly against the open edit philosophy of the Foundation. We can quickly put an end to the vandalism that is around and continues. — billinghurst sDrewth 12:12, 29 June 2012 (UTC)

• Oppose. One of our admins edited as an anon until the time they were nominated to be a sysop. Wikisource:Administrators/Archives/ResidentScholar. John Vandenberg ^(chat) 14:29, 29 June 2012 (UTC)

An international effort

At least, we should be content that the blanking is truly an international effort and this only shows our universal scope and popularity. So far in the last month we had page blanking from the Ukraine, Russia, Hungary, Poland, Germany, Great Britain and Washington D.C. and this last contribution was from Brazil. All of this makes me wonder - the activity is progressing from east to west and now it's heading to the southern hemisphere.— Ineuw talk 16:32, 11 July 2012 (UTC)

Other discussions

Cuneiform

Take a look here: w:Cuneiform#Syllabary. This is the English Wikipedia article about Cuneiform.

Now take a look here: User:Amire80/Cuneiform. This is a page here in the English Wikisource. Its contents is the same as of that Wikipedia page.

If you are like most people, then you will see squares or some other garbage instead of Cuneiform in the first link, and if you use a reasonably modern browser, then you'll see a Cuneiform characters in the second link.

That's because a few minutes ago, the Wikimedia Localization Team deployed Cuneiform WebFonts here on Wikisource.

We hope to deploy them in the English Wikipedia in not-too-distant future.

Now if only someone who knows Cuneiform could transcribe this book, which has pages like this... --Amir E. Aharoni (talk) 19:02, 5 March 2012 (UTC)

Or who wants to learn one of the earliest known forms of written expression, You don't need to know the language to start the transcription. JeepdaySock (talk) 11:47, 6 March 2012 (UTC)

That's absolutely right, I transcribe Latin, French, and German, even though my German is not good, my French is worse, and I've never learned any Latin and I've played around with transcribing some others.

BTW, there is a problem with the DjVu, there may be missing pages because the text layer on the above linked page (451) does not match the scan.

Also, I do wonder if the work really belongs here or shouldn't be on mul.ws as it contains multiple languages and is going to be far from easy to use interwiki transclusion on (which is a poor work around to messy problem to begin with). I understand that the introduction is in English but that doesn't change anything. I'm starting to think all multilingual works belong at mul.--Doug.^{(talk • contribs)} 07:57, 3 April 2012 (UTC)

In this case, it is an English book about Cuneiform, with the latter limted to some examples, so en.ws is probably appropriate here. - AdamBMorgan (talk) 11:23, 3 April 2012 (UTC)

Little by little I have been working on matching the scans of the book mentioned above. Daytrivia (talk) 00:54, 6 June 2012 (UTC)

Trial of thumbnail regenerator — volunteer testers?

I have asked one of the gadget developers at Commons to assist adapt a tool for our use.

The current problem is that when in transcription mode with Proofread Page, there are occasions when the image is not generated properly, and it is difficult to purge the thumbnail. This application adds a PURGE tab to the top right in vector/monobook skins, which should then purges stubborn image file. To identify where and when is needed is a little sporadic as we don't know when the thumbnail generators for commons will play up, hence the call for vols, and to request your feedback. [Note: Only tested in monobook and vector skins]

To trial the application, add the following text to your file Special:MyPage/common.js

// test of thumbnail regenerator [[File:User:Rillke/forWikisource.js]]
mw.loader.load('//commons.wikimedia.org/w/index.php?title=User:Rillke/forWikisource.js&action=raw&ctype=text/javascript');

Please provide your feedback, so I can look to how we can update, preserve and manage the gadget. Thanks. — billinghurst sDrewth 03:23, 6 May 2012 (UTC)

Curious - how is this any different than having the clock-purge gadget installed? -- George Orwell III (talk) 11:33, 6 May 2012 (UTC)

The clock purge doesn't (well hasn't been, though I am not going to cross-my-heart) purge thumbnails, because of the different way that thumbnails are generated within djvu files within ProofreadPage. — billinghurst sDrewth 12:49, 6 May 2012 (UTC)

Gotcha, Thanks. After loading it, I see it is mucho different alright. Still no joy however. Remember this one?

from this page on the scans are no longer visible in edit mode

Go down 1 page or more from the above, and the thumbnails are fine in edit mode. Reposting the previous comparison using "full" commons file path...

• https://upload.wikimedia.org/wikipedia/commons/thumb/3/31/Popular_Science_Monthly_Volume_44.djvu/page633-800px-Popular_Science_Monthly_Volume_44.djvu.jpg 800px thumbnail
• https://upload.wikimedia.org/wikipedia/commons/thumb/3/31/Popular_Science_Monthly_Volume_44.djvu/page633-1000px-Popular_Science_Monthly_Volume_44.djvu.jpg 1000px thumbnail

I still say its hardly ever the cache (save for those times when our servers are stretched to thier limits or when somebody's browser is in a funk) but some flaw in the interaction between the wikicode and the djvuLibre-type package used to generate these images for certain djvu files but not others.

We've discussed this before - the specific wikicoding related to this seems less than optimal to put it nicely and my bet the same is true for the DjvuLibre "package" currently in place too. All I know is at some point many months ago this kind of thing stopped happening on my local install after upgrading to latest build at the time. -- George Orwell III (talk) 13:38, 6 May 2012 (UTC)

If you change the pixel size on the thumbnails above or below 1000 (997, 998, 999, 1001, 1002,...) you will see that they are generated fine, which says that there is something wrong with the generation of the thumbnail. This gadget basically takes that principle for regenerating a thumbnail one pixel larger and displaying such, so whether it the production, or a cache of a problem, this is a resolving process. — billinghurst sDrewth 11:23, 7 May 2012 (UTC)

So "Purge" is a bit inconsistent with what is actually taking place - I get it now. Well it works, for a instance at a time that is. Close and re-open the same page; same problem. Close and open the following page; same problem.

Thanks for the effort. I will stick to changing the resolution on the Index: page however. -- George Orwell III (talk) 23:14, 7 May 2012 (UTC)

The script does the following:

1. Send a purge request to Commons if your browser allows that (some browsers limit even sending cross-site XHRs while others send the request and discard the response if a special response-header is missing)
2. Request a new thumbnail, +-1px compared to the previous one
3. Append a random number parameter to the requested image (just in case your browser has cached an old version)

The script can't

1. Purge your browser's cache (if someone knows how to accomplish, let me know on Commons) If you encounter that after Shift-reload, you get the right image, I could build-in automated page-reloading window.location.reload(true) after clicking the purge-tab
2. Catch server errors. If the server refuses to purge the images, there will be no way

-- Rillke (talk) 14:27, 15 May 2012 (UTC)

Currently it does not work because the purge API module was disabled on Commons by T. Starling. -- Rillke (talk) 12:40, 22 June 2012 (UTC)

Guidance is asked on some pages' proper namespace

I moved this page: Wikisource:WikiProject Popular Science Monthly/Uncategorized recurring titles from the main NS to the project, which seemed to me the proper location. Consequently, I am not sure if the pages listed on the page should also be moved from the main NS to the project NS, since the final lists are all in the main NS.— Ineuw talk 18:29, 18 May 2012 (UTC)

To me the collected pieces either belong in the Portal: namespace, or categorised. Definitely not fodder for the main ns, and I would have only put them as subpages of the project pages if there is sense to have them identified with the project side of the transcription, and it is not evident to me that this is the case. — billinghurst sDrewth 15:48, 19 May 2012 (UTC)

Thanks for the input. After re-examining the list, I realize that re-organization is in order. I will re-visit this post later.— Ineuw talk 03:54, 20 May 2012 (UTC)

Categorization is preferred

After studying the options, categorization is the most sensible and the simplest solution. Below are my general indications for the category names, but there are better qualified and experienced people here, to suggest more appropriate category names.

• The category groups indicate that the various section titles contain similar types of information, and only the section titles were changed over time by the publishers.
• The information in the sections don't follow strict organization and often cross over to the other sections. — Ineuw talk 02:43, 22 May 2012 (UTC)

Sections	Category
Correspondence	Popular Science Monthly letters to the editor
Editor's Table	Popular Science Monthly editorials
Literary Notices	Popular Science Monthly literature reviews
Scientific Literature	Popular Science Monthly literature reviews
Publications Received	New publications announced in Popular Science Monthly
Fragments of Science	Popular Science Monthly Scientific and academic news
Miscellany	Popular Science Monthly scientific and academic news
Progress of Science	Popular Science Monthly scientific and academic news
Entertaining Varieties	Popular Science Monthly scientific and academic news
General Notices	Popular Science Monthly scientific and academic news
Shorter Articles	Popular Science Monthly scientific and academic news
Minor Paragraphs	Popular Science Monthly scientific and academic news
Notes	Popular Science Monthly scientific and academic news
Obituary Notes	Obituaries in Popular Science Monthly

Categorization was preferred but cannot be used

Unfortunately, Categorization would have been the simplest method of organizing the above list, but this created unacceptable ambiguity, so I created the Portal:Popular Science Monthly and the above list will be placed there.

I also noticed that portals are used as expanded categories. Am I correct? — Ineuw talk 20:26, 4 June 2012 (UTC)

Purpose of soft redirects

Hi. I'll start by saying that I'm a very infrequent contributor here. I just came across the English Wikisource's practice of taking MediaWiki-generated automatic redirects (as the result of a page move) and turning them into "soft redirects" and then subsequently deleting the soft redirects. I searched the Scriptorium's archives and read previous discussion about this, but I'm still left wondering why in the hell anyone would ever do this. Can someone please explain this practice to me?

An example page would be: Author:James Graham, Marquess of Montrose. This page was moved and then "soft redirected" and eventually this page will be deleted (according to the top of Category:Soft redirects/March 2012). Why not just leave the redirect in place? This is baffling. --MZMcBride (talk) 22:06, 30 May 2012 (UTC)

In the example you give, the redirect should have been left in place.

Unlike Wikipedia, we have a great many works that are structured into subpages. e.g. War and Peace, War and Peace/Book One, War and Peace/Book Two, War and Peace/Book Three, and so on. When we have to move a work to a new title (e.g. to disambiguate), all of these subpages need to be moved. The root redirect should remain (or become a disambiguation page), but the subpage redirects are pointless and should be deleted. Our use of temporary soft redirects allows a period of grace for external sites to update their deeplinks before we break them.

Hesperian 00:38, 1 June 2012 (UTC)

They're not pointless, they redirect the user to the content they're after from old links. Nobody is reading the notice you all put up for a few months before the redirects are deleted. And deleting the redirects actively harms the project and its users without providing any benefit, as far as I can tell. So why does this practice exist? --MZMcBride (talk) 21:17, 3 June 2012 (UTC)

Apparently the people who pass through that redirect count as valuable readers when it comes to measuring the harm of deleting it, but count as "nobody" when it comes to measuring the efficacy of soft redirects.

A mental exercise for you, MZMcBride:

1. We post the book "Blah" by Joe Bloggs at pages Blah, Blah/Chapter 1, Blah/Chapter 2, etc.
2. Later, wishing to post the book "Blah" by Joe Smith, we move Blah to Blah (Bloggs), Blah/Chapter 1 to Blah (Bloggs)/Chapter 1, Blah/Chapter 2 to Blah (Bloggs)/Chapter 2, etc.
3. We then post "Blah" by Joe Smith at pages Blah (Smith), Blah (Smith)/Chapter 1, Blah (Smith)/Chapter 2, etc.
4. And finally we convert Blah to a disambiguation page listing both works.

What then should be do with Blah/Chapter 1? You would leave it as a redirect because historically Blah by Bloggs was posted first? Even though that title is now ambiguous? Or would you convert it into a disambiguation page? What if both Blahs have a hundred chapters? — create a hundred disambiguation pages?

Wikisource practice is to remove the subspace of disambiguation pages altogether. I am satisfied that this is the best approach.

Hesperian 02:02, 4 June 2012 (UTC)

I don't really follow that logic. A redirect with an ambiguous name is bad because it confuses readers, but a deleted page is an improvement? It seems to me that in the case you are describing, there is actually not a high chance of confusion, since you are likely to get to one of those ambiguously named pages by following an (unambiguous) inbound link. These are the people harmed by the deletions. I think MZMcBride's point is that the ones following links are not the ones who wrote the content with the link and have the power to update it. I don't think we should rely on others to proactively update their content, anyway; the web doesn't work like that. I do think leaving a normal redirect is better, even for your example. A disambiguation page might be useful, but I'm not sure it's necessary; perhaps all the chapter pages could be redirected to Blah (the single redirect page) if we are really worried about ambiguity, but that still breaks link chains. Dominic (talk) 18:22, 5 June 2012 (UTC)

I once thought along the same lines you've laid out above, but after many many months of pointing folks here for one thing or the other in other forums & in e-mails, one thing became abundantly clear; people are lazy. Nobody searches for Blah, Chapter 7. They search for Blah and that is why there is no point in preserving any old chains or redirecting x number of sub-pages. Once there are 2 or more works of the same (or similar enough) Title(s) being hosted on WS, disambiguation at the base-page level only makes the most sense for folks landing here as result of a search.

For those landing here because they are following a prior link chain that is now broken because some sort of renaming/moving has taken place since the chain was first established, the amount of confusion really depends on the user at that point. As long as contributors use the edit summary field to properly detail their moves &/or changes (see the pink-ish infobox), and as long as visitors can read carefully, there is little chance for confusion in reality. -- George Orwell III (talk) 23:32, 5 June 2012 (UTC)

Gazetteer

Hello! I know about a copy of the Gazetteer of the city Hisar available on a government website. It was published in 1883-83. Is it free? Can I upload it here? Vishal14k (talk) 18:38, 1 June 2012 (UTC)

Any thing published before 1923 is free {http://copyright.cornell.edu/resources/publicdomain.cfm], Jeepday (talk) 23:40, 1 June 2012 (UTC)

Follow up question [1] brought to Wikisource:Possible copyright violations#Gazetteer

Help with Index formatting

I would love some feedback on how to format the Index that I am working on...in particular issues that come up like at the end of this page. Thanks! Londonjackbooks (talk) 17:47, 2 June 2012 (UTC)

Hi. I did a hack using directly style tags to keep text in pages where it belongs (cons: if {{outdent}} is changed, that line will not change). If you go for this, probably is better to adopt a uniform approach? Maybe a better solution is to copy in page 179 text from the following page and do not include it in p180. BTW, I do not think outdent is needed for the indented entries, as you already use ":".--Mpaa (talk) 09:50, 3 June 2012 (UTC)

Thanks, Mpaa. I used outdent for the indented entries as well because that is how text is rendered in the original when a line is "too" long (even with the indented lines). I think the Index looks good now in the Main from what you've done—unless you think it would be better to implement one or two of your above suggestions (which I am still trying to decipher—i.e., understand!)... Londonjackbooks (talk) 17:04, 3 June 2012 (UTC)

What I meant is that my hack, as is now, is not future-proof. {{outdent}} uses 3em as default for indenting. I have have used directly<div class="tiInherit" style="text-indent:-3em; margin-left:3em;">. So, if someone will change {{outdent}} and set default to e.g. 5 em, then the alignment of my hard-coded line will be wrong. Unless you either explicitly set the parameter to 3em when you use the template, or use <div class="tiInherit" style="text-indent:-3em; margin-left:3em;" instead of the outdent template everywhere else.--Mpaa (talk) 13:24, 3 June 2012 (UTC)

Thanks; I think I understand. Londonjackbooks (talk) 11:32, 4 June 2012 (UTC)

Footnote in a footnote

On Page:The Works of William Harvey (part 1 of 2).djvu/11, there is a footnote within a footnote. What should I do to fix it? - Lucyrocks=) (talk) 13:07, 4 June 2012 (UTC)

Done — billinghurst sDrewth 15:40, 4 June 2012 (UTC)

A marvellous book but no time!

Hello,

Here is the book but it ought to be read before the 5th of June, so in such a case I suppose Wikisource can offer the pdf file alone. What can we do? --Zyephyrus (talk) 23:12, 4 June 2012 (UTC)

Would it be possible to quickly port Commons' ImageAnnotator? Prosody (talk) 00:34, 5 June 2012 (UTC)

I came up with a cheap and easy transcription method based on how we currently do comics and linking users directly to the page namespace (gasp). On a serious deficit of sleep right now but I'll try to proofread the entire thing in about six hours if no one beats me to it. Prosody (talk) 02:20, 5 June 2012 (UTC)

The file has been deleted on Commons because it had a nc (non commercial) element in its licence, so we can’t do anything. Sorry Prosody, I had not seen it. You can find it in the external links of the WP article. --Zyephyrus (talk) 15:16, 5 June 2012 (UTC)

Dutch wikisource

The Dutch wikisource is trying to start working in a professional and decent way with the djvu files. We encounter many problems with this, is there anyone interested in helping us out with the technical aspects of this? We have some experienced users but most of us are new to this, so we don't know, yet, how everything is working and how to change certain things. Some examples of problems we encounter are: we do not get the colored page links on an indexpage: [2], we don't have the easy to navigate arrows at the different pages [3] etc. Can someone explain or help implementing these features (and other usefull things as well)? Asacha (talk) 15:25, 6 June 2012 (UTC)

For the colored page links (on an Index page or elsewhere) see bug 36979 on Bugzilla. You can help voting to give priority to this bug.

The links to the previous and the next page don't appear because Index and Pagina are not real namespaces, but just pseudo-namespaces. You can request the creation of these two namespaces by entering a new bug about this. At first you need a Bugzilla account (if you don't have one). If you can't or don't want to do this, leave me a message (here or at the Italian Wikisource) and I'll do.

I don't know Dutch, but you can use English or French with me. Soon, Erasmo Barresi (talk) 13:58, 7 June 2012 (UTC)

I now filed bug 37482, asking for the namespaces to be created. --LA2 (talk) 06:56, 12 June 2012 (UTC)

Also, some of us sit in the #wikisource irc channel at freenode (link at top) and are happy to help if that is of value. — billinghurst sDrewth 08:02, 12 June 2012 (UTC)

Thank you very much for the help so far, for filing the bug report and the support. Concerning the additional namespaces I've created the (bureaucratic?) poll, very soon you'll have some votes for this. If there are more, quick, questions, I will ask them in the irc channel. Hopefully these namespaces will help us a step further in the development of the project! Asacha (talk) 17:55, 12 June 2012 (UTC)

Thank you for your bug report.

The new namespaces are now deployed, as you can see on this search form. --Dereckson (talk) 09:30, 13 June 2012 (UTC)

Now that the namespaces are in place, how do we get nl.wikisource in the list at http://toolserver.org/~phe/statistics.php ? --LA2 (talk) 21:29, 14 June 2012 (UTC)

Ask Phe.--Erasmo Barresi (talk) 09:24, 21 June 2012 (UTC)

Thanx a lot for helping us! For now one more question: thde yellow marks (proofread/proefgelezen) and the grey ones (no text) on the Index-pages are now alright (see for instance: this index, but the green ones (validated/gecontroleerd) and pink ones (not proofread) are not visible. Does anyone know how we could change that? - Dick Bos (talk) 21:44, 16 June 2012 (UTC)

If x Then y

I have some small but perhaps important questions regarding proofread of the month where several people work on a book. (1) If we see this word :—word should we copy that exactly or should we use this word:—word? (2) When we see the quotes removed from the word, as in, " Example... should we place those double quotes closer to give "Example... (I ask this because sometimes there are a lot of quotations close to one another.) (3) If the book is a proofread of the month, where editors work differently, should we all conform to the book or to what we so often do on WS. i.e. a "gap" for indentation preceding first word of a sentence or no "gap" preceding an indented word? There are other simple situations I have come across but do not recall at this moment. I thank whomever is willing to share their knowledge for the sake of others. —William Maury Morris II ^Talk 21:09, 7 June 2012 (UTC)

This is my personal opinion and other editors may well disagree. Our intention is to make works accessible and searchable rather than slavishly reproduce the printed page. If it was just the last, then sites that provide scans of those printed pages such as Internet Archive do a good job of that. Making works searchable often means using modern orthography, so we should always remove the space between punctuation such as : or " and the word they belong to.

Indentation of the first word of a paragraph is used in books to help the eye move through a work. The alternate method of distinguishing paragraphs is to make the leading between paragraphs greater than that within the paragraph. The two methods should never be used together. Because the wikimedia software uses the second method we (generally) should not use {{gap}} at the beginning of a paragraph.

With respect to co-operative editing, if there are exceptions or special formatting requirements for a particular work they should be noted on the Index Talk page with a note on the Index page asking editors to refer to the Talk page for instructions. Beeswaxcandle (talk) 07:59, 8 June 2012 (UTC)

Thank you, Beeswaxcandle. I remove the spaces with word ; word : word " &c. but I have seen the books doing the opposite so often that I was getting concerned if I was making mistakes by closing those spaces. I am not inclined to use {{gap}} at the beginning of a sentence because we use a blank space between paragraphs so we need no indentation. I have also see that various editors use various methods and it was bothering me that I was making mistakes. I at least want to correct the simple situations. I was not thinking of how the software works but rather I was thinking and wondering about different editing methods in one book i.e. book of the month to be edited. Too, a few days ago I started using {{gap}} when I came across a letter written by a man to his home and friends all-the-while wondering if that should be done. In that I did not use {{gap}} with the author's writing—only when there were letters to someone. I got weary of wondering about all of these and thus my questions. Again, I thank you ever so much. Now I can edit with more peace of mind thanks to you. Humbly & respectfully, —William Maury Morris II ^Talk 08:35, 8 June 2012 (UTC)

ISO or IPA version of a non-English work Accepted?

I want to know that is it possible to upload either ISO version or IPA version of a 19th century Tamil work here in English wikisource. So that the phonetic version is readable although the contents can't be understood. Thanks. Vaikunda Raja (talk) 18:14, 10 June 2012 (UTC)

Generally only English Language works are placed on the English Wikisource, except where is translation to English existing or where one it will be translated, see Wikisource:Translations. JeepdaySock (talk) 10:32, 11 June 2012 (UTC)

It should also be pointed out that there is a Tamil Wikisource, for works in the Tamil language. Dominic (talk) 16:06, 11 June 2012 (UTC)

News?

On the front page of WS there's a link News which leads to Wikisource:News.

The first item is "Wikisource:Featured texts for June 2010". This doesn't give a very good impression of the health of the endeavour. Should the front page link be removed or is someone prepared to take on the task of refreshing it regularly? Chris55 (talk) 09:54, 19 June 2012 (UTC)

Rem'd out "News" — billinghurst sDrewth 12:58, 19 June 2012 (UTC)

Wikimania in DC

I'll be there. Anyone organised enough to get us on http://wikimania2012.wikimedia.org/wiki/Meetups? Charles Matthews (talk) 21:18, 22 June 2012 (UTC)

Did you have a topic and or time/place in mind? Jeepday (talk) 14:20, 23 June 2012 (UTC)

Not as such. Thursday isn't great for me, is all, for a couple of reasons. Charles Matthews (talk) 06:55, 26 June 2012 (UTC)

I'll be there, and giving a presentation related to Wikisource. If someone wants to do a meetup, I'll try to make it, and I would also encourage people to attend the GLAM Night Out and the Wikipedia Loves Libraires workshop. Dominic (talk) 15:24, 25 June 2012 (UTC)

Can I use something similar to 'sic' inside 'source' tags for correcting code?

In page 6 of Scheme - An interpreter for extended lambda calculus there is a bug in the code of the function fact that is present in the original text:

(DEFINE FACT
   (LAMBDA (N) (IF (= N 0) 1
                   (* N (FACT (- N 1))))))) <- that last parenthesis is one too many

Using sic in the following way (or similar) to let the reader know doesn't work in a source tag:

(DEFINE FACT
   (LAMBDA (N) (IF (= N 0) 1
                   (* N (FACT (- N 1)))))){{SIC|)|Bug - this last paren is a bug present in the original}}

So I was wondering if there was a known way to handle it (or do we just leave it as is?). Srilumpa (talk) 10:12, 23 June 2012 (UTC)

I don't think templates will work inside the <source> tags. You could add a user annotation to the text immediately before the bug to explain the problem; ie. a note in <ref> tags including the {{user annotation}} template (although this is controversial). Alternatively, you could include this note in the notes field of the header when the text is transcluded to the main namespace. - AdamBMorgan (talk) 14:27, 23 June 2012 (UTC)

I will be controversial in this. I would consider wrapping it in a <noinclude></noinclude> and see if that works (it makes the book representation right in the Page: ns) PLUS I would add one of the two annotation methods that ABM suggested. My reasoning is that as we are adding a <source> tag we are already differentiating from the original so correcting with annotation makes sense. Or, just use a traditional [sic] — billinghurst sDrewth 01:59, 24 June 2012 (UTC)

I omitted the extra ')' from the original and added a {{user annotation}} in a <ref> tag explaining the divergence from the original text and the reason for it. For a technical text I think it is better to correct an error and make a note of it than leave readers find out the mistake on their own which is IMO a waste of time (especially if the mistake is hard to spot). If the consensus here is otherwise then I'll go with the flow so let's see how the community reacts.Srilumpa (talk) 08:57, 24 June 2012 (UTC)

100% agree which is why we have the approach as guidance rather than a rule, as I would think that it is more a typographical error, than something intentional by the author. If there are others, you may find it helpful to group refs, and then stick the collection into the notes section. — billinghurst sDrewth 09:52, 24 June 2012 (UTC)

where is the note section? Is it the same as the Talk page? Incidentally on the talk page (both of the page and of the book) a previous editor noted this error and a repeat elsewhere (as well as a couple of wrong dates and a missing citation), intentionally kept them and noted that they were corrected when published in a journal (HOSC ).
I corrected them and noted the correction in the talk page of the book and each individual page where the error appears instead of a note in the text that way the text is as intended with minimal modification (no note) but anyone noticing and wondering why it differs can see in the talk page that it was to correct an error (as long as they think about looking there, which I didn't until your reply or I probably wouldn't have tried to change it in the first place as the error was noted there). Shall I go ahead and also correct the date (on 2 pages) and citation too?

I was thinking the notes section of the respective {{header}} on the page. Though on the talk page also works, though you may consider the addition of {{edition}} to the page as a pointer. — billinghurst sDrewth 05:07, 25 June 2012 (UTC)

Ok, I didn't see this because I was editing the individual pages which don't seem to have them (they have a separate text field called header which is noinclude). Adding {{edition}} to the page's header field does not work so I copied the notes to the respective sections's talk page (and to the whole text's talk page) and put the {{edition}} in those section's headers as a reader probably won't end up on the page's page but stay on the section/whole text page. Thanks for the help.

Doesn't seem to accept a new cropped version of an image from Commons.

Hello.

I'm in the process of uploading George Cruikshank images to Sketches from Boz. On this page I linked from Commons an image I hadn't cropped, thought better of it and uploaded a new cropped version into Commons. But try as I might I can't get this new cropped version to show.

I've flushed my cache so it's some problem with the software? TheCircleSquared (talk) 20:56, 24 June 2012 (UTC)

It looks fine to me. Thumbnails don't always purge successfully, which would seem to have been your issue. — billinghurst sDrewth 05:04, 25 June 2012 (UTC)

Cheers B. I've just checked and it's showing now. Can't imagine what the problem was, but computers are basically all geek to me... :) Thanks for checking. TheCircleSquared (talk) 10:58, 25 June 2012 (UTC)

Odd section behaviour in Page namespace

This diff has changed the section formatting from old-style to new-style, but transcludes as a list. I'm sure the user concerned did not type the change himself, so there is patently a problem, but I'm not sure where it starts. Does it occur when a user who doesn't have the gadget for old style sections turned on opens a page? Does it occur when that user saves the page? Is it nothing to do with the section style but related to something else? Beeswaxcandle (talk) 22:02, 24 June 2012 (UTC)

I'm think the problem was the new-style section marker must be on a line on its own, and wasn't in this case. Hesperian 00:35, 25 June 2012 (UTC)

HaitiTrust

Can anyone see the scans of this book on w:HathiTrust? I suspect it is PD because it is a work of the government of Indonesia. John Vandenberg ^(chat) 10:18, 25 June 2012 (UTC)

I can not see the content, says "Full view is not available for this item due to copyright © restrictions.". JeepdaySock (talk) 11:03, 25 June 2012 (UTC)

I HAVE 2 HAND WRITTEN DRAFTS Ronald Reagan July-September 1975

• 
  Caption2

Untitled and Program 75-18, 1 September 1975 "A FEW IRONIES" -

INCLUDED ONLY P.1

Program 75-18, 1 September 1975 "A FEW IRONIES" -Ronald Reagan July-September 1975

Handwritten Draft Discovered

At the Hoover Institutes Draft of Ronald Reagans Radio Address "A Few Ironies" can be found below

Audio, Box: 8, Script, Box: 2 A Few Ironies,

"...but there are no drafts for the remaining 353. Of these, archival evidence has confirmed that members

of Reagan’s staff drafted 39. The authorship of the remaining 314 is uncertain...." Says Hoover Institute.

WELL... Now, I will confirm that 312 of them is uncertain, because...

I am CERTAIN of the Author of two of them and that would be they were drafted/written by Ronald Reagan during the summer/fall months & recorded Sept 1975 While campaigning.

This is not a copy so I KNOW it has never been seen nor read it.

Attached you will find the First Page of The September Radio Essay "A Few Ironies". I own 2 of them, the second no title but Im assuming shortly follows "AFI" Since it was paper clipped right behind the other. Both written on a letter size legal pad, 3 pages long...

They were both written on legal pad letter size paper, 3 pages. My aunt who worked for RR pulled it out of the waste basket.

I have two more pages and an entire additional essay that im assuming follows A FEW IRONIES.