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

I would like to propose that we have Extension:DynamicPageList (Wikimedia) turned on for EnWS, which would allow wiki users to create a list of pages that are listed in a set of categories, and was discussed at a period greatly earlier and is widely installed on a number of WMF wikis. Probably should be turned on for all the WS wikis, however, how about we start here. — billinghurst sDrewth 09:47, 3 November 2010 (UTC)

This is an excellent idea; I am sure that many would find it useful.--Longfellow (talk) 11:37, 3 November 2010 (UTC)

Sure, don't see why not. —Spangineer (háblame) 11:55, 5 November 2010 (UTC)

I agree; let's get it running.—Zhaladshar ^(Talk) 13:51, 5 November 2010 (UTC)

How long should this discussion run? A week, a fortnight, or a month? — billinghurst sDrewth 13:58, 11 November 2010 (UTC)

See also the equivalent 2007 unanimous proposal, Bugzilla request, Wikisource News mention, and wikitech-l discussion. —Pathoschild 14:21:14, 11 November 2010 (UTC)

In talking to Bawolff (talk • contribs) about this, we may or may not get it if we push hard enough, however, it is still server intensive. So possibly not worth continuing the battle. He did point me towards research being done on better tools, and for those more technically literate than I the info is at http://brightbyte.de/page/Neo4j Also he said that there was hope for MW application upgrades at the end of January, so it will be interesting to see if other of ThomasV's fixes are involved. — billinghurst sDrewth 10:45, 29 December 2010 (UTC)

It.source too asked for DynamicPageList. In the meantime: something like could be obtained by a toolserver bot. I'll tell you if I'll build something useful; the idea is, to implement (partly) dynamicpagelist code into a page, and to run a bot as soon as the page is edited (so avoiding frequent, banal runs). An #irc listening bot could give an almost immediate response, both updating the same page containing the dynamicpagelist code, or building a remote, linked html page. There's an advantage too: DynamicPageList produces only a list of pages (with few additional options), a good bot could do a really deeper work. --Alex brollo (talk) 12:59, 5 January 2011 (UTC)

I don't know where or when it was added, however, Special:Version says that it is installed. We should go and play. — billinghurst sDrewth 01:20, 15 February 2011 (UTC)

It works … for the sake of a thrown together test https://secure.wikimedia.org/wikisource/en/w/index.php?title=Wikisource:Sandbox&oldid=2389142 — billinghurst sDrewth 01:27, 15 February 2011 (UTC)

You lucky fellows! You have it running!!! We are waiting for it from so a long time into it.source… we struggled with "catwords theory" just to use it… OK, let's see what you'll do with it, and let's learn by example. --Alex brollo (talk) 08:56, 15 February 2011 (UTC)

I was playing fighting with the Babel templates such as {{user fr-2}} yesterday, and found that we have a very patchy coverage of languages and level, added to a chaotic situation whereby every template uses a different format: some are tables, some are divs and some are based on one of several standard templates.

After a long and painful construction of a attempt at a neat solution, I was shown the Meta:Babel extension, which seems to simply and easily solve the problems caused by the current template-based solution (i.e. poor scalability and maintainability). There is a vote going on there as to whether to install on all WMF wikis. However, since this has been ongoing since 2008, I thought me might be able to jump the gun and get it installed here independently of other WMF projects. This would serve two purposes:

1. Get us the Babel extension sooner and with less bureaucratic wrangling
2. Demonstrate to other wikis that the extension is worth having.

If other users feel that this extension is desirable, I propose that we begin the process to gain consensus to install (or not) it here. Inductiveload—talk/contribs 17:30, 12 January 2011 (UTC)

I'm not sure what the Babel extension is. I talked to Pathoschild once about importing the system he made for Meta, the user language system [1], but as you can see I never got around to doing anything about it. Our current system is pretty horrid; I'm not sure I'd want an untested extension, but it would be good to get a working system in here.--Prosfilaes (talk) 05:30, 13 January 2011 (UTC)

The Babel extension is a way to use a tag like {{#Babel:fr-1|de-1|en}} without the need for hundreds of templates, and the maintenance that that would require. As far as testing goes, it's been open for acceptance into WMF wikis since 2008, which implies it's production-level, though I'll clarify with the creator Meta:User:MinuteElectron. Inductiveload—talk/contribs 13:10, 13 January 2011 (UTC)

Forgive my intrusion, but I've been tinkering with babeltemplates for almost four years, and I was summoned from it.wikisource to put my advice.

Be patient if this shall result a little long, but I think it's necessary.

The story so far

In the beginning it was something like en.wikipedia (which is reflected here)

...then three paths were chosen:

1. commons: one general userbox; a subtemplate to describe the level of proficiency and to create all the boxes; everything left in parameters inside these boxes. Messages are hardly manageable.
2. Babel extension: you just pointed it out: very user friendly, but with too limited access for localization. The proposal has lingered for years... leaving (e.g.) la.wikisource still waiting for a solution.
3. meta's solution (Pathoschild invention): one template to represent all the boxes through switching css classes; textual matter inside template subpages. Good solution, but disseminating the messages in hundredth of subpages.

These are the problems:

• Separating layout and content (this is easily achieved, I'm still puzzled when I see en.wikipedia mess)
• Reducing as much as possible the number of pages or subpages involved (scalability and customizability) That's a problem as for textual content.
• Adapting the system to the established interproject practice of writing{{Babel|xx|yy-1|zz-3|jj-0}} (that means managing the inclusion of single babeltemplates into another template:Babel).

I worked on this system in these last two years.

what I'm doing now

My purpose is the following:

• one template for box layout and categorization, with #switch to have it working for all proficiency levels (that's done). This template should call...
• ...one page enclosing all labels (it-2) and messages (Questo utente può contribuire con un italiano di livello medio) separated with labeled sections. this solution would be peculiar to those wikis allowing labeled sections.

I'm no real technician, but I spent many hours (to say the least) thinking about the most practical and flexible solution, and I feel very near to it. I've recently made some experiments keeping Pathoschild's system, but I failed as I summed up too many calls to parse functions. To have it working I'm afraid I'll have to tread a different approach.

I'm still waiting for Babel extension to be fully released, but after watching it in action at translatewiki I wasn't so impressed.

My proposal: either you can implement/import Pathoschild's system from it.wikisource where it is fully operational and equipped with a top-notch and triple-checked set of messages; or if you are interested in my trial I could develop it thoroughly, sacrificing the existent one to fully exploit labeled sections (this of course is a Work in Progress, but I could find a faster result with a little help from here).

In both choices I'm willing to help here much as I can.

I beg your pardon... Maybe I'm a little rough with words, but look at my babel, I'm only en-2 :D - εΔω 18:15, 13 January 2011 (UTC)

Personally, I'd prefer to import Pathoschild's system. But our current system needs fixed, I'm probably not going to do it, and as long as who ever does picks a reasonably sane and complete system, of which there seem to be several options, I feel out of place to be complaining.--Prosfilaes (talk) 06:44, 14 January 2011 (UTC)

I'll share my experiences. I brought in m:Template:User language to English Wikibooks because we didn't have the full set of standalone templates and it was easier bring in one for each language rather than five for each language. Also, bring in m:Template:Babelold for old-style formatting if you do so. Replace existing standalone templates with m:Template:Deprecated babel to encourage updates. I also recently found an implementation at pl.wikibooks that I brought in and tweaked to call b:Template:Babel that calls Babelold (which in turn calls User language) in order to maintain the formatting people are used to with the Babel template, with the benefit of centralized translation. Also m:Template:User language category is needed for category labeling. More wikis should use the system; if you decide on it and need assistance, please let me know. Adrignola (talk) 14:54, 14 January 2011 (UTC)

Part of the confusion (at least for me) comes from the fact that Pathoschild's system (m:Template:User language) is not only the system actually used on meta, but the words "the Babel system" on m:Babel extension where the vote is going on linked to m:Meta:Babel templates, which has been redirected for the past three years to Pathoschild's system; on the Template talk page Pathoschild's system clearly distinguishes itself from the "the Babel system"; thus the links go round and round with all ending on Pathoschild's system which says it's not like the others (well, they did until I clarified the links moments ago). The vote page talks in only the most general terms about the extension and runs through a heavily edited pros and cons, followed by a long long vote, it never describes the system. The description of the actual extension is here: mw:Extension:Babel and it is in use on Translatewiki.net. I can't tell from this discussion, who is supporting Pathoschild/Meta's "User language" system and who is actually supporting the Babel extension system. I think I'm clear that no one is actually supporting the plain vanilla old Babel system that most MWF wikis have enabled in varying states. I think either system can work, I'm not sure which one is easier to implement, though meta's system of adding deprecation tags to the old templates is useful. When looking at other language wikisources even finding these is not always easy, not all use the template name "Babel" as some translate the template name, some have local language names for the base name of individual templates whereas others choose to use the English "user" and the same goes for the categories where some change the grammatical number of the category name. it.ws has thoroughly organized a nearly complete Babel system here: it:Wikisource:Babel/Lingue, which incorporates several of these complications (from the point of view of internationalization). All three systems have a similar output when fully implemented and none work well when partially implemented. There's a lot of importing to be done with any of them as none of them create the templates for you.--Doug.^{(talk • contribs)} 21:21, 21 February 2011 (UTC)

BTW, I think the answer from the creator of the Babel extension to inductiveload (viz. mw:User_talk:MinuteElectron#Babel_extension_-_ready_to_deploy.3F) was that although it's "production-level" for non-WMF mediawikis, until it has gotten through the required WMF reviews, it can't be deployed on any WMF sites. This would suggest that Pathoschild's User languages may be the better option.--Doug.^{(talk • contribs)} 21:30, 21 February 2011 (UTC)

Update: I can show you a beta version of what I suggested in my post some lines above: on vec.wikisource I developed pathoschild idea to exploit labeled sections: I have now just two elements:

1. the user language template (the "box") providing table, colours and categories according to language and level
2. a page with many labeled sections (the "messages") providing proper descriptions inside every template. I currently added only als, en, fr, it and vec, but imagine that page with all the messages avalaible in it.source.

Example in action: vec:Utente:OrbiliusMagister. As with Pathoschild's system the old Template:Babel (a table including many templates) is deemed to be deprecated, I don't like this but I didn't find an alternative.

Just one template and a subpage. I find it very practical... What do you think? - εΔω 17:54, 24 February 2011 (UTC)

What is the problem with having one template call per language like we do now, I think, and having another template with a list of the strings. That would require only 3 templates at the most. One as frontend, one for the userbox, and one for the strings. They would be {{Userbox}}, {{Babel}}, and either {{Babel/Strings}}, or Mediawiki:Babel Strings. Or am I totally misunderstanding everything? Arlen22 (talk) 20:04, 4 March 2011 (UTC)

Proof of concept done in 25 minutes: {{User Babel}}

If mw:Extension:Babel is approved by the devs (bugzilla:15308), would English Wikisource be willing to test it? If there is support, it is easier for the WMF to justify asking a dev to look at it. John Vandenberg ^(chat) 03:47, 4 March 2011 (UTC)

• Support. the Babel extension doesn't conflict with Template:Babel, so we can have both until the extension is proven, or decide to rollback without much trouble. John Vandenberg ^(chat) 03:47, 4 March 2011 (UTC)

• Support, so long as we aren't going to wait for it. ;-) Talking with Pathoschild I think everyone agrees it's the best thing except for the fact that it isn't available. In the interim, we should transition to Pathoschild's user language system.--Doug.^{(talk • contribs)} 00:09, 5 March 2011 (UTC)

• Support, it's so much better than the template soup we have now, and it will be great to get this extension off the ground for the rest of WMF. Inductiveload—talk/contribs 00:04, 5 March 2011 (UTC)

I am looking to obtain a bot flag for EnBot. Currently, my only plans for him are to create author pages for authors that are listed in {{header}}s but without an actual author page (see User:Eliyak/Authors, which contains many false positives). EnBot is based on pywikipediabot, and will initially run semi-automatically for several dozen pages, then automatically.

The author pages will contain minimal information (first name, last name, last initial) and a list of works which have the person as author or translator in the header. If there are no such works, no page will be created. --Eliyak T·C 16:28, 16 January 2011 (UTC)

Why do want to do this? We will end up with a whole lot of pages without life information, no copyright template and no particular means to get back to them to fill in the detail. Also there would be no works linked, and no links to Works about, all things that can be done quickly when creating pages. Personal preference is that we do the research and fill them pages with detail, then we can find problematic pages with regard to work being public domain. Also with Phe's author-fill script it can provide relevant detail if available from WP, and link. I suppose that I am not sold on the benefits, as broached, as the negatives that I see. Addendum: with so many abbreviated names in the list, we also run the risk of duplicating author pages (full name ←→ abbrev. name), not picking up errors, etc.; all of which can be an issue. — billinghurst sDrewth 11:41, 17 January 2011 (UTC)

•  Support - I see value in this if his bot also places the work that has the redlinked author on the page. For many authors that may be all we ever have is a list of their works but that is enough information about them to justify an author page. If it's just going to create the framework and leave the page blank then it won't be very useful. Though it may have to do that on the first pass then look for works that link to it. Some authors have works that are in public domain and works that aren't, the license should be dealt with on the work primarily.--Doug.^{(talk • contribs)} 11:52, 17 January 2011 (UTC)

I agree with sDrewth, that Eliyak should implement a procedure for dealing with entries that have a possible match. Phe has done some similar work and identified possible matches. Should be addressed, doesn't make the proposal nonviable. --Doug.^{(talk • contribs)} 12:06, 17 January 2011 (UTC)

I understand the concerns, and will make the script more robust in the following ways before running EnBot:

1. I will use Phe's possible matches (or generate my own) to avoid creation of any possible duplicates
2. I will make use of the WP bio templates to grab birth and death years. In the case where the WP article is a disambig page, I will manually choose which is the appropriate person, or, if this is not obvious, leave off the years. Similarly, if there is no matching WP page, I will leave off the years. Also, I will add the WP sister link to {{author}} when a WP page is available.

Finally, the existing WS works will definitely be listed on the final author page. This was part of the original plan. --Eliyak T·C 15:33, 17 January 2011 (UTC)

How many authors have works here, but no page? I tend to think this sort of thing can be done while working on a text, or by taking some time to check here and the other place. If there is no author page I don't see how a bot helps. I've seen how it can go wrong when done as a routine, creating more problems than it solves. The listing of these should be better advertised, so people can pick off the ones they know or worked through by those who know the pitfalls described above. cygnis insignis 04:51, 18 January 2011 (UTC)

Comment Phe (talk • contribs) produces a list of all redlink Author: references which is on second rendition and available, which are at Special:PrefixIndex/User:Phe/Author, where as Eliyak's proposed list for authors of works that we host (ie. people appear in {{header}}). I would think that it would be great for Phe's list to be hosted in the Wikisource: namespace. — billinghurst sDrewth 05:52, 18 January 2011 (UTC)

Oh, right, a much shorter list. I see the user space lists turn up in the incoming links, but don't correct them, refreshing the data and breaking the large size would be good thing there. This listing, 'works here, but no page', would be much more manageable and important, and easier to resolve than incidental references. cygnis insignis 10:49, 18 January 2011 (UTC)

• Have you tested this script on another account? I only 4 contribs for EnBot. Generally we don't flag until after a test.--BirgitteSB 18:13, 7 February 2011 (UTC)

• • I want to modify the code to meet the concerns mentioned above, but I haven't had much time lately. When I get around to those modifications, I will make some test edits and make a note here that I feel EnBot is ready for prime-time. --Eliyak T·C 05:44, 8 February 2011 (UTC)

Sorry for yet another bot approval request, but I've recently done the grunt work to set up pywikipediabot and get it running. I am planning to use it for mass page moves: such as are required when a proofread index is moved, or a work with many subpages needs to be moved to make way for new editions. In the future I may also use some of the other capabilities, especially replace.py, but in all cases the edits I make with the bot will be tested prior and supervised during.

Details: Python 2.6.5, pywikipediabot, using standard script movepage.py. Performed a test page move in my userspace with no issues.

I plan to use the bot (as Spangineer) to slowly move pages of The Federalist Papers (as outlined at Talk:The Federalist Papers) later this week if there is no objection. Once complete and verified, I will request a bot flag for a new account (which I have not yet created). --Spangineer (háblame) 16:18, 17 January 2011 (UTC)

 Support – No issue with your request for BOT approval at all, though I missed your post about moving/organizing Fed. Papers itself so I left a response over on its talk-page rather than adding to the clutter here. -- George Orwell III (talk) 23:42, 17 January 2011 (UTC)

• Question With moving pages, do you see it only working in the Page: namespace or is it going to be broader and work in other namespace? Do you envisage that there will be a redirect left behind? If so hard or soft? —unsigned comment by Billinghurst (talk) 00:40, 18 January 2011.

In the page namespace, no redirects. I plan to use the bot in the main namespace as well (i.e., The Federalist), and in those cases the redirect decision may vary. For the Federalist, hard redirects are necessary, as there are many incoming links to the current structure (from WP and potentially elsewhere). In other, less established works, perhaps soft redirects or nothing at all would be preferable. If soft redirects are desirable, I will make sure I can make the bot perform the replacement prior to making the page moves. Page moves via bot in the main namespace in any case will be done only after making a proposal on the work's talk page (unless I'm the only contributor and the work is new). --Spangineer (háblame) 05:09, 18 January 2011 (UTC)

I hope you realise that your bot account won't be able to suppress redirects unless it gets the admin bit too. Hesperian 05:14, 18 January 2011 (UTC)

Yes; it's my impression that admin bots are rare, so I was planning to do manual deletions of redirects when necessary. --Spangineer (háblame) 05:23, 18 January 2011 (UTC)

It could leave {{Dated soft redirect}}'s, if desired.--Doug.^{(talk • contribs)} 09:53, 18 January 2011 (UTC)

 Support - no issues. I believe the bot should be making test edits under its own name now though so that we can distinguish and examine.--Doug.^{(talk • contribs)} 09:53, 18 January 2011 (UTC)

• I have set up User:Spangineer's bot, though it will be several days before this account can perform page moves. —Spangineer (háblame) 14:10, 19 January 2011 (UTC)

I am currently moving The Federalist Papers with movepages.py and making small navigation fixes with replace.py. See the contributions at Special:Contributions/Spangineer's_bot. —Spangineer (háblame) 15:34, 26 January 2011 (UTC)

I also used the bot to create about 80 redirect pages, using pagesfromfile.py. This run of the bot is now complete. —Spangineer (háblame) 18:35, 26 January 2011 (UTC)

• Done I issued the bot flag.--BirgitteSB 18:19, 7 February 2011 (UTC)

• Thanks! —Spangineer (háblame) 21:09, 7 February 2011 (UTC)

I request to run DougBot.
DougBot (talk · contribs · deleted contribs · logs · block user · block log · SUL)
edit count

• Purpose: Repetitive text replacements and formatting prior to proofreading (esp. making chapter headings and other page formatting internally consistent throughout).
• Scope is limited to mainspace and pagespace edits within certain works that I'm involved in (in most cases virtually the sole editor), namely:
  • Three Books of Occult Philosophy (619 pages)
  • Fourth Book of Occult Philosophy (238 pages)
  • The Art of Cookery Made Plain and Easy (1774) (index) (444 pages)
  • The Complete Confectioner (1800) (index) (395 pages)
  • The Husbandman and Housewife (index) (206 pages)
  • The Chronicles of England, Scotland and Ireland (index) (2857 pages)
  • The Art of Distillation (239 pages)
  • The poems of Gaius Valerius Catullus (Cornish) (index) (176 pages)
  • The Tragedy of Hamlet, Prince of Denmark (I recently discovered that our text may have missing sections or other deficiencies and we have no page scans, I'm working with Inductiveload to get good scans of a 17th C. edition uploaded to commons and will soon begin working with this work; I will change the formatting to accord with the scans)
  • Other works as I begin them or as requested but I have no plan for the bot to do project wide jobs (in other words each job will be limited to a single work at most). The works are often very large and what works best develops with the project but making changes and keeping them consistent becomes increasingly difficult without a bot on hand.
• Language: Python
• Framework: PWB
• Mode: Manual/semi-automatic; later the bot may run automated on short runs with review by me afterwards.
• Operation: Intermittent - only operates when I have a job to do.

--Doug.^{(talk • contribs)} 16:20, 17 January 2011 (UTC)

No opposition -- Annoucement noted. Go ahead and make some limited runs - the sooner the community sees it in action, the faster the bot can get flaged and auto-patrolled status. George Orwell III (talk) 21:34, 17 January 2011 (UTC)

• These things can be accomplished with scripts and buttons as part of the proofreading process. I deleted the empty works above, please ask for them to be recreated when there is something usable in those works. cygnis insignis 04:26, 18 January 2011 (UTC)

For ref: User_talk:Cygnis_insignis#Deletion_of_title_pages.--Doug.^{(talk • contribs)} 07:19, 18 January 2011 (UTC)

Comment My thoughts would be to pick a work and let it run in the page namespace, and let us watch the results. I have no issue looking to let it run on a per work basis, and systematically. What we are not wanting is a whole lot of "sea of red" pieces sitting there for some other poor dweeb to get to. We believe that active curatorial work and moving to proofread status with works has been something that presents a quality product, builds impetus and keeps both the contributor and others "entertained". With regard to main namespace, botifying them to me seems to be overkill for the task, but may I just like to a constructed page appear with a TADA, and tweak as necessary. Always find spellings and formatting ... to do when it appears on the full width. Having sidebar and toolbar bits makes it relatively easy. All that said, I would be again be looking for a per work approach, not creating multiple head pages, with content behind on the never-never. — billinghurst sDrewth 10:47, 18 January 2011 (UTC)

I think maybe my plan was misunderstood due to the discussion with Cignis. I have no intent to simply bot in pages. That's really a different discussion. The point is that as one gets several dozen pages into a several hundred page work or finds that pre-existing (and more or less abandoned) work is not consistent with the original, etc. changes are not easy. Botting in to page space in advance of editing, maybe, but I'd only use it on mainspace pages that had been created by hand for things that existed in pagespace already. The point with chapter headings that I mentioned was that when you get to Chapter 43 and realize that you haven't kept the chapter headings all the same size or that the one you used was two small/large, it's really nice to be able to go back and bot the change. I might bot in headers in pagespace, if there's an existing OCR layer, so that the pages are already really there, maybe, depending on the circumstances. I only listed the long list because I didn't want to have anyone say, oh, you listed works X, Y, and Z, why are you using your bot on work W. Those are the ones I'm working on right now.--Doug.^{(talk • contribs)} 11:16, 18 January 2011 (UTC)

• DougBot has made some basic formatting edits to Page:The poems of Gaius Valerius Catullus - Francis Warre Cornish.djvu/23 thru /40. Links to DougBot's contributions have been placed at the top of this section. These were performed on the raw OCR text to apply the format and demonstrate; obviously it has limitations in working with the raw OCR and only so much can be done, but it provides a cleaner copy for the proofreader and places much of the formatting that the proofreader would have to place before a human has ever looked at the page (other than supervising the bot). Yes, this could be done with a regex script in my .js and I have such scripts for some of this but I prefer this method. Moreover, The intent is that the bot will make this kind of edits but that they won't only be made to raw OCR but to proofed or partially proofed text to make changes across a work. For example, we discovered that {{right sidenote}} didn't work well on this work when transcluded for side-by-side display of the Latin and the English. Had we discovered this later, a bot run would have made the change to the new {{right sidenote2}} easier. At the moment, I don't have any of that sort of edit to demonstrate but when I do I will post links here. There was some delay in editing as I reconfigured from using User:Inductiveload's Handler Script and replace.py to using the much more flexible Page Namespace Editor he prepared for PWB for this purpose.--Doug.^{(talk • contribs)} 09:47, 26 January 2011 (UTC)
• They aren't all this good but these are prime examples of the intent:
  • Page:The poems of Gaius Valerius Catullus - Francis Warre Cornish.djvu/103
  • Page:The poems of Gaius Valerius Catullus - Francis Warre Cornish.djvu/104

  Neither has ever been edited by a human editor.--Doug.^{(talk • contribs)} 22:02, 26 January 2011 (UTC)

• Looks nice. One more thing that would be simple to add would be regex to remove spaces that appear before terminal punctuation (exclamation points, question marks, etc.). And a question: where did the OCR text come from that your bot edited? Was it from the text layer, or generated by clicking the "OCR" button? IMO it'd be better to use the text layer, since that's usually more accurate.

  In any case, I can see a bot like this saving time: I support your use of it for new works. —Spangineer (háblame) 13:12, 27 January 2011 (UTC)

• Good suggestion on the terminal space. Maybe I'll make another run to remove that throughout as well as repair some of the sidenotes where I didn't have the settings right (early on I only had it set to take two digits and then found several of the poems go up in to triple digits).

  The OCR text came from the text layer. It was placed by mjbot using djvutext.py.--Doug.^{(talk • contribs)} 18:14, 27 January 2011 (UTC)

• Glad to hear that the text layer was used; thanks. Also just remembered: many times OCR picks up a space prior to semi-colons and colons; those can be removed easily with regex as well. —Spangineer (háblame) 19:06, 27 January 2011 (UTC)

• Do people support or oppose the bot flag for DougBot? The conversation seems ambiguous.--BirgitteSB 18:25, 7 February 2011 (UTC)

• I support the bot flag. —Spangineer (háblame) 21:59, 7 February 2011 (UTC)

• Support. -- No Concerns. — George Orwell III (talk) 14:08, 8 February 2011 (UTC)

Done--BirgitteSB 19:51, 8 February 2011 (UTC)

• Assuming no objections, after the bot obtains a flag, I would like to also use it for relatively small and carefully planned mainspace jobs that go beyond the scope above. The bot currently runs a script written by User:Inductiveload to generate a report of WS pages which have interwiki links to WP and WQ where no backlink exists. From this report we have identified many pages that don't exist and on investigation, the vast majority appear to have been created more or less automatically and no article for the author on WP has ever existed. In over half of the ones checked so far the authors are Popular Science article authors who are unlikely to meet the notability requirements to ever have an article on WP, or if they would it would require extensive research. I have proposed a bot run to remove the links to non-existent WP articles. The pages would then join the ranks of authors who are not linked to WP to begin with and would actually become easier to track and build articles for where justified. Although I don't expect an ongoing need for this, I do plan to run the backlinks script from time to time to update it. The output of the last run is currently in my userspace.--Doug.^{(talk • contribs)} 20:20, 26 January 2011 (UTC)

Seems like a worthy job. Dead links reflect badly on WS. I would also like to bring up an idea mentioned in IRC. Perhaps we should establish hidden categories such as Category:Authors without a Wikipedia link, and the alternative Category:Authors without Wikipedia notability. These would probably be best implemented through the author template with | wikipedia= giving the first and | wikipedia= NN giving the second. --Eliyak T·C 20:35, 26 January 2011 (UTC)

A bot run for this is a good idea. So is Cat:Authors w/o WP link, but I'm not sure about the other one: maybe in a few "obvious" cases it would work, but realistically the amount of research required in most cases to truly verify that someone is "not notable" is more than what most people will be willing to do. So I fear the category would be misused and thus be unhelpful. —Spangineer (háblame) 13:12, 27 January 2011 (UTC)

Isn't the first the same as Category:Author pages not linking to Wikipedia, I agree the second cat would not be helpful, I brought this up to preempt the thought that we should leave the dead links because the articles are needed, in many cases they aren't.--Doug.^{(talk • contribs)} 00:04, 4 February 2011 (UTC)

This is a side point, but I don't think (Cornish) is the best disambiguation. I looked at that and wondered if you were uploading the work in Cornish.--Prosfilaes (talk) 04:20, 1 February 2011 (UTC)

(responding on user's talkpage)--Doug.^{(talk • contribs)} 07:38, 1 February 2011 (UTC)

I intend to run an almost identical bot to DougBot solely for interwiki language links. The bot is pending approval on de and la wikisource in addition to en and has begun making some initial edits on several languages.

• Name: Interwiki-Bot
• Operator: Doug (talk)
• Purpose: Interwiki language links
• Scope: All en wikisource namespaces (especially Categories and Help)
• Language: Python
• Framework: PWB
• Mode: Semi-Automatic

To the best of my knowledge there is only one other marginally active interwiki language bot on wikisource and that's User:Cswikisource-bot, he has not requested a flag on any major project as far as I can tell.--Doug.^{(talk • contribs)} 07:01, 10 February 2011 (UTC)
Global edits--Doug.^{(talk • contribs)} 07:11, 10 February 2011 (UTC)

• Comment - I don't see why this needs a full flag. The Commons-image-replacement/deletion-bot, as well as the User you cite above, run every so often (what I assume is) whenever the need arises in relation to their home-wiki or base-language sites' demands - not for the sake of tagging stuff just because they can easily automate it. Personally, & without any immediate community demand driving the need for such inclusions, I don't see why this warrants full Bot-flag status. — never mind. Turns out most if not all of those accounts I was thinking of are indeed flagged Bots but aren't given auto-patrolled status at the same time. — George Orwell III (talk) 08:29, 10 February 2011 (UTC)

Bots that do inter-language link on xxWS do not require community authorisation at English Wikisource — billinghurst sDrewth 10:52, 10 February 2011 (UTC) …

Right, I put this in this section because it appears to be where anything related to bots goes, not just requests. This is intended as a notice that I am operating the bot (I don't believe even that is necessary, I'm just trying to be helpful) and a prelude to asking a crat for a flag.--Doug.^{(talk • contribs)} 11:26, 10 February 2011 (UTC)

Note: Be carefull, standard interwiki-bot implementation may have an bugs. I'm a ru-ws administrator and some time ago i found VolkovBot's malfunction like this:

• diff 1
• diff 2
• diff 3

There are an accidental removal of right iwiki without any comment. The bot operator say me, that he use standard interwiki code from sourceforge.net and stop your bot. I sure that we need to inspect the standard implementation for this issue. -- Sergey kudryavtsev (talk) 10:13, 11 February 2011 (UTC)

• Well, this isn't a bug, the way the script works is by ensuring that all interwiki links are reciprocal, this results in one and only one interwiki link for each language for each page, if you want an extra one you have to put it in by hand normally and a later bot run (by any bot using the standard script) will remove it. This can easily be overridden for individual pages or individual groups of pages by running the bot in -confirm or -select mode. Currently, I always do this anyway. If the above handler of the bot making the above edits defended it the way you describe then that suggests he or she didn't understand the script nor the optional parameters available. Still, I'm not exactly sure why anyone would want interwiki links to muliple locations like that as it will display the language link twice in the sidebar. It would be better to have express links in the text or in the header for such cases. Normally one link per language per page works fine. Note that issue was on ru.ws and I'd be happy to make special runs for them if they want to keep multiple interwiki links on large numbers of pages.--Doug.^{(talk • contribs)} 21:39, 11 February 2011 (UTC)

Please don't run interwiki bots on any Wikisource main namespaces until you understand the problem with reciprocal interwiki links on Wikisources. Interwikis do not work reciprocally for texts. In general you will probably want the text ruA (original) to inwikilink to a disambiguation page on en.WS which disambiguate enB (1870 translation) enC (1913 transltion) and enD (unrelatied text of the same name). You will want enB and enC (but neither enD nor the disambiguation) to inwikilink to ruA. ru.WS may also want ruA to inwikilink enB and enC if they plan on getting the side-by-side extension working, but that is their call as the choice is debatable given the current technical limitations. Do not run a bot that make reciprocal links over this sort of thing.--BirgitteSB 23:38, 11 February 2011 (UTC)

In main namespace we stored poems, novels, stories etc. Here interwiki link has meaning of translation-to-original relation. E.g. Bayron's Darkness translated in Russian by Lermontov and by Turgenev. We cannot prefer Lermontov's translation in prejudice of Turgenev's one, therefore we should give both interwiki links here. Alternative way is one interwiki link to disambiguation page like Chechov's After the Theatre, but IMHO this is worse:

1. How we will choose the name for disambiguation page, especially for a poems without title?
2. Our reader will click twice instead of once.
3. These disambiguation pages is a unnecessary work for our contributors.

In any case an interwiki links is a question of cross-domian collaboration and should be decided jointly.

NB: The special run over ru.ws is not needed, all VolkovBot's edits reviewed manually. -- Sergey kudryavtsev (talk) 23:56, 11 February 2011 (UTC)

It certainly is debatable. It is not very bad to have two English interwiki links on a text at ru.WS (although it would be even better if we did not have to display then identically) But at the same time I could see a case where the number of interwiki links becomes overwhelming and linking to disambiguation pages would be preferred. For example the interwikis available to The Internationale could easily become more work for the reader to figure out than to click through a disambiguation page if all the different translations where represented on Wikisoures.--BirgitteSB 05:27, 12 February 2011 (UTC)

• I have no plans to even enter the mainspace (except where necessary because as on de there is no author space) in the short term. At the very top I said the focus was on Cats and Help, which is why de wanted a bot. I do understand the problem and I've told ru that I will make separate runs for them if they want multiple links to stay, using -select. Better yet, if I run an interwiki run in the mainspace at all I will do it with the -select parameter on. Again, this is not my focus and not an area I anticipate doing much if any of, certainly not automatic work.--Doug.^{(talk • contribs)} 08:03, 12 February 2011 (UTC)
• I have responded further at ru:Викитека:Заявки на изменение прав. I have tested the bot on the requested pages and found mostly what I expected, I have to override the bot's desire to remove links when they aren't reciprocal but when duplicate interwiki's are reciprocal the bot has no problem with them. I did identify a possible issue with -select but running -confirm prevents any edit without my approval so I'll just do that. Again, as I stated on ru.ws I can't read the Russian text so I'm not going to remove links from it, I am quite cautious even with categories and project pages and have found apparent errors introduced by other bots.--Doug.^{(talk • contribs)} 10:04, 12 February 2011 (UTC)

Two questions:

• Why in the world would we want to rubber-stamp interwiki bots with even a cursory approval of their script when interwiki bots are among the actual proven cases of bots really screwing up en.WS in a time-consuming way? When did this become policy? (If anyone know off the top of their heads. I can do my own research this weekend.)
• Does anyone else control multiple bot accounts? Why would it be reasonable or unreasonable to have more than one bot account? (Off the top of my head one bot account flagged only for bot and one flagged for both bot and admin seems a reasonable case?

--BirgitteSB 19:08, 11 February 2011 (UTC)

• As to the first question, I have no idea, and I am merely trying to follow the current policy while providing as much information as other bots. Though I will note that many projects (though relatively few wikisource projects, possibly because it takes affirmative steps) allow auto approval and/or global bots and most projects have simplified procedures for the flagging of interwiki bots. For example, I'm already flagged on de, and although I filed a formal request at the Scriptorium there, I was informed that it was unnecessary.

  As to the second, they're really the same thing, the two bots, they both are in the pywikipediabot framework, but a bot that does more than just interwiki linking is disqualified from automatic approval or a global flag, so I have chosen to set up a new account, running an identical copy of pywikipediabot but executing a different script. On wikipedia mulitple bots under one owner are fairly common and several handlers operate three or more bots.--Doug.^{(talk • contribs)} 20:57, 11 February 2011 (UTC)

I admit I don't know much about the ins & outs of inter-language linking etc. but I'm starting to regret any such thing - it turns simple patrolling into a far bigger headache; that much is sure.

I'm starting to regret supporting a BOT that is turning out not to be the primary concern of your's here on WS & introducing "well this how Wikipedia does it...." will win you even less latitude as far as I'm concerned. — George Orwell III (talk) 23:26, 11 February 2011 (UTC)

My other bot is sitting waiting for a job, there's one in the background I need to gear up for but other than that I don't have work for it a the moment. Folks at de.WS specifically asked me for help with an interwiki language bot. My comments about wikipedia were only relevant to the concept of one operator running multiple bots. I'm not advocating that we do things the way they're done there, just pointing out that running multiple bots isn't a novel concept of mine.--Doug.^{(talk • contribs)} 07:15, 12 February 2011 (UTC)

On the first point. The interwiki script only screws up Wikisources because texts will not correlate 1:1 in the manner encyclopedia articles do, so what is done on Wikipedias is pretty meaningless as the scripts were written for the situation on Wikipedias.

Two the second point. You have an account with a bot flag. Why does it the fact that the flag you already have was disqualified from an automatic flag mean you need another account to get an automatic flag? It just doesn't make any sense to me, especially if they are the same under the hood.--BirgitteSB 23:26, 11 February 2011 (UTC)

I'm not using the script on texts and have no particular plans to anytime soon. My bot was advertised on de and here as focusing on Category and Help pages. Automatic flags are important on small projects where bot requests may never get comments and Stewards are required for flagging.--Doug.^{(talk • contribs)} 07:15, 12 February 2011 (UTC)

• I was just informed that the historical way of dealing with this on en is to allow interwiki bots to act without express permission but not to flag them! This way they can be tracked. This is consistent with the policy on WS:BOTS, pointed out by sDrewth, above, but it isn't clear in it that no flag is given. If that is the policy, I have no problem with it. I thought I needed a flag. On some other languages I was told that my bot could not operate without a flag, although when I asked, a crat gave me the flag without any questions or discussion. I assumed that I could not operate without a flag here and that was my only reason for posting. Therefore, if I don't need a flag, I withdraw my request and I'm sorry to have caused such a stir.--Doug.^{(talk • contribs)} 10:44, 12 February 2011 (UTC)

Here's a question that crops up from time to time when working on the Mishnah and other translations, and probably deserves a note at WS:T: When translating, is it permissible (i.e. legal) to consult other translations? If so, to what extent? I have been unsuccessful so far in finding an answer to this question online. Does someone have any knowledge of this issue or where to look for answer?

My personal view on the matter is that a copyrighted translation should be able to be consulted for possible translations of a single word or phrase, but not a complete sentence or a sentence clause. Also, if a translation uses a distinctive translation/interpretation (the two are often intertwined) of a word or phrase, that should not be used.

By the way, here is a funny article I came across in my search for definitions of plagiarism: [2]. --Eliyak T·C 05:57, 25 November 2010 (UTC)

Plagiarism is not illegal unless it imposes someones intellectual property, it is simply unethical. If someone refers to part of another text for a reference then we would be encouraging all users to reference what texts they would have consulted.

As a note, I am still have a level of discomfort with hosting Wikisource-based translations as it seems to have a level of contrariness to WS:WWI. I always wonder whether the works belong at Wikibooks, though strongly linked through from the original source. — billinghurst sDrewth 08:31, 25 November 2010 (UTC)

I did find http://www.copyright.monash.edu.au/faqs/citations-plagiarism.html which gives some opinion that addresses plagiarism, and that it is a translation should not be of any difference with regard to intellectual property. — billinghurst sDrewth 08:40, 25 November 2010 (UTC)

creating this into a separate thread …

As a note, I am still have a level of discomfort with hosting Wikisource-based translations as it seems to have a level of contrariness to WS:WWI. I always wonder whether the works belong at Wikibooks, though strongly linked through from the original source. — billinghurst sDrewth 08:31, 25 November 2010 (UTC)

I would strongly agree that WS should not host original translations. Published (public domain) ones are fine, but WS shouldn't be in the business of allowing people to upload new, unpublished work, still less of allowing others to amend that new work.--Longfellow (talk) 19:03, 26 November 2010 (UTC)

In my opinion Wikisource is the best location for free-content collaborative translations because of its goals of maintaining fidelity to the original text. Firstly, the translation can easily be cross-linked to the foreign language source text at <foreign language> Wikisource (as well as to other translations of the same text). Secondly and equally important, a primary goal of good translation is fidelity to the original text to the greatest possible extent. I don't have confidence that this would be the case at Wikibooks. If the translation paraphrased the text into modern vernacular, or gave an ideologically based translation (such as Artscroll does) I would agree wholeheartedly that the translation belonged at WikiBooks. Translations that are constrained to conveying the meaning of the original belong at Wikisource.

In short, I would like to see faithful translation continue to be a subset of WS:WWI. --Eliyak T·C 20:14, 26 November 2010 (UTC)

Not including something doesn't mean excluding mention of its existence. If a foreign-language public domain work exists that is hosted on another wiki, we can have a page saying so, and also saying where an English-language translation of the work exists on Wikibooks. The work exists all the same, it is merely directed to the appropriate project for hosting it. BD2412 T 23:49, 26 November 2010 (UTC)

I don't see the need to narrow Wikisource's scope. Furthermore, if the general course is users coming to Wikisource and being redirected to Wikibooks, instead of finding the material through Wikibooks, then it's a mistake to move it. Given the more general scope of Wikibooks, I find that likely. All the works of Tolstoy or Zamenhof, or Author:Arkady Timofeevich Averchenko should be here, not split between here and Wikibooks.--Prosfilaes (talk) 01:29, 27 November 2010 (UTC)

A translation is an original work of authorship. My understanding was that those are not within the scope of this project. BD2412 T 01:55, 27 November 2010 (UTC)

WS:WWI specifically states that we include original translations, and last time I looked (there's a table of WS policies I can't find right now) virtually all the Wikisources, except German, do. The scope of Wikisource, as it is currently practiced and stated, includes original translation.--Prosfilaes (talk) 02:16, 27 November 2010 (UTC)\

My mistake, then. Cheers! BD2412 T 02:55, 27 November 2010 (UTC)

Eliyak, that is a useful point that you raise. Plus please don't take "a level of discomfort" to be that I am at the point of advocating their removal. It is more that with the movement of time, sometimes it is worth reflecting on what was said earlier, and comparing where the wmf wiki world is now

WS-based translations are an oddity in that they have original thought, and the range of actions that we can undertake can be from: doing nothing; updating Wikisource:Translations to reflect our process; update WS:WII to explain the oddity and reasoning; to working out that as they have original thought that there needs to be a wider approach. I have no end game, I just wanted to express a reflection that I had had. — billinghurst sDrewth 00:37, 27 November 2010 (UTC)

Thanks for that clarification, billinghurst. I admit I panicked a little when I saw my question seem to become something else entirely. I appreciate the atmosphere and easygoing community at WS, and I know we're not going to take any impulsive actions, but think things through and come to a consensus to take action or not to. --Eliyak T·C 00:40, 28 November 2010 (UTC)

Translations are a historical exception, not an obvious inclusion. I don't see why it is supposed they will 'stable' here, and why wikibooks is inappropriate for the creation of this new content. That hasn't happened here, later translators have disagreed with a work and changed it to what they believed was correct. The "integrity" of wikisource is based on a community transcribing text, which is a reasonably objective procedure. Translation is new content—or copyvio that is difficult to detect—and the source of a great deal of critical dispute; it is highly subjective and requires editorial judgement, usually reviewed by other experts. The evidence is seen in the expansive introductions in conventionally published translations, and the volumes of critical review. What would preclude something that was rejected by a publisher being hosted here, or is that within scope too? Should we include new poetry if it claims to be a translation, 'authentic' or otherwise, and create an editorial department to manage that. Do we start resolving literary disputes between authors with drawers full of rejections slips? Wikibooks have processes for creating new content, and the idea a translation can be indisputably accurate is fiction; it is quite beyond the scope of the site. cygnis insignis 04:56, 27 November 2010 (UTC)

It may be an exception from the viewpoint of process, but from the viewpoint of a reader, it's a obvious inclusion to have all the works of an authors that we can host here, whether the translations are new or old. For most books, for most readers, translation is invisible; people read War and Peace, The Girl with the Dragon Tattoo and Around the World in Eighty Days and don't care about translator. Most translations don't have expansive introductions; no translation of Harry Potter does, and many editions of Verne's works neglect to mention that they're translated at all. Only literary translations do, and only readers of literary translations really care.

I'd be much happier if this call was in response to real issues. During the time I've been an admin, translations haven't seemed really problematic. If the minor issues that have popped up about the Wikisource Bible concern others, I wouldn't object to setting up rules asking that new translations of works that have a free translation are justified, and translations like the Bible and the Iliad are rejected. But right now I don't see any issues with any translations that call for changing our behavior.

In any case, while WS:WWI says we include them, wikibooks:WB:WIW is pretty clear that Wikibooks considers them out of scope. It's not simply a matter of moving them to Wikibooks; we've got to convince Wikibooks to change their scope to include them.--Prosfilaes (talk) 07:09, 27 November 2010 (UTC)

Prosfilaes correctly points out that the occasional comments and debates in recent years about the appropriateness of translations and/or annotations derive seldom derive from abuse or inappropriate material (and when they do that can easily be dealt with) but rather from concerns about "principle", especially by those who are bothered by any text not directly based on a scan using "Proofread Page".

While I agree that working from a scan is indeed the best procedure for most books, there are definitely cases where it simply doesn't make sense. Translation is one such category. Using scans is supposed to help expand the library and serve as a form of documentation. But to use it as a reason to exclude translations simply limits the scope of the library and its usefulness to users. Working with scans is a tool, not the whole purpose of Wikisource. Wikisource is using wiki tools in order to build a library, and translation is one area that the wiki-method can be uniquely effective in making literature more widely available through our library. Don't mistake the method for the goal.

Typical Wikisource is taking public domain literature and transcribing a scan of it, for instance something like Mark Twain or an old encyclopedia. But there are amazing ways our tools can be used that go way beyond that, and provide excellent value to the public. Here are some ideas we have implemented at Hebrew Wikisource. None of these ideas implement the "Proofread Page" extension because that excellent tool isn't the best tool for these purposes. (That the extension doesn't for for RTL languages is besides the point...) It's not wrong to think "out-of-the-box"!! Or "out-of-the-scan" in this case... :-)

• Critical editions based on manuscripts. We have uploaded scans of multiple medieval manuscripts for a single work, which allows documentation for a critical edition based on manuscript evidence. A simple template allows for documentation of the variant readings within the edit page. "Wikisource:" pages devoted to each book in question allow the community to collaborate on formulating the appropriate procedures for editing each book in question. So both the textual evidence and the procedures are transparent and collaborative.
• Critical editions based early printed editions. For Mark Twain, the differences between editions aren't terribly significant. But at Hebrew Wikisource we are dealing with books that have been published dozens of times, and no one edition is the best choice for our online edition. Here too, the title page can list the editions which the wiki-text has been corrected against, and documentation can be stored on the edit page and in links to scans at Commons.
• Text-with-commentary. We are dealing with works that have been published with multiple commentaries, and some editions include different commentaries than others. The wiki framework allows for community collaboration towards defining the rules for how such texts should be presented with commentaries (sometimes in multiple wiki-editions when warranted), and also for working on the texts themselves. This cannot be accomplished with "Proofread Page".
• Hyperlinks. We are dealing with literature where even the shortest works contain thousands of direct references to previous literature. Hyperlinks make our editions of such works the most useful ever re-published. "Added value" that didn't exist within the scanned edition, but must be within the same Wikisource library.

There is plenty of classical literature in English (or that has been translated into English or can be) that could enrich the library at English Wikisource as well and provide ever more treasures to readers that can best be developed right here. (I immediately think of Aristotle and the generations of commentaries on his works.) I think the above examples also show that Wikibooks, a wiki devoted to writing study guides for schools or hobbies, is certainly not the place for developing and serious collection of literature. The right place is the multilingual library built by the wiki method, namely Wikisource in its many languages.

I truly hope that English Wikisource will never turn into a slightly-more-useful clone of Distributed Proofreaders. What DP does is outstanding, as is the transcribing of scans that is done right here at en.wikisource. But don't limit the library just to what is standard for certain kinds of literature with certain specific tools. Think out of the box! Encourage and make use of any and all ideas to expand this library. The beauty of the wiki-method is that it allows new ideas and new methods, and thus leads to new valuable content that might not have been possible previously. Don't close the wiki off! Keep up the excellent work, and make sure the website's mission is formulated broadly so that it will remain open to new ideas in the future. Dovi (talk) 17:22, 27 November 2010 (UTC)

Eliyak says above "In my opinion Wikisource is the best location for free-content collaborative translations because of its goals of maintaining fidelity to the original text. ... If the translation paraphrased the text into modern vernacular, or gave an ideologically based translation (such as Artscroll does) I would agree wholeheartedly that the translation belonged at WikiBooks." This seems to me a good argument for not allowing translations. Just because we have a goal doesn't mean it will be achieved. The Bible is an excellent example. We have no need to create our own translation as there are PD translations. And one person's good faithful translation of such a work is another person's "ideologically based" one, as the Bible project demonstrates. Longfellow (talk) 10:43, 28 November 2010 (UTC)

On the contrary, I think that it's a strength of Wiki-(source) translations, that they can be edited and improved by anyone. And, as these translations are in fact source-texts, they belong to Wikisource in my opinion. However, I asked the Wikibooks-community (see b:Wikibooks:Reading room/General#PD-Translations on Wikibooks?), what they think about this issue. --D.H (talk) 11:26, 28 November 2010 (UTC)

(copy of my response in case anyone isn't following along at Wikibooks) I think Wikisource is the place when the translation intends to preserve the original meaning with no other changes. If the intentions is to also provide an updated work of educational value, I think the answer depends on what form the work is intended to take. If the work is intended to take on an encyclopedia quality it should be forked to Wikipedia after translation. If the work is intended to take on a form that is within Wikibooks' scope than it should be forked to Wikibooks after translation. If the work is intended to be some other kind of learning material it should be forked to Wikiversity after translation.

Different language editions of Wikisource may have different inclusion requirements about translations too. Whether translations intended to preserve the original meaning belong at the target language Wikisource project or should be moved there after completion is best left up to Wikisource. --darklama (talk) 12:42, 28 November 2010 (UTC)

I was directed here by the Wikibooks discussion. Straight translations would not be acceptable at Wikibooks (see WB:SOURCE). Specifically, Wikibooks does not allow original fiction or literature per policy. What would be acceptable? I would say a translation or modernization of a public domain textbook would be okay. Also, Wikibooks allows annotations of source texts for the purposes of study guides for students, similar to Spark Notes. A translated piece of literature could possibly be worked in via a loophole at [[b:WB:WIW#Wikibooks_includes_annotated_texts|]], which says that annotated texts are permitted and that annotated texts "are a kind of text that includes an original text within it and serves as a guide to reading or studying that text" (emphasis mine). So a person could probably place a translation at Wikibooks if such a translation is heavily annotated by the translator and the original text is freely licensed. Add pages on characters and settings and concepts and you have something like the text chapters of The Grand Inquisitor. Investiture of the Gods may be an abuse of that loophole in that it is likely a straight translation with no annotations. – Adrignola (talk) 16:16, 28 November 2010 (UTC)

The Bible is a terrible example. It is indicative of the most useless Wikisource translation, IMO, given that we do have a host of PD translations. But there are a lot of works out there that don't have free translations, or in many cases have never been translated at all, and for the most part these translations are not going to be contentious. By killing Rat on a tray and Pinglopiketoj, you're taking away something unique, valuable, and completely unproblematic.--Prosfilaes (talk) 16:56, 28 November 2010 (UTC)

• My contribution: personally I like the flexibility to allow Wikisource translation of PD works, as it gives us a way to give access to works that may otherwise be hidden away in XX.wikisource and in an different language. For example, the Berber Dahir (translated by myself, and proofread by a French speaker) may not have been otherwise accessible to a non-Francophone, depending on the PD translations that may or may not exist, may or may not be available on the Internet and may or may not have acceptable provenance, licence-wise.
• However, I do think that Wikisource translations should be held to a high standard, so if a half-finished or poorly translated document is on Wikisource with no prospects of improvement, it can be deleted, or at least moved out of the "main" namespace. We also need to be vigilant against people "contributing" automatic translations. Having the Wikisource translations automatically tagged and categorised helps us to keep an eye on things as it is.
• Possibly we could also consider a policy whereby you cannot have a translation on en.WS without the original text on the relevant other Wikisource, though this might be a restriction in the absence of scans, meaning that you can't host at e.g. de.WS.
• I also think we could have an international forum where contributors can ask for help from other Wikisources on translations. Of course, we don't want to overwhelm the generally small WS communities, but I think it would be a good exercise in inter-Wikisource relations if it were possible for (say) an English user to request a (say) Spanish user check an original English translation of some interesting Spanish work. Likewise, a Spanish user could post his own English translation at en.WS and request an English proof-reader. These are both en.WS-centred, but I would think the cooperation could extend both ways. I would anticipate the rate of requests and fulfilments to both be pretty low, but in some cases, this may be a valuable resource.
• I don't think it is a good idea to host at Wikibooks, as it would seem to be even further out of their scope than ours, except for textbooks. Even in the case of textbooks, it is questionable for Wikibooks to deliberately host out-of-date material.
• In summary, I like having the option of a user-contributed translations at Wikisource, but I think we need to be careful to only host "good" translations. Inductiveload—talk/contribs 22:54, 28 November 2010 (UTC)

A couple of reflections. As WS-generated translations sit outside of the standard "published/peer-reviewed" works, do they belong in our main namespace? Or might this be something that puts them into another namespace, be that an existing namespace or yet another? If they stay where they are, do we look to emphasise their difference, well at least more than we do now. At the bare minimum it seems worthwhile each of the WS wikis to have a conjoined Wikisource:WikiProject Translations, and one wonders whether there needs to be a tie-together with oldwikisource: so this does not belong solely as an enWS directed project.— billinghurst sDrewth 23:58, 28 November 2010 (UTC)

I would suggest the following templates, and depending on the article, one of them should be placed at the beginning:

What do you think? --D.H (talk) 10:26, 29 November 2010 (UTC)

Do you have transwiki import set up from English Wikibooks? I didn't see a page for requesting imports when searching. It is possible that consensus will be found to have Investiture of the Gods, a translation of Fengshen Yanyi, seen at Chinese Wikisource brought here. If not allowed here, a transwiki result would become a deletion; Wikibooks is not a repository for source texts and so it is out of scope there. Adrignola (talk) 14:06, 11 January 2011 (UTC)

Yes. Will take to your talk page. — billinghurst sDrewth 14:19, 11 January 2011 (UTC)

Above there are two excellent practical suggestions. Actually there are more than two, but there are two that can be developed immediately at en.wikisource, and which would settle nearly all of the real or perceived problems discussed above:

1. Inductiveload: "However, I do think that Wikisource translations should be held to a high standard, so if a half-finished or poorly translated document is on Wikisource with no prospects of improvement, it can be deleted, or at least moved out of the "main" namespace." And billinghurst asked: "...do they belong in our main namespace?" This is a simple, neat, and highly intuitive solution which myself and others have suggested in the past. Having a "Translation:" namespace and an "Annotation:" namespace is a a clear and effective way to differentiate those works that are fully-verifiable transcriptions (down to each individual letter) from works that contain (at least in part) original Wikisource contributions or added-value. The latter namespace could also include the kinds of critical editions I described above, or any edition that for whatever good reason doesn't exactly conform to a previously-published edition.

   At this point in time, I am not suggesting another namespace, though wondering whether either the Wikisource: or the Portal: namespaces may be appropriate. Newbies have enough issues fumbling through those existing without getting buried in more. It would be good if we could first see what we can sensibly fit into the existing spaces. — billinghurst sDrewth 00:20, 30 November 2010 (UTC)

   If we don't create a new namespace, we only have one that takes content: the main namespace. Wikisource is for the bureaucracy, and Portal is for portals, neither of which translations or annotations are.--Prosfilaes (talk) 02:06, 30 November 2010 (UTC)

   In terms of newbies, using appropriate names with clear purposes will be positive and effective enough. One or two more won't bother them as long as it is clear what they are for. In our experience at he.wikisource, the following method is extremely clear and works quite well (using Descartes' Meditations on First Philosophy as an example): Meditations on First Philosophy (Jones) in the Main Namespace is a basic transcription of the book from a scanned public domain translation by "Jones" (with no added value). Annonation:Meditations on First Philosophy is a fuller edition (possibly created through transclusion) that might include helpful new titles for sections, or a digest of commentaries, or references to later philosophers who cite Descartes, in addition to the main text. A new translation from the Latin by Wikisource contributors would be called Translation:Meditations on First Philosophy (it might actually be an updated version of the Jones' translation instead of an entirely new one). And finally, Wikisource:Meditations on First Philosophy is a process page created by the community, which explains the reasoning behind the the various editions of Meditations on First Philosophy at Wikisource, the editorial rules and decisions governing those editions, and the current status of the work being done (e.g. transcription complete, translation-update halfway done, titles for subsections complete and digest of commentaries written for selected chapters). A link to the process page usually appears in the title page like this: About this edition. I think using "Portal" would be terribly counter-intuitive.

   Regardless, the essential question that should be considered is whether en.wikisource wants to use namespaces for this purpose. If the answer is yes, then deciding what to call them is a much smaller problem. Dovi (talk) 04:29, 30 November 2010 (UTC)

2. D.H suggested a regimen of appropriate templates for assessing the quality and peer-review of documents that contain some amount of originality. That is the normal and appropriate of dealing with issues like this in a Wiki framework. At Hebrew Wikisource we went a step further than that, and implemented the "Stable Versions" extension along with its built-in rating system for this purpose.

Namespaces and a template system would add clarity and promote healthy standards for both readers and editors. Dovi (talk) 18:31, 29 November 2010 (UTC)

What about Template:Translation (I've included some changes)? --D.H (talk) 11:46, 1 December 2010 (UTC)

I started to write this over a week ago but my notes were scattered between work and home and I lost what I had started in a reboot. But there are a few points I would like to add to this discussion. Online collaborative translations are going to happen. People's conception as to what can possibly to done collaboratively has been altered in the past ten years and translations are an area that is particularly well suited to needing the internet to gather collaborators who are dispersed globally. Even people who have no known connection to Wikimedia are talking about this. I happened to read a book this year, and because I am a geek who reads books cover to cover I read the acknowledgments and was surprised to read the author suggesting that a wiki be used to translate Le Opere di Galileo Galilei into English (Acknowledgments page here ). I am certain that such collaborative translations are going to be undertaken successfully on the internet in my lifetime. I think Wikisource is well poised to the place for this breakthrough to happen. En.WS has a community that cares about texts and thinks a great deal about how to best maintain the fidelity of texts while digitizing them. In addition, we are well-connected to a network of such communities in different language traditions. We are also connected to a community of people who have broken a great deal of ground in how to manage the actual work of collaboratively translating messages online. The Wikimedia translators who work on with the fundraisers, board elections, and WMF official statements are a great resource that we haven't really consulted. I think we should ask their opinions before committing to any particular template system (It would probably be a good idea to wait till the fundraiser is finished though). I think the two terms that are technically used are "accuracy" for the proofread by the native of the source language and "fluidity" for the the proofread by the native of the target language. I believe that Wikisource will have to as innovative as Wikipedia was back in 2004 to make this breakthrough into collaborative translations succeed. There is a lot of work to be done in this area, both in technical solutions and in collaboration management, and not much of a road map on how to do it. However, whether we do that work or someone else does, I have no doubt that the breakthrough will be made. The only real question I think the there is over the future of collaborative translations is whether or not they will be free content. That is one thing that our work here can guarantee. If the breakthrough, however, comes by way of hundreds of special interest societies each translating there own special interest topic, I think it is likely that the translations will simply copyrighted in the same manner that those societies copyright the journals they currently produce. It seems mostly likely to me that it will bee either us or one of those societies (and then spread about to other such societies), that will make the breakthrough. We probably have the technical advantage, they probably have the collaboration advantage. So I really think the next steps are to talk to people who have been doing translations for Wikimedia and think hard about how we can best adopt the tools we have found to work for simple proofreading into a translation framework. If we can develop a strong and intuitive technical framework for collaborative translations we can attract the translators. If we can develop strong community backing and a networking system to support those translators, we can convince them to do the collaborative work here and release their work under CC-BY-SA. If we only manage the first, there is a possibility that a good number of potential contributors to Wikisource will simply start their own wikis with a much narrower focus and keep the resulting texts copyrighted. --BirgitteSB 20:00, 12 December 2010 (UTC)

I think that Birgitte is absolutely right that these will exist and probably that WMF should have a place for them. I also largely endorse Dovi's comments. A few things I think we need to look at further though:

• Any wiki translations are going to be subject to change as pointed out above, unlike our core work they are always going to be somewhat subjective.
• The literary intent and the relative importance of the underlying original are going to drive the subjectivity level: a relatively literal work on mechanical processes is going to be less subjective, poems will frequently reach "mind-blow" subjectivity levels; the "great works" are going to cause more people to apply their subjectivity due to interest level. Eliyak's comments notwithstanding, staying true to the original text is often a very subjective matter.
• Unlike many of our works, no underlying source text will be available that can be looked at to see objectively whether the text is "correct".
• We have many forms of modern English in use all of which are valid. Additionally as Prosfilaes has pointed out above at Proposals, there are also non-modern Englishes that some editors may want to use for translation purposes.
• Consequently, unlike any other works we host, wiki translations may draw disputes, POV issues, and a new level of vandalism and we could end up with many independent versions; not to mention forks when editors disagree on the translation of a couple words. Although we may draw collaborative groups with our technical solution, as Birgitte suggests, we may not want all of them. ;-)

These are not, however, reasons to reject them; rather they are the kinds of issues we will have to manage if we (continue to) allow them.

I think sDrewth/Billinghurst's comments about a separate namespace (or maybe that was Dovi who said that) have merit; especially with respect to user annotations or annotated versions of texts. Whether a separate namespace is used or some other technical solution, it would be useful to all to clearly distinguish where we are acting as a library from where we are acting as a collaborative translation and/or annotation project - if we choose to be both. Furthermore, we should take holistic approach and consider translations together with annotations. Although we've generally said that user annotations don't belong her but belong at Wikibooks, neither our practice, our policy (or lack thereof), nor common sense, would drive such a bright line. When working with arcane texts, as I often do, one finds many opportunities to link to Wikipedia, strict rules suggest these are user annotations that belong on Wikibooks; however, practice allows me to link to another work in Wikisource, an authorspace page, or a wiktionary article although there is just as much potential for me to do so in a POV manner. In many ways, this prevents us from using the WMF framework for anything useful and from creating a truly useful text. It also results in the complete duplication of texts due to the technical limitations that prevent transcluding a base text here into wikibooks. Even for translations this has occurred. We need a common solution because annotations and translations are both subjective and both need to be somehow distinct from the pure transcriptions that are at the core of our project - and there is no such thing as a pure translation - furthermore, they both serve related purposes by making works more accessible to the English-speaking reader.

If we don't want these issues, we should restrict ourselves to transcriptions.

A few ideas, more brainstorming than trying to actually propose things:

• Translations could require pre-translation vetting of proposals such as de.ws uses for long works, this could ensure more than a single person was involved from the start, or if not at least that we knew about it and that the community agreed to the idea of a a wiki translation for that particular work.
• Translations could have a sort of post-vetting, in which various native speakers certify the translation. This is essentially what the various headers above suggest and is also similar to de.ws's greater requirements for proofreading. Though if we put this in a talk or transcluded from a subspace we could allow for an unlimited number of reads.
• Translations (and user annotations) could also adopt the practice on other projects of setting up edition ground rules at the outset, posting these to the index (as on de) or the (main) talk page and possibly including these in the pre-edition vetting suggested above.

Yes, I know these ideas are ideas for more rules and bureaucracy but there must be a way to establish what community consensus is with respect to a specific wikitranslation/wiki-annotation. I'm sure I'll have more later, but believe Birgitte is correct, if we reject these from our area, we drive them elsewhere and possibly drive them outside WMF to places where the result may not be free. --Doug.^{(talk • contribs)} 12:26, 5 February 2011 (UTC)

I started working on books for children and intentionally enlarging the text, primarily due to our standard text size being, in my opinion, fairly small. This can be changed many ways, ie in the browser or even in the PC settings. However, computers are typically shared, so something internal to WS should take care of that. I also enjoy consistency among the pages, so editing each work for a specific text size seems tedious, and for some, unnecessary as they may have the setting outside of WS to enlarge the text in their browser or computer. In fact, one large work (that I can't recall at the moment) which was validated offered very large font and looked great on my PC, but after viewing it on a different computer with a smaller resolution, the text size was largely unnecessary, and made the page length gigantic as roughly 10 words fit per line. I think that if all of our pages were constructed in the default text size there would be some benefits:

1. Uniformity among the appearance of pages
2. One less parameter to consider when building
3. Give users the option of size regardless of their browser/PC settings

There are also some problems with compatibility I imagine on existing pages which already define text sizes, as well as page widths. But maybe we could start with some test pages if you like the idea? Let me know what you think. - Theornamentalist (talk) 22:46, 28 December 2010 (UTC)

We generally recommend that people under-format rather than over-format, though where a work is more artistic, then there has been a tendency to be follow the trend. Some do like to go towards a replica rather than a transcription. Most of our size changes are done as relative rather than fixed. We also see that issue with page widths, especially with the emergency of wide screens. It is all a challenge and one where we need vigilance. — billinghurst sDrewth 01:53, 29 December 2010 (UTC)

How about a row for text size in Display Options? This is currently fitting into the "Layout" row, but I think text size should have its own; check out what I mean by position in the left bar:

here's what I'm working with:

self.ws_layouts['Larger text'] =

    { '#text-container':"font-size:135%" , }

and for those who do not feel like modifyig their vector.js I've made a side by side comparison. Note that the :Page: links do not increase in size, the pictures maintain their original size, as does every non-work page. Also, it is an unenforced option.

Still feel the same way I did a month ago about this. Can we try this out in MediaWiki:Common.js? - Theornamentalist (talk) 03:16, 30 January 2011 (UTC)

For months now i am fighting with the three selectable layouts. Most of the pages of book that i maintain here most of the time, Gesenius' Hebrew Grammar, look as they should only in Layout 2; its table of contents looks as it should only in Layout 1. I can make the table of contents look well in Layout 2 and this will more or less solve the problem for me, but not for the casual anonymous reader, who will see the bad display in Layout 1 and will not have any idea that to make the book look as it should he has to click "Layout 1" to switch to "Layout 2".

How exactly Wikisource readers are supposed to know about these selectable layouts? It's an odd link with an unclear name hidden in a sidebar. I am a pretty experienced Wikisource editor and it took me a while to get used to it and i'm still cursing it; why do we force the casual readers to cope with that?

Please don't get me wrong - i appreciate the designers' work, but this system is just wrong. --Amir E. Aharoni (talk) 15:58, 19 January 2011 (UTC)

Regarding your table of contents, you can force a width to make it wider in layout 2: see the TOC of State Documents on Federal Relations.

Regarding giving readers the option of alternate layouts... I've also thought about how to better tell users about those options. I don't like the idea of including notes on pages, like what appears on Page:Gesenius' Hebrew Grammar (1910 Kautzsch-Cowley edition).djvu/15. But I've thought that perhaps MediaWiki:Anonnotice could be employed for this purpose: we could create a page that briefly describes, with pictures, how to change layouts and view page images. Then, put that link and some welcome text in MediaWiki:Anonnotice, which appears for all anonymous users until dismissed.

Alternatively, it would be great if we could get a way to specify a layout # for each work (perhaps in the header template), and give users options in their preferences to either override or use those suggested layouts. But further development in this area is not likely to happen soon, so in the meantime we need an alternate solution. —Spangineer (háblame) 16:27, 19 January 2011 (UTC)

I don't quite understand why do we give those three layouts in the first place, but specifying the default layout for a page would be nice. --Amir E. Aharoni (talk) 17:07, 19 January 2011 (UTC)

It's much easier for most people to read a narrow line of text than a wide one. So layout 2 can be used by readers who prefer that. But the option is buried on the sidebar; most readers see layout 1 by default. —Spangineer (háblame) 17:13, 19 January 2011 (UTC)

style="prose" used to it quite well. I don't understand why did it have to be changed. --Amir E. Aharoni (talk) 17:27, 19 January 2011 (UTC)

From what I understand, because some users didn't like the narrow lines that style="prose" created, and didn't want to be forced to use it. So this was developed as a solution: it gives each user the ability to choose line width. In some ways this is a better solution, in other ways, not so much. To get a more "perfect" solution, where the creators of works can suggest layouts and user preferences either accept or reject those suggestions, will take a lot more development. And right now, implementing new developments is strictly controlled, making it difficult to do. —Spangineer (háblame) 17:36, 19 January 2011 (UTC)

It it's just some users, it can be made a gadget for them. Changing the default for all users just because a few of them didn't like narrow lines is a rather odd decision.

I don't know about other people here, but i like showing off my works in Wikisource to people in my field. They usually like it. Lately it has become a pain to click that silly "Layout 1" link every time i do it. And it already happened a few times that after a few days they call me and ask me why doesn't it look as nice as it did when i showed it to them. I'm sincerely sorry about venting my frustration like this, but i'm really trying to bring Wikisource to the public and this is quite discouraging.

I just send a screen-grab image of the page(s) needed and email it directly now - its just not worth the time and and effort anymore to try and walk everybody through their browser and settings in order to get them to "see" what I "see". -- George Orwell III (talk) 23:30, 19 January 2011 (UTC)

How much people would be pissed off if it would be turned into a gadget? --Amir E. Aharoni (talk) 18:34, 19 January 2011 (UTC)

Before we get into talk of scuttling the whole thing into an option for logged in users, I have to wonder if it would really take that much effort to make page defaults viz Spangineer. This is probably a naive, hackish idea, but if the conditional in line 19 of init_page_layout in MW:PageNumbers.js were replaced with something like

if (layout) {
  layout_num = parseInt(layout);
} else if (document.getElementById("layout2")) {
  layout_num = 1;
} else if (document.getElementById("layout3")) {
  layout_num = 2;
} else {
  layout_num = 0;
}

and templates were made which contained simply <div id="layout2"></div> and <div id="layout3"></div>, would that not fit the bill? Prosody (talk) 00:28, 20 January 2011 (UTC)

I looked over French Wikisource, and I have to say that I am totally in support of changing the default layout to the smaller width. I know that this can be employed many ways with templates and such, but I think that virtually all of the works look better in it. It's not that I necessarily have a problem with reading wide continuous text (I've been using Wikipedia for years now..) but it does simply look nicer. When a paragraph on a scanned copy spans 4 rows, and that gets reduced down to a single line on Wikisource, it just looks awful. Many works have shorter paragraphs which are reduced to multiple single row after single row.

On a similar note and as a potential benefit, pictures could appear in the whitespace on either side in this format, leaving the text uninterrupted, as right now most images in index format separate mid sentence and even if properly connected can cause slightly larger gaps between text. - Theornamentalist (talk) 22:39, 25 January 2011 (UTC)

Sorry for the above rule but I am adding this 3 days after the last post. I’ve been following this discussion closely because the issue is very close to my heart. I have the identical problem as Amir E. Aharoni, of retaining the proper presentation to interested visitors/readers. Perhaps, a simple code on the Index page(s) of a particular book/project can be added and set the default view for main namespace pages? - Just a thought. — Ineuw talk 05:28, 29 January 2011 (UTC)

I am trying to float the text beside the image in this Page:Popular Science Monthly Volume 13.djvu/328, and I must be doing something wrong, but can’t figure out what. Can someone please look at it whenever time permits? Thanks in advance. P.S: I also put an identical copy in a sandbox HERE. — Ineuw talk 04:50, 24 January 2011 (UTC)

When I see a caption oriented that way, I treat it as a hint that the image itself is intended to be viewed with the page turned so that the caption is oriented correctly. That is, since we can't expect our readers to turn their computer screens on their sides, the image needs rotating. But for what it's worth, I've floated the image for you. Hesperian 08:53, 24 January 2011 (UTC)

Thanks Hesperian for helping me out (again). I always rotate the image as you taught me awhile ago, except that with this image there are two reasons why I kept the vertical layout. The first one was that the etched reference numbers are oriented vertically, and the second was concern that shrinking the image would affect whatever is still visible. Nevertheless, I will upload a horizontally oriented image as well and see how it looks. — Ineuw talk 17:51, 24 January 2011 (UTC)

I didn't notice the etched reference numbers; you convinced me, it is meant to be upright. Hesperian 01:35, 31 January 2011 (UTC)

Please don’t worry about it. The image is uploaded both ways but vertically the text didn’t float on the right side of the image, or at least I couldn’t do it, so there was a large white space next to it. I reverted it for you to see.— Ineuw talk 08:31, 31 January 2011 (UTC)

Is it technically possible to have dynamic layout enabled for works that are not transcluded from the Page: namespace? Is there any reason why we should not do this? - Htonl (talk) 23:15, 28 January 2011 (UTC)

Presently the dynamic layout system is somewhat intermeshed with the proofread page numbering system. I think it would work fine if the test as to whether the article is using PP in init_page_layout were removed, and a similar test were added in refresh_pagenumbers. As to reasons against, articles that don't use PP are frequently from an older, more anarchic period of WS history, and may have special formatting which wouldn't carry over well. This is sometimes even a problem for more recent works which simply predate the dynamic layout system: see a few discussions above. Also, the code to do this is being imported from multilingual WS, and therefore affects other projects, so someone would have to check that the other languages WSes are down with it and don't depend on that behavior. Prosody (talk) 22:23, 29 January 2011 (UTC)

On closer inspection, refresh_pagenumbers already checks it in a roundabout way. So the only technical reason it isn't working is because the function to initialize the dynamic layout system checks whether PP is being used and aborts if it isn't. Prosody (talk) 22:35, 29 January 2011 (UTC)

Can anyone please check what happened to Index of Volume 43. It’s totally messed up and I’ve done a lot of work on the page which I would like to preserve. Many thanks in advance. — Ineuw talk 20:51, 29 January 2011 (UTC)

The Psm template was missing a character. I also adjusted the page numbering so that the number on the index page aligns with page numbers of the text. The offset was 10. JamAKiska (talk) 21:54, 29 January 2011 (UTC)

Many thanks for helping. Now, I can continue. — Ineuw talk 22:01, 29 January 2011 (UTC)

I got very frustrated when I discovered that one page (original page 17) is lacking into the file I uploaded as source file (djvu 1) for Index:Horse shoes and horse shoeing.djvu. It's a large book, ore than 700 pages. There's a much better version (djvu 2), but when taking a deeper look, I found there too some lacking pages! Now, my question is: can I add lacking pages into djvu file 2 taking them from djvu file 1? And a second question: some of you was right, it's a very bad idea to upload pages by bot fro layer text! Luckily I stopped the bot at page 350. But obviusly the pages of the new djvu doesn't match with loaded text. I could avoid to move 300 pages simply adding some empty page into djvu file 2. Doing this, I could move only the text of some dozens of pages, and to edit a little bit pagelist tag. Can I go on? I apologyze for wasting your time; I'll be more careful next time, and I'll never use a bot again to upload text layers. :-( --Alex brollo (talk) 20:34, 31 January 2011 (UTC)

I am nearly ready to upload Lad: a Dog into Wikisource. Can I use the colon in the title? On Wikipedia there is a template named {{correct title}} which must be used when there is a colon in the title. Do we have such a template on Wikisource? •••Life of Riley (T–C) 02:04, 1 February 2011 (UTC)

I believe that you should use the same rules as in Wikipedia. DOS/Windows have restricted characters and a colon is one of them. Using them here may complicate web searches for others. I looked at the article titles where w:Template:correct title is used and a colon is replaced with the hyphen (-). If you are to consider an extreme solution, I titled articles LIKE HERE without punctuation, and images using lowercase characters and without punctuation, for easier use by Linux users. — Ineuw talk 03:27, 1 February 2011 (UTC)

In general, we don't title our works with subtitles, so colons are usually not an issue. Is the colon an essential part of your work's title? Also, you mention "upload": if you mean uploading a file (like a djvu), there are two things to keep in mind—first, we upload files at Wikimedia Commons, not here, and second, in a file name, it's fine to replace the colon with a comma or other punctuation. —Spangineer (háblame) 04:10, 1 February 2011 (UTC)

Actually, by "upload", I mean the upload the text of the novel to Wikisource. Yes, the proper name of the book is Lad: a Dog. I suppose I can upload it as "Lad, a Dog" as it is in Wikipedia (see w:Lad, a Dog). •••Life of Riley (T–C) 05:10, 1 February 2011 (UTC)

That seems like a good way to do it. —Spangineer (háblame) 14:03, 1 February 2011 (UTC)

Mostly colons in titles are OK, but in this particular case "lad:" is the the code for the Ladino language so there would be a clash. Your suggestion makes sense, since following Wikipedia's lead will reduce confusion. - Htonl (talk) 14:47, 1 February 2011 (UTC)

Does anyone know how to make http://twitter.com/Wikisource look like http://twitter.com/Wikiversity .. ? And who is this dr.nate? John Vandenberg ^(chat) 08:16, 2 February 2011 (UTC)

It looks like we/WMF might be able to have this fixed via their trademark and policy. John Vandenberg ^(chat) 10:20, 21 February 2011 (UTC)

I've just found WikiSourceBot. It looks like it is a filtered feed of Special:NewPages. \o/ I think the page selection algorithm could do with some improvement --John Vandenberg ^(chat) 10:16, 21 February 2011 (UTC)

I've chatted with the author of WikiSourceBot, and it is based on Special:Random. Any enhancement requests? John Vandenberg ^(chat) 23:33, 22 February 2011 (UTC)

I had noticed that the format changed earlier today, between The Call of Cthulhu and Rosalie. Is it possible to add the author's name to the message? Alternatively, can it post an occasional random author (say, every 20th tweet or so)? I'm not sure of the limits of this bot. - AdamBMorgan (talk) 00:37, 23 February 2011 (UTC)

I would like to see a similar format to what is present in {{new texts}} title/author/year. Also, I think that if there are tweets that some of the priorities are new texts, PotM, and FT as they are our active works, and where the effort is occurring. I am not sure whether we want to advertise new protals and author pages, though some of those do have some information, at least in a collective summarative sense, though generally the interest in these pages will lag rather than be interesting in NEW. So once we bring people in, it is our task to show them around. — billinghurst sDrewth 01:43, 23 February 2011 (UTC)

I am creating on a new texts twitter bot. Can we added completed POTM to new texts, at least where they are a new text?

We could create a separate twitter 'topic' bot which filters special:random/author and special:random/portal so that only 'good' author/portal pages are tweeted. How many authors and portals do we have? I thik we want a low frequency otherwise we would cycle through all author&portal pages too quickly.

I think the 'wikisource' twitter account would be suitable to announce the monthly FT and advertise the start of each POTM. They are low volume, so we don't need a bot for them. I've sent out an email to wikisource-l to ask who this dr.nate is. John Vandenberg ^(chat) 04:02, 23 February 2011 (UTC)

I think we need bugzilla:16655 fixed so the random twitter feed does not include subpages? I've added it to oldwikisource:Wikisource:Bugs. John Vandenberg ^(chat) 03:52, 23 February 2011 (UTC)

You should create http://identi.ca/wikisource as well; I've already created https://identi.ca/group/wikisource. Nemo bis (talk) 08:51, 23 February 2011 (UTC)

Could you do that; I'm still getting my head around twitter. John Vandenberg ^(chat) 10:01, 26 February 2011 (UTC)

Done, let me know when/if I can transfer it to you (I need an email address not used by other identi.ca accounts). Don't forget to connect it to the Twitter account, when Moka recovers it. Nemo bis (talk) 11:04, 26 February 2011 (UTC)

I didn't find a help page about linking guidelines. Obviously I'm not speaking of links coming from main templates, but of links that could be added into the text:

• links to authors present into en.source;
• links to works present into en.source;
• links to wikipedia, pointing persons, works, topics;
• links to wictionary.

Is there an help page missing my search? Thanks. --Alex brollo (talk) 11:21, 2 February 2011 (UTC)

There's Wikisource:Annotations and Wikisource:Style_guide#Wikilinks. In actual practice, it seems that links to works and author pages are usually uncontentious, as are Wiktionary links for uncommon words. Wikipedia links will sometimes be edited out or disputed on the talk pages. Prosody (talk) 20:29, 2 February 2011 (UTC)

Prosody gave a good summary of actual practice. In general, I avoid linking to WP (except in headers) because links to WS works, authors, or portals are almost always just as good, and they keep our readers here. —Spangineer (háblame) 20:41, 2 February 2011 (UTC)

OK thanks, very similar to guidelines into it.source. --Alex brollo (talk) 22:10, 2 February 2011 (UTC)

I've run into a pretty odd bug. Not really sure what the exact circumstances are, but on Language and the Study of Language/Lecture VII the page number for 254 gets placed above 252, and 253 gets deleted because of a test in the page number generating code to confirm that the immediately following number is sufficiently higher than the the immediately preceding number. It doesn't seem like the page break spans that are placed by the proofread page system are in incorrect locations, but the proprietary function to determine the offset from the top of the page gives a weirdly low number for 254. So also does jQuery's offset function! I found some reports of bugs in that function in earlier versions of jQuery which are supposed to be fixed in newer, but even deploying those with web inspector, still no dice. Anyone have a better idea of what's going on here? Prosody (talk) 20:40, 2 February 2011 (UTC)

I see the same problem in Chrome at State Documents on Federal Relations: page numbers down the left are 1, 2, 7, 4, 5, 9, 10. Page 8 is not called, but 3 and 6 get lost in the shuffle. I don't have a solution, but Chrome is a popular browser and this bug is a problem. —Spangineer (háblame) 21:43, 2 February 2011 (UTC)

The same thing is happening with Firefox with State Documents on Federal Relations. --kathleen wright5 (talk) 21:53, 2 February 2011 (UTC)

And also with Internet Explorer 8. --kathleen wright5 (talk) 22:02, 2 February 2011 (UTC)

Hope it is not to late to jump into this conversation. Am in the middle of uploading volume 58, and am not having any success accessing the uploaded images in the edit mode or the image view mode. The uploaded text images are available while reading the page. My browser is chrome. Could someone please take a look with anther configuration? Thanks… JamAKiska (talk) 23:09, 2 February 2011 (UTC)

You can partially check rendering under IE 6, 7 or 8 at http://ipinfo.info/netrenderer/ to see if that helps narrow down the cause some. FWIW....

Images come up slow for DNB vol 58 but they do come up on the pages I checked in edit-mode.

State Documents comes up [1]=5, [2]=6, [7]=11, [4]=8, [5]=9, [9]=13 and [10]=14 in Layout 1 on the left-side (I think this has to do with use of <pages> syntax more than anything else) but Layout 2 or 3 sends the left-side links into the middle or to the right-side somewhere. [IE 6 & 7] — George Orwell III (talk) 00:39, 3 February 2011 (UTC)

I think this problem has always been known to come up with tables--see an earlier revision of Help:Proofread, which advises against using PP for full page tables at all! They're both symptomatic of a general problem though, that calculating offset information is for whatever mystifying reason extremely error-fraught. I don't normally do web design so I can't recommend an actionable remedy for these particular problems or an alternate implementation of displaying page numbers (would it be possible to keep them inline such that the y offset wouldn't need to be calculated and they'd just need be placed in the left margin?). If anyone who knows a bit about web design and JS has a free hour, please take a look at it. The relevant code is at oldwikisource:MediaWiki:PageNumbers.js. Prosody (talk) 02:31, 3 February 2011 (UTC)

Its a combination of factors, one of which is typically the use of tables spanning multiple pages, plus the use of 2nd, 3rd, 4th etc >noincludes within the normal pagetext field and/or the use of templates that, for the lack of a better term, "switch" content item links in the Page: to their corresponding anchors in the main namespace. Once the "redlink" portion of the auto-switched section of the State Documents table is removed, the page numbering corrects itself.

See the sandbox for this tranclusion. Page numbers fine up to 1st page of multi-page table (happens to be the only pagecontaining no redlinks)

In order to determine if it is the link conversion template being used by itself or a combinition of factors, one of which being the use of auto link-namespace conversion templates, etc. the rest of the table needs to valid links added or a temporary removal of such template use from the pagetext field. — George Orwell III (talk) 03:54, 3 February 2011 (UTC)

Fixed. Factors were (1) last item on previous page was always one of those auto page-namespace-to-main-namepace link converter templates at the end of a closing table-column-cell preventing the insertion of a paragraph <p> or <span> tag needed on following for page break & transclusion. (2) every page opened with a table cell column aligned right followed by the text-content for that cell; making insertion of same paragraph <p> or <span> tag needed for page break transclusion impossible without injecting an extra line. (3) workaround for extra line was not to use the page namespace header for no-inclusion but to use a second no-included section in the pagetext field immediately at the top to hold the opening table-row-column, etc. info per page; again, prematurely "closing" the abilty for the needed insertion of a paragraph <p> or <span> tag at that point. The fixes in the page namespace are more for illustration so the transclusion could be viewed properly. There must be a more elegant solution than forcing a 3rd span tag from the end of one page to the top of the next to create a "wrap" where the needed tags for page-breaks in transclusion can be inserted properly. — George Orwell III (talk) 05:50, 3 February 2011 (UTC)

I had a fiddle to present an alternative as starting a row on the previous page is a fraction icky when someone else is proofing it. In that it is about either sticking in a <!--placeholder comment--> or <noinclude>start of the table rather in the body</noinclude>. It is one of those times that the {{ts}} template doesn't overwhelm the text. — billinghurst sDrewth 09:14, 3 February 2011 (UTC)

Well be it at the very top of the pagetext field or somewhere before the end - some browsers will take that "foreign" 3rd no-include and interpret it as the footer no-include; blanking all text after that point upon the opening edit tab click under the Page: namespace, so some potential readers will loose out that way instead of opening the icky squeezed-in pagebreak transcludible-wrapper from end of the page before to top of the following page. It's a catch 22. — George Orwell III (talk) 09:55, 3 February 2011 (UTC)

The <!--placeholder comment--> method does allow for insertion but does so by going against the basic HTML "table rules".

Note the underlying code of the mainspace page showing the table rows & column cells at the transcluded pagebreak point and the location of the opening and closing paragraph & span tags below...

<<<<SnIp>>>
 <tr>
   <td align="right">27.</td>
   <td><a href="/wiki/State_Documents_on_Federal_Relations/27" title="State Documents on
     Federal Relations/27">Resolutions of Virginia against the Bank. 1811.</a></td>
   <td align="right"><span align="right">54</span></td>
 </tr>
 <tr>
   <td align="right"></td>
   <td><a href="/wiki/State_Documents_on_Federal_Relations/28n" title="State Documents on 
    Federal Relations/28n">Massachusetts and the Militia Question. 1812–14.</a></td>
   <td align="right"><span align="right">54</span>
<p><span><span class="pagenum" id="4" title="Page:State Documents on Federal Relations.djvu/8"></span></span></p>
   </td>
 </tr>
 <tr>
   <td style="text-align:right;">28.</td>
   <td><a href="/wiki/State_Documents_on_Federal_Relations/28" title="State Documents on
    Federal Relations/28">Letter of Governor Strong to Secretary of War. 1812.</a></td>
   <td align="right"><span align="right">56</span></td>
 </tr>
<tr>
   <td align="right">29.</td>
   <td><a href="/wiki/State_Documents_on_Federal_Relations/29" title="State Documents on
    Federal Relations/29">Opinion of the Judges of Massachusetts. 1812.</a></td>
   <td align="right"><span align="right">57</span></td>
 </tr>
>>>sNiP<<<<

←←This inserts the dredded extra line between the non-included header and the start of the desired content in the pagetext field under the Page: namespace as well bloat what appears to the eye as the normal line-height for that table-row when transcluded and rendered in the main namespace. Some folks will see the "bloated" line-height right away, others will need to try different font sizes to see the effect.

The other factor in play as mentioned above is the use of {{DJVU page link}} in the last table-row column-cell at the end of the page prior to the break. It forces the span tag before the paragraph tag wrapping the actual needed-to-transclude-pagebreak-correctly doubled up-span tags closed (the <span align="right">54</span> line). Ever wonder why your hover mouse-pointer highlight the-page-text feature starts indented anywhere from a bit over from where it should be all the way up to way over somwhere in the content? It's because of the constant "breaking" of traditionale HTML coding "ettiquette" for the sake of such wikibilities. — George Orwell III (talk) 10:59, 3 February 2011 (UTC)

I have returned it to your version as the stable version. — billinghurst sDrewth 11:26, 3 February 2011 (UTC)

OK - now let's look at the same page-break point.....

<<<<SnIp>>>
 <tr>
   <td align="right">27.</td>
   <td><a href="/wiki/State_Documents_on_Federal_Relations/27" title="State Documents on
     Federal Relations/27">Resolutions of Virginia against the Bank. 1811.</a></td>
   <td align="right"><span align="right">54</span></td>
 </tr>
 <tr>
   <td align="right"></td>
   <td><a href="/wiki/State_Documents_on_Federal_Relations/28n" title="State Documents on
    Federal Relations/28n">Massachusetts and the Militia Question. 1812–14.</a></td>
   <td align="right"><span align="right">54</span></td>
 </tr>
 <tr>
   <td align="right"><span><span><span class="pagenum" id="4" title="Page:State Documents on Federal
     Relations.djvu/8"></span></span>28.</span></td>
   <td><a href="/wiki/State_Documents_on_Federal_Relations/28" title="State Documents on
    Federal Relations/28">Letter of Governor Strong to Secretary of War. 1812.</a></td>
   <td align="right"><span align="right">56</span></td>
 </tr>
<tr>
   <td align="right">29.</td>
   <td><a href="/wiki/State_Documents_on_Federal_Relations/29" title="State Documents on
    Federal Relations/29">Opinion of the Judges of Massachusetts. 1812.</a></td>
   <td align="right"><span align="right">57</span></td>
 </tr>
>>>sNiP<<<<

The only reason this open-span-tag → non-included-footer → actual-pagebreak → following-page-non-included-header → desirable-text-content → close-span-tag → close-paragraph-tag happens to "work" for this particular multi-paged-spanning table problem is the same reason {{nop}} works for preserving the desired "extra-line +break" from the end of a paragraph proper at the bottom of one page to the next paragraph-proper at the start of the page that follows without actually "hitting your return key twice" - it nullifies what I assume is nothing more than than inverted opening and closing paragraph tags, rendered in differing sequencing, being dropped when transclusiion takes place (IOW you only need to prefix some text with a <p> - it assumes a closing </p> tag without the need to type one, especially if the next tag found happens to be another opening <p> tag and, at the same time, a closing </p> tag Not preceeded by an opening <p> tag is discarded and not-rendered. The sequencing of the opening and closing paragraph tags is what I believe "no-include", etc really is).

The closing paragraph tag after the "extra" span that is manually added to enable the normal double spanned page-break's URL(title=) and Page#(id=) transfer during transclusion satisfies this first-line/unwanted extra line jeopardy by "faking out" the header (non-included) in the Page: namespace (which is completely discarded in the mainspace rendering as shown in the underlying code in box#2 above).

I realize it's not a perfect solution, nor easy to explain, but it is a solution that does NOT contradict traditional HTML coding and I'll bet everybody "sees" exactly the same thing in both namespaces instead of bits and pieces depending on what browser you are using. This is why, imho, some tables are NOT worth creating using simple wikified table-notation over the plain old html tags. — George Orwell III (talk) 12:39, 3 February 2011 (UTC)

The talk is a little bit intricated, but perhaps it's not a bad idea to tell here again a "discovery of the wheel" recently found into it.source into a general form, after many headaches from troubles in formatting transcluded text: "When a html block (div, p, list elements, td) is splitted into two pages, use html tags instead of wiki markup and apply the trick to close block into footer of the page 1 and open again it into header of page 2". I.e., it.source uses : and ; tags for theatre, and now it's very easy to merge splitted texts following this rule (t.i. using explicit list tags instead of : and ; tags for splitted texts). Explicit use of p tag prevents often automatic wiki addition of the tag, that's the source of other painful headaches. --Alex brollo (talk) 16:45, 3 February 2011 (UTC)

Nothing is ever "split" as you infered above occurs in this particular example. Every page "ends" with a table row (</tr>) and every page that follows 'technically' (the desired text content & not the repetative noinclude table header) starts with a new table row (<tr>). The point between the two is where the page break needs to occur but cannot since span and/or paragraph tags cannot "intersect" @ the table row tags. In transclusion, they must find a way to be injected at the end of the last table-row's last column-cell at the bottom of a page or the first table-row's first column-cell at the top of the following page.

The use of {{DJVU page link}} pretty much closes out the last-row last-cell option (speaking of DJVU page link - what cafacta browser renders <span align="right"> as valid HTML anyway?) so the only thing left to do is force it into the top of the first-row, first cell of the next page. This works but the side effect is the extra line +break; leading some editor's to try and work-around that with the addition of another noinclude tag - leading to the loss of either editing capabilities in Page: namespace for still some-other sub-set of editors or causes "line-bloat" in the main-space for any remaining editors (or some combination/vise-versa of that)

To be clear, the use of : and ; only "cloaks" the use of plain old html tags for defined lists, defined terms etc. (<dl> <dt> and <dd>. These options still couldn't help us in this specific table example. — George Orwell III (talk) 17:19, 3 February 2011 (UTC)

I apologyze for OT, caming merely from association of ideas. Amost nothing to do with the specific issue covered here. --Alex brollo (talk) 18:12, 3 February 2011 (UTC)

I found very comfortable to add these rows to my vector.css, so fixing toolbar to the bottom of the browser page; no more scrolling to find it when editing Page: contents.

/* moves toolbar into a fixed, bottom-of-page position, very confortable when editing Page text without scolling */
div.mw-editTools {width:98%; position:fixed; right:0%; top:85%; height: 15%; overflow:scroll; 
background-color: aliceblue; color:#202122; border: 2px solid cadetblue; opacity:0.9; z-index:10;}

Try it if you like… and leave me a feedback (or, better, develop the idea …) or tell me if I discovered the wheel once more! ;-) --Alex brollo (talk) 16:03, 3 February 2011 (UTC)

Ineuw tested it, with an interesing observation: my trick only has some utility (with some drawbacks…) if you use side by side view, while it's unuseful if you use top-down view. So, it turns out as that kind of tricks, depending on user preferences.Not so a brillant idea….:-( Nevertheless it could be inspiring for a deeper review of edit window: the project would be that all buttons, js links, and toolbar should stay into a fixed position into the window, and that only the image/edit box should scroll. This could be done IMHO with some css and js, but is far from my skill. --Alex brollo (talk) 08:03, 7 February 2011 (UTC)

Thanks for the info. It’s a very good idea and know that you will eventually fix it, as I know you love challenges. :-) — Ineuw talk 18:52, 7 February 2011 (UTC)

Yes you're right, but… one at a time. Now my current challenge has been called "wikicaptcha" by John V. :-) --Alex brollo (talk) 21:00, 7 February 2011 (UTC)

I can certainly wait as long as it takes. I’ve also been busy, and I haven’t even tried your solution to dot leaders yet (but didn’t forget about it). So, as you say, "one issue at a time". — Ineuw talk 23:55, 7 February 2011 (UTC)

While searching for authors to link, I found that there was a Template:Populate into Author:Pliny the Younger, while a work by him had been added into en.source. I presume that a bot could remove such templates from author pages, simply browsing author pages pointed by the template. Can I have a try just to test my bot? I'll not edit pages by bot, I'll only try to build a list of author's pages to fix; merely a test and a scripting exercise. --Alex brollo (talk) 09:53, 4 February 2011 (UTC)

If it only has one work, is it worth the effort? Has the reason for the template being there been resolved? It is very much a template that someone can remove when passing and adding works, so apart from being a visually ugly template, it does no physical harm, and probably encourages people to add works. — billinghurst sDrewth 09:11, 5 February 2011 (UTC)

You are right. I took a look to a sample of such "unpopulated" authors, and I found that in most cases the template is appropriate; I found too that IMHO en.source incourages to create "naked" author's pages, often listing "wanted works" as red links. There's some talk into it.source about this issue, so it's a very interesting comparison of differents points of view. Comes en.source politics simply from use, or are they specific guidelines about?

Unaspectedly, the book I'm proofreading : Index:Horse shoes and horse shoeing.djvu, far from being a merely a farriery book, is a collection of historical documents full of quotes of ancient classics (many of them "minor" authors), archaeologists, and commentators. Do you encourage me to create author pages for any one of ancient author quoted, when lacking? --Alex brollo (talk) 08:44, 7 February 2011 (UTC)

Judgment call, if they are writers in English, or have been translated to English, then it is worthwhile, it is all library building. In general, a whole lot of red links on a page can be a little off-putting, so we at least try to do something. Also, may of the authors have biographical accounts, especially in some of the works that we are transcribing, so it can all be part of the WS journey. On author pages, I personally am less inclined to red link works, and just list them, however, we have no hard and fast guidance. — billinghurst sDrewth 11:21, 7 February 2011 (UTC)

Thanks. So I'll follow these rules:

1. I'll open a author page of any author that I presume could be considered "relevant" (ancient Greek and Latin authors, IMHO, are all relevant), adding minimal bio data and the link to pedia if any;
2. I'll add "red links" to their works only when I'll find Internet Archive books in English, so encouraging their upload and their proofreading. I'll add too IA link/links when I'll find existing "red links" (i.e. I found into IA good English translations of Xenophon works). --Alex brollo (talk) 12:46, 7 February 2011 (UTC)

One article from a 1953 issue of the People's Daily is highly controversial. It is the subject of on-going dispute at:

• en:Senkaku Islands dispute
• ja:尖閣諸島問題
• zh:釣魚台列嶼主權問題

There are reliable sources in support of the translation of the first sentence of "Struggle of the people of the Ryukyu Islands against U.S. occupation" (琉球群岛人民反对美国占领的斗争), People's Daily (人民日報), January 8, 1953

No translations based on reliable sources in English have been found to confirm the remainder of the sentences in this article text. Compare table at Talk:Struggle of the people of the Ryukyu Islands against U.S. occupation.

What is an appropriate next step?

If it makes sense to ask for help in translating the other sentences, is this the venue for such questions? --Tenmei (talk) 22:48, 7 February 2011 (UTC)

I don't understand the problem. Translation is not about "reliable sources"; it's about translating what the source says, right or wrong. Is it that we don't have a competent translator for this text?

I'm concerned in general about this text. It's a 1953 text; what makes it public domain? Why do we think the Japanese Communist Party translation is public domain?--Prosfilaes (talk) 23:41, 7 February 2011 (UTC)

Prosfilaes -- Yes, we do not have a full translation of the text. I hope this thread can be a step in a process of developing a credible English version of the article.

In response to your general concern: The column of digitized Chinese text was copied from the Chinese Wikisource; and the image of the article was copied from Commons. The Japanese Communist Party translation is only only the first sentence. A link to the People's Daily archived text is at the bottom of the page. --Tenmei (talk) 01:18, 8 February 2011 (UTC)

The question was, why are you talking about reliable sources? If you don't have a full translation, why don't you translate it? The sentence form the Japanese Communist Party needs to be retranslated. This page needs a copyright license here, and I'm pretty sure this is not public domain in the US; if it expired in 2003 in China, it would still be under copyright in the US. Since the copyright in China is life+50, I don't know that it's PD even in China, so I'm nominating the picture for deletion at Commons and the page here.--Prosfilaes (talk) 03:41, 8 February 2011 (UTC)

I asked for help. I got none.

Prosfilaes identifies other issues, but my initial request for help is marginalized.

What I have learned from this experience is not to ask for help. I understand no more than before I began; and instead, Prosfilaes heads off on a path which leaves me puzzled, a mere bystander. --Tenmei (talk) 03:55, 8 February 2011 (UTC)

What I would hope you took from this experience is to make sure that something is public domain before working on it, and so tagged, and not to copy other translations.--Prosfilaes (talk) 05:23, 8 February 2011 (UTC)

Prosfilaes -- You are urgently addressing the wrong question -- an important point, no doubt; but the result is not collaborative editing. Your focus on abstract considerations is unquestionably valid, but what is not valid is the consequential refusal to engage any issues but the ones which you see as clearly as your own image in a mirror. You are not wrong in the your own terms, and I have not disputed any point you make except you ignore the question with which this thread began.

In other words, you convert this thread into a binomial issue. This is unhelpful and non-collaborative.

One sentence is not a public domain issue. One paragraph -- the first paragraph -- from this controversial article can remain unchallenged. As far as I know, the controvercial part is the first sentence only; but a Chinese argument may require select sentences from other parts of the article.

For now, the underlined text should be restored without delay. Other outstanding issues can be resolved in due course. -- Tenmei (talk) 22:08, 9 February 2011 (UTC)

Hello, I've installed wikt:fr:MediaWiki:Gadget-searchbox.js from wikt:pl:MediaWiki:Gadget-searchbox.js. It adds the text treatment functions: "go to line n°", "change the capitalization", "search and replace" (eventually "replace all") and sort alphabetically. JackPotte (talk) 20:42, 9 February 2011 (UTC)

Looked at the list of Recent changes and noticed a column of bracketed numbers in green, like (+10) . . . etc. What do the numbers mean? :-) — Ineuw talk 04:20, 10 February 2011 (UTC)

The number of bytes (characters) added or removed as a result of the change. Beeswaxcandle (talk) 04:26, 10 February 2011 (UTC)

Thanks for the info. Very impressed. — Ineuw talk 05:04, 10 February 2011 (UTC)

Index:Horse shoes and horse shoeing.djvu is really a collection of challenges. One from them is the issue of long references splitted into more than one page. I solved it applying "the it.source style", here an example: Page:Horse_shoes_and_horse_shoeing.djvu/134 and Page:Horse_shoes_and_horse_shoeing.djvu/135; it uses {{ShowTransclude}}, alias {{St}}, imported from it.source; it's one from the most frequently used it.source templates when there's an issue of differeces in desired display between nsPage and ns0. Another interesting challenge is a particular image in Page:Horse_shoes_and_horse_shoeing.djvu/130 (thanks to User:George Orwell III for his help!) --Alex brollo (talk) 10:04, 10 February 2011 (UTC)

PS: I'd like a lot to have links to other pages where the same issues have been solved with different approaches. I don't know as I can find them! --Alex brollo (talk) 16:05, 10 February 2011 (UTC)

I do something similar but without using a template and instead of a switch statement using #ifeq: see Page:Nature and Character of our Federal Government.djvu/32 and 33. Your way looks easier though. —Spangineer (háblame) 16:51, 10 February 2011 (UTC)

I can't give you links but I've been solving this with the approach outlined in User:Hesperian/Notes/Overflow. Hesperian 23:44, 10 February 2011 (UTC)

Tarmstro99 frequently uses the same method as Hesperian links above on the Statutes at Large project. See United States Statutes at Large/Volume 1/Organic Laws of the United States/Constitution of the United States for one basic application of the tagged section approach. — George Orwell III (talk) 23:58, 10 February 2011 (UTC)

ThomasV has written an extension to handle this, which will allow you to use something like "<ref name="p42 overflowing ref">" on the first page, and "<ref overflow="p42 overflowing ref"</ref>" on later pages. In page namespace the overflow name won't map, and the ref will appear unnumbered on its own. Once transcluded into the mainspace, the overflow name will map onto the previous named reference, and will be appended. Really clever solution. I'm not sure where he's at with it; probably still trying to push it through the approval process. Hesperian 23:44, 10 February 2011 (UTC)

It is my understanding that it is through code review and is part of the imminent roll-out with other fixes that were attempted earlier this week. — billinghurst sDrewth 02:56, 11 February 2011 (UTC)

it is deployed; the syntax is "follow=" , not "overflow=" ThomasV (talk) 07:55, 22 February 2011 (UTC)

Cool, hopefully the API will finally start return DjVu page counts then too! Hesperian 03:21, 11 February 2011 (UTC)

I don't remember the buzgilla, and the search is very unhelpful. I will try to remember to dig when I can find the bugzilla ref

https://bugzilla.wikimedia.org/show_bug.cgi?id=26125 Hesperian 04:06, 11 February 2011 (UTC)

Confirming that it was started in Cite.php mw:Special:Code/MediaWiki/71157, and that has progressed to [Cite_body.php] though I cannot tell which bits have been banked and are part of the release code. <shrug> — billinghurst sDrewth 03:22, 11 February 2011 (UTC)

Confirming that it has been rolled out and works https://secure.wikimedia.org/wikipedia/commons/w/api.php?action=query&titles=File:The%20Harvard%20Classics%20Vol.%2051;%20Lectures.djvu&prop=imageinfo&iiprop=timestamp%7Cuser%7Curl%7Csize though I note that the information text in api.php didn't get the text tweak, so I have added that request to the bugzilla. — billinghurst sDrewth 10:00, 19 February 2011 (UTC)

I was just wondering if it is conceivable that Wikisource include a embeddable font directory (WOFF for instance).

I would find this useful to render properly Foucauld's Tuareg dictionary on all modern browsers with ligatures and all. Currently only Windows 7 users have a font pre-installed (Ebrima) which can represent the basic tifinagh, it is not able to represent the ligatures frequently used.

See http://fr.wikisource.org/wiki/Page:Foucauld,_Dictionnaire_touareg,_part_1.djvu/946

I have a font that would do the job. —unsigned comment by 98.143.217.66 (talk) .

In short, no we do not, we try to keep things as simple as possible and something that will present for as wide a variety of browsers as possible. We discourage overly formatting fonts and allowing the users to determine what they see with the fonts they wish to use; hence so far and as outlandish as we go is to use unicode. — billinghurst sDrewth 00:45, 11 February 2011 (UTC)

Okay, I think what you say is very legitimate for Latin texts or those encoded in common scripts, but I think it may be a different ball game for rare scripts with very few fonts available. As far "as wide a variety of browsers as possible" is concerned, that's precisely the idea to have the font embedded: it will display better on those that support WOFF and no worse otherwise, you just increased the variety of browsers that can display the text correctly rather than little rectangles.

I can't say that using Unicode is a very outlandish move when you target a planetary audience... It is a basic necessity even for English scientific or scholarly texts...

There's precedent at least for use of normal font rules to select fonts which are technically capable of rendering the text where we can't otherwise assume that user environments would be, accompanied with a note at the top of the text instructing users to install the font, see for example {{lang-he}} in Gesenius' Hebrew Grammar. If technically possible, embedded fonts would expedite this solution. Per billinghurst though, for those users who don't have the most modern web browsers, the technique previously mentioned should be used as a fallback. As a caveat I would assume that the font in question would have to have a sufficiently liberal license. Regarding the technical issue of hosting fonts (if this isn't already hosted by something like Google Font Directory), you might want to ask on Commons:Village_pump; it doesn't appear to have been previously considered. Prosody (talk) 00:46, 12 February 2011 (UTC)

It would have to be a free font, and I'm not sure that there's enough texts on the English Wikisource that would need this for it to be worth our trouble. It's a big complex change.--Prosfilaes (talk) 08:18, 12 February 2011 (UTC)

Hello,

Wikilivres is a Mediawiki site similar to Wikisource, hosted in Canada, which allows it to host texts which cannot be hosted to Wikisource due to copyright issues. It hosts texts in at least 10 languages, with 7 "main languages" (Chinese, Czech, English, French, German, Russian, Spanish). I have been managing it all alone since April 2006, technically and financially.

I cannot manage it alone anymore, for technical and financial reasons. The site is attacked by spammers for the last 3 weeks. It needs a software upgrade. I don't have the time and the finances to manage it any more. So I need help. Thanks, Yann (talk) 21:18, 12 February 2011 (UTC)

After speaking with Yann, I'll be helping maintain Wikilivres. —Pathoschild 22:20:38, 13 February 2011 (UTC)

Thanks a lot for your help, Pathoschild. Yann (talk) 06:41, 26 February 2011 (UTC)

Pathoschild, thank you very much! --Zyephyrus (talk) 18:18, 26 February 2011 (UTC)

Can someone produce text for this? It needs text so I can start proofing it. Thanks. - Tannertsf (talk) 04:45, 13 February 2011 (UTC)

If the original PDF has a text layer, then you should grab the file, do a FILE > SAVE AS TEXT, and you will have the text save to a file and apply as you so wish. Alternatively, upload the file to http://www.archive.org/ with all its details, and in a day or so it will have derived the alternate file types and there will be a djvu available to upload to Commons, and when we build the Index page for that the text layer will be available. — billinghurst sDrewth 09:52, 13 February 2011 (UTC)

After some after thought … digging deeper. Why are we working on a modern (unverified? and without provenance?) copy of a 90 year old work that has already been reproduced by paxlibrotum.com? Wouldn't we be better to either leave it, or grab a copy of the works themselves Godley's or broader search. — billinghurst sDrewth 10:05, 13 February 2011 (UTC)

My thinking was that we should have this book (don't care which version) on here somehow. - Tannertsf (talk) 11:23, 13 February 2011 (UTC)

Just to let you know that I'm slowly develop something that could be developed into a running wikicaptcha - i.e. a reCAPTCHA originating from our source djvu files, and fixing OCR issues into them. I have no hope to get that interesting goal but I'm exploring basic routines. The state of art by now is this: there's a test djvu into toolserver (File:Horse shoes and horse shoeing.djvu; there are runnng routines to extract text layer, to parse it, to select words containing a ^ character (characters that FineReader can't interpret), to extract the image of such words as a tiff segment and to convert them into jpg images, and to publish them into a html form. Presently the input of the user into the form is not treated (I just wrote my Hello world CGI script, and I am unexperienced about html forms….), but I have the needed scripts to fix the text layer into djvu file, so that I feel that I'm not far from a running, complete result. It's not a real CAPTCHA, it's only a test to see if it's possible to build it. Here the inactive html form resulting from my layman tests: http://toolserver.org/~alebot/cgi-bin/hello.py (the name of the page simply comes from its nature of a "hello world" test). --Alex brollo (talk) 10:21, 14 February 2011 (UTC)

If you like, you can find the name of the djvu file and the no. of the page containing any word from word image name; so the name of the first image is http://toolserver.org/~alebot/img/wrc/Horse_shoes-51-278_691_684_754.jpg, i.e. pag. 51 of file Horse shoes, here Page:Horse shoes and horse shoeing.djvu/51; the last four numbers in the name are absolute coordinates of the word into the page image. --Alex brollo (talk) 13:46, 14 February 2011 (UTC)

Reading the reports from WIKITECH-L it looks as though they have successfully ironed the bugs out of the upgrade and it will be all systems go on Wednesday. — billinghurst sDrewth 12:08, 14 February 2011 (UTC)

Labelled section transclusion appears to be broken, I am assuming as a result of the upgrade. This is a show-stopper bug, of course, as it affects a huge proportion of works using the ProofreadPage system. - Htonl (talk) 11:38, 16 February 2011 (UTC)

Correction: #lst isn't broken in general, but it doesn't seem to be working when used by the "fromsection" and "tosection" parameters to ProofreadPage's <pages> tag. - Htonl (talk) 11:45, 16 February 2011 (UTC)

For a concrete example, see 1911 Encyclopædia Britannica/Cape Town, where the end of the previous article and the beginning of the next article are transcluded in despite the use of "fromsection" and "tosection". - Htonl (talk) 12:27, 16 February 2011 (UTC)

Version does show the upgrade to 1.17wmf1.... a stroll through any of the DNB pages does show a complete unraveling of sectionalized tranclusions alright. :-(

Hopefully, its still in progress — George Orwell III (talk) 12:27, 16 February 2011 (UTC)

There has been an issue with the ENHANCED toolbar Preferences > Editing, where it has been switched back on. Toggle it off and save, and you should be back to the basic form which is necessary for the PAGE namespace. Still looking at other issues, though running broader tests as a WMF drone at this point. — billinghurst sDrewth 13:36, 16 February 2011 (UTC)

Just to confirm, the toolbar issue is unrelated to the <pages> issue, right? - Htonl (talk) 13:41, 16 February 2011 (UTC)

Correct, separate issues. I am talking to Catrope now, just need to set up a few tests, and he will look into the #LST issue. — billinghurst sDrewth 13:53, 16 February 2011 (UTC)

Great, thank you. To be clear, I don't know if there's any issues with #lst itself; "raw" #lst works ok, as does the "section" parameter to {{Page}}. It's only in <pages> that there seems to be a problem. - Htonl (talk) 14:18, 16 February 2011 (UTC)

Just seems to be ProofreadPage related, as I have this test User:Billinghurst/2 that would seem to demonstrate that. Catrope thinks he has identified where the issue may be, and I have sent a couple of emails to ThomasV to see if we can attract his attention. I have added detail to Buzilla. — billinghurst sDrewth 14:51, 16 February 2011 (UTC)

I've filed a bug. - Htonl (talk) 13:07, 16 February 2011 (UTC)

Since the upgrade I have not been able to type numbers, this is also happening at Wikia. My browser is Firefox. --kathleen wright5 (talk) 12:45, 16 February 2011 (UTC) Disregard the above, I've found the trouble is at my end --kathleen wright5 (talk) 12:53, 16 February 2011 (UTC). Solved, something happened to the Num Lock key. --kathleen wright5 (talk) 13:02, 16 February 2011 (UTC)

Pagelist tag into index: pages doesn't run. See Index:The works of Xenophon Vol III Part II.djvu: no pagelist specification has been applied. --Alex brollo (talk) 14:53, 16 February 2011 (UTC)

A possibly related observation, when using <pagelist> can be found on index pages where the page numbering has reverted to the original djvu. JamAKiska (talk) 14:55, 16 February 2011 (UTC)

Would be worth collating the issues into an easy list so we can refer people to it, and not have to manage the discussion. — billinghurst sDrewth 15:05, 16 February 2011 (UTC)

Pagelist tag seeems dead. Is this perhaps coming from a new try to implement 1.17 wiki version? --Alex brollo (talk) 14:18, 16 February 2011 (UTC)

Do you mean <pages>? If so, see above. —Spangineer (háblame) 14:28, 16 February 2011 (UTC)

Ah, I see; good catch. —Spangineer (háblame) 15:10, 16 February 2011 (UTC)

I have added a WATCHLIST announcement so that issues are brought to Scriptorium.

— billinghurst sDrewth 15:12, 16 February 2011 (UTC)

• Javascript patrolling is again broken. I will try to remember what I was told to do last time to fix it and get to it in the next day or so. The links at the bottom work to patrol. — billinghurst sDrewth 15:38, 16 February 2011 (UTC)

The scans are not loading for me, but it works when I'm logged out. cygnis insignis 16:27, 16 February 2011 (UTC)

It is probably a preference thing, possibly the "Use lightweight scans" gizmo under Gadgets. Cygnis insignis (talk) 16:47, 16 February 2011 (UTC)

indeed, this gadget is deprecated. I deleted it. Scans in edit mode now have a default width of 1000 pixels. It is possible to increase this default width in your preferences, or only for some books. ThomasV (talk) 12:31, 17 February 2011 (UTC)

Same indications for me, works better logged out… ANOTHER observation, while the section links do not appear to work in original DNB volumes, the errata (DNB errata template) are correctly displaying only the applicable lines from the errata page. JamAKiska (talk) 21:58, 16 February 2011 (UTC)

The traditional #LST & {{Page}} methods are not affected. 1911 Encyclopædia Britannica and the DNB errata portions, among others, rely on these methods is all. — George Orwell III (talk) 00:08, 17 February 2011 (UTC)

On a positive note, the server updated the images in DNB volume 58, and I got my browser to work again. JamAKiska (talk) 02:02, 17 February 2011 (UTC)

I see Thomas has turned on the scroll wheel to be zoom function in Mediawiki:common.js. I am wondering whether that may be better to be gadgetised for easy toggle on and off, rather than something that we force users to manually edit. — billinghurst sDrewth 06:16, 17 February 2011 (UTC)

Regardless which way this feature is active - thanks for re-implementing it. It’s far more useful to zoom in or out than the toolbar -/+ buttons.— Ineuw talk 06:18, 18 February 2011 (UTC)

I hope you were not using the buttons ; the selection of an area with the mouse is the most efficient method. ThomasV (talk) 12:55, 23 February 2011 (UTC)

THIS WILL FIX IT (in Google Chrome): Click on "My preferences" text link (top right of any Wikisource page) Select the "Editing" tab Look at the "Show edit toolbar (requires JavaScript)" checkbox. It's turned on. You need to turn it off (!). After the MediaWiki upgrade, it seems to be doing the opposite of what it's supposed to do. And then, presumably, when things are fixed, you need to remember to turn it back on again. -- P.T. Aufrette (talk) 22:57, 16 February 2011 (UTC)

I use Firefox, and the beta toolbar was just added for me (without the toggling header/footer etc.), even though I previously opted out. Would this have anything to do with the MediaWiki updtae? Regardless, this should stop, and the default for the page namespace had better remain the old toolbar. —innotata 16:39, 21 February 2011 (UTC)

Hi, when looking at an article the display options on the left don't work. For example when viewing Horse shoes and horse shoeing: their origin, history, uses, and abuses/Chapter I and Ornithological Biography/Volume 1/Bonaparte's Fly-catcher I cannot chance the layer from Layer 3. Also the the page links are not shown. Both "Show page links" and "Layer 3" are dead links and not clickable.

Further, there is no toggle button for the header and the "pagelist" does not show up. I am using Firefox 3.6.13.

How do I get "display options" to work?

Is there any help? Thanks! Mattisse (talk) 16:08, 17 February 2011 (UTC)

I downloaded Chrome and can now see the "page links". I will not click any "display options" so they will not become nonfunctional again. (That was my mistake in Firefox: I clicked on "show page links" which caused it to stop working, permanently stuck on no showing page links.) The "Layer" link is still not clickable and now is stuck on "Layer 1". What am I doing wrong? Mattisse (talk) 17:43, 17 February 2011 (UTC)

I would guess this is another problem related to yesterday's Mediawiki upgrade (see above). I don't think you're doing anything wrong, and there's not much you can do other than wait for the developers to fix it. - Htonl (talk) 17:45, 17 February 2011 (UTC)

Ok. Thanks for answering. So there is hope! Mattisse (talk) 18:03, 17 February 2011 (UTC)

This should be working now, thanks to ThomasV I believe. —Spangineer (háblame) 14:40, 18 February 2011 (UTC)

The clock displays the time but doesn’t purge. It’s not a major issue, I just thought of reporting it.— Ineuw talk 06:15, 18 February 2011 (UTC)

I assume you're talking about the "Clock and Purge" gadget available under preferences. I have it enabled as well, and it won't purge for me either. Good catch. —Spangineer (háblame) 14:10, 18 February 2011 (UTC)

Just fixed it; you'll probably need to bypass your cache to get it to start working for you. —Spangineer (háblame) 15:00, 18 February 2011 (UTC)

Thanks, it’s working fine.— Ineuw talk 21:43, 20 February 2011 (UTC)

I'm using IEv6 on a laptop and therefore I don't have a scroll wheel with which to zoom. The Page NS toolbar in IE has a pair of buttons for zooming in and zooming out. However, these have stopped working. I've played with the various settings in my Preferences, but to no avail. (There are software compatability reasons why I can't upgrade the version of IE I'm using.) Beeswaxcandle (talk) 23:34, 19 February 2011 (UTC)

I tried in IE 7 and it didn't seem to have any effect, but you might try disabling the new wheel zoom capability: add self.proofreadpage_disable_wheelzoom = true; to your skin's .js file and see if that makes a difference. —Spangineer (háblame) 23:57, 19 February 2011 (UTC)

Thanks Spangineer, but it didn't work. When I look at the source HTML and search for "zoom" it's not returning anything, which makes me suspicious. Beeswaxcandle (talk) 00:24, 20 February 2011 (UTC)

This may be an issue for me as well, but I better clarify to avoid a misunderstanding. In my case (Win XP SP3, FF 3.6.13) The zoom works fine when in Edit page mode, regardless if side by side or the over/under view is used. But, the image is frozen in Read mode. If I remember correctly, prior to the update, one could zoom the image in Read mode as well. Is this the new normal? Or, would the above .js code apply to Read mode? — Ineuw talk 22:14, 20 February 2011 (UTC)

When it is used, it also imports its version of the {{header}} or a header-lite version. Is there a means to turn it off / import it without the header component? The first page of a work is one where you often want to have extra detail, and we have been including this within the headers, eg. parameters: wikipedia, portal, year. while it is a little more work to add a header, it is often a vital contextual work, and the addition of the header without the context for me means that this additional feature is not useful. — billinghurst sDrewth 06:36, 24 February 2011 (UTC)

so what ? can’t you add a parameter to it ? ThomasV (talk) 06:53, 24 February 2011 (UTC)

MediaWiki:Proofreadpage header template gives some info about enabling (or disabling?) the header call to header-lite but I must be applying it incorrectly because it didn't change anything on that one given WS.en example I tried it on. — George Orwell III (talk) 07:27, 24 February 2011 (UTC)

I added it for you ; is that better now ? ThomasV (talk) 10:05, 24 February 2011 (UTC)

Thank you. I'm sure another notes field will lessen the burdens to come re: disgruntled contributors. Though I full well realize there is no way that future development is going to "allow for" the over-riding of this default top-level page with its header and all the tracking, catagorizing, interliking, etc. will just have to be done via something/somewhere else. I'd think your time would be better spent matching then porting over as much as you can from the current header over to the index page & its parameters rather than working around the same grievances over and over again here. — George Orwell III (talk) 10:51, 24 February 2011 (UTC)

I do not have much time to do this, and I do not know exactly what you want, so I think it would be better if someone active at en.ws did this. ThomasV (talk) 10:59, 24 February 2011 (UTC)

"I" really don't need much personally - it's all the folks who have been a bit intoxicated lately with the embedding of various specialized linking, tracking, organizing, etc. templates to the main header template. If there is no way for them to get that blue notes field back and be able to showcase this thing or that point on the top-level mainspace page of a work then countless hours of work will be for not. I recommended removing Notes from the Header completely just a couple of days for just this reason - leave the green header for basics and sub-page navigation and have that "call" notes only when needed to host whatever it is that is handled through manipulating Notes now. It hardly ever displays right in conjunction with the green portion when loaded up anyway and it will be one less thing to worry about when header becomes all divs instead of the current HTML type tables. (I was being sarcastic about that notes fix btw), but if you can solve the author parameter problem outlined far below it might maake the realities go down smoother over the next day or two. — George Orwell III (talk) 11:19, 24 February 2011 (UTC)

• Doug came up with an interesting idea in IRC the other day. What if we store metadata in some "other" location (could be index, talk, or a new NS), and the header template (explicit, or called py <pages>) slurps it out of there onto the page? Obviously, this solution may end up being more work than it is worth, but it is one idea to separate content from metacontent, which I personally think is a good thing.
  • Can't say I disagree. <sigh> "If I only had dollar for everytime...." — George Orwell III (talk) 07:27, 24 February 2011 (UTC)
    • ....that my to-do-one-day/wish-list got longer instead of shorter...I'd have at least minimum wage. And the items just keep on getting bigger and more complex. Inductiveload—talk/contribs 07:53, 24 February 2011 (UTC)
• Also, the automatic header uses the "author" parameter incorrectly, causing an error. This is caught and corrected by {{header}}, but it is a little untidy (and it clutters Category:Pages using the author field hack). The "proper" way to do it is to use the "author" parameter without a wikilink, or if you need a wikilink, then use "override_author". Ideally, we don't want to use the broken link detection, as it is a hack which relies on the template getting some specific error message from the parser (<strong class="error">Expression error: Unrecognised punctuation character "["</strong>), which seems fragile to me (unless this message is set in stone for all time).

I wouldn't mind so much if there was way to catch the error using a real parserfunction or something that we can truly rely on. If there was a way to do it properly, we could probably ditch the "override_" fields altogether.

This isn't a very important problem, I just thought you'd like to know. Inductiveload—talk/contribs 06:57, 24 February 2011 (UTC)

Cannot say that I agree with much of this. It is counter-intuitive to editors to go to (yet) another page to add links. That would mean that users have to know to go to the /Source\ tab to find the Index page to add English sister links, yet other language i/w are added directly, and links for Portal are where? Sure we may want the metadata for the work in the one place, however, there is more than just that. We also now have two different configurations for header; and one of most of those are in the Template namespace, and the other is tucked away in the Mediawiki: namespace. — billinghurst sDrewth 12:44, 24 February 2011 (UTC)

What part are you having trouble with? The way I read all this is basically If there are no scans to a work - you are on the short end of the contribution stick, No?

All this other "stuff", is subserviant to the works themselves (technically), so of course its logical to push in this direction rather than than hammer out an alternative. Was there an unfulfilled need for this feature to be incorporated... yet here it is - I'd take a moment and reflect on that.

I'm curious - hasn't anybody worked at the 'enterprise' level around here? Push updates have become the painful norm - now bend over. — George Orwell III (talk) 13:27, 24 February 2011 (UTC)

Observed an unusual table distortion in the transcluded presentation while using only a single pages index statement from=59 to=60 as seen in "Revision as of 17:22, 1 March 2011." The current presentation uses two separate page index statements, one for page 59 and the other for page 60. JamAKiska (talk) 17:45, 1 March 2011 (UTC)

Are the Pages in the same state as when the problem emerged, the revision of the Main page wont show that. Regarding a separate problem, use a single column to keep the alpha order. I'm sure some clever person can invent a way to make double columns across Pages work - please don't. CYGNIS INSIGNIS 18:09, 1 March 2011 (UTC)

I can still get that distortion with volume I only if I combine both pages into a single statement. Volume II displays correctly using one or two statements. I now have both volumes of writers on that page as it helped determine column alignment. Can go back to single column if that helps alph-wise…JamAKiska (talk) 20:57, 1 March 2011 (UTC)

Distortion…gone…thanks…JamAKiska (talk) 16:06, 3 March 2011 (UTC)

How can I best ascertain whether or not it is permissible to include a work I would like to see here at Wikisource? The work is "The Gateless Gate" and one very common English translation can be found here: Gateless Gate Index. That version seems to have a 1934 copyright; if that disqualifies it, how best could I go about finding something that does qualify? Thanks! WikiDao ☯ 22:28, 16 February 2011 (UTC)

1934 is complicated as works from that year had to be renewed in 1961-62 to remain under copyright. I have not found any renewals for this text, however, so it should be OK to add to Wikisource (this was implied by your link's "[1934, no renewal]" but I checked anyway). Before you go ahead, the prefered method is to work from a scanned copy of the book (See: Help:Beginner's guide to Index: files). I couldn't find one at archive.org but you probably know more about what you're looking for and may have better luck. If you can find a .djvu file of the book, it would help. - AdamBMorgan (talk) 00:22, 17 February 2011 (UTC)

I have a hardcopy of the Paul Reps translation found in Zen Flesh, Zen Bones, would it be okay for me to work from that, or should I be scanning and posting copies of that at commons...? (Sorry, clueless here about how exactly Wikisource works). That text is identical to the text here, btw. I have started formatting that and putting it up here -- is that okay so far? All comments/criticism welcome! :) WikiDao ☯ 23:28, 17 February 2011 (UTC)

To be honest, I'm not sure. I know there is some debate over whether scanless text should be added but they're not actually banned. Scans allow other users to proofread the text or check errors, as well as improving the perceived reliability of Wikisource (a Wikipedia analogy would be the references in an article). The text being online elsewhere helps but we can't be sure that they got it right. (So, you might want to wait for someone else to reply to this question.)

That said, there are similar texts here and I've added the {{textinfo}} template to the talk page to provide some referencing. The scan could probably be added later by match and split (don't ask, it's not important at this stage). If you can scan a copy yourself then that would, of course, be good; although the version in your book might be under copyright if it was edited (if it matches the online version, this is less likely). There are help files for that too if you want to try it. - AdamBMorgan (talk) 00:42, 18 February 2011 (UTC)

Thanks. I'll put a few more up and then wait to see what happens. WikiDao ☯ 00:54, 18 February 2011 (UTC)

Zen Flesh, Zen Bones, constantly in print since the late 50s, is PD? CYGNIS INSIGNIS 18:13, 1 March 2011 (UTC)

According to [3], it's not, but the Gateless Gate part was previously published and is.--Prosfilaes (talk) 20:31, 1 March 2011 (UTC)

I could not find any copyright renewal when this was first raised as well. Original copyright registration is linked on its talk page fwiw. — George Orwell III (talk) 00:34, 2 March 2011 (UTC)

I had a look at Zen Flesh, Zen Bones as it would have been an easy solution. As far as I can tell, it was public domain in the late 1980s but it had its copyright status restored later (a "GATT/URAA restoration"). - AdamBMorgan (talk) 05:47, 2 March 2011 (UTC)

Links from Regex framework were displayed with a large font, I fixed this issue with a couple of rows into my vector.css (the issue comes from lacking class p-body, I presume):

div.p-body ul{list-style:none;list-style-image:none;list-style-type:none;padding:0;margin:0;}
div.p-body ul li{line-height:1.125em;padding:0;padding-bottom:0.5em;margin-left:1.25em;overflow:hidden;font-size:0.75em}
div.portlet h5 {line-height:1.125em;padding:0;padding-bottom:0.5em;margin-left:1.25em;overflow:hidden;font-size:0.75em}

It's a rough solution, but I feel that uploading a local copy of original script and fix its code would be a worse solution. Any better idea? --Alex brollo (talk) 08:34, 18 February 2011 (UTC)

Is this ok under the rules: The Great Gatsby? It is listed on Author:Francis Scott Fitzgerald as a work. But it is not possible to edit it or even to check the source. It is under copyright in the US. I didn't know that Wikisource hosted other sites. So it does? Thanks! Mattisse (talk) 23:49, 18 February 2011 (UTC)

The purpose of the WIKILIVRES site is to host texts and images in the public domain, or under a free licence pretty much like Wikisource does, but that site is hosted in Canada and therefore it follows the Canadian copyright law. Big difference. — George Orwell III (talk) 23:58, 18 February 2011 (UTC)

To add to that, from author pages, we are comfortable with them being used to list to full copies of work on or off site. Of course, we prefer works locally, though sometimes that just cannot happen. — billinghurst sDrewth 12:20, 19 February 2011 (UTC)

But as Mattisse rightly points out, we shouldn't link to copyvios. As George Orwell points out, we haven't.--Doug.^{(talk • contribs)} 13:08, 19 February 2011 (UTC)

But it is not copyvio, so there would be nothing wrong with linking to it. — billinghurst sDrewth 15:02, 19 February 2011 (UTC)

I've discovered that out collection of sidenotes is broken in the default layout, if the sidenote occurs within a table. It doesn't float out to the margin, and if you position absolutely, the surrounding text won't wrap (that's what absolute does). The default sidenote format is pretty ugly anyway, as a bunch of variously sized outlined boxes elbow their way down the margins of the text.

See here for examples of left and right sidenotes in and out of tables.

We also use tables to create columns via {{multicol}}. Using tables is a common hack to force correct layout, but is not correct practice. I do accept that if tables are the best way, then so be it, but it would be nice if we can do it the "right" way and make it look good.

My problems are thus two-fold: sidenotes and columns. Here are some thoughts I've had, any of which may be impractical or impossible:

• Make sidenotes render nicely on pages in the default layout.
  • I had thought that it would be nice if the default layout is to have no margins, but if a sidenote appears, a margin is created for it, preventing the ragged appearance of both margins without intruding on works which don't have sidenotes. I have no clue if this is even possible.
  • If a margin exists, the sidenote can be positioned absolutely with position:absolute in the CSS (as in Layouts 2 and 3), and this solves the problem of the sidenote being stuck in the table cell. If the margin doesn't exist, the text is overlaid on the main text stream.
  • Perhaps this can be solved by editing the dynamic layout CSS in MediaWiki:Common.js? I've had a play with layouts in my JS, to no avail.
  • Another way may be to somehow enforce a specific layout for certain pages (or at least change the default away from "Layout 1").

• Using tables for layout is not ideal, but it works, after a fashion. Can anyone think of a better way to do it, perhaps using floating divs? And if the sidenotes are not fixed, can they think of a way to make columns that don't break sidenotes in the default layout?
  • For a related example, it seems to me that {{block center}} could use a div rather than a table hack. See its talk page for the code.
    • That doesn't work on many version of IE. Gotta love browsers' standards compliance. Inductiveload—talk/contribs 04:31, 23 February 2011 (UTC)
      • It really is some sadistic joke isn't it? One thing "works" in IE8, but "breaks" something in IE7 and, out of nowhere, "opens" a work-around for IE6. Resolve that → break something else. You can't win; only minimize the damage. — George Orwell III (talk) 15:24, 23 February 2011 (UTC)

I've tried a slightly different use of div, which seems to work (I'm using IE6 on my office computer). Does it work for everyone else? Is it better or worse? Revert it if there's any problem. - AdamBMorgan (talk) 13:26, 23 February 2011 (UTC)

Anyone with thoughts or ideas is more than welcome to weigh in, I'm out of ideas at the moment. Inductiveload—talk/contribs 15:42, 22 February 2011 (UTC)

The US Statutes project uses {{USStatCols start}} and {{USStatCols end}} to create nested divs that generate a side column. Unfortunately these look terrible in layout 2, but perhaps there's a way to use the idea? —Spangineer (háblame) 13:23, 23 February 2011 (UTC)

Don't go that route - its just div-wrapper upon div-wrapper plus (or minus) some classes along the way; not very elegant at all. Legislative works needs a layout of its own imo - one that "does away" with the side Not holding any sidenotes after transclusion to the mainspace (duh!).

....though I'd appreciate if you took a look at the various sidenote templates themselves and adjusted the font-sizing to better reflect that last "20%" proposal of yours. I don't know about the rest of you folks but using smaller rather than xx% for example actually displays larger than the main content's text does under some settings. — George Orwell III (talk) 15:24, 23 February 2011 (UTC)

It looks like {{USStatSidenote}} indirectly passes a {{{size}}} parameter, which the root templates, {{Right sidenote}} and {{Left sidenote}}, don't use. So the update I made to those latter two templates in January, to change from "smaller" to "83%", should be in place as far as I can tell. —Spangineer (háblame) 15:58, 23 February 2011 (UTC)

Well sorta - it goes through the Outside & family of templates to get to the main sidenote templates and that added those parameter(s) into the mix. Still, I think your changes saved some pixels at least - looks just as good if not better than before here.

Something still doesn't seem right - the "padding" (both the padding parameter and the gap template's padded value) aren't making it all the way to rendering. I found why the default wasn't working but the over-ride value is still coming back

<span style="display:inline-block; width:2;"> </span>

instead of what I assume should be

<span style="display:inline-block; width:2em;"> </span>

when USStatSideNote is applied. The default (1em) seems to work for IE8 irregardless of any inputed over-ride value or not; not so for 7 or 6. :-( — George Orwell III (talk) 17:02, 23 February 2011 (UTC)

Found & "fixed" in the main {{Outside}} & {{Outside2}} templates - left unresolved is the use of the same named-parameter (((padding))) for 2 differing inputs/parameter values. I can't figure out why there is need for a trailing {{gap}} spacer at the end of the sidenote text come to think of it - any clues? — George Orwell III (talk) 17:54, 23 February 2011 (UTC)

Regarding the issue of law texts needing a special layout ("one that 'does away' with the side Not holding any sidenotes after transclusion to the mainspace"). Why not set all templates to show sidenotes on one side in the main namespace? Book publishers always put sidenotes on the side of the page away from the book's binding, but we don't have that restriction in the main namespace. Make sidenotes always appear on one side, and this problem is solved, correct? —Spangineer (háblame) 14:58, 24 February 2011 (UTC)

Thanks - this 'solution' was so obvious that it was almost painful to keep watching the alignment/floating debates. Now the question, correctly, becomes are you a leftie or a rightie? — George Orwell III (talk) 23:02, 24 February 2011 (UTC)

To me I feel that is easy to answer. We want right margin free to expand and contract not force a width many discussions around about that, so we dress to the left on the web. -- billinghurst sDrewth, 25 February 2011 (UTC)

It is an easy answer when you treat everything, and I do mean everything, as simple paragraphs, with minimal changes in paragraph-start and/or indentation, if at all, rather than the actual mix of paragraphs, defined-lists, list-items, etc. that is being conveyed in the original work. Left handed sidenotes are most certainly my answer too if the work in question is pretty much a "straight" essay or report; not so much when the work in question is, at its core, codifiable in nature (as depicted below).

I uploaded updated images to the Commons Categories of Popular Science Monthly Volume 20 and 22. last week, when the new software update was taking place and they are out of order and the images ended up at the end of the page. Is this a cache issue? P.S: I requested help from a Commons admin but received none.— Ineuw talk 14:31, 24 February 2011 (UTC)

Not sure I understand. Are you saying that the images are not in numerical order when you look at the category? They do for me: first image I see is File:PSM V22 D010 Charles Adolphe Wurtz.jpg, next is File:PSM V22 D041 The fir tree of alliaz.jpg, etc. —Spangineer (háblame) 14:51, 24 February 2011 (UTC)

Sorry, I should have been more informative. The corrected images ended up at the end. If you look, D170 is after D773. The same is in Volume 20.— Ineuw talk 15:56, 24 February 2011 (UTC)

I think that might be covered in Commons' Village Pump (Village Pump: Ordering of images in category) and bugzilla:27553. The software changed the category sorting order; which is something I've noticed here as well in some places. - AdamBMorgan (talk) 18:29, 24 February 2011 (UTC)

Thanks for pointing out this post. At least I know that it’s a common error and will wait for the fix whenever that happens.— Ineuw talk 23:16, 24 February 2011 (UTC)

The news of version 1.17 (above) said the new template {{align}} can hint DoubleWiki. After playing around with this, I found several flaws. It derails when the page contains images and/or tables, and I can't get it to match headings or text in italics. For example, here the 2nd paragraph is aligned (After the memory...), but not the CHAPTER I heading and not the 1st paragraph which contains smallcaps. The rest of this chapter aligns quite well.

The second chapter is more interesting, as the English translation leaves out many paragraphs towards the end. But the paragraph immediately following the illustrations of the Eskimo underwear fails to align. What am I doing wrong?

According to oldwikisource:Wikisource:DoubleWiki Extension, it should be possible to support alignment by inserting empty divs in the text. I tried this at the top of Chapter II, but I don't see any effect from this. --LA2 (talk) 21:13, 24 February 2011 (UTC)

no, that info is deprecated ; I removed it ThomasV (talk) 21:19, 24 February 2011 (UTC)

That answer doesn't solve my problem, though. As far as I'm concered, DoubleWiki is a dead end, and the best I can do is to warn others from trying to use it. --LA2 (talk) 21:38, 24 February 2011 (UTC)

ThomasV created a sandbox (though still within the Mediawiki: namespace) that allows for the trialling and testing of new layouts for a wider audience. To see the test layout, you need to turn on the respective gadget (and it becomes your default layout). — billinghurst sDrewth 13:04, 25 February 2011 (UTC)

Nice. Can anyone tell me which bit of the code makes it the default? Inductiveload—talk/contribs 03:41, 26 February 2011 (UTC)

Best I can do is point to https://secure.wikimedia.org/wikisource/en/w/index.php?title=MediaWiki%3ACommon.js&action=historysubmit&diff=2406204&oldid=2392591

Anybody that can point me to the php-code for the Wikisource/Wikipedia text search box? Sigmundg (talk)

I'm not sure I understand the question—do you mean Special:Search? English Wikipedia and Wikisource use Lucene, via Extension:Lucene-search and Extension:MWSearch. All the extensions are listed at Special:Version. Cheers, stephen (talk) 02:52, 26 February 2011 (UTC)

Look at {{engine}} locally, and a number of pages at WP give instruction. If you are looking to use it locally, to note that it doesn't work on transcluded pages. — billinghurst sDrewth 10:35, 26 February 2011 (UTC)

Is there any limit for how many pages I can use in an Index-page? I have found a bible who would make ~1900 files for the Old Testament. (Ten books of the Apocrypha and the New Testament adds to that.) -- Lavallen (talk) 18:10, 25 February 2011 (UTC)

2857 is the longest I've seen, but I don't believe there to be any hard limit. Inductiveload—talk/contribs 03:16, 26 February 2011 (UTC)

That indexpage suprised me, that it took almost no time at all to upload to my browser (<1 s). I have an index-page that takes me 2-3 s to upload. -- Lavallen (talk) 06:26, 26 February 2011 (UTC)

• That could be because your's is sucking in all the page quality information. I'm not sure how to be organise an index made of JPGs like mine (eg, how do you do page numbers?), so don't take mine as an example of how to do it. I used a table, as I saw it done that way before, and at least the links are there. I was just saying it is the longest I know of.
• Anyone else know how to use <pagelist/> with a JPEG scan? Inductiveload—talk/contribs 06:38, 26 February 2011 (UTC)

The table makes it look more attractive on the Index-page. I havn't thought of that! - But setting up a table for >2000 pages looks like hard work! - Lavallen (talk) 07:39, 26 February 2011 (UTC)

Setting up a vanilla table like that is easy with a Python script: User:Inductiveload/Scripts/Index page tabulator. However, if you want to add numbers corresponding to the real page number, that's a lot more work. Inductiveload—talk/contribs 07:43, 26 February 2011 (UTC)

Aah, Interesting! I am already using C#-code to upload files to Commons. Maybe I can add something similair to that to modify the index-page at the same time... -- Lavallen (talk) 09:33, 26 February 2011 (UTC)

If you have excel so can do a reasonable list of page numbers, then you can use the Custom Regex gadget to build the code around a page break (\n). If you have two columns of data, just take that into excel and export. Truth be known you can do the whole code for tables in excel, and parse it out. — billinghurst sDrewth 10:40, 26 February 2011 (UTC)

I am working on Ante-Nicene Fathers. The content was pulled from an online library, and it has everything from opening quotes to dashes, all in html code numbers like &#160;. I am wondering if I should leave them in, or if I should just replace them with the standard character (convert opening (&ldquo;) and closing quotes (&rdquo; to plain quotes (&quot;). Arlen22 (talk) 22:45, 2 March 2011 (UTC)

It would be good if there were a bot that would at least convert them to their HTML name equivalent. Arlen22 (talk) 23:05, 2 March 2011 (UTC)

On second thought, I have decided not to, though if I see any right quotes that should be apostrophes I change them. Are there any HTML bots? Arlen22 (talk) 02:23, 3 March 2011 (UTC)

Requests to Wikisource:Bot requests — billinghurst sDrewth 03:17, 3 March 2011 (UTC)

With our expansion of Portals, does anyone know if it is possible to identify links at Wikipedia that would be inbound to [[Wikisource:name your space]]? — billinghurst sDrewth 03:21, 3 March 2011 (UTC)

Other than counting up the templates specifically hard-coded to utilize WS, I know of no such existing "project" that concerns itself with linking WikiSource - the argument, as I understand it, being a.) who the blazes cares what somebody said, wrote, reported, opined, etc. about X, Y or Z pre-1923 when most topics are not static enough for these to be relative today; and b.) who cares what a primary source can give us - we want information digested by a third party and regurgitated, correctly or incorrectly, by that third rather than simply read the original and draw our own conclusions.

For example, the WP Template:ExecutiveOrder only has about 200 or so valid uses (the template producing an internal link to their own executive order encyclopedic article under the "Executive Order" part and an en.WS sister link under the "#####" part) when there are literally 10 to 20 times that many EOs being referenced throughout various WP articles and currently 13,566 EOs issued to date. Many of these references in place not using the template frequently get the facts wrong or completely contradict the EO as issued.

Basically folks on WP don't neccessarily want what the Audubon Society painstakingly once published and meant to last for all time but what some bird-watcher-of-the-moment thought of their findings as laid out in the book. The relationship between the two sister-sites has been "one-way" for most part the best that I can tell - other than the DNB-like or similar specific Author: based sister-linking going on both ways that is. Sure we get some link action on WP but its mostly at the bottom, near the end or flat out mixed in with the External Links section. — George Orwell III (talk) 05:02, 3 March 2011 (UTC)

Hmmm... many moons ago I wrote a script that was complicated by the fact that these sister project links were getting stuck into the links table as if they were normal internal mainspace links. This bug/feature would have made it possible to do what you're asking, but I can't replicate it now, and I fear it has been patched. Hesperian 05:21, 3 March 2011 (UTC)

Yeah, can't be done, they're not tracked in the database.[4] Hesperian 05:31, 3 March 2011 (UTC)

The External Link Finder on enWP shows up 9468 links to en.wikisource.org.*, which are of different kinds, but do include examples of links from articles. Those, obviously, are URL linking, while there will be other links going via the interwiki code as [[:s:*; I don't immediately see how to search for those with Google.

The links from specific citation and attribution templates run into thousands; w:Template:Wikisource is used a few hundred times. The scope is there for much more linking - for example some thousands of links to the Catholic Encyclopedia could be directed here.

I don't agree that such links are not "wanted", because it entirely depends on what kind of topic you mean. Charles Matthews (talk) 09:58, 3 March 2011 (UTC)

I did not mean to arbitrarily come off as dismissing that notion, only that viewing such WP page's per page-views under the history-tab compared to the linked WS page's page-views here is woefully disproportionate more often than not when I have bothered to follow-up/follow-through on such things. The sampling, while not limited just to my favorite areas, was of course still too small to be the final say either way. — George Orwell III (talk) 11:49, 3 March 2011 (UTC)

What happened with this file? I just uploaded it, and now the words aren't appearing at all. Here it is: Index:Thehistoricthames.pdf. - Tannertsf (talk) 18:10, 3 March 2011 (UTC)

Was unable to read the uploaded pdf file, would it be okay if I uploaded the AI djvu file instead? JamAKiska (talk) 18:40, 3 March 2011 (UTC)

Can I delete the 1st attempt Index:Thehistoricthames? — George Orwell III (talk) 21:14, 3 March 2011 (UTC)

Yes to uploading the djvu file, and yes to deleting the 1st attempt. - Tannertsf (talk) 21:57, 3 March 2011 (UTC)

Pdf deletion request is in the system. Replacement file is Index:TheHistoricThames.djvu.-JamAKiska (talk) 03:01, 4 March 2011 (UTC)

Done here and there — billinghurst sDrewth 12:05, 4 March 2011 (UTC)

What do you all think of what I did to the navigation links in Ante-Nicene Fathers/Volume IV/Tertullian: Part Fourth? I think it greatly enhances it. Arlen22 (talk) 00:07, 4 March 2011 (UTC)

I will start with the following ref'd sentences from the Wikipedia's Second Continental Congress, but link it to Wikisource pages to indicate notability. [In 1776] Congress would formally adopt the resolution of independence, but only after creating three overlapping committees to draft the Declaration, a Model Treaty, and the Articles of Confederation. The Declaration announced the states' entry into the international system; the model treaty was designed to establish amity and commerce with other states; and the Articles of Confederation, which established “a firm league” among the thirteen free and independent states; together these constituted an international agreement to set up central institutions for the conduct of vital domestic and foreign affairs.

After considerable, hopefully fruitful yak shaving, I believe this notable document may be found and V'd at this this RS, with little additional work. I had planned to do it as my first Wikisource article, but ran into a basic lack-of-knowledge question about titling on Wikisource. Avalon's first line, 'Plan of the Treaties with France of 1778', is historical (revisionist) fact, but not what the authors knew or wrote. The primary(?) sources' name, 'Journals of Congress. Tuesday, September 17, 1776.', seems insufficiently uninformative; it also requires knowledge of the following to avoid OR: "The Model Treaty was a template for commercial treaties that the United States Continental Congress sought to make with France and Spain in order to secure assistance in the struggle against the British in the American Revolution. Congress approved the treaty on September 17, 1776.", from here, which has not yet been added to W:'s appropriate article, the Model Treaty.

I believe 'Model Treaty' is better than 'Plan of 1776', since those authors had other big plans that year, but I'd appreciate some knowledgeable comments for the document's title at Wikisource. Thanks and regards, CasualObserver'48 (talk) 08:10, 4 March 2011 (UTC)

We tend to prefer to use print sources, not web sources, for our texts, and for this reason I've used American Archives as the source of these types of documents (see Portal:American Revolution). I'll try to find the treaty you are talking about in that series of books, and see what it's called there, and then we can go from there. —Spangineer (háblame) 12:18, 4 March 2011 (UTC)

The text of the treaty starts in the second column of Page:American Archives, Series 5, Volume 2.djvu/740 and goes on several pages. There it is titled Plan of a Treaty with France, which seems like a good title to use. Best practice is to now transcribe that page and following ones, similar to other works from these books. —Spangineer (háblame) 13:30, 4 March 2011 (UTC)

Thanks for that work, the rapid reply, and a better understanding of what gets included here and how it is supposed to be done. That said, I will back off from my overly optimistic 'first article' inference, for both technical and personal considerations. Basically, going through the djvu process (with my limited bandwidth) has caused this yak to reappear considerably more hirsute than I originally anticipated, and I am unfamiliar with the use of this strop. Additionally, I am already committed to a Wikimedia project, which is starting another iteration, and am now overly booked into the future.

As you suggest, the noted Plan of a Treaty with France is the acceptable title, based on this source. I remain convinced that it is significantly notable and should be included in Wikisource, but that must await another more experienced in the cosmetology of text. Regards and thanks again, CasualObserver'48 (talk) 04:37, 5 March 2011 (UTC)

Hi all,

I'm currently in the planning phase of a project to digitize a very low-circulation 19th-century magazine published by a very small 19th-century American school (that went on to become a very small 21st-century college). This magazine appears to fit within the letter of the law at What Wikisource includes: it is a published, static text that is firmly in the public domain.

Assuming that I/we follow the procedure in Help:Beginner's guide to Index: files, closely adhere to the practices of existing projects like Popular Science Monthly, and hand-check all text before posting, would there be any likely objections to the inclusion of such material in Wikisource? Thanks in advance for your advice! -- Visviva (talk) 18:38, 4 March 2011 (UTC)

I don't think notability is an issue. Arlen22 (talk) 19:46, 4 March 2011 (UTC)

Such a text is welcome; notability is generally not a concern provided the criteria you mention are met. —Spangineer (háblame) 21:25, 4 March 2011 (UTC)

Or to express it this way, at WP they their measure is notability, for us publishing = WS test for notability. With unpublished (historical) documents then we have a notability measure, as great grandfather's will is necessarily notable, we apply other tests. — billinghurst sDrewth 23:40, 4 March 2011 (UTC)

Excellent! Thanks to all. -- Visviva (talk) 21:25, 5 March 2011 (UTC)

   In the above poem W.B.Rands says," Chairs to mend and Delf to sell"...What does the poet imply/

?