Wikisource:Scriptorium/Archives/2011-04
Please do not post any new comments on this page.
This is a discussion archive first created in , although the comments contained were likely posted before and after this date. See current discussion or the archives index. |
Announcements
PLANNED Mediawiki upgrade Tuesday, February 8, starting at 07:00 UTC
Full post at http://techblog.wikimedia.org/2011/02/planned-1-17-deployment/
“ | The engineering team is busy working on the deployment of the 1.17 branch of MediaWiki. We plan to roll this out next week to all languages and projects, Tuesday, February 8, with work starting at 07:00 UTC (which is 11pm on Monday, February 7 for San Francisco).
If all goes well, you should only notice the improvement. If it doesn’t go well, that’s because there’s something we missed, and that’s where we’d love your help. Please help us test this release!
|
” |
— billinghurst sDrewth 07:24, 1 February 2011 (UTC)
Gadgets
Following the recent update of the Mediawiki application, there is now a preferred methodology for the system to utilise gadgets that are more broadly used across the Wikimedia Foundation wikis. I have been through and updated several, and from my testing they are all (still!) functional. If people see gadgets that are not functioning then please add a note here at Wikisource:Scriptorium.
For those who use the Navigational Popups, as it is a little more temperamental I have added the new version into the Test/Developmental area at the base of the gadgets page, please play there and if there are no issues raised about it then I will roll it out in a week or two. Apologies to those who were inconvenienced earlier when I had to disable the old gadget to do some tests. — billinghurst sDrewth 14:15, 8 March 2011 (UTC)
Update.
- I have removed the old patrolling gadget (LinkPatroller) from the menu and moved the new, shiny gadget (AjaxPatrolLinks) from development to the interface section.
- I would like to disable the old navigational popups, and move the tested upgrade to be the default. Not hearing any issues to the contrary, I will do so in the next day or so.
Billinghurst (talk) 00:23, 13 March 2011 (UTC)
index headers & footer fields
as a follow-up to the recent code update, I enabled header and footer fields on index pages. sDrewth will be working on a way to conceal complex settings and display help messages, because index pages now might "scare off the noobs" ThomasV (talk) 11:43, 5 March 2011 (UTC)
- Or more accurately put, I will be asking people very nicely who are competent in js/css to contribute their coding skills, and I will do the appreciation and tributes. What I think would be useful would be
- (extra/advanced settings) some sort of twistie, or similar means, behind which the more advanced settings are placed; this will keep the basic settings simpler
- (header settings) it takes the {{{pagenum}}} parameter from <pagelist />, so we can look to means that we can add headers using {{RunningHeader}} and it knows that odd pages set on the right, and odd pages to the left.
- (help pages) organise some additional code that can be plugged into oldwikisource:MediaWiki:IndexForm.js so that we can sprout link(s)/help to help pages, whether we use MediaWiki:Proofreadpage index attributes
- — billinghurst sDrewth 12:43, 5 March 2011 (UTC)
- For an example of an active index page with prescribed header and footer see Index:England's alarm!.djvu — billinghurst sDrewth 14:18, 5 March 2011 (UTC)
I find this {{{pagenum}}} syntax disturbing. The page number masquerades as a named template argument, and puts me in the frame of mind as if I were writing template internals. I expect parser functions, substitution, etc, to work; and I don't expect {{{pagenum}}} to be substituted unless I explicitly request substitution. Instead I get the header/footer text copied verbatim, except that {{{pagenum}}} is unexpectedly replaced with a page number. This is syntax corruption, and is likely to cause confusion and extensibility/compatibility problems down the line. It should be a {{PAGENUM}} variable, not a faux argument. Hesperian 03:04, 8 March 2011 (UTC)
maintenance
I started a robot process that converts old PageQuality template to the new syntax. it should take about 18 days. ThomasV (talk) 06:19, 25 March 2011 (UTC)
WMF blog - Commons thumbnails issues
Wikimedia Foundation talks about existing issues with the thumbnail servers and what is happening to address the issue in their Techblog. Some other interesting information there too. Billinghurst (talk) 09:15, 3 April 2011 (UTC)
Proposals
Provisional ban of the person who most recently edited as Longfellow
I have been thinking about this upcoming discussion and two points are really bothering me.
- Longfellow (talk • contribs) has not revealed all the accounts they have created on SUL wikis. This is a requirement we made of them back in 2008 when we decided not to ban them after they had been editing as Poetlister (talk • contribs). They revealed a list of accounts at that time, but have since created more which have not been accounted for.
- Longfellow has never acknowledged which of their actions they understand to be inappropriate. This was something I really wanted from them in the 2008 ban discussion, but I deferred to the people in email contact with them, assuming that they were getting such assurances privately. After having been deceived once again by this person, I feel that more should be required of them than in the previous ban discussion.
I can't believe we should spend our energy reviewing all the evidence of their actions and trying to figure how to explain the parts which should remain largely private when these two points have not been satisfied. If this person wants to return to our community, the burden should be on them to give us some information so we can deliberate with intelligence and decide under what terms, if any, they will be welcome here. Is there any objection to provisionally banning this person without prejudice until they email an admin with such information to be posted on-wiki? Then we might have a detailed ban discussion on the merits provided the information they supply does not turn out to be dishonest.--BirgitteSB 02:25, 9 January 2011 (UTC)
- I have blocked as the Longfellow account as they are advertising that they have active account(s) on some other WMF site(s) and therefore Longfellow is an abandoned sock. All known accounts that have shown up locally are now blocked. They can expect no one in this community to keep their confidence. For all intents and purposes they are locally banned. If anyone objects to this defacto ban, please state you objections below. If anyone is contacted by this person, or otherwise learns that they have an active account on en.WS, leave a notice on the administrator's noticeboard with the details of the account concerned.--BirgitteSB 06:13, 10 January 2011 (UTC)
- Note Longfellow comments in email [1] came from Wikiquote under the Longfellow ID, it is not completely clear, if the intent was to use separate ID's, known or unknown socks. JeepdaySock (talk) 11:59, 10 January 2011 (UTC)
- I am leaning strongly towards support of a ban, I am also unsure how much effort to put into collecting evidence, or to what extent the ban should be. JeepdaySock (talk) 12:02, 10 January 2011 (UTC)
- Support ban (John Vandenberg mentioned this ban at Wikiversity) but allow him to use one account in the future as long as we are able to guarantee he has one account. This is mostly in accordance with what BirgitteSB mentioned above. Ottava Rima (talk) 18:38, 27 January 2011 (UTC)
- Full-on-ban. And m: should bump it to WMF-wide. This person is here for narcissistic fun and games, more than anything else. Begone. Jack Merridew 04:49, 30 January 2011 (UTC)
- agree with this proposal and Ottava's suggestion, however I assume Ottava means "guarantee he has only one account. John Vandenberg (chat) 12:16, 2 February 2011 (UTC)
- Support ban per Jack Merridew, as for limiting him to a single account did we not already try that? JeepdaySock (talk) 11:46, 4 February 2011 (UTC)
- Rational; When his bid for Admin fell apart he stopped improving WS and started planning a return to old habits, which did get him blocked. He requested an unblock to respond, but that motivation seems questionable, as he has been invited to respond on his talk page, where he is able to edit. His goals are not inline with the goals of WS or any wiki-project. JeepdaySock (talk) 11:46, 4 February 2011 (UTC)
Implement a perpetual ban
- Document
- The community has considered the actions of Poetlister / Longfellow and his sock accounts, and supports the administrator's ban from English Wikisource.
- Background
- Poetlister, more recently operating as Longfellow operates or operated the SUL accounts Quillercouch, Bevidere, Cato, Londoneye, Whipmaster, Yehudi, and Crum375, Ole Holm.
- Poetlister was previously an administrator at Wikisource, and as a result of the sockpuppet investigation this was terminated in a vote of confidence. At the time of the removal a vote to ban the user was unable to reach a consensus for that action Wikisource:Scriptorium/Archives/2008-09#Poetlister.
- A result of the ban discussion was the limitation of Poetlister to one account to edit at English Wikisource.
- Comment
- Poetlister returned to edit at Wikisource in March 2010 as the account Longfellow. He notified a checkuser of his return and his intention to edit under that identified account.
- Longfellow proposed himself to become an administrator on 13 December, Wikisource:Administrators/Archives/Longfellow, during which he sent email from his sockpuppet accounts, deceitfully misrepresenting himself as a female, though associated with the Poetlister saga. There were also instances in the bid for adminship of statements that were at best intentionally misleading, or outright lies.
- Following that email, it can be demonstrated that Poetlister had previously reactivated old SUL accounts for various means, including continuance of sending emails intended to deceive or to continue previous deceptive practices (see supplementary information below).
- Poetlister demonstrated that they are unable to be restrained by the fair conditions that were applied by the community, alternately they decided to disregard them in favour of their continuance of previous activities.
- Poetlister has continued to deceive the community, and despite previous the community's honest attempts to provide a framework to continue to edit.
- Action
- That the community supports this proposal to ban Poetlister/Longfellow from editing and participating at Wikisource.
- Supplementary information
- Across multiple Wikimedia projects, Poetlister has a long track record of deception and trouble-making, including a great deal of sockpuppetry, and impersonation of other people.
- They are now formally banned from several Wikimedia Foundation sites. In the wider community there are those who feel that he should be persona non grata across all Wikimedia Foundation sites
- There is a view that he has used smaller sites such as Wikisource as a springboard to re-entering or influencing larger sites; he has been successful at this. At one time even becoming a bureaucrat and checkuser for the English Wikiquote
- Further information can be found at w:Wikipedia:Wikipedia Signpost/2008-09-15/Poetlister and m:Requests for comment/Poetlister and Cato.
— billinghurst sDrewth 14:21, 2 February 2011 (UTC)
- I have a vague memory of LongFellow from somewhere, and I thought he was a member in good standing. Arlen22 (talk) 19:51, 4 March 2011 (UTC)
- After a brief discussion, I have changed the request that the community consider to document a community consensus. We have all considered enough. Jeepday (talk) 23:58, 16 March 2011 (UTC)
Forbidding translations into ancient languages
There was some fuss about translations into ancient languages recently, and I thought I'd bring it up independent of anything a user may or may be doing. I think we should have an established policy going forward; either we do, or do not, forbid translations into Old English and Middle English.--Prosfilaes (talk) 21:24, 4 February 2011 (UTC)
- If WMF decides to establish a 'policy', and the other apparatus (labelling, attribution, copyvio, review, and the inevitable need for arbitration, etc.), for translation at one of the sisters, I have seen no reason to forbid this type. Familiar texts are translated into other languages for pedagogical purposes, they are potentially 'useful', wikisource wouldn't exclude a properly published edition of these texts. cygnis insignis 21:59, 4 February 2011 (UTC)
- The distinction is that we translate into English to make the document available to more readers; I've always perceived translations into dead languages as an artistic exploit. A Latin translation occasionally has actual value to readers, and there is some possible value in offering would-be learners of Old English a new range of texts.--Prosfilaes (talk) 06:54, 5 February 2011 (UTC)
- Not sure I fully understand the proposal - is the question whether to allow translations into dead languages rather than the current practice of updating works from dead languages? — George Orwell III (talk) 01:56, 5 February 2011 (UTC)
- The question is do we permit translations into dead languages.--Prosfilaes (talk) 06:54, 5 February 2011 (UTC)
- Well that seems counter-productive not to mention a bit ridiculous. I would hope the primary goal here is to preserve the original work, as published, to the best of one's given abilities and the tools available, supplemented by various versions of the same work if so desired - but always post-publication. If an older version is "found" then that version becomes the new "baseline". Of course there will be instances where the original as-is may need annotations/translations to bring it up to some degree of modern readability or a later version may be considered definitive by its peers etc., etc., but taking a perfectly fine popular novel or whatever, changing the for ye, esses into effs, will(while?) for whilst and so on, is (to put my real opinion mildly) pointless.
I agree w/the below that to outright forbid this is probably not the best approach but one should have to justify the value such a work would contribute to the 'timeline' of already hosted versions of the work and why. At any rate, it should not be easy nor encouraged via policy. There's always Old.Wikisource if that many folks want a place to pretend or flex their skills - anywhere but here! — George Orwell III (talk) 20:19, 5 February 2011 (UTC)
- That's a little derisive; Old English is its own language probably harder to read for a monolingual English speaker then modern French.--Prosfilaes (talk) 21:33, 5 February 2011 (UTC)
- Apologies; that did come off bit too mocking. I'm having trouble understanding the reasoning behind contributing a "translation" that is contrary to the timeline, or eveolution if you prefer, of language in relation to a work or a set of versions of a work over time. Unless there is some "academic need" to translate backwards in time into a dead language to illustrate how different interpretations, etc. may have managed to diverege at some point along that works' timeline, I cannot envision the need (nor benefit) for such translations to be created. Irregardless of such a need existing or not (again too subjective of a determinatiion for an unqualified community to make), doing so here on WS would be beyond its scope wouldn't it? I would consider it to be an original work. — George Orwell III (talk) 01:32, 6 February 2011 (UTC)
- That's a little derisive; Old English is its own language probably harder to read for a monolingual English speaker then modern French.--Prosfilaes (talk) 21:33, 5 February 2011 (UTC)
- Well that seems counter-productive not to mention a bit ridiculous. I would hope the primary goal here is to preserve the original work, as published, to the best of one's given abilities and the tools available, supplemented by various versions of the same work if so desired - but always post-publication. If an older version is "found" then that version becomes the new "baseline". Of course there will be instances where the original as-is may need annotations/translations to bring it up to some degree of modern readability or a later version may be considered definitive by its peers etc., etc., but taking a perfectly fine popular novel or whatever, changing the for ye, esses into effs, will(while?) for whilst and so on, is (to put my real opinion mildly) pointless.
- (my opinion only) I do not see the need for translation into dead languages as a general course of action, and comfortable to see guidance to that effect. Forbid? That is a strong word and there may be may be may be … — billinghurst sDrewth 10:27, 5 February 2011 (UTC)
- The question is do we permit translations into dead languages.--Prosfilaes (talk) 06:54, 5 February 2011 (UTC)
Where? Here? Isn't this the English Wikipedia? I thought we only allowed texts in English or translated into English. We don't translate out of English here so why should we 'prohibit' it. Shouldn't this discussion occur at oldwikisource:Wikisource:Scriptorium.- I just re-read your question, oh, so the question is a bit more specific than it sounds, it's do we permit the creation of wikitranslations into a variety of English that is not spoken in the Modern World, do I have that right, now? I don't think we allow it because we aren't even wholly comfortable with wikitranslations to begin with and these wouldn't even meet the stated goals of wikitranslations. It seems to me that a wikitranslation or individual work translating something into Old English or Middle English would be in the same category as a user annotated work, at some point it's your own personal creation and needs to go on WikiBooks or a non-WMF project.--Doug.(talk • contribs) 10:05, 5 February 2011 (UTC)
- I don't see the distinction that many are making. If we forbid it, then certainly a justification could lead us to make an exception. If we don't forbid it, we've not been in the practice of demanding justification for each new work, and I'd not like that to change.--Prosfilaes (talk) 21:33, 5 February 2011 (UTC)
- Personal speaking, forbid means "no way, no how, never," however, someone may have a reason that I can never envisage, so I would like to leave the door very slightly ajar for that person to present their reason about why their translation is different. — billinghurst sDrewth 04:49, 6 February 2011 (UTC)
- I take no position on whether to forbid translations into ancient languages. More importantly, users' own translations always require the sources and copyright licenses. If you want new policies, how about a vote?--Jusjih (talk) 18:02, 23 February 2011 (UTC)
- Personal speaking, forbid means "no way, no how, never," however, someone may have a reason that I can never envisage, so I would like to leave the door very slightly ajar for that person to present their reason about why their translation is different. — billinghurst sDrewth 04:49, 6 February 2011 (UTC)
Have people been using English Wikisource for creating translations into Old/Middle English? I can't see the value in permitting that; it sounds like a task more suitable for Wikiversity, as Wikisource typically only wants to hosts one translation of each text for each language, so any pedagogical purposes are limited after the first translation is completed. John Vandenberg (chat) 06:22, 14 March 2011 (UTC)
- Yes; all the books at Biblioþēce that have a star after them are new translations. User:Gott wisst/1 Hēafodƿeard is a start of a translation of Oliver Twist that was started in user space.--Prosfilaes (talk) 18:48, 17 March 2011 (UTC)
- "Wikisource typically only wants to hosts one translation of each text for each language,"
{{tl|fact}}
It may be a personal preference, but I see no reason why Wikisource wouldn't want more than a single translation of The Three Musketeers if we had the opportunity. StateOfAvon (talk) 20:12, 17 March 2011 (UTC)- That would be only referring to Wikisource-generated translations, not published translations. This is to say that we don't want group A doing a translation (to completion or not) and then group B starting another. Billinghurst (talk) 22:27, 17 March 2011 (UTC)
Deprecate Match and Split
It has it uses, I have used it on occasion, but it is, overall, a very bad idea to use this tool. I've outlined some of the issue of its general usage at Help talk:Match and split, much more in response to almost every application of I have seen. What seems like a good idea turns out to foul up main space, often by turning perfectly acceptable Gutenberg texts in main ('fixing' something not broken), into something needing lots of tedious fixes to the Page: namespace, and that is if the problem is easily detectable (like ocr errors). cygnis insignis 09:24, 12 February 2011 (UTC)
- I think that a call to deprecate is premature. It is a useful tool when used properly. — billinghurst sDrewth 11:46, 12 February 2011 (UTC)
I mean that using it should be discouraged as a general solution "migrating text", to be used instead of near perfect ocr, and especially that existing texts be used to replace the text layer. The tool is most often used to attempt a merge of PG text to a scan, which introduce different problems, frequently with detrimental consequences.
- The tool is damaging texts, proofread and accepted.
- It is often operating as an unsupervised bot. Other users get confused about who is supervising the edits [2], currently no one is accountable and not all are able to fix the problems if they are willing.
- The preliminary investigation of whether it appropriate, a second opinion, a sanity check on the net benefit to the site, is not being undertaken before the process.
- There is no documentation of when or why to use it, only how, with the assumption it is a good thing to do.
- The problems it generates are not being fixed, some situations require an admin to delete hundreds of pages to recover the text layer.
- The tool has been available for over a year, I've reviewed the results and seen dozens of examples of it going horribly wrong. Those problems remain, they are rarely fixed after the bot run.
- I've also seen a lot of time invested in cleaning up the mess, in discussion, and in unproductive work and noise.
- Of the few indices and main-space texts I have repaired, the time taken was 2 to 3 longer than it would take to simply proofread the ocr.
- It makes a text appear to be from one copy (the scan), when it actually duplicates another source (and any overlooked or introduced errors) eg. [3]
- At no stage in the regular proofreading process have I seen how it saves time or "makes things easier".
- A transcript from a high quality source is good, so is proofread ocr with scans; some supervised automation is standard practice for both types, but mashing the two together is simply the wrong approach.
It has a use in very special circumstances, like a very good transcript and poor text layer, these points apply to way it is being frequently used. cygnis insignis 06:41, 13 February 2011 (UTC)
- I would generally support your comments that it is being over-used, or to be more accurate that there has not been adequate checks of the appropriateness for the task with the specific works. I would also agree that if the tool continues to be available that there should be a wider community management and responsibility, rather than the reliance on one or two individuals. The documentation and the guidance is lacking and that too should be improved by the community. If the community cannot do those things, then it should be deprecated. — billinghurst sDrewth 10:16, 13 February 2011 (UTC)
- Deprecation is the wrong answer, this is a valuable tool, especially when working with old texts that OCR'd poorly. However, I agree with Cyg that it is overused and I have found that many users, even very experienced ones, believe that mjbot is no longer useful because match and split is nearly always better, which simply isn't true. Because of this mattwj2002. There's lot's of use for mj over M&S. What if we required users to request permission to use the tool such as AWB on enwiki? probably too much bureaucracy, but just a thought.--Doug.(talk • contribs) 11:50, 13 February 2011 (UTC)
- I found that OCR of English texts is much better than OCR in other languages as Italian, so I found Match and Split extremely useful when converting naked texts into proofread ones into it.source. I used too for "splitting without matching", adding manually match code into a naked text when a OCR layer doesn't exist. I see that fr.source too uses M&S on lots of works, and I presume that it's the main reason for the fast change of proofread/naked proportion of works into that project. But I don't know at all mybot, I'll take a look. So, I don't support at all the idea of deprecate it globally; but obviously I can't balance pro and cons into en.source. --Alex brollo (talk) 08:46, 18 February 2011 (UTC)
- Yes this probably is en.ws specific, ocr doesn't handle a lot of other languages as well as English - I expect that software will be improved. I'm not proposing to disable the tool, just to 'deprecate' the way it is overwhelmingly used. I'm not fussed about how it is phrased, the choice of words, just that promoting this to break things not broken be stopped. Some saw this as a way to back texts with scans, for whatever reason (site statistics?) replacing good ocr with a different text was an especially bad idea. cygnis insignis 22:03, 6 March 2011 (UTC)
2,500,000th edit
I propose we determine who makes the 2,500,000th edit and give them a prize. It's sure to happen this weekend. Something like the print version of Wikipedia. How often are the statistics updated anyway? I've never seen the edit count actually move between refreshes. Well I'm sure someone knows better than me. Okay I've outlined the plan, now you folks take the idea and run with it! ResScholar (talk) 06:42, 12 March 2011 (UTC)
- The numbers keep leaping ahead at about 50 at a time, while only 3 or 4 edits are being made. The 2,500,000 edit figure must include every language at wikisource.org. Current value: 2,499,721. (excuse my indulgence in a little comic relief from the bad news in Japan; I stayed up late last night watching the earthquake news and worrying about our English editors in Australia) ResScholar (talk) 07:04, 12 March 2011 (UTC)
- Fr:Spécial:Statistiques gives a value of 2,282,875, which is suspiciously close to a number which might be given if the number is updated once every two months or so. Anyway we're at 2,499,832. ResScholar (talk) 07:12, 12 March 2011 (UTC)
- Oooh! 2,499,939! ResScholar (talk) 07:21, 12 March 2011 (UTC)
- Well maybe the server calculates these edits when there's nothing else to do, like a sensible person (unlike me) would, but let it be known that the server realized it had made its 2,500,000th edit, even if it really happened earlier, at the time given on the stamp with my signature. (yay!) ResScholar (talk) 07:27, 12 March 2011 (UTC)
- I checked De:Spezial:Statistik, which gave a totally different edit number, so it wasn't that the counters were slow; then I went to the Recent changes and realized I had set it for hide bots! I can now state fairly conclusively that the 2,500,000th edit was made at 7:26 UTC by none other than User:Slaporte's Benchbot! Congratulations! ResScholar (talk) 07:42, 12 March 2011 (UTC)
Input and decisions are sought on the following
Will be asking for input on the merits of several ideas, each to be posted separately.— Ineuw talk 09:19, 15 March 2011 (UTC)
Requests for articles/pages to be proofread
The first is my implementation of this PSM section for requests of pages/or articles to be proofread. I followed this up with this template for requests in general. Subsequently, these ideas needed some rethink, and concluded that a page like requested texts would be far more useful. My own concern is how a casual reader would find the page?
If this idea has merit, then I would create the page in the Wikisource namepspace and transfer current outstanding requests.— Ineuw talk 09:19, 15 March 2011 (UTC)
Unique PSM article titles
In the first 25 volumes of the PSM Project numerous titles were repeated, some of which the original editors numbered sequentially by suffixing roman numerals. Using this method, I made sure that every article title is unique without the preceding "path" — excepting the monthly recurring features which are not categorized.
Originally, this was done to address concerns about the path names displayed in the article titles in the Categories. Later, when I saw the results of Goggle searches, the idea of uniqueness gained greater importance.
I tested a single categorized redirect some months ago to see how long it would take for Google to include the title in a web search. — Waited several weeks, but the page never showed up. However, if this idea is feasible, then there are two possibilities, but don't know which is simpler and satisfies all requirements.
One option would be to convert the current titles which include the path into redirects. The other would be to create redirect pages and move the Categories. I have the page names HERE, and can easily provide a text file, as instructed, to meet bot requirements.
- Titles with paths would have to be masked somehow from appearing in a web search.
- Bots would be needed to create the pages and to move the categories.
Based on the resolutions of issues emerged during the first 25 volumes, and proposals here, I would like to continue building the pages for Volumes 25 to 50, as were done for the first 25 volumes.
- I can help with the first point: According to mw:Help:Magic words, adding __NOINDEX__ will stop search engines listing that page. (Adding __INDEX__ will tell search engines to list the page but it's up to the search engine if they actually pay attention to it). I don't think search engines index the redirects. Note: I've seen a few PSM articles with unique names that didn't reference their source. I can work it out from the DjVu but casual readers probably can't do that; a note in the notes section might be helpful. - AdamBMorgan (talk) 13:25, 15 March 2011 (UTC)
- Not sure what I am missing, I ran a check of four article titles
- A Run Through the Museums of Europe
- rated first
- "Quoted" Google search http://www.google.com.au/search?q="A+Run+Through+the+Museums+of+Europe"
- rated first
- A Belt of Sun-Spots
- rated fourth
- Equality and Inequality in Sex
- rated third
- Evolution and the Doctrine of Design
- rated third
- A Run Through the Museums of Europe
- So, your articles are being found, and high in the Google search results. With regard to sequential articles in sequential volumes, I would think that we can transclude together each part into the one consolidated article. This is the advantage of transclusion in that we can have the parts in many places, and easily pull together the parts that we wish to have. Billinghurst (talk) 21:41, 15 March 2011 (UTC)
- Not sure what I am missing, I ran a check of four article titles
Thanks for the comments. Thinking further on this issue, I came to realize that the idea is less than ideal because even if the article title is unique within the PSM project, it doesn’t mean that it’s unique in Wikisource. Also, on re-examination, the search results are sufficiently outstanding, so, please scratch this idea.— Ineuw talk 11:36, 16 March 2011 (UTC)
As for Billinghurst’s comment; I assume that you are referring to something like The Study of Sociology page to organize serialized articles. I will implement this in due time.— Ineuw talk 11:36, 16 March 2011 (UTC)
Masking of PSM "path" in the Category listings
To improve on lists such as this, is there a way to mask the path/volume/dates and display a clean list of article titles in the Category listings? Alternatively, can a single column display be applied on long article titles? — Ineuw talk 11:36, 16 March 2011 (UTC)
- The first has been requested as a feature in bugzilla:17212, you may want to register and vote on it to increase its prominence. Prosody (talk) 03:34, 17 March 2011 (UTC)
- Hi Prosody. Registered as suggested, but since there are only three registrants, and it’s a display enhancement, I doubt that it will be acted upon in this decade. :-) It was first posted in 2009.— Ineuw talk 21:16, 19 March 2011 (UTC)
BOT approval requests
Help
Other discussions
US only books via HathiTrust
Hello,
Could someone from USA help getting these books?
It seems this tool is needed. The issue is that this tool doesn't work with a proxy. Thanks in advance, Yann (talk) 20:34, 25 February 2011 (UTC)
- Oh please Lord God Almighty... give someone here, with the skills that I lack, the strength and courage to take up this request,
- Finally I managed to get these with a script and a IP proxy. Yann (talk) 21:55, 22 March 2011 (UTC)
- Yes, Stephen managed to get a large swath of volumes for me this way as well. I hope a better solution presents itself - their Digital Library really is growing leaps & bounds and it would really be a shame if we are not able to utilize it. — George Orwell III (talk) 00:23, 23 March 2011 (UTC)
- Finally I managed to get these with a script and a IP proxy. Yann (talk) 21:55, 22 March 2011 (UTC)
National Maritime Museum data question
Wikimedia UK is talking to the National Maritime Museum, in London, about them releasing a large quantity of data under a CC-BY-SA licence. The material in question consists of information about British warships, which has been collated by their curatorial staff from the primary documents in the NMM. It is presented as a flat data file (actually they have it in Excel but could equally well be .csv, .odb etc) and also as a series of PDF documents. A sample of the former can be viewed here. More information about the project is available here.
I am aware Wikisource doesn't normally accept contributions which are purely reference material, as is the case here. However to the best of my knowledge this is the first time a museum has thought about directly releasing data (rather than media) to a Wikimedia project. I understand the concerns set out in the Inclusion policy, which says...
"Wikisource does not collect reference material unless it is published as part of a complete source text. Such information has not been previously published, is often user-compiled and unverified, and does not fit the goals of Wikisource."
In this case what is on offer is in a sense a "complete source text". It is "published" in the sense that it is available to the public for inspection in the National Maritime Museum. It is certainly not user-compiled or unverified. So my question is, would this information be a welcome addition to Wikisource? Regards, The Land (talk) 10:20, 27 February 2011 (UTC)
- I am not even slightly well informed about this side of Wikisource but: Technically, it is published by the National Maritime Museum and it might (possibly) count as a documentary source. I believe the intent of excluding raw data is to prevent users adding their own unverified lists; this, as you say, avoids that problem. It might set a precedent, of course, or be otherwise brought up in future discussions, which could be a problem. However, I would hazard that it might be OK as a borderline case in this instance. (Also, I think almost half a millenium of specialist historical data compiled by an authoritative source would be useful.) If it does happen, I would recommend uploading a DjVu (not PDF but it can be converted from one) copy as well as a CSV file. The DjVu would be the basis of the page on Wikisource and it can link to the CSV file on Commons (which would be useful on its own). It might help to tip it over from "raw data" into a "source text" if it comes with some sort of preamble or introduction (as part of the DjVu). - AdamBMorgan (talk) 14:24, 28 February 2011 (UTC)
- From the sample given, this looks to me like being a ship's equivalent of a telephone directory, and I suspect it would therefore fail the inclusion criteria outright, on the grounds as being a pure list that has never been formally published, is user-compiled (admittedly by museum staff), but is unverified in the sense that it has not been peer reviewed by an external authority on the subject matter.
- The quantity and quality of reference material appears to rudimentary, so even its use as a reference source seems to be very limited. Personally, I don't see the point of this list. The National Maritime Museum is probably sitting on a treasure trove of material from which this list is drawn that would qualify for inclusion. Maybe The Land could ask for some of the really good stuff that the museum has hidden away in its archives, rather than this low value barebone list material? ----Gavin Collins (talk|contribs) 14:57, 28 February 2011 (UTC)
- Thanks for those replies. I'm aware this is an unusual situation. It is definitely material that en.wikipedia wants to make use of, but the question of where exactly these files live remains open.
- Gavin - actually, in my opinion as someone who writes warship articles on Wikipedia, this is very helpful material which fills an important gap in what we have available. Obviously the NMM has vast quantities of primary documents - fascinating material, but to the best of my knowledge undigitised, and not something they are currently keen to share. A productive collaboration making use of what they're offering at the moment will help make it more likely that the cultural sector decides to open up more of its information in future. Though of course I appreciate "stuff like this is good" isn't the same as "this particular material belongs on this particular project". The Land (talk) 15:34, 28 February 2011 (UTC)
- It might be useful material in some ways, but because it is self-published and has not been peer reviewed, it is not really reliable: it is a truncated, second-hand account of what is in the original source documents. Perhaps The Land is closer to the material, and can, to some extent, vouch for its reliability and attest to its usefulness. However, I personally would not accept scraps skimmed from primary sources, knowing that that it is just a summary of really interesting and important documents from which the data has been drawn.
- I believe there is a big debate going on in public institutions in the UK regarding whether access to their archive material should be made to the general public via the internet. On the one side, the likes of the National Maritime Museum have the option to digitalise their archives or let their collection slowly rot or fade away. The benefit of digitalising the archive and releasing it into the public domain is it then becomes possible to come up with lots of new ways to utilise and study their collection in ways that nobody ever thought of: like writing books or encyclopedic articles which has only become possible with its release. The benefit of not digitalising the archive is that the museum "preserves" their collection by restricting control over access to collection, but this has the effect of restricting who can see it. I think this list falls short of what the museum should really be doing: the release to little snippets of information, like this list, falls far short of what they should be doing.
- I can't say I approve of this "collaboration" at any level, but one of them is that is just an unreliable way to get the data. What we need is primary source documents, not a list summary of their content, written by unnamed staff whose output is not peer reviewed. If a less well regarded institution were to drip feed us with a list in this way, I am sure it would be refused point blank. ----Gavin Collins (talk|contribs) 16:47, 28 February 2011 (UTC)
- You're quite right to say that cultural institutions should be more open. Hopefully working productively with them will encourage that. But what cultural institutions should or shouldn't be doing isn't really the question here. More views on whether it's appropriate content for Wikisource would be appreciated. The Land (talk) 16:55, 28 February 2011 (UTC)
- To add to my first comment, the sample has some additional material (to the right under description, attrib_comment and notes) that makes me think it is more of a borderline case than simply raw data. The National Maritime Museum is a well regarded academic institution with authority in this area, so I don't think that should be a problem. As for the principle: pragmatically, this could represent a "foot in the door" with the museum. Wikimedia UK might be able to build on this to get their other documents (they have microfiche files, perhaps Wikimedia could assist—financially or otherwise—to convert these or scan other documents; both Wikimedia and the museum would benefit from this). That in turn might attract other volunteers, from Wikipedia and (maybe) Wikimedia UK promotion. However, even considering all of this, my opinion is still very much "maybe" leaning slightly towards yes. - AdamBMorgan (talk) 17:15, 28 February 2011 (UTC)
- In fairness, it is not a borderline case is it? If this data has not been published elsewhere, then essentially Wikisource is being invited to be the first publisher. There is nothing "borderline" (unless you ignore the inclusion criteria altogher) about this case at all. ----Gavin Collins (talk|contribs) 17:36, 28 February 2011 (UTC)
- I count the National Maritime Museum as the first publisher, they have made this information available to the public. As a museum and academic institution they are quite capable of legitimately self-publishing; I don't think that's an issue. I think the borderline nature comes from whether this is properly reference material or not under Wikisource:What Wikisource includes. I could be wrong but I maintain my opinion and I'd like a broader range of opinions. - AdamBMorgan (talk) 20:49, 28 February 2011 (UTC)
- In fairness, it is not a borderline case is it? If this data has not been published elsewhere, then essentially Wikisource is being invited to be the first publisher. There is nothing "borderline" (unless you ignore the inclusion criteria altogher) about this case at all. ----Gavin Collins (talk|contribs) 17:36, 28 February 2011 (UTC)
- To add to my first comment, the sample has some additional material (to the right under description, attrib_comment and notes) that makes me think it is more of a borderline case than simply raw data. The National Maritime Museum is a well regarded academic institution with authority in this area, so I don't think that should be a problem. As for the principle: pragmatically, this could represent a "foot in the door" with the museum. Wikimedia UK might be able to build on this to get their other documents (they have microfiche files, perhaps Wikimedia could assist—financially or otherwise—to convert these or scan other documents; both Wikimedia and the museum would benefit from this). That in turn might attract other volunteers, from Wikipedia and (maybe) Wikimedia UK promotion. However, even considering all of this, my opinion is still very much "maybe" leaning slightly towards yes. - AdamBMorgan (talk) 17:15, 28 February 2011 (UTC)
- Based on the little I have been exposed to on WP when providing the Executive Order(s) authorizing the seizure of one ship or another during war-time, this UK data basically mimics what is typically found in an U.S. warship's info-box template in most cases -- but that data comes from first the published printed volume(s) of some naval dictionary followed by the same volumes' conversion(s) to online HTML of the original volume text. This data is a supplement to the main summary text covering actions, history, etc. of the "warship" before, during, and after seeing action. At the end of such WP articles, typically a dedicated template is used to auto-external link, much like a proper citation would, to that online conversion of the originally printed volume.
- In the straight UK data's case the, summary or context text validating the straight data is not made present together or even married by internal (same domain) linkage. Yes, it cites, rather poorly, the original printed volume that could validate the entry but only vaguely and in passing, as in This record is a conversion from the Museum's warship histories || 1785. Not enough to get over all the hurdles for hosting by a long shot in my view. Based on that, these are merely an excerpts and an incomplete work of a much larger volumized collection nor does it have any embedded, non-alterable same-domain linkage from one(data) to the other(content) or vise-versa that may serve as a qualifier for validity, granting some leeway in defining "an excerpt" on WS in return. IMHO it does meet WS guidlines for hostable works. — George Orwell III (talk) 06:57, 1 March 2011 (UTC)
- There are no printed volumes. What we're talking about is a digitisation of card file records. Those card file records have been assembled by the NMM's staff from the original primary documentation, and are available to the public; we are offered them complete and unexcerpted. As I mentioned above, the primary documentation is neither digitised nor on offer. The Land (talk) 09:40, 1 March 2011 (UTC)
- So there is no evidence that this list has been published, not even self-publshed. This card index does not have an ISBN like many of the the other texts published by the Museum have (for example). Like a museum's inventory or a libary's catalogue, this list may have been collated by their curatorial staff for their own internal purposes, but collation is not publication, not even self-publication. The list it does not qualify for inclusion, unless of course we deliberately choose to ignore or try to circumvent existing inclusion policy by way of obfuscation. ----Gavin Collins (talk|contribs) 09:53, 1 March 2011 (UTC)
- Obviously I'm not greatly experienced on Wikisource, but it does seem to me that the way the policy is worded indicated verifiability is a greater concern than publication. Indeed, Wikisource explicitly accepts some unpublished works. The Land (talk) 10:10, 1 March 2011 (UTC)
- Simple question - do any of these data, card-file, whatever-you-call-its have a link that takes you to the exact same info on any site under the National Maritime Museum's registered domain name(s) or not? I would tend to agree with Mr. Collins POV if there is no such tie readily available to verify authenticity if not merely insure accuracy. — George Orwell III (talk) 10:15, 1 March 2011 (UTC)
- No. But I would be very surprised to find a Wikimedia project saying that offline sources were unnacceptable references. The Land (talk) 10:19, 1 March 2011 (UTC)
- Then who insure's the lists accuracy and credibility in the absence of a.) scans of the original as published if/as printed or b.) no readily verifiable means for potential readers to verify accuarcy on there own (placing the credibility portion squarely at the reader rather than WS)? ...and please - I doubt anybody is going accept that parsing of one wikis's mission, policies and practices as a substitute for this one's.
- The latter is far more complicated when the linkage is to some non-sanctioned site rather than the principle source's well established and properly registered domain name and sites. If no scan were available for WS upload, and I needed to create a work surrounding Washington's list of military requests to Congress on WS, I could afterwards point to that list or letter on OurDocuments.gov without worry since it is a registered domain name associated with the National Archives and Records Administration as well as the Library of Congress using the well-recognized dot Gov suffix in each consecutive url of the work but I wouldn't point to something like WashingtonsBrigades.org or any of the dozens of other General Washington dedicated fan-sites out there for all the obvious potential pitfalls one can come across at such well-intentioned but not neccessarily always authoratative sources on the subject matter that is also managed by recognized experts - the degree of credibilty is a craps-shoot there in short. — George Orwell III (talk) 10:53, 1 March 2011 (UTC)
- Yes, we do include unpublished work in the public domain, though it specifically says historical documents, and this is sort of where we apply a notability test, also to note that would be with regard to a static document, noting the inference about living documents. I do not see how one could say that an individual card is a historic document, and where you have people working on bits now. To me it seems the basis for a building block, but I do not see the necessity or interest of it to be a specific static document, which is what we put into the main namespace. — billinghurst sDrewth 11:04, 1 March 2011 (UTC)
- No. But I would be very surprised to find a Wikimedia project saying that offline sources were unnacceptable references. The Land (talk) 10:19, 1 March 2011 (UTC)
- Simple question - do any of these data, card-file, whatever-you-call-its have a link that takes you to the exact same info on any site under the National Maritime Museum's registered domain name(s) or not? I would tend to agree with Mr. Collins POV if there is no such tie readily available to verify authenticity if not merely insure accuracy. — George Orwell III (talk) 10:15, 1 March 2011 (UTC)
- Obviously I'm not greatly experienced on Wikisource, but it does seem to me that the way the policy is worded indicated verifiability is a greater concern than publication. Indeed, Wikisource explicitly accepts some unpublished works. The Land (talk) 10:10, 1 March 2011 (UTC)
- You're quite right to say that cultural institutions should be more open. Hopefully working productively with them will encourage that. But what cultural institutions should or shouldn't be doing isn't really the question here. More views on whether it's appropriate content for Wikisource would be appreciated. The Land (talk) 16:55, 28 February 2011 (UTC)
- [edit conflict]A thought for consideration. To me this compilation sounds like perfect material for our Portal namespace, to do something like we did with Portal:British Museum. The data could become the basis for a central page with each ship being a redlink, that can then spawn to a portal page for each ship. As we get individual documents/works/... they are put into the main namespace as usual, be they one page long, or fifty, linking back to the relevant portal page. On the portal pages it can link out to sister links, back to NMM and it is a place where reference material can be added, links to ships, for which we have lots in DNB and for and works like The Life of Captain Matthew Flinders, R.N., An account of a voyage to establish a colony at Port Philip in Bass's Strait on the south coast of New South Wales, in His Majesty's Ship Calcutta, in the years 1802-3-4 +++ It would be also make an interesting WS:CotW to build the pages. — billinghurst sDrewth 09:57, 1 March 2011 (UTC)
- billinghurst proposal seems to me to be the right approach. I do not deny the utility of such a list, and it could be put to good use in the way he describes. But it does not qualify as an "offline source" because it is clearly and unambiguously exlcluded from inclusion by way of being reference material. If this presumption is not correct, please say so. ----Gavin Collins (talk|contribs) 11:00, 1 March 2011 (UTC)
- Does sound like a very interesting idea! I'm not at all familiar with the Wikisource portals, but I think I get the idea from your post, Billinghurst. Bear in mind that there are some 13,000 or 20,000 RN ships (depending on whether you take a broad or narrow definition) so sub-pages would probably be needed for comprehensibility. The Land (talk) 11:33, 1 March 2011 (UTC)
- So, Portal:National Maritime Museum (which can also hold other information about the museum) with, say, a subpage for each initial, ie. Portal:National Maritime Museum/Warships-A etc? Then, for example, Portal:HMS Ark Royal, which can cover all of the different Ark Royals under section headings? (These ship-specific portals can also link back to Portal:Royal Navy as well as the NMM portal). It should work. All it needs to go is the CSV file. - AdamBMorgan (talk) 12:34, 2 March 2011 (UTC)
- I would add the suggestion that each version/rendition(?) of the ship name has an anchor on the page for it, so that way ships refs eg. Endeavour, Investigator, Persephone, ... can have point directly as necessary, rather than just to the page. We would probably wish to agree on a nomenclature, eg. HMS XXXXXX (yyyy) and that would seem to follow what WP has done. — billinghurst sDrewth 13:26, 2 March 2011 (UTC)
- I would suggest a family of pages like Portal:Royal Navy/Warships-A which then have a set of redlinks to Portal:Royal Navy/HMS Ark Royal, and if there is enough content to justify it, you can split down to Portal:Royal Navy/HMS Ark Royal (1587) through to Portal:Royal Navy/HMS Ark Royal (R07). The structure could be broadly similar to the way en.wikipedia handles things, e.g. here. I think that given what's proposed "Royal Navy" is a better name than National Maritime Museum as what I think you're proposing is collating materials relevant to the Navy and the individual ships, rather than material relevant to the NMM per se. In terms of nomenclature en.wikipedia also has a workable set of ship naming conventions which are quite well followed there. The Land (talk) 16:21, 2 March 2011 (UTC)
- Makes complete sense to me start with the RN, xlink to NMM, and for ship naming to mimic the hierarchy and nomenclature, and it works well for both WP/WS and presumably (hopefully) Commons, especially with sister links. — billinghurst sDrewth 03:16, 3 March 2011 (UTC)
- In terms of source material to add, it strikes me that there is probably a fair bit here already that's relevant. I also notice there's quite a lot of Royal Navy material freely available from the Open Library project (I was actually having a look around for the only out-of-copyright book I own, and found it wasn't here, but was available on Open Library). Is it considered acceptable, or indeed useful, to copy public-domain material from the Open Library project to here? Am just about to head off on holiday but will be back in a week... The Land (talk) 20:44, 4 March 2011 (UTC)
- Depends on what you are looking to copy, the guide is Wikisource:What Wikisource includes. If you are talking about published works, then yes, see Help:DjVu files and Help:Proofreadit ends up in our main namespace. Many of our works come from either scans available for Archive.org or Google Books and . If it is just data, then that belongs in the Portal: ns as that is supportive and research orientated. — billinghurst sDrewth 23:54, 4 March 2011 (UTC)
- Right, I've uploaded the DjVu of Volume 1 of The Royal Navy, a History From the Earliest Times to the Present along with the OCRs of the text, and proofread some of it. Could you review that and give me some feedback... hopefully I'm doing that right! The Land (talk) 20:22, 14 March 2011 (UTC)
- Depends on what you are looking to copy, the guide is Wikisource:What Wikisource includes. If you are talking about published works, then yes, see Help:DjVu files and Help:Proofreadit ends up in our main namespace. Many of our works come from either scans available for Archive.org or Google Books and . If it is just data, then that belongs in the Portal: ns as that is supportive and research orientated. — billinghurst sDrewth 23:54, 4 March 2011 (UTC)
- In terms of source material to add, it strikes me that there is probably a fair bit here already that's relevant. I also notice there's quite a lot of Royal Navy material freely available from the Open Library project (I was actually having a look around for the only out-of-copyright book I own, and found it wasn't here, but was available on Open Library). Is it considered acceptable, or indeed useful, to copy public-domain material from the Open Library project to here? Am just about to head off on holiday but will be back in a week... The Land (talk) 20:44, 4 March 2011 (UTC)
- Makes complete sense to me start with the RN, xlink to NMM, and for ship naming to mimic the hierarchy and nomenclature, and it works well for both WP/WS and presumably (hopefully) Commons, especially with sister links. — billinghurst sDrewth 03:16, 3 March 2011 (UTC)
- I would suggest a family of pages like Portal:Royal Navy/Warships-A which then have a set of redlinks to Portal:Royal Navy/HMS Ark Royal, and if there is enough content to justify it, you can split down to Portal:Royal Navy/HMS Ark Royal (1587) through to Portal:Royal Navy/HMS Ark Royal (R07). The structure could be broadly similar to the way en.wikipedia handles things, e.g. here. I think that given what's proposed "Royal Navy" is a better name than National Maritime Museum as what I think you're proposing is collating materials relevant to the Navy and the individual ships, rather than material relevant to the NMM per se. In terms of nomenclature en.wikipedia also has a workable set of ship naming conventions which are quite well followed there. The Land (talk) 16:21, 2 March 2011 (UTC)
- I would add the suggestion that each version/rendition(?) of the ship name has an anchor on the page for it, so that way ships refs eg. Endeavour, Investigator, Persephone, ... can have point directly as necessary, rather than just to the page. We would probably wish to agree on a nomenclature, eg. HMS XXXXXX (yyyy) and that would seem to follow what WP has done. — billinghurst sDrewth 13:26, 2 March 2011 (UTC)
- So, Portal:National Maritime Museum (which can also hold other information about the museum) with, say, a subpage for each initial, ie. Portal:National Maritime Museum/Warships-A etc? Then, for example, Portal:HMS Ark Royal, which can cover all of the different Ark Royals under section headings? (These ship-specific portals can also link back to Portal:Royal Navy as well as the NMM portal). It should work. All it needs to go is the CSV file. - AdamBMorgan (talk) 12:34, 2 March 2011 (UTC)
- Does sound like a very interesting idea! I'm not at all familiar with the Wikisource portals, but I think I get the idea from your post, Billinghurst. Bear in mind that there are some 13,000 or 20,000 RN ships (depending on whether you take a broad or narrow definition) so sub-pages would probably be needed for comprehensibility. The Land (talk) 11:33, 1 March 2011 (UTC)
- billinghurst proposal seems to me to be the right approach. I do not deny the utility of such a list, and it could be put to good use in the way he describes. But it does not qualify as an "offline source" because it is clearly and unambiguously exlcluded from inclusion by way of being reference material. If this presumption is not correct, please say so. ----Gavin Collins (talk|contribs) 11:00, 1 March 2011 (UTC)
- [edit conflict]A thought for consideration. To me this compilation sounds like perfect material for our Portal namespace, to do something like we did with Portal:British Museum. The data could become the basis for a central page with each ship being a redlink, that can then spawn to a portal page for each ship. As we get individual documents/works/... they are put into the main namespace as usual, be they one page long, or fifty, linking back to the relevant portal page. On the portal pages it can link out to sister links, back to NMM and it is a place where reference material can be added, links to ships, for which we have lots in DNB and for and works like The Life of Captain Matthew Flinders, R.N., An account of a voyage to establish a colony at Port Philip in Bass's Strait on the south coast of New South Wales, in His Majesty's Ship Calcutta, in the years 1802-3-4 +++ It would be also make an interesting WS:CotW to build the pages. — billinghurst sDrewth 09:57, 1 March 2011 (UTC)
- (outdenting) I have taken the liberty of creating Portal:Royal Navy/HMS Blake as an example of how this might work - it's a child of the main Royal Navy portal, includes some relevant Wikipedia info, and lists a relevant sources on this project which refer to the relevant ship. This shows how we might construct a taxonomy of portals for RN warships as discussed earlier. The Land (talk) 22:39, 15 March 2011 (UTC)
- It might also be worth looking at something with more potential for inbound links, eg. for HMS Beagle search or HMS Endeavour. We can dig through the work of Author:John Knox Laughton and look to do links in and out. I will put further comment at Portal talk:Royal Navy. Billinghurst (talk) 23:17, 15 March 2011 (UTC)
Since this is unpublished, research oriented and digital, couldn't Wikiversity be a more appropriate project to place this data into? - Theornamentalist (talk) 23:59, 4 March 2011 (UTC)
I think that our default text width needs to be examined again.
PREFACE - I understand the need for minimizing white space on either or both side of works, that other sister sites (famously, Wikipedia) have no default page width and do so without question, that under-formatting is better as a whole for maintenance, that page width used to be limited by the width of the printed page, that compressing the width subsequently expands the height, but there is only one thing that led me to writing this out...
it looks ugly.
I have looked at other discussions, and some points were made, but there are other important factors that disagree with our default layout. With our ever-widening wide-screen everything, it will only become worse. I have 1366 x 768 resolution, and I typically get 200-220 characters per line. This is by far not the widest monitor I know of. There are many sources that suggest much less; at an average I've found it to be 40 to 60 characters recommended (here's one and another) Otherwise, I find images (unless very wide themselves) to cause ugly breaks within text with sudden white spaces on both sides, paragraphs reduced to single lines, among other catastrophes. I, for one, don't mind seeing white space on both sides. I haven't seen a formal vote, and I don't know if we need one, but I think it needs to be discussed, so please, let me hear your opinion :) - Theornamentalist (talk) 23:37, 4 March 2011 (UTC)
- Disagree with enforcement. What we need are more and a variety of layouts, and the ability for people to set their own default. Setting hard right margins is problematic, so enforcing it as the default is not ideal. Then when it comes to printing it is butt ugly. We have work to do in this area. — billinghurst sDrewth 23:46, 4 March 2011 (UTC)
- I generally like "layout 2" as seen as the default in the French Wikisource. I would not disagree with having a larger variety of layouts, but I think we should be able to at least default the work to a particular layout, instead of using code per work. - Theornamentalist (talk) 23:51, 4 March 2011 (UTC)
- User set default, not per work. — billinghurst sDrewth 23:58, 4 March 2011 (UTC)
- What I mean is that if a work can be better viewed in a particular layout, the user should be able to default that specific work to that layout. I believe that most who migrate here from WP will be used to the width as seen there and not be familiar with the option on the side panel. Maybe even strain their neck and simply think that reading the pdf on google books might be easier. I don't want to compromise my first point though by offering different layouts, yet still defaulting to the full screen one. We are not WP and do not have to follow their format. To add, text on WP is typically interrupted often by infoboxes, images, sound files, headers, etc., whereas en.ws can potentially have a massive block of seemingly unending text. On WP, you may only be interested in a portion, and/or skim, which is my personal belief that most people do when reading articles. A source text or novel is not meant to be read that way, but rather carefully and in its entirety.
- User set default, not per work. — billinghurst sDrewth 23:58, 4 March 2011 (UTC)
- I generally like "layout 2" as seen as the default in the French Wikisource. I would not disagree with having a larger variety of layouts, but I think we should be able to at least default the work to a particular layout, instead of using code per work. - Theornamentalist (talk) 23:51, 4 March 2011 (UTC)
- to billinghurst: what began as a response ended up becoming more opinion, and the bulk of text above was not written with the idea that you hold the opposite of any opinion I have specified. - Theornamentalist (talk) 00:08, 5 March 2011 (UTC)
- Default-ing the work to a particular dynamic layout is not really setting an unbiased default now is it? Picking the dynamic layout most appealing to one viewer at the possible expense of other potential viewers never seemed like a good idea and that's pretty much why I wish it was enabled per one's user preferences rather than universally. Not disagreeing with your principle point - just in the manner you seemingly look to resolve/enforce it. — George Orwell III (talk) 00:15, 5 March 2011 (UTC)
- Enforced is such a harsh way to say default! ha, please ignore any suggestions I've made for a solution, as well as opinions following my initial statement: that our page width, as supported by many sources, is set to default in such a way that is non-ideal for readers. - Theornamentalist (talk) 00:22, 5 March 2011 (UTC)
- Nevertheless, the only real default would be one that was not dynamic. It is a contradiction at its core and in every sense of the word(s). — George Orwell III (talk) 00:30, 5 March 2011 (UTC)
- As I understand it, the "dynamic" in "dynamic layout" only refers to the fact that the layout is changeable by the user. I don't see how that affects the default-ness of a particular layout. - Htonl (talk) 00:41, 5 March 2011 (UTC)
- What would you call the state of viewing a work when no dynamic layout is automatically envoked nor available under 'Display Options'? — George Orwell III (talk) 01:43, 5 March 2011 (UTC)
- "Static layout"? I grant that that would be a default layout. On the other hand, if there are a number of dynamic layouts available, but one of them is invoked by default, would that not also be a "default layout"? - Htonl (talk) 01:53, 5 March 2011 (UTC)
- I understand your point that only one particular dynamic layout is called-up over the others depending on the circumstances at hand, mostly dependent upon the manner in which the content being viewed has come to exist in the main namespace prior to that point in time. I just believe a true default should not only cover those circumstance but all circumstances from the initial arrival on forward until that state of operation is manually altered, changed or selected by the user in some way, shape or form - causing a new pseudo-custom state of operation to replace the automatic one. Splitting hairs I suppose. — George Orwell III (talk) 03:22, 5 March 2011 (UTC)
- "Static layout"? I grant that that would be a default layout. On the other hand, if there are a number of dynamic layouts available, but one of them is invoked by default, would that not also be a "default layout"? - Htonl (talk) 01:53, 5 March 2011 (UTC)
- What would you call the state of viewing a work when no dynamic layout is automatically envoked nor available under 'Display Options'? — George Orwell III (talk) 01:43, 5 March 2011 (UTC)
- As I understand it, the "dynamic" in "dynamic layout" only refers to the fact that the layout is changeable by the user. I don't see how that affects the default-ness of a particular layout. - Htonl (talk) 00:41, 5 March 2011 (UTC)
- I apologize; without using the word default, I mean to say that the page width upon visiting en.ws for a new visitor is currently too wide; whether or not dynamic layouts exist, in which a user can select a preference, I am uninterested in. - Theornamentalist (talk) 00:48, 5 March 2011 (UTC)
- What exactly are the objectionable width and/or margin layout values you'd like to see changed and where can they be found? — George Orwell III (talk) 01:43, 5 March 2011 (UTC)
- Our width on opening a work on en.ws for the first time currently spans the entire page width, which can create an excess of characters per line; in my case, over 200, where the suggested amount is roughly an eighth of that value. Even if had a resolution which resulted in half of the character count per line I experience, that may still cause issues for reading comfortably. I don't have a practical solution, although French Wikisource seems to address this somewhat. - Theornamentalist (talk) 02:02, 5 March 2011 (UTC)
- What exactly are the objectionable width and/or margin layout values you'd like to see changed and where can they be found? — George Orwell III (talk) 01:43, 5 March 2011 (UTC)
- I apologize; without using the word default, I mean to say that the page width upon visiting en.ws for a new visitor is currently too wide; whether or not dynamic layouts exist, in which a user can select a preference, I am uninterested in. - Theornamentalist (talk) 00:48, 5 March 2011 (UTC)
- Ok I looked at your example on fr.WS and, for argument's sake, agree that it looks better than most that I've been seeing here. Maybe you can help me find some more examples for continued comparison - I can't readily locate such a rendering that also has header-notes (brief additional text within a light blue field found directly under the main green navigation portion of a typical header) present; can you? — George Orwell III (talk) 03:22, 5 March 2011 (UTC)
- With regard to the default, the current default, it truly is the vanilla ice-cream version. No width or right margin inhibitors, and allows users to easily stretch or shrink their browser to suit. That should always be the default so it works on all browsers, on all screens from 4 inch to 36 inch. After that go for your life with the number of options that are presented. The issue is that we have seen so many issues with different browsers and their standard and non-standard responses to pages, coding, etc. that the default has to fit into the Keep it Simple model, and allow obvious choice from their, and then when someone has their preference that the option becomes sticky for them, or maybe for their browser on that apparatus. — billinghurst sDrewth 13:01, 5 March 2011 (UTC)
- Absolutely Right - but the point I was going to eventually extract from that labored line questioning is that the fr.WS uses a completely div based header that never seems to incorporate the light blue header notes field & all it's recent trimmings while we use a table based header married to the the light blue notes field. Their header expands and contracts (heck even disappears if you maximize or minimize your browser window too much at once) effortlessly with whatever layout you choose or come up with while ours is tossed about much like a brick in washing machine - made worse by the uneven sizing of the blue notes field at times in relation to the green navigation field. That, I believe, is more the issue with the display one may or may not be seeing than any margin or width settings are and how ugly those might be to some.The fact dynamic layouts are enabled and replaces that "keep it simple default" under certain conditions rather than leaving the feature off until enabled by the user is a whole other matter. — George Orwell III (talk) 19:17, 5 March 2011 (UTC)
- In order to maintain our notes field and header width, I don't think it would be too difficult to have the works fit to a separate width (see here).I understand the default logically should be very simple in order to have compatibility for a user who happens to come in with a 600 x 480 resolution and size 14 font, among others. But I am truly curious, who has experienced these issues with bizarre formatting on WS? I've used en.ws on many computers, with res and font settings that have left me with roughly 40 characters per line to 350 per line; used windows, mac, and 4 different browsers. I have not seen anything not working properly, or the sudden disappearance of headers because of a fixed width. This is not to say that it couldn't happen to someone, but I can't imagine what they would need to have in order to not see en.ws in a way suitable for reading. George, how did you make the header contract on fr.ws? It seems to be a fixed width, not percentage based or something. Regardless of any of formatting and compatibility issues, it is still recommended for have only 40-60 characters per line; yes, we are capable of compressing our browser width, but I don't surf the web with a browser opened 1/3 of it's regular size, nor do I know of anyone who does (it hides the mess that is my desktop..) Maybe it's better said like this and here instead of as a link:
- Theornamentalist (talk) 14:46, 6 March 2011 (UTC)The ideal line length for text layout is based on the physiology of the human eye… At normal reading distance the arc of the visual field is only a few inches – about the width of a well-designed column of text, or about 12 words per line. Research shows that reading slows and retention rates fall as line length begins to exceed the ideal width, because the reader then needs to use the muscles of the eye and neck to track from the end of one line to the beginning of the next line. If the eye must traverse great distances on the page, the reader is easily lost and must hunt for the beginning of the next line. Quantitative studies show that moderate line lengths significantly increase the legibility of text.
- <sigh> You most likely "surf" the various wikis after you log-in and under your user name right? - that is why you "see" what you normally see I'm guessing (making most of your observations under those different boxes, OSs, etc. pretty much moot when it comes to defaults, no?).
You may need to put yourself (your cache, your settings, etc.) in the shoes of the annoymous, non-member, never-been-here-before newbie, clicking in from a Google search result or some similar external linkage and then observe "what can happen". IMHO, if one wishes to have an "ideal layout" displayed instead of a bare universal default for all, I think you should continue tweaking your css &/or js files until satisfied rather than tax the potential visitor even before they arrive here. — George Orwell III (talk) 15:31, 6 March 2011 (UTC)
- Regarding how I surf the various wikis, the answer is no. I do read on here too, and I never log in to do so. In fact, I intentionally visit works that I've done to see how they look specifically for the non-contributor. I assure you there is no sarcasm here: what can happen to the annoymous, non-member, never-been-here-before newbie when they first visit? Of course I could simply select "Layout 2" or make a modification to my js files, but that's not solving the problem. What is really taxing about our default is the line length. Just because my en.ws has 50 characters per line does not change the fact that anyone else who comes in here could get hit with double, triple or quadruple that amount.If fr.ws uses a similar approach to what I am proposing in their layout, how come the anonymous French masses aren't crying out? - Theornamentalist (talk) 15:44, 6 March 2011 (UTC)
- I really don't know how to respond to that. I guess I have nothing more to contribute on the matter. Good Luck. — George Orwell III (talk) 15:49, 6 March 2011 (UTC)
- Regarding how I surf the various wikis, the answer is no. I do read on here too, and I never log in to do so. In fact, I intentionally visit works that I've done to see how they look specifically for the non-contributor. I assure you there is no sarcasm here: what can happen to the annoymous, non-member, never-been-here-before newbie when they first visit? Of course I could simply select "Layout 2" or make a modification to my js files, but that's not solving the problem. What is really taxing about our default is the line length. Just because my en.ws has 50 characters per line does not change the fact that anyone else who comes in here could get hit with double, triple or quadruple that amount.If fr.ws uses a similar approach to what I am proposing in their layout, how come the anonymous French masses aren't crying out? - Theornamentalist (talk) 15:44, 6 March 2011 (UTC)
- <sigh> You most likely "surf" the various wikis after you log-in and under your user name right? - that is why you "see" what you normally see I'm guessing (making most of your observations under those different boxes, OSs, etc. pretty much moot when it comes to defaults, no?).
- In order to maintain our notes field and header width, I don't think it would be too difficult to have the works fit to a separate width (see here).I understand the default logically should be very simple in order to have compatibility for a user who happens to come in with a 600 x 480 resolution and size 14 font, among others. But I am truly curious, who has experienced these issues with bizarre formatting on WS? I've used en.ws on many computers, with res and font settings that have left me with roughly 40 characters per line to 350 per line; used windows, mac, and 4 different browsers. I have not seen anything not working properly, or the sudden disappearance of headers because of a fixed width. This is not to say that it couldn't happen to someone, but I can't imagine what they would need to have in order to not see en.ws in a way suitable for reading. George, how did you make the header contract on fr.ws? It seems to be a fixed width, not percentage based or something. Regardless of any of formatting and compatibility issues, it is still recommended for have only 40-60 characters per line; yes, we are capable of compressing our browser width, but I don't surf the web with a browser opened 1/3 of it's regular size, nor do I know of anyone who does (it hides the mess that is my desktop..) Maybe it's better said like this and here instead of as a link:
- Absolutely Right - but the point I was going to eventually extract from that labored line questioning is that the fr.WS uses a completely div based header that never seems to incorporate the light blue header notes field & all it's recent trimmings while we use a table based header married to the the light blue notes field. Their header expands and contracts (heck even disappears if you maximize or minimize your browser window too much at once) effortlessly with whatever layout you choose or come up with while ours is tossed about much like a brick in washing machine - made worse by the uneven sizing of the blue notes field at times in relation to the green navigation field. That, I believe, is more the issue with the display one may or may not be seeing than any margin or width settings are and how ugly those might be to some.The fact dynamic layouts are enabled and replaces that "keep it simple default" under certain conditions rather than leaving the feature off until enabled by the user is a whole other matter. — George Orwell III (talk) 19:17, 5 March 2011 (UTC)
- With regard to the default, the current default, it truly is the vanilla ice-cream version. No width or right margin inhibitors, and allows users to easily stretch or shrink their browser to suit. That should always be the default so it works on all browsers, on all screens from 4 inch to 36 inch. After that go for your life with the number of options that are presented. The issue is that we have seen so many issues with different browsers and their standard and non-standard responses to pages, coding, etc. that the default has to fit into the Keep it Simple model, and allow obvious choice from their, and then when someone has their preference that the option becomes sticky for them, or maybe for their browser on that apparatus. — billinghurst sDrewth 13:01, 5 March 2011 (UTC)
- Ok I looked at your example on fr.WS and, for argument's sake, agree that it looks better than most that I've been seeing here. Maybe you can help me find some more examples for continued comparison - I can't readily locate such a rendering that also has header-notes (brief additional text within a light blue field found directly under the main green navigation portion of a typical header) present; can you? — George Orwell III (talk) 03:22, 5 March 2011 (UTC)
Okay, what I meant to say is that if a similar approach to viewing text exists on fr.ws and there hasn't been any apparent issues with usability for logged in and non logged users, how come we are concerned with it hypothetically? The model already exists. And the other question I had regarding the first visit for non-contributors, I haven't seen any major issue myself in various settings and OSs. - Theornamentalist (talk) 15:54, 6 March 2011 (UTC)
- A nutshell: The reader can change the font-size, the width, and the layout to their own preference; there are buttons and commands in browsers and modern devices, one popular device only needs to be rotated through 90 degrees to get a 'book view'. When I'm on wide-screen I have the benefit of putting two windows side-by-side, very useful for lots of reasons, though some of that valuable real estate is already taken up with the sidebars of the sister sites; allocating space for white-space (nothing) is especially abhorent in this circumstance.
There is no way of setting a width of "about 12 words", even if that were desirable, unless things like font-size is also imposed.This is about user's preferences, not any individual idea about what is good for everyone else. Anyone reading, not surfing, can and will make these adjustments, if they are too stupid to do that they are beyond help. The additional scrolling or page downs also interferes with comprehension, the user has to keep finding their place. The imposition of width begets all sorts of problems, the 'benefit' of a top-down solution ignores the fact that human brains find a solution that avoids labour. If it is 'wrong' for them they can and will change it. If they are ignorant of a device's main functions, they can select a layout from the sidebar. Our business is transcribing essential formatting: if a user is more interested in looking at a text and wringing their hands at the presentation, rather than adjusting their preferences (and reading), they can take the suggestion above and go to the scan. The only loser is the user who wants to "enforce" and override everyone's settings. CYGNIS INSIGNIS 16:05, 6 March 2011 (UTC)
- Well, according to this website, we can set page width using the width of a capital M (em) which can finely tune to a specific character/word count per line. Also, every source I've seen suggests a a much smaller width then what generally occurs upon using our default. IMO, it is certainly our responsibility to present our work in an optimal format; why spend so much time working on this if it is difficult to read? This page is an example with using em's for width; try changing your font settings. - Theornamentalist (talk) 16:52, 6 March 2011 (UTC)
- Here's a successful "page" width in action. I found that the number of em-widths (width of a capital M) that are roughly approximated to 60 characters per line is 30. Justified and centered text are a personal preference, but I think that this is how text should appear default; in a range that is optimally presentable and readable for users. - Theornamentalist (talk) 01:38, 9 March 2011 (UTC)
- And I would think that successful is decidedly POV. I do hope that you plan to free that work from its constraints as it is not how I wish to read it. — billinghurst sDrewth 05:28, 9 March 2011 (UTC)
- I agree. Although in general I prefer Layout 2 because I like to reach each line in one glance, the enforced layout in Here's a successful "page" width in action is too narrow; the lines are much shorter than I can encompass in one glance. This makes for disjointed reading. Please give the reader the flexibility to decided what is comfortable for that person. Mattisse (talk) 03:35, 11 March 2011 (UTC)
- We can't have the perfect length for everyone, but capping off the default width seems beneficial to all, especially for those who stumble upon en.ws and don't wish to resize their browser, font size, etc. - Theornamentalist (talk) 04:03, 11 March 2011 (UTC)
- I agree. Although in general I prefer Layout 2 because I like to reach each line in one glance, the enforced layout in Here's a successful "page" width in action is too narrow; the lines are much shorter than I can encompass in one glance. This makes for disjointed reading. Please give the reader the flexibility to decided what is comfortable for that person. Mattisse (talk) 03:35, 11 March 2011 (UTC)
- And I would think that successful is decidedly POV. I do hope that you plan to free that work from its constraints as it is not how I wish to read it. — billinghurst sDrewth 05:28, 9 March 2011 (UTC)
- Here's a successful "page" width in action. I found that the number of em-widths (width of a capital M) that are roughly approximated to 60 characters per line is 30. Justified and centered text are a personal preference, but I think that this is how text should appear default; in a range that is optimally presentable and readable for users. - Theornamentalist (talk) 01:38, 9 March 2011 (UTC)
It looks like we can agree that it would be best if registered users could choose their desired default layout as a user preference, and that the layout links in the sidebar remain for anonymous users. But that leaves two issues:
- Which layout should anonymous users see by default?
- Until editable as a user preference, which layout should be the default for registered users?
I am not suggesting, and nor do I think it wise to suggest, that any user be prevented from choosing any non-default layout. Thus, hard coded line widths are not a good solution. Same thing for templates like Template:USStatCols start.
Nonetheless, our library exists for the sake of readers, not editors. It's foolish for a restaurant owner to say "I don't care if my new customers don't like my food – I like it, and that's what matters." Let's make sure we're not doing the same thing here by unnecessarily complicating a new reader's experience.
I don't think a reader who prefers a narrow band of text and yet chooses not to resize his browser (whether out of laziness, ignorance, or other reasons) is "stupid"; I suspect that it's normal. Users might not change browser size because they use many tabs, or because they like consistency, or because they don't want to be distracted by other open windows, or because they have customized toolbars, or who knows what else. The point is that there are many good reasons for a new reader to leave wikisource (and find a pdf, etc.) rather than adjust browser size.
Unlike Wikipedia, our text is often not broken up by images and text boxes, so readers see long lines of text much more frequently here than there. In the print world, large works like bibles and dictionaries and encyclopedias avoid this problem by using multiple column formats in order to reduce line length and make reading easier. The fact that this multi-column format is universal among such works indicates at minimum that most readers are used to it, and more likely, that they prefer it.
This should not be an argument over which view is "best"; obviously that depends on each individual's preference. But just like we attempt to simplify editing for new editors, we should attempt to simplify reading for new readers. We ought to make layout 2 (or something similar) the default view, while allowing more knowledgeable users to choose a different view at will. —Spangineer (háblame) 15:32, 9 March 2011 (UTC)
- The work that I listed above is hardcoded only for an example; I meant to say it was successful in using "em" as width, which I did not know I could do, and in that it could generally keep the suggested characters per line (say.. 40-80) consistent regardless of pixel width (which can fail if the font is either too large or small) and font size (which can fail if the screen is either large or small). How we establish a definite value to default upon arrival, I do not know how to decide upon, but I think that this is the way we should be going. - Theornamentalist (talk) 00:42, 10 March 2011 (UTC)
I agree that users should have control of their desired layout. What I propose is this: We should provide some kind of World Wide Web-based interface to HTML versions of our works, so that users are able to display those works in a popular application called a Web browser. As I understand it, all modern Web browsers offer their users complete control over the key points of layout, such as font size and page width. Apparently it is trivial to change these things in your Web browser, and the Web browser will respond by laying out the text in accordance with your settings, wrapping lines at just the right places, and even justifying the text for you if you want! In fact, it's my understanding that the whole point of HTML is to decouple content from layout, allowing us to serve textual content without having to worry about how our readers will choose to lay that content out. What a brilliant idea! I really think we should get onto this whole World Wide Web idea, it is going to be the next big thing. Hesperian 01:06, 10 March 2011 (UTC)
- Wow, okay. Please pardon my ignorance, and forgive me for thinking that actual user behavior, and not just the intentions of programmers, might be an important consideration. What's the point of this project again? —Spangineer (háblame) 02:06, 10 March 2011 (UTC)
- Ah, my sarcasm has offended. I apologise. I find sarcasm can be a persuasive device at times, if used with care, but clearly I failed dismally this time. Again, I am sorry.In response to your comment about 'the intentions of programmers', I would say that what is being advocated here is that we build a tool to support limited layout flexibility, on top of a framework that has superior layout flexibility already built in. Layout flexibility is the raison d'etre of HTML, and we're assuming our readers will ignore that, stalwartly refuse to resize their browser windows, and instead look for sidebar buttons that will let them cycle through a limited number of fixed layouts. If the fact that our readers already have fine-grained control over window width and font size can be dismissed as 'the intentions of programmers', what cannot be dismissed in this way? Hesperian 02:28, 10 March 2011 (UTC)
- I don't disagree that the browser/HTML combination offers amazing flexibility. My point is that while computer geeks the world over will tell you how "trivial" something is, and how easy it is to completely customize your software experience, I contend that most users don't do it and won't do it. Neither are they likely to click a layout button in the sidebar – hence this discussion about the default. Of course, I don't have data, only anecdote, so we're at an impasse; readers by definition aren't involved in this discussion.
- If there's an argument to be made that layout 2 looks crappy on iphones, or that it breaks for xyz browser/OS combination, great, that's helpful information regarding reader experience. That's what should be an end goal: improved reader experience. In the absence of hard data, I'm arguing that readers have spoken and their voice is reflected in a century of printing conventions. So if there's a way to default to shorter line lengths without seriously impairing viewing or customizability for anyone, I don't see a downside.
- Maybe one of my premises is wrong, or perhaps I'm failing to consider something, but the fact that brilliant programmers invented an powerful programming language and an amazing piece of software isn't relevant unless its users (our readers) actually use those capabilities instead of just looking for what they want on Google books instead. Who knows, perhaps they are resizing Wikisource windows, but I doubt it... —Spangineer (háblame) 03:22, 10 March 2011 (UTC)
- All your sarcasm aside, I don't change my browser width, and I rarely play with font sizes. Most sites are set up with broad enough margins and reasonable enough defaults that I don't have to.--Prosfilaes (talk) 05:17, 11 March 2011 (UTC)
- Not Project Gutenberg. Not Project Gutenberg of Australia. Not the vast majority of sites randomly browsed from http://onlinebooks.library.upenn.edu. Not the stories at my local news site at http://www.abc.net.au/news/. But yes to the New York Times, yes to most blogging sites, yes to facebook. The common factor in the yes's is that they actually have lots of content to promote, and make liberal use of sidebars in doing so. I don't think there are sites out there just throwing away screen real-estate in unused margins. Hesperian 06:13, 11 March 2011 (UTC)
- Another common factor in the yes's is that they are for-profit, which means they have a greater incentive to respond quickly to the preferences of their users. Regarding the "waste" argument, unused != waste. Our goal should be to present text in a readable way without requiring the user to perform gymnastics. Our goal should not be to slam as much text into a page as possible – and only with such a goal is unused real estate a "waste." —Spangineer (háblame) 14:39, 11 March 2011 (UTC)
- I can handle Project Gutenberg's website without changing the margins. I don't see what you're saying about http://www.abc.net.au/news/; not only do most of the stories start at 6-7 words wide, increasing out to 20 below related stories, on my screen there's empty two inch margins on both sides of the screen. As for the books, the first one I looked at [4] had pretty narrow margins. A lot of them don't, but it's clearly not universal.--Prosfilaes (talk) 18:13, 11 March 2011 (UTC)
- Project Gutenberg, from my understanding, is the bare minimum intentionally. We have scans, more options for text formatting, hyperlinks and on and on. We are not the bare minimum; although I think we should offer that too, maybe finally allowing .txt files to download unformatted plain text for the works. Using PG as comparison is not right; it's means to providing content is somewhat different; at greatest length by our index/proofreading feature. I clicked on 10 different works, and for whatever reason, all led back to PG.. And the news site, like it has been said above, they have caps on line length generally! It seems to be a fixed width using pixels, but I'm not too sure; and it is set right around what is recommended by the source found below. - Theornamentalist (talk) 23:25, 11 March 2011 (UTC)
- Not Project Gutenberg. Not Project Gutenberg of Australia. Not the vast majority of sites randomly browsed from http://onlinebooks.library.upenn.edu. Not the stories at my local news site at http://www.abc.net.au/news/. But yes to the New York Times, yes to most blogging sites, yes to facebook. The common factor in the yes's is that they actually have lots of content to promote, and make liberal use of sidebars in doing so. I don't think there are sites out there just throwing away screen real-estate in unused margins. Hesperian 06:13, 11 March 2011 (UTC)
I have a feeling that this probably is not how most of us edit: although I prefer "layout 2," I keep it at default; I always have the incoming reader in mind and want to see it how they do; therefore, I always use the full page width layout, although I dislike it. I want to say that again, I have roughly 200-225 characters per line in my browser, and no, I'm not going to change my font setting just so en.ws looks good, and like most people (that at least I am aware of) I keep a full browser open, and not just a portion. Especially with reading a book, visual distractions should be removed, and splitting windows or revealing desktop or other programs is not immersion into the text. Those are my opinions and habits, here's what the experts say about characters per line:
- 50-60 Advertising design and typography By Alex W. White
- 45-75 Web style guide: basic design principles for creating Web sites
- 60-72 The Christian Writer's Manual of Style
- 50-60 The elements of graphic design: space, unity, page architecture, and type
- 45-75 (66 ideal) The Elements of Typographic Style Applied to the Web
- 50-60 in type: the practical philosophy of typography
- 65 Printing it: a guide to graphic techniques for the impecunious
Theres more, but that's what Gbooks gave me. I'm not saying we jump conservatively down to 45 CPL, but it seems like we need to put some cap on it. - Theornamentalist (talk) 22:08, 10 March 2011 (UTC)
- What do these sources have to say about margin width? Show me a source that says it is okay to waste 50% or more of your space in ultra-wide margins. Hesperian 01:22, 11 March 2011 (UTC)
- Oddly enough, they don't address that. But convention tends to either increase the font size to meet the standard range of CPL or introduce multiple columns per page, if that helps. - Theornamentalist (talk) 03:18, 11 March 2011 (UTC)
- I agree. But I don't see anyone advocating 'default' layouts that make use of increased font sizes or multiple columns. As far as I can tell, what is advocated is the ability to set a work to a 'default' layout that constrains line width by setting ludicrously wide margins. This approach is, I think we agree, utterly unconventional—convention offers no precedent for such extreme wastage of real estate—so we can dismiss any argument that makes recourse to 'conventional' line widths. Hesperian 03:39, 11 March 2011 (UTC)
- The difference, of course, is that the wide margins don't cost us anything; if wikimedia ever goes for-profit, we'll be ahead of the curve. I am not saying that it isn't wasteful of space, in fact, I never have. My point has been to show that there is a convention for characters per line, and it is based off of what readers prefer, what they are used to and what may be the most comfortable to read (see here for quote). However, there are things which may occupy the spaces to the right and left, and thus not some of the space go to waste; this includes illustrations, which I read Thomas was working on but seems to have dropped, which would allow for no interruption in text separated by a page with an illustration, those boxed ref's/notes, to which I can't recall the name and have only seen them in passing, maybe even the ever increased height header, with its plain sister of potentially 4 rows of portals, authors, sister sites and the proposed shortcut. Perhaps a table of contents, if not appearing in the work could appear fixed on the left side for easy navigation? These are simply ideas, and I do not submit them for consideration at the present discussion. - Theornamentalist (talk) 03:57, 11 March 2011 (UTC)
- What it comes down to is this:
- The difference, of course, is that the wide margins don't cost us anything; if wikimedia ever goes for-profit, we'll be ahead of the curve. I am not saying that it isn't wasteful of space, in fact, I never have. My point has been to show that there is a convention for characters per line, and it is based off of what readers prefer, what they are used to and what may be the most comfortable to read (see here for quote). However, there are things which may occupy the spaces to the right and left, and thus not some of the space go to waste; this includes illustrations, which I read Thomas was working on but seems to have dropped, which would allow for no interruption in text separated by a page with an illustration, those boxed ref's/notes, to which I can't recall the name and have only seen them in passing, maybe even the ever increased height header, with its plain sister of potentially 4 rows of portals, authors, sister sites and the proposed shortcut. Perhaps a table of contents, if not appearing in the work could appear fixed on the left side for easy navigation? These are simply ideas, and I do not submit them for consideration at the present discussion. - Theornamentalist (talk) 03:57, 11 March 2011 (UTC)
- I agree. But I don't see anyone advocating 'default' layouts that make use of increased font sizes or multiple columns. As far as I can tell, what is advocated is the ability to set a work to a 'default' layout that constrains line width by setting ludicrously wide margins. This approach is, I think we agree, utterly unconventional—convention offers no precedent for such extreme wastage of real estate—so we can dismiss any argument that makes recourse to 'conventional' line widths. Hesperian 03:39, 11 March 2011 (UTC)
- Oddly enough, they don't address that. But convention tends to either increase the font size to meet the standard range of CPL or introduce multiple columns per page, if that helps. - Theornamentalist (talk) 03:18, 11 March 2011 (UTC)
Reader wants | |||
---|---|---|---|
Full width text | Constrained width text | ||
We provide | Full width text | Reader is happy | Reader can increase font size and/or reduce browser window width |
Constrained width text | Reader is fucked. | Reader is happy |
- Setting a width is taking away reader options. You guys are saying '/I/ want constrained width, and /I/ can't be bothered resizing my browser window, so lets force /everyone/ to have it the way /I/ want it.' Hesperian 00:02, 12 March 2011 (UTC)
- You need to contribute more like this. Bravo. — George Orwell III (talk) 00:07, 12 March 2011 (UTC)
- The user can change the layout just as they can now, only difference is that the default is set differently. Our current default, against any suggested line width, is obscenely long. I don't think anyone likes reading 150-200 characters per line. I am genuine with this: maybe I am wrong. It's really been like this for me: I thought to myself, "Wow, these lines are very long; it's kind of difficult to seamlessly move to the next line, I think it might be easier if we had less characters per line." Then, in looking up in some books, "Wow, it seems that this subject has been addressed before, even decades ago; and they are kind of saying the same thing: there is a range in which the CPL is optimal. Wikisource does not address having this range for its works, in fact, there's no cap on CPL... and with the ever-enlarging screen width and pixelation we should probably do something about it.." That's the order of events. - Theornamentalist (talk) 00:34, 12 March 2011 (UTC)
- "The user can change the layout just as they can now, only difference is that the default is set differently." And how am I to change to window-width text if the default is constrained-width? Certainly not by adjusting my window width. Do you mean by cycling through a limited number of options until I find something tolerable?
- "Son, your mother and I have decided that you can't be trusted to choose your own wife, so we are going to go out and find someone suitable for you. But we know you like to have your freedom to make your own life choices, so what we're going to do is find you three candidates we approve of, and you'll be completely free to choose whichever one you want. And to make sure that you have genuine choice, we'll be sure to pick you out a blonde, a brunette and a redhead. Happy, son?"
- Hesperian 01:12, 12 March 2011 (UTC)
- "Son, your mother and I decided not to force you to speak our language. We now know that you will likely never be able to speak a language, but aren't you glad you had the choice?"--Prosfilaes (talk) 01:19, 12 March 2011 (UTC)
- The user can change the layout just as they can now, only difference is that the default is set differently. Our current default, against any suggested line width, is obscenely long. I don't think anyone likes reading 150-200 characters per line. I am genuine with this: maybe I am wrong. It's really been like this for me: I thought to myself, "Wow, these lines are very long; it's kind of difficult to seamlessly move to the next line, I think it might be easier if we had less characters per line." Then, in looking up in some books, "Wow, it seems that this subject has been addressed before, even decades ago; and they are kind of saying the same thing: there is a range in which the CPL is optimal. Wikisource does not address having this range for its works, in fact, there's no cap on CPL... and with the ever-enlarging screen width and pixelation we should probably do something about it.." That's the order of events. - Theornamentalist (talk) 00:34, 12 March 2011 (UTC)
- You need to contribute more like this. Bravo. — George Orwell III (talk) 00:07, 12 March 2011 (UTC)
- Setting a width is taking away reader options. You guys are saying '/I/ want constrained width, and /I/ can't be bothered resizing my browser window, so lets force /everyone/ to have it the way /I/ want it.' Hesperian 00:02, 12 March 2011 (UTC)
Reader wants | |||
---|---|---|---|
Blinking text | Non-blinking text | ||
We provide | Blinking text | Reader is happy | Reader can turn off blinking or use a better browser |
Non-blinking text | Reader is fucked. | Reader is happy |
- It's wonderful to have things as flexible as possible, but when people are no longer using this site, because it forces them to screw with their browser to work right, flexibility came at a cost of making a site people want to use.--Prosfilaes (talk) 01:19, 12 March 2011 (UTC)
- RE: Hesperian - What we have currently is 3 layouts available to switch between; one which is free of width parameters; one which uses a sans-serif font and pixels to set width, and one which places the header on the right, thus creating a column on the right empty of content. The first is much like en.wp, the second like fr.ws and the third like de.ws, and each are successful models. What I meant by using a different default and allowing for others to change the layout based on preference is not much different from how they function now; almost literally starting off at something similar to the current layout 2, and allowing the user to cycle to other ones if so desired. What I am proposing (which IMO is the best solution but not necessarily what we are discussing) is the use of "em" for defining width. The books say to set within a certain range, roughly 45-75 on average, which (WARNING: ORIGINAL RESEARCH AND UNSOURCED INFORMATION) is representative what the general population, or majority, prefers to use. The outliers may prefer reading 10 or 200 CPL. As of now, we are catering to the reader who prefers a large line length by default, when in my opinion we should be catering to the bulk of the population. So with modifying our default, there will be a higher probability that the user will want what is deemed an "average" line length. The outlier can cycle through our layouts to find which they prefer. - Theornamentalist (talk) 04:49, 12 March 2011 (UTC)
- See here - I've made a page for comparison. Change your font settings, window size, resolution, browser. In maintaining the range suggested, the most consistent is "em," which is mostly immune to changes in to any of the settings I listed. - Theornamentalist (talk) 14:26, 12 March 2011 (UTC)
- Option 2 is not sans-serif, it's serif, at least on my machine it's the other two that are sans-serif. Just to make sure we're not seeing things differently. ;)
- Also Option 3 doesn't display well when there are maintenance templates.--Doug.(talk • contribs) 11:47, 13 March 2011 (UTC)
- RE: Hesperian - What we have currently is 3 layouts available to switch between; one which is free of width parameters; one which uses a sans-serif font and pixels to set width, and one which places the header on the right, thus creating a column on the right empty of content. The first is much like en.wp, the second like fr.ws and the third like de.ws, and each are successful models. What I meant by using a different default and allowing for others to change the layout based on preference is not much different from how they function now; almost literally starting off at something similar to the current layout 2, and allowing the user to cycle to other ones if so desired. What I am proposing (which IMO is the best solution but not necessarily what we are discussing) is the use of "em" for defining width. The books say to set within a certain range, roughly 45-75 on average, which (WARNING: ORIGINAL RESEARCH AND UNSOURCED INFORMATION) is representative what the general population, or majority, prefers to use. The outliers may prefer reading 10 or 200 CPL. As of now, we are catering to the reader who prefers a large line length by default, when in my opinion we should be catering to the bulk of the population. So with modifying our default, there will be a higher probability that the user will want what is deemed an "average" line length. The outlier can cycle through our layouts to find which they prefer. - Theornamentalist (talk) 04:49, 12 March 2011 (UTC)
- It's wonderful to have things as flexible as possible, but when people are no longer using this site, because it forces them to screw with their browser to work right, flexibility came at a cost of making a site people want to use.--Prosfilaes (talk) 01:19, 12 March 2011 (UTC)
<Sigh>. I can play the red herring game too: You guys are saying '/I/ want as much text as possible slammed into the browser window as possible, and /I/ can't be bothered to click the sidebar layout link, so let's force /everyone/ to have it the way /I/ want it.' Funny how that works. Just like the previous red herring argument, it completely ignores the subjects at hand (which view is preferable to most readers, and the relative ease of various methods of view customization). If your goal is victory by attrition and absurdity, congratulations. —Spangineer (háblame) 13:59, 14 March 2011 (UTC)
- Exactly; it boils down to:
- In general, default browser, resolutions and font settings, whatever their combination, result in a line length that is greater than the range suggested by published and reliable sources.
- I would love to hear other opinions from users on the site, the handful of us here have already drawn lines, some of us tables, and billinghurst, no matter how fancy or profoundly simple of a table you make can convince me otherwise ;) Can we bring this to the next level... vote? - Theornamentalist (talk) 20:48, 15 March 2011 (UTC)
- No table of mine; me thinks that you misread the bringer of the opinion. With regard to a vote, it is not how we generally have progressed matters here. More about consensus, and moving along with where we do agree, and nutting through where we do not. At this point, a vote would seem to be divisive, rather than resolutionary. I would think that looking at proposed solutions and implementing and testing. Billinghurst (talk) 03:58, 16 March 2011 (UTC)
Concluding the "I have an opinion" component. There is no disagreement that width options should be available, and it is the means to do this. The proposal for a fixed width based on existing layouts has no consensus, and that to me sounds like I can present the following summary and challenges for presenting solutions, rather than more opinions.
- Proposed solutions
- more layout options
- this can be done now, develop it somewhere, and an administrator can put into the test layout facility, and commentary can be made at new part MediaWiki_talk:Common.js/layouts which currently transcludes to the parent talk page
- users modify browser width
- users can do this now
- ability for users to be able to set their own default option
- needs a someone with programming skills to create the gadget and possibly modifications that allows a default to be set
- setting a different default option
- options have been proposed, and there is no consensus that there is a solution in existing layouts; this would indicate that the above solutions are more sophisticated, see solution 1.
Billinghurst (talk) 03:47, 11 March 2011 (UTC)
Library transcriptions
I've just been doing some preliminary research for sources for an article on Wikipedia. A fair few of the sources are short: tracts, pamphlets, leaflets etc. They are out-of-copyright (19th century) and are in the British Library. But I'm guessing they probably are not scannable: the BL take rather a harsh view on scanning, unless you get their imaging services to do it. And that costs money, and you cannot reuse the images you get from that as the BL enforces a copyright on the reproduced image of the work.
But, hypothetically, imagine if a group of Wikipedians with reader access to the Reading Rooms at the British Library were to request out-of-copyright works and transcribe them then and there (with laptops, straight onto Wikisource). I plan to ask the British Library about the legal issues with this: the only thing I see being a problem is that the Conditions of Use of the London Reading Rooms s.25 states:
- Copies of Library collections must only be made using Library copying facilities.
I am not sure whether the 'Copies' they are referring to mean photographic/photocopy-type copying or whether copying a whole document by typing it into a computer or writing it down long hand and then typing up the long hand copy into a computer counts as 'Copies' in the meaning of these conditions.
Anyway, subject to clarification of the meaning of that, and the copyright status of works copied by hand in the British Library by a reader, can anyone confirm what the situation is with Wikisource? From my readings of the site policy, the issue is simply whether or not the works are verifiable. They aren't verifiable in the sense that you can go and read a djvu or pdf file of a scan, but they are sort of hypothetically verifiable: if you go to the British Library, get a reader pass and request the item from the archive, you can then read the document and compare it with the Wikisource copy. In terms of the metadata, that is obviously verifiable because you can check it online against the Integrated Catalogue. Thoughts? Tom Morris (talk) 23:47, 5 March 2011 (UTC)
- I think that the best leverage is through Wikimedia UK who have been doing much work in this space. See their support us idea. Re verifiability, yes and we use {{textinfo}} on the article's talk page to capture those details. Re Wikisource one person's transcription is proofread once, and then needs a separate person to access in situ and proof the work to get it through twice. Possible to be done. Though with those difficulties you can see why we encourage and like djvu files and Help:Proofread. — billinghurst sDrewth 00:34, 6 March 2011 (UTC)
I've inquired further into the British Library policy and legal side of it and posted up the results here: British Library and Wikisource: copyrights and permissions. Tom Morris (talk) 13:33, 8 March 2011 (UTC)
- After reading your blog, my comments are … That is conditions of use of BL, not copyright management. I would hazard a guess that §25 of their rules has been in that form or similar for an extended period and it is just easier to give it a tick every time they review things. They have a general rule in place as it is easier to set a restrictive rule that covers all scenarios and works, and it is easy to do a vague encompassing rule than get into specific detail with lots of IF BUT statements. Remember that they do have works of value and of copyright that they do wish to protect, and not all users have scruples. If I was in a similar circumstance, I would think that with a little research you can choose a book that will not be damaged by photography and laying open, and put a proposal (formal and written snail mail to a power-broker and decision-maker at BL) to how you would like to photograph the work, the equipment that you will use, and how it will not disadvantage or disturb any other users. Call it a pilot/proof-of-concept, and something for them to judge how the process cor/will work and then see how it proceeds. It is easier to say no than to review the rules; but it is easy to look to approve a pilot when it is non-threatening and has wider benefits.
- Tom, I don't know if you were involved in any of Wikimedia UK's collaborations with the British Library but I'd strongly suggest you make contact with Mike Peel as I'm sure he'll be very interested to help. The Land (talk) 13:04, 15 March 2011 (UTC)
Demetrius Charles Boulger
This author has many good books, which are all out of copyright and we could use them. Would someone be willing to make an index file for me (and the community) to proofread? - Tannertsf (talk) 16:38, 7 March 2011 (UTC)
- Author page Demetrius Charles Boulger establish (without much research - hope that counts as an index file). Identified 7 works by the close of the Victorian era. Have located djvu file of The Story of India published 1897, the second part of five found in the Empire Series and will have that index page available tomorrow. JamAKiska (talk) 19:41, 7 March 2011 (UTC)
- Add to that the The History of China too. JamAKiska (talk) 20:05, 7 March 2011 (UTC)
Ok. Thank you for making the author page.(I assumed we would need that if we were going to host many of his works. China doesn't have to be the first one on here though, because I'm reading it (Kindle, 3% of the way through) and am not going to heavily work on it until i finish the book. But still, kudos to you for helping me out on this. - Tannertsf (talk) 22:17, 7 March 2011 (UTC)
- Please consider the author page a rough draft of highlights by this author and continue to add to it as you see fit. There seems to be demand for this author's material. The author page seemed like a great location to store his works. Quite a bit of material on WS, commons and embedded in several WP articles which led me to India. Sounds like you are running cooler on The History of China. The original, published as two 500+ page volumes in 1898, and the Short History of China published in 1900 (merely 500 pages). Both complete versions are available for upload (might be a bit much huh…). Also found England and Russia in Central Asia published in the late 1870's. Wanted to find the biography on Gordon as I recall seeing that in some of my earlier readings. I’ll leave the background notes on the author page as events unfold. If you have a specific request use the notes there if you find that more convenient. For the time being, I’ll hold off on China and upload the other two for starters. As for the index page, will organize with similar level of detail as the Thames pending a better alternative… Good luck…JamAKiska (talk) 02:13, 8 March 2011 (UTC)
- Plus bits more on the author pages. For files that you upload and for which you create index pages, please do add them to the author page utilising {{small scan link}}. Thanks. — billinghurst sDrewth 06:54, 8 March 2011 (UTC)
Announcement
I am sorry to announce that with my adding of Fighting Off Aviators with Shotguns this evening, there is no point to any of you continuing work on the project. We have reached the pinnacle of awesome articles. That is all. No seriously, what are some of the most fun articles you've added?
:) StateOfAvon (talk) 04:07, 8 March 2011 (UTC)
Be careful here...you can't just throw stuff on here that's not correctly sourced to the right index, etc. Im just saying it looks fishy, and to warn you. - Tannertsf (talk) 04:16, 8 March 2011 (UTC)
- It is from Index:Popular Science Monthly Volume 92.djvu and while we will host it under the Popular Science Monthly banner, we do encourage the creation of redirects from the main level to the article, though know that they may become disambiguation articles in time if other works of the same name exist. Though that sounds unlikely on this occasion. With regard to fun, we are too silly and boring to understand fun, we hear that it is all happening at wiktionary where they pull our works apart and analyse them word by word. Accordingly we have been holding some old works back just so they don't have a complete set. — billinghurst sDrewth 05:58, 8 March 2011 (UTC)
Yes, I just realized that. My mistake...I thought he was just goofing off when I saw the title. All apologies. - Tannertsf (talk) 06:09, 8 March 2011 (UTC)
- You weren't the only one. :-) I probably have a bit more familiarity with the site, and so I noticed a thing or two extra that made me dig deeper.<shrug> No harm done. — billinghurst sDrewth 06:55, 8 March 2011 (UTC)
- With regard to awesomeness, "Death and extermination to all whales" hits the mark for me. CYGNIS INSIGNIS 08:29, 8 March 2011 (UTC)
- Haha, that is indeed a nice title compared to the "Save the Whales" rhetoric...very nice, I may need to find something to break the tie...consider the challenge laid down ;) StateOfAvon (talk) 19:46, 9 March 2011 (UTC)
Wikimedia email server problems?
I am getting email from other sources without any problems, but email notifications from here, and elsewhere on Wikimedia, are dated back to early February. Is, or was there a problem on the Wikimedia mail server system? — Ineuw talk 23:27, 8 March 2011 (UTC)
- Yes, or maybe that is "there was". — billinghurst sDrewth 05:10, 9 March 2011 (UTC)
Thanks. Now I can rest easily. :-) — Ineuw talk 05:57, 9 March 2011 (UTC)
Commons: Innovations for enWS users to note
I just wanted to bring to the attention of those who may have missed these innovations at Commons:
- the creator namespace, akin to our Author ns; and it uses {{Creator}} (there is a preload facility)
- {{Book}} for use with books, and more informative than
{{information}}
and more akin to the detail that we complete for the Index: namespace.
At some point it would be really nice if we could get some means for Creator: <-> Author: ns, and Index: and {{book}}
intercommunication for data extraction. — billinghurst sDrewth 13:24, 9 March 2011 (UTC)
Homeschool community outreach
The thought has occurred to me on a couple occasions that this site would probably appeal to the homeschool community (which numbers in the millions)... What better way to be exposed to classics and public domain materials than for someone's kids to contribute to the stores here via daily "copy work"! This site would benefit, and the students would benefit. Perhaps even add a homeschool portal/page with get started/basics instructions/links for "newbies", links to current classics (even translations for students learning foreign languages) or other works-in-progress here that might be appealing to homeschoolers... (Think Facebook pages, etc. too...) Just a thought—after having read the recent Wikimedia message... Londonjackbooks (talk) 13:18, 11 March 2011 (UTC)
- Ah, a cunning plan to acquire cheap proofreading labour! :) Well, it would be cheap if we actually paid anyone. Seriously, though, would we need to set aside some scans for this? (Possibly grading them in some way - easy/hard etc). Would any scans be OK or should we have a prepared list? As readers, what sort of texts would you want to present? We could probably get primary or secondary level reading list and add as many as possible (maybe with the
labourpupils). Is there anything else? Do we need things like textbooks (I actually looked once and couldn't find any here, besides which any we have might be out of date) or do we just point to Wikibooks? On top of all of this, it would need promotion to the parents of home-schooled children. Hopefully someone knows how to do that (I'd imagine Wikimedia might have someone who could help with this). I would suggest breaking the ice as "Wikipedia's library" and let them find out the name "Wikisource" later. - AdamBMorgan (talk) 21:54, 11 March 2011 (UTC)
- Just my personal biased opinion, but the idea of "assigning" levels (primary, secondary, etc.) to texts makes me cringe... As do "assigned" reading lists... But that is me. I don't think much effort on the part of WS (you all) would be involved at all, and that parents/guardians-as-teachers would be able to discern what would be appropriate for their children/students. Merely pointing to some texts-in-progress as you mentioned could of course get the ball rolling for them... Thanks below for getting Wikisource:WikiProject Homeschooling started... I'll chew on some ideas, and I have some friends I can get opinions from... But my initial feeling is that this need merely be a low-maintanence effort on the part of this WS community. The home school community is pretty diverse itself, so gearing a project toward any specific direction may be counter-productive... Thanks for considering! Londonjackbooks (talk) 00:43, 12 March 2011 (UTC)
- The works of people like Charlotte Mason would be a major draw in this instance, likely "hijacking" Portal:Education temporarily to focus on listing/linking many works that would appeal to homeschooling families. At risk of unmasking the man behind the mask, I'd be more than happy to help as long as there's at least one other committed user willing to help set it up and bring in some homeschool groups/families. We could make a Wikiproject,set up a unique {{Welcome-homeschool}} message that includes specific instructions/links, and we could have two or three people who are willing to scramble and help find/upload/setup specific books if families/groups request them, etc. StateOfAvon (talk) 22:07, 11 March 2011 (UTC)
- I can help with technical or organisational bits but I'm not so great with people. I wouldn't have a clue how to bring homeschool group in. So, if you do need help I can, for example, assist with the find/upload/setup bits. - AdamBMorgan (talk) 23:14, 11 March 2011 (UTC)
- Alright, well I went ahead and created Wikisource:WikiProject Homeschooling, if you want to watchlist it and start filling in ideas/requests, finding online textbooks we could add, etc. StateOfAvon (talk) 23:39, 11 March 2011 (UTC)
- Looking great! :) If you build it, they will come! Anxious to see how this develops! Londonjackbooks (talk) 00:57, 12 March 2011 (UTC)
- It'd be great if you'd look on WS, Archive.org, Project Gutenberg, and find nice "textbook" examples we could list up here StateOfAvon (talk) 01:00, 12 March 2011 (UTC)
- We might want to be careful about not leaning too heavily in one direction or the other with regard to pro-state or anti-state education works/views. The same could be said with regard to religious works, evolution vs. creation, etc... While I have my own personal preferences, I think it best to let truth speak for itself. Not all homeschoolers are necessarily anti-state, etc., and we may push some people away if we seem to be leaning one way or the other...? Londonjackbooks (talk) 03:38, 12 March 2011 (UTC)
- I think we usually tend towards allowing Portal:Islam to assume it will be catering to Muslims, Portal:Judaism to Jews, etc. That's not to say we don't include works that are anti-Jewish, but that there's nothing wrong with having an image of Moses or some Hebrew ornamental texts or quotes littering the page. StateOfAvon (talk) 03:46, 12 March 2011 (UTC)
- ...Just as long as we know that WikiProject Homeschooling isn't located on Portal:Separation of School and State. Londonjackbooks (talk) 04:15, 12 March 2011 (UTC)
- Speaking of which, we could use a nice image to balance out the "Contents" table which has a lot of deadspace on the right-hand side... StateOfAvon (talk) 03:52, 12 March 2011 (UTC)
- Education quotations in the header area may be a good idea... as long as they change on occasion, and are not too heavily "leaning" this way or that... Perhaps biblical references to education one day, something from John Dewey on another, Kant, Aristotle,... You get the picture... Something akin to Billinghurst's header... Londonjackbooks (talk) 04:44, 12 March 2011 (UTC)
- Added a daily rotating quotation header...More quotations to be substituted at later time. Londonjackbooks (talk) 06:07, 12 March 2011 (UTC)
License for Wikisource logo is disputed
Hi! You may find this discussion interessting Commons:Village_pump#Wikipedia_screenshots_and_licensing_issues. There is a discussion about the logo somewhere in the discussion. Please help find the right place for this notice. --MGA73 (talk) 09:36, 20 March 2011 (UTC)
Link from Page:
I've been working on linking up references from wp; an example being reference 1:
which links to the page:
Although this is not a big deal for this single page clip, I was wondering if we could include a link directly to the mainspace. For whatever reason, there is no link to the index for 1 page djvu files, but even in the case where there is, I think something like "Continue reading this work" or "from A given work" along the top above or below the proofread status bar. This maybe can be achieved by using the "title" parameter in the index page? That way, when a reader has followed a reference here, they can find their way back to the transcluded work easily, as opposed to, in the case of a single page work, having no apparent way back, and in the case of a multi-paged work, not have to navigate (not that it's hard once you know it) using ^ tab or < given work which both lead back to the index, and then click on the "title" link. What do you think? - Theornamentalist (talk) 03:19, 22 March 2011 (UTC)
- I fixed the link at the other place [5]. One can find the main-space tranclusion from the Page: namespace by using 'what links here' in the toolbox. The solution is to link the transclusion in references, not the workspace. CYGNIS INSIGNIS 03:55, 22 March 2011 (UTC)
- I believe that linking to the scanned copy it necessary; I do not wish to ask the reader to trust what we have transcribed; it would be no different then referencing an excerpt of a work within another work; cut out the middle man. It is more of a fundamental thing than anything else. Plus, to link directly to page is nice, in place of potentially setting up a lot of sections within Page: space to link to in mainspace. For larger and notable works, within the Cite templates the pages should be used for referencing, not the title (which should link to the relevant wp article. Regular editors who are aware of "what links here" can use that, but I do not think that that tool is common knowledge to the non-editor. - Theornamentalist (talk) 04:00, 22 March 2011 (UTC)
- cygnis insignis, for the time being, would you mind returning the link to its prior state? - Theornamentalist (talk) 04:01, 22 March 2011 (UTC)
- The transclusion is the same text, the link to verify that is at the left of what ever section or page # you link to: s:Some Work#247. The reader is already provided with links to the workspace/verification from its main presentation.
- Will I make an edit to wikipedia to illustrate a point? No, you would need to do that yourself. CYGNIS INSIGNIS 04:18, 22 March 2011 (UTC)
- Cygnis clearly identifies the accepted practice which has been arrived at from plenty of discussion about this; and surely in the archives of this page. I know that I had parts of your viewpoint, however, the argument was cogent and has convinced me. You have clearly identified one of the issues yourself about why we don't link to the Page namespace directly. For me at WP it is not about trust, it is about verification, and that capacity exists — for the ardent verifier it is a two step process, to main namespace, then to page. For most people, one would think that they just want to read the text, not see a scan of the printed word on the page. Billinghurst (talk) 05:42, 22 March 2011 (UTC)
- Cygnis, it was not very absurd of me to ask you to remove your edit out of courtesy during the discussion. Of course, asking you to required more work than actually doing it myself; it doesn't matter I suppose. Responding: the link is not necessarily the same as the text.To Billinghurst: it just seems odd to me; if some website hosted by "some guy" had plain text of some work, and another page with the original scanned copy of the work, wp users I believe would unanimously say to link to the scan. And we are just a website of "some guys and girls." It is somewhat in the same way that wp can't reference itself, even if what is being referenced in it is in fact referenced. - Theornamentalist (talk) 10:10, 22 March 2011 (UTC)
- Then can we make the discussion about how we give more direction and information about the underlying scans, information about the text and the process, and supporting verification, and not about linking to Page. Is it that we give people the option of turning on thumbnails of the pages? etc.
- What is so wrong with linking to a Page:? We have the scan linkable and ready to go; I see adding thumbnails as being a lot of extra work, when we have the ability to internally view the actual original-non-wiki scan, by page. - Theornamentalist (talk) 21:34, 22 March 2011 (UTC)
- Then can we make the discussion about how we give more direction and information about the underlying scans, information about the text and the process, and supporting verification, and not about linking to Page. Is it that we give people the option of turning on thumbnails of the pages? etc.
- If the majority opinion was in fact to link to a scan rather than transcibed plain text - wouldn't they just prefer a link to the NY Times archives in the first place? — George Orwell III (talk) 10:15, 22 March 2011 (UTC)
- It is my opinion that their are many benefits to linking internally; the primary one being stability (or at least tracibility) among others. - Theornamentalist (talk) 10:56, 22 March 2011 (UTC)
- Right... that's why those pagenums come up under that dynamic view thingy. Anyway, would you like me to add a 2nd page that is blank to this single-page djvu to enable the arrows in the Page: namespace? — George Orwell III (talk) 11:01, 22 March 2011 (UTC)
- It is my opinion that their are many benefits to linking internally; the primary one being stability (or at least tracibility) among others. - Theornamentalist (talk) 10:56, 22 March 2011 (UTC)
- Cygnis, it was not very absurd of me to ask you to remove your edit out of courtesy during the discussion. Of course, asking you to required more work than actually doing it myself; it doesn't matter I suppose. Responding: the link is not necessarily the same as the text.To Billinghurst: it just seems odd to me; if some website hosted by "some guy" had plain text of some work, and another page with the original scanned copy of the work, wp users I believe would unanimously say to link to the scan. And we are just a website of "some guys and girls." It is somewhat in the same way that wp can't reference itself, even if what is being referenced in it is in fact referenced. - Theornamentalist (talk) 10:10, 22 March 2011 (UTC)
- Cygnis clearly identifies the accepted practice which has been arrived at from plenty of discussion about this; and surely in the archives of this page. I know that I had parts of your viewpoint, however, the argument was cogent and has convinced me. You have clearly identified one of the issues yourself about why we don't link to the Page namespace directly. For me at WP it is not about trust, it is about verification, and that capacity exists — for the ardent verifier it is a two step process, to main namespace, then to page. For most people, one would think that they just want to read the text, not see a scan of the printed word on the page. Billinghurst (talk) 05:42, 22 March 2011 (UTC)
Update
I think I have made a happy medium; now I know what you're thinking, "we definitely need another way to link in the references to Wikisource from Wikipedia." Ha, my apologies... but here is another, which I plan to use:
Here is an example of it in the reference section at the bottom of the article: Abel I. Smith Burial Ground
What do you think? - Theornamentalist (talk) 12:20, 26 March 2011 (UTC)
{{DJVU page link}}
Do you have an equivalent template (or some other recommended notation) to be able to link pages (in a TOC) within an index that uses JPG images instead of DJVU?...Such as here? Thanks, Londonjackbooks (talk) 12:52, 22 March 2011 (UTC)
- [brought over from template talk page:] ...it would actually come in handy when in the process of transcribing pages from texts that are unpaginated. Since the link doesn't translate over into the Main, it is at least helpful with Index navigation when proofreading... Londonjackbooks (talk) 13:24, 22 March 2011 (UTC)
some formatting questions
- ...on Stops of Various Quills Index:Talk page... Thanks, Londonjackbooks (talk) 03:17, 23 March 2011 (UTC)
- @Cygnis: Your recommendations have been/are being applied. Example given on Talk page. Thanks! Londonjackbooks (talk) 12:49, 23 March 2011 (UTC)
special character
I cant find a special character that appears twice on a page, perhaps the italic is misleading me; the context suggests it is a phonetic character. This link is to the .jpg, which is clearer than the .djvu file. The word is "ma[?]ther" and occurs in the second sentence of the footnote. Does anyone know what this character is, and is it likely to display if I add it? CYGNIS INSIGNIS 06:56, 23 March 2011 (UTC)
- It is Norfolk dialect, apparently (as "mawther" appears on the linked page—the letter-in-question being a "w")... Maybe there is a "Norfolk font" 'out there' somewhere? Also w:Norfolk dialect. Londonjackbooks (talk) 12:46, 23 March 2011 (UTC)
- The text quoted is here. It seems to be a normal italic w there. Prosody (talk) 17:50, 23 March 2011 (UTC)
- Whoops, the specific page is here. Prosody (talk) 17:53, 23 March 2011 (UTC)
Some big news regarding the URAA
The U.S. Supreme Court has agreed to hear Golan v. Holder so there's still hope of getting the URAA overturned. The WMF is thinking about joining an amicus brief with the EFF. What the Foundation needs from the community is to find out what kind of impact this decision is going to have on Commons. I've already sent a high-level overview of the situation here to the WMF lawyers, but they would also like to highlight some specific examples. Are there any especially historically important files that are in danger of deletion due to the URAA (or have already been deleted)? For example, I've heard some people mention the works of Picasso. The full list of files currently identified as being in violation of the URAA is here. There are about 3000, so it's a lot to comb through. If you find anything interesting, please post it at commons:Commons talk:Licensing#Some big news regarding the URAA. Thanks! Kaldari (talk) 20:32, 22 March 2011 (UTC)
- Please also see Talk:The Collected Works of Mahatma Gandhi#URAA issues. Thanks! Kaldari (talk) 00:12, 23 March 2011 (UTC)
Conversion of text to pdf in Mainspace
I guess it makes sense that when the following formatting is used in a Mainspace page...
{{Page|Howells, Stops of Various Quills, 1895 009.jpg|num=9}} or <pages index="Lyrics of Life, Coates, 1909.djvu" from=22 to=24 />
- ...that conversion to pdf would fail (renders as blank space) since there is actually no text on the page to convert... So I guess there's no way around that? Londonjackbooks (talk) 16:00, 23 March 2011 (UTC)
- The bug report is on record as ticket #646 but it hasn't been fixed yet. There are some ways around the problem but they aren't great; if you enter each line as, for example, {{Page:Lyrics of Life, Coates, 1909.djvu/22}}, the book tool recognises the transclusion and renders the transcluded text instead of blank space. I don't know if it transcludes the text properly, with {{nop}}'s and {{hws}}' intact, but you should at least get text. - AdamBMorgan (talk) 17:57, 23 March 2011 (UTC)
- Thanks! That was the notation I was looking for! I thought I used to use it before with Coates poems, but couldn't find instances of it in the page histories... I'll try to see how it renders in the sandbox for a jpg page: {{Page:Howells, Stops of Various Quills, 1895 009.jpg}} Thank you! Londonjackbooks (talk) 18:42, 23 March 2011 (UTC)
- What needs to happen here is that we need to build an Index: page, where we would manually construct the page list
[[Page:Howells, Stops of Various Quills, 1895 009.jpg|9]] [[Page:Howells, Stops of Various Quills, 1895 010.jpg|10]] ...
rather than use <pagelist>. We then transclude it with <pages> as per the non-djvu example at Wikisource:ProofreadPage. Holler if you need a hand. Billinghurst (talk) 05:58, 25 March 2011 (UTC)
- What needs to happen here is that we need to build an Index: page, where we would manually construct the page list
- *Hollering* Three books I am working on are JPG indices built up of individual scans. By building an "Index: page," do you mean merely listing the pages in the Pages section of the Index:page? (For they already are),—or are you saying some separate Index:page should be created for the purpose of transclusion? I tried playing around with the notation you pointed to:
<nowiki><pages index=foo from=foo_page1.jpg to=foo_page15.jpg />
, substituting<pages index=Florence Earle Coates Mine and Thine (1904) from=Florence Earle Coates Mine and Thine 1904 079.jpg to=Florence Earle Coates Mine and Thine 1904 081.jpg />
(I also tried changing the notation in various ways in case there was more "to it"), but all I got was an Error: no such index rendering in the Main...
- *Hollering* Three books I am working on are JPG indices built up of individual scans. By building an "Index: page," do you mean merely listing the pages in the Pages section of the Index:page? (For they already are),—or are you saying some separate Index:page should be created for the purpose of transclusion? I tried playing around with the notation you pointed to:
- Placing the following, however, on the Mainspace:page does "translate" text when converted to pdf (but with pdf conversion issues—indentation, etc.—as I have addressed elsewhere)
{{Page:Florence Earle Coates Mine and Thine 1904 079.jpg}} {{Page:Florence Earle Coates Mine and Thine 1904 080.jpg}} {{Page:Florence Earle Coates Mine and Thine 1904 081.jpg}}
- What might I be misunderstanding, or where might I be going wrong? Londonjackbooks (talk) 12:36, 25 March 2011 (UTC)
- Simple thing, the titles weren't wrapped inside quotes, alternatively replace the spaces with underscores.
<pages index="Florence Earle Coates Mine and Thine (1904)" from="Florence Earle Coates Mine and Thine 1904 079.jpg" to="Florence Earle Coates Mine and Thine 1904 081.jpg" />
- as here, with your example it just sees the file name as Florence. I've been there done that, easy thing to do. Billinghurst (talk) 14:57, 25 March 2011 (UTC)
- Excellent, thank you! One formatting scenario I hadn't tried! It print-previews well from the sandbox too, but the formatting apparently isn't compatible with pdf (you just get the notation and not the text), which would make this
{{Page:Florence Earle Coates Mine and Thine 1904 079.jpg}} {{Page:Florence Earle Coates Mine and Thine 1904 080.jpg}} {{Page:Florence Earle Coates Mine and Thine 1904 081.jpg}}
- still seem more desirable if we want more output options available...? Londonjackbooks (talk) 16:35, 25 March 2011 (UTC)
Overlapping of text onto image: would love feedback!
I would DEFINITELY love some feedback here... I stole the formatting from Sherurcij 's Wikipedia page after having remembered seeing the overlapping of text and images in the past... I modified the formatting somewhat to fit my purposes, but otherwise have NO IDEA what I am doing! Please feel free to do some modifications in my sandbox for my benefit! Thanks, Londonjackbooks (talk) 16:00, 24 March 2011 (UTC)
- Can you clarify what you see as problematic? I took the liberty of adding "alt=T" for the T image, FWIW. (I'm hoping/assuming this is noncontroversial; see w:Wikipedia:Alternative text for images, [6].) -- Visviva (talk) 03:38, 25 March 2011 (UTC)
- That formatting would generally be considered contrary to our formatting guidance as we don't wish to force pages to form to a printed page construct. People viewing the web have different configurations (monitors, browsers, fonts, font sizes, ..., even devices) so forcing page widths and word wraps is problematic. Forcing a width for a small screen means that the viewer has to try and do a horizontal scroll, which can be difficult. Note that the typesetting in itself wraps the poem seemingly to conform to the book size (from my illiterate knowledge of poetry). Our effort is to make the work available and then not to constrict who can view it, for whatever reason or disability that affliction themselves or their browser, while trying to remain true to the work itself.We encourage alt text as some of our readers may not see images. Billinghurst (talk) 04:57, 25 March 2011 (UTC)
- I viewed the page (text/image) in different browsers, print-preview & pdf-preview, minimized the page, etc... Still looks ok... But you all know what you are doing, and I will depend on you guys to tweak it for me since I don't know an "alt" from a "div" ;) Thank you ahead of time! :) Londonjackbooks (talk) 05:03, 25 March 2011 (UTC)
- Here an example could include the visually-impaired, so the alt attribute [7][8] gives words for the image, so their text reader would read the alt tag to them, rather than just "Image". Billinghurst (talk) 14:10, 25 March 2011 (UTC)
- Ooh...That's nice! And thanks for the "tutorial" via links too... Little by little it will sink in! :) Londonjackbooks (talk) 16:40, 25 March 2011 (UTC)
- Came to me while driving... So Visviva's "alt=T" will render (or sound) as a "T" then... I am a bit slow... So I will then apply the same notation to all the historiated initials! Better late than never, Londonjackbooks (talk) 18:41, 25 March 2011 (UTC)
- I set the page as problematic because while it "looks good" to me, I have pretty much no understanding of the formatting technicalities (which I merely copied and pasted and tweaked a bit)—I don't even know what "Alt=T" does or means! Assuming there are details in the formatting that need refining (height/width/margin specifications, etc.)—and not knowing how to do that myself—I thought I'd let those who understand such formatting refine it for me. Thanks! Londonjackbooks (talk) 04:47, 25 March 2011 (UTC)
- I like it a lot; although I wish the formatting wasn't so heavy. In the example you provided, I wouldn't have a problem with not using it, as the overlap is not substantial. However, there are some texts which have tremendous overlap, and make formatting it any other way impossible (until this example you've given). Notice Billinghursts wording "formatting guidance;" I would not worry about it (no offense to you Billinghurst). If we are afraid of forcing a width on a page for all reasons listed above, then we fundamentally should not be including any images, as they are defined by a pixel width, which will certainly not work on a small phone screen the same way as they do on a wide screen monitor. <sarcasm>Our 400px width image size will all but dissapear once Dell comes out with their 24,000 x 11,000 res. monitor. We will be in some serious trouble then! ;)</sarcasm> Now we have a way to construct something like this :) —unsigned comment by Theornamentalist (talk) .
- Did some more tweaking to compensate for the fact that there are two more pages of the poem, and the result in the Main is this (I'll add the remaining 2 images soon)... Print-previews adequately (minor alignment issue in preview
...I think, due to needing to play[which might be remedied by playing] with block-centering placement in headers/footers on Index:pages), pdf-previews as well as it possibly can. I have unwanted double-footer notation on Index:page [53] that I can't seem to fix myself, if someone can lend a hand (I still have to fix my preferences settings that were changed during past maintenance; that might be the culprit)... Thank you! Londonjackbooks (talk) 16:17, 25 March 2011 (UTC)
- Did some more tweaking to compensate for the fact that there are two more pages of the poem, and the result in the Main is this (I'll add the remaining 2 images soon)... Print-previews adequately (minor alignment issue in preview
McCartney? Or Lennon?
I wonder if we could have a |collaborator or |spouse type template that would throw a {br} and link to another authorpage in {{Header}} for situations like Author:Richard Burton and Author:Isabel Burton or Author:Louise and Aylmer Maude or similar situations? My idea might not be perfect...but clearly we should have something other than just writing in the infofield "often collaborated with" or "was married to", etc. Ideas? TheSkullOfRFBurton (talk) 21:47, 24 March 2011 (UTC)
- Can I presume that you mean the header {{author}} for Author pages. Where people collaborated on a work, then that should be shown against a listing for each individual work. Where they collaborated in general, then appearing in the notes field is appropriate and where all our sister links (currently) appear. As it is only an occasional thing, making it a field in {{author}} would seem to be overkill. If you are talking {{header}} then we would use the parameter override_author as stated on the documentation. Billinghurst (talk) 04:45, 25 March 2011 (UTC)
- Sorry, yes I am talking about {{author}}, not {{header}} - and I'm not sure it would be "overkill" to have an optional parameter...it doesn't have to appear by default. But it would be much tidier to have it embedded, than just written in prose in the "notes" section. TheSkullOfRFBurton (talk) 14:30, 26 March 2011 (UTC)
- There is a fulsome discussion about the inclusion of notes, references, and all such bits. Every one is welcome to read it and comment at Template talk:Author
- Sorry, yes I am talking about {{author}}, not {{header}} - and I'm not sure it would be "overkill" to have an optional parameter...it doesn't have to appear by default. But it would be much tidier to have it embedded, than just written in prose in the "notes" section. TheSkullOfRFBurton (talk) 14:30, 26 March 2011 (UTC)
Purge clock
Just wondering if the "purge clock" gadget has stopped appearing in it's usual place for other folks or just for me. — George Orwell III (talk) 00:15, 25 March 2011 (UTC)
- Still working for me... it's at MediaWiki:Gadget-UTCLiveClock.js, which links to this page, and neither page has changed since last month. —Spangineer (háblame) 02:35, 25 March 2011 (UTC)
- It is working for me in FF3.16.15, Chrome 10.0.648 and IE6. Billinghurst (talk) 04:33, 25 March 2011 (UTC)
English work containing non-English fragments - how to translate
Fourie and Another v Minister of Home Affairs and Another (High Court) is an English work which contains two fragments in Afrikaans. A reader's understanding of the judgment would be enhanced by having a English translation of these fragments. I'm able to translate them, but unsure how best to link the translations to the work. I was thinking of footnotes, with a note to make it clear that the footnotes were added at Wikisource and are not part of the original work. But are there any better ideas? - Htonl (talk) 01:33, 26 March 2011 (UTC)
- Best guidance is Wikisource:Annotations. I have seen a number of approaches and that partly depended whether it is a transcluded Page: ns text or not, whether a clean text should/can exist on its own, side-by-side, etc. I have seen {{definition}} used for the occasional words and phrases. For slabs of text usually {{user annotation}} wrapped in a named ref, eg.
<ref group=annotation>
, though could see that you could use something likegroup=translation
. It should not detract from the text, and it should be clearly identified as separate from the actual text. Billinghurst (talk) 04:35, 26 March 2011 (UTC)- Thanks! Do you think what I've done with it now is acceptable? - Htonl (talk) 05:30, 26 March 2011 (UTC)
References to Wikisource
I have moved, expanded and de-orphaned Wikisource:References to Wikisource. I found it while I was looking for indexes to move to portal space and I've been making a list in my spare time (mostly through Google searches). It isn't complete; there are more for which I have missing details, Google doesn't store everything and even the Google searches came up with hits with no further information. I'm making this note in case anyone has something to add or if they're just interested to see what Wikisource works get cited elsewhere. I'd say it's mostly constitutions, treaties and transcripts of speeches. - AdamBMorgan (talk) 00:11, 27 March 2011 (UTC)
- Is there a list of Wikipedia articles using Wikisource as a reference? JeepdaySock (talk) 10:58, 29 March 2011 (UTC)
- Not currently and it might be hard to build one as the referencing format is not necessarily consistent. There is nothing stopping editors linking to Wikisource directly in a reference and I don't think cross-project links are tracked. On the other hand, there are a several special citation templates in Wikipedia:Category:Wikisource link templates, from which each template's "What links here" page will list usage. For example, the most obvious one is the Wikipedia template Cite wikisource, which is used a few hundred times. Template 1911, which cites 1911 Encyclopædia Britannica, is used a few thousand times. It would take a while to compile them all, especially if you wanted to know which text was being referenced, unless a bot could be programmed to acquire the data. - AdamBMorgan (talk) 12:15, 29 March 2011 (UTC)
- Cite DNB; Cite Men of the Times; SBDEL (though not neatly), +++. To note that the classic use of url in all the Cite templates requires that you paste a full url, so there have been a variety of approaches at WP, some by utilising title and full url, whereas others utilise a tradition wikilink, leaving the url empty. <shrug> Personal opinion is that it is a hotchpotch over at WP and could do with a tidy up. Billinghurst (talk) 00:33, 30 March 2011 (UTC)
- Not currently and it might be hard to build one as the referencing format is not necessarily consistent. There is nothing stopping editors linking to Wikisource directly in a reference and I don't think cross-project links are tracked. On the other hand, there are a several special citation templates in Wikipedia:Category:Wikisource link templates, from which each template's "What links here" page will list usage. For example, the most obvious one is the Wikipedia template Cite wikisource, which is used a few hundred times. Template 1911, which cites 1911 Encyclopædia Britannica, is used a few thousand times. It would take a while to compile them all, especially if you wanted to know which text was being referenced, unless a bot could be programmed to acquire the data. - AdamBMorgan (talk) 12:15, 29 March 2011 (UTC)
- ←After doing a bit of work on this it occurred to me that it may be a good idea to organize a wikiproject to get these works up to a high standard of quality. Anyone interested? Prosody (talk) 05:40, 31 March 2011 (UTC)
- Count me in. I was thinking the same thing, like Wikiproject:Wikisource, only a few days ago (...universal consciousness). - Theornamentalist (talk) 10:05, 31 March 2011 (UTC)
- Interested in getting some uniformity in the citations, and looking to better ways to get citations for our works, though that might also be with looking to convert some of the existing. Note that over yonder is w:Wikipedia:WikiProject Dictionary of National Biography that is already a direct tie in. Billinghurst (talk) 10:25, 31 March 2011 (UTC)
- I am curious how you feel about a recent template I made w:Template:Cws. Can I get some feedback? I imagine it could, in some ways, be implemented within the actual citation templates as long as we introduce the parameters, I don't know how anyone feels though about it. - Theornamentalist (talk) 16:50, 31 March 2011 (UTC)
- I like, and count me in on the project. Jeepday (talk) 22:23, 31 March 2011 (UTC)
- I'm not much of a Wikipedia contributor, so I'll leave organization of efforts there to someone else. For work to be done on this side though, I've thrown together Wikisource:WikiProject References to Wikisource. Have at it. Prosody (talk) 23:43, 31 March 2011 (UTC)
- Over the next few days, I plan to work on something like the wikiproject over at en.wp for referencing and maybe as to act as a representative for Wikisource formating there. The list you've compiled is good; I am surprised to see how some of the texts are so outdated by the standards we have currently; I'll be helping. - Theornamentalist (talk) 03:36, 1 April 2011 (UTC)
- I'm not much of a Wikipedia contributor, so I'll leave organization of efforts there to someone else. For work to be done on this side though, I've thrown together Wikisource:WikiProject References to Wikisource. Have at it. Prosody (talk) 23:43, 31 March 2011 (UTC)
- I like, and count me in on the project. Jeepday (talk) 22:23, 31 March 2011 (UTC)
- I am curious how you feel about a recent template I made w:Template:Cws. Can I get some feedback? I imagine it could, in some ways, be implemented within the actual citation templates as long as we introduce the parameters, I don't know how anyone feels though about it. - Theornamentalist (talk) 16:50, 31 March 2011 (UTC)
- Interested in getting some uniformity in the citations, and looking to better ways to get citations for our works, though that might also be with looking to convert some of the existing. Note that over yonder is w:Wikipedia:WikiProject Dictionary of National Biography that is already a direct tie in. Billinghurst (talk) 10:25, 31 March 2011 (UTC)
- Count me in. I was thinking the same thing, like Wikiproject:Wikisource, only a few days ago (...universal consciousness). - Theornamentalist (talk) 10:05, 31 March 2011 (UTC)
Magnus's PrettyLinkWidget.js
I found a quote of PrettyLinkWidget.js (here a screenshot, here the code), the last creation of Magnus, it's really pretty simple to customize for wikisource projects to let it run, I customized it for it.source, but Ns0, Page: and Index: are pretty different in structure from wikipedia plain pages, and I couldn't get the expected result (the inclusion of a sentence and of a image). Is there someone interested about a test here into en.source? --Alex brollo (talk) 09:38, 27 March 2011 (UTC)
Catholic Bible (1913)
Could we add in the Catholic Bible of 1913 on here as an index page? - Tannertsf (talk) 00:30, 29 March 2011 (UTC)
- Wikisource:Requested texts is where requests are placed, though we probably are not the best at using that, we tend to have our interests. If this is a request for assistance to do such, then phrasing that request in that sense would be helpful. For the latter, please find the work and the edition that you want uploaded, and we can provide some tutoring on how to progress. Billinghurst (talk) 00:28, 30 March 2011 (UTC)
I've decided on this: http://www.archive.org/details/a596716300myeruoft .... if someone can upload this as an index file, that would be great ... but try to do it ASAP please. - Tannertsf (talk) 01:39, 30 March 2011 (UTC)
done/uploaded. - Tannertsf (talk) 09:32, 30 March 2011 (UTC)
Not sure whether anyone has an interest in this work, however, looking at it, it is pretty shabby, initially grabbed from a website which doesn't reference its translation or its original source, etc. It would seem that getting a quality version (or more so we can have proper versions) of a public-domain translation so we could rid ourselves of an inferior copy would be a great idea. I hope that this interests someone Billinghurst (talk) 13:22, 30 March 2011 (UTC)
If we could find a DJVU I would start working on an index page for it. - Tannertsf (talk) 13:35, 30 March 2011 (UTC)
I would like to Move on!
Sorry to litter this space with a Commons rename request, but perhaps some of you are "movers" over at Commons who can help...? I would like to "move on" with the Howells text here on WS, but in a recent fit of uploading, I have misnamed 11 image files. Thank you! Londonjackbooks (talk) 13:41, 30 March 2011 (UTC)
- File moves complete. —Spangineer (háblame) 14:11, 30 March 2011 (UTC)
- Flawless file moving,— Thank you :) I hope I have made good use of your time... Londonjackbooks (talk) 03:29, 31 March 2011 (UTC)
- That was evil! Billinghurst (talk) 14:30, 30 March 2011 (UTC)
- I am SOOO sorry about that... Knowing it would be a pain, I tried at least to make it easier for whoever (whomever?) volunteered to tackle it... Thank you! Londonjackbooks (talk) 01:16, 31 March 2011 (UTC)
- That was evil! Billinghurst (talk) 14:30, 30 March 2011 (UTC)
Discussion to modify Collaboration of the Week
Because Collaboration of the Week is currently neither the action nor the noun, and nobody seems willing to give it some love as its steward, I have a proposal at Wikisource talk:Collaboration of the Week to make it a semi-automated beast where we can load data (Author / Graphic / time period) and let it just do its thing. I am happy to set it up, and preload data, no time to steward something else. Billinghurst (talk) 02:01, 31 March 2011 (UTC)
- I'll keep an eye out for your "beast" as I am sure to copy your formatting handiwork for something I have in mind to "automate" myself, but don't know how I should go about doing it... Londonjackbooks (talk) 03:36, 31 March 2011 (UTC)
Academic papers under a free license
Hi all, this past January the 5th Bienniel Conference on Innovative Data Systems Research (CIDR 2011) took the unusual leap of allowing all authors of accepted papers to release their work under a Creative Commons Attribution License, including diagrams, etc. They apparently did this because Internet content is one of the topics of the conference. Someone on the English Wikipedia suggested it'd be a good idea to upload them here, but I have limited experience with Wikisource, and as far as I know nothing like this has happened before. Can someone give me some guidance on how the documents should be structured, categorized, etc? Should they be uploaded as PDF or converted manually to wikitext? Dcoetzee (talk) 20:41, 31 March 2011 (UTC)
- Gday Dcoetzee. It is about time that you were assimilated (into our fringe collective). The short answer is yes, they are appropriate, and we have a project specifically for such at Wikisource:WikiProject Academic Papers which would be the ideal place for the conversation on the nitty gritty. While PDF is okay, we have a general preference for DjVu files and our practice is to upload them into Commons wherever the joint licence conditions allow. We could just take the text alone, but you can understand the nicety about text and image files. Then we set up Index: files, and have the pages created in our Page: ns workspace and wikified, and then transcluded to main namespace, per process at Help:Proofread Billinghurst (talk) 23:50, 31 March 2011 (UTC)
Upload help
Could someone help me by uploading a djvu and corresponding index page for A Short History of England by Gilbert Keith Chesterton?(http://en.wikisource.org/wiki/A_Short_History_of_England)? - short but good book, 142 pages i think. - Tannertsf (talk) 21:09, 2 April 2011 (UTC)
- I'm waiting on something else to materialize so I'll give it a shot - where's the PDF/DJVU of the work ? — George Orwell III (talk) 21:17, 2 April 2011 (UTC)
Internet Archive (http://www.archive.org/details/superstitiondiv00chesgoog). - Tannertsf (talk) 21:21, 2 April 2011 (UTC)
- You sure? that is the page for The Superstition of Divorce (1920) not A Short History of England (1917) -- same author though... — George Orwell III (talk) 21:34, 2 April 2011 (UTC)
- There's two versions on the IA: http://www.archive.org/details/ashorthistory00chesuoft (UK edition) and http://www.archive.org/details/ashorthistoryen00chesgoog (US edition). I'd do it myself, but I'm working on a very dodgy Internet connection at the moment, and 6MB uploads are more than it could handle. - Htonl (talk) 21:45, 2 April 2011 (UTC)
- While the UK version seems to be a bit "cleaner" and at a higher resolution than the US version - it is missing pages (127, 128, 216 & 217 by my count). I assume that makes the UK version a "non-starter" but given the crossed signals above, I'd still like an OK to go with the US one (A Short History of England that is; NOT the Divorce one). — George Orwell III (talk) 22:13, 2 April 2011 (UTC)
- Scratch the above about the UK version - seems like I was looking at 3rd version -- http://www.archive.org/details/shorthistoryofen005202mbp -- and that is the one missing pages. — George Orwell III (talk) 22:39, 2 April 2011 (UTC)
┌────────────────┘
Well I went ahead and, based on similar uploads of the same author, set up the UK version. The .djvu is now indexed at Index:Chesterton - A Short History of England.djvu. I hope this what you wanted/needed. — George Orwell III (talk) 23:57, 2 April 2011 (UTC)
Yes it was. Thank you. - Tannertsf (talk) 02:32, 3 April 2011 (UTC)