Jump to content

User:Sanbeg/Wikisource:Scriptorium/Archives/2010-12

From Wikisource

Announcements

DYK that the UK is reviewing its Copyright laws, the details can be viewed at BBC News - UK copyright laws to be reviewed, announces Cameron. --kathleen wright5 (talk) 08:20, 5 November 2010 (UTC)

Suppressing fundraising banner

For those who are logged in as regular users, there is the ability to suppress that banner through your gadgets. [Imported from enWP] — billinghurst sDrewth 07:41, 2 December 2010 (UTC)

Proposals

Structure Portals by Dewey Decimal or Library of Congress Classification

Should the Portal: namespace be organised and indexed according to:

a) Dewey Decimal Classification (DDC)
b) Library of Congress Classification (LCC)
c) A different classification system
d) No systems at all - left as it is.

This came up in More about Author: namespace vs Portal: namespace (below at time of writing). I mentioned that it should be a proposal and, as that discussion seems to have ended for now, I thought I'd start it off. Each system has pros and cons.

DDC is in several editions, the earliest of which is in the public domain (copy at Project Gutenberg). Ten classes, each divided into ten divisons, each further divided into ten sections; although not all "slots" in this structure are used. Pros: Very commonly used in real-world libraries; Published and authoritative system; Clear and highly detailed structure. Cons: Possibly too detailed (full implementation would require roughly 900 portals in a hierarchy of up to 5 layers including the top level index, although many could remain as red links until actually required); Lowest level portals may get lost (or "diluted") among the many sections; Using a 19th century classification might by out of date over a century later.

LCC is public domain as a work of the US government (Library of Congress Classification). Twenty one classes, each divided into a varying number of subclasses. Pros: Presumably commonly used in American libraries; Published and authoritative system; Simple structure (full implementation would require roughly 200 portals in a hierarchy of up to 4 layers including the top level index; again, some could remain as red links); Up to date classification. Cons: America-centric (two classes for American history separate from the general history class; although, i) this need not apply if we use it, and, ii) we do have a lot of portals relating to American history anyway); Too many lowest-level portals in one sub-class could overwhelm the system (unlikely at the moment but it may happen later).

If someone wants to suggest another system, there are several to choose from, or Wikisource could create its own structure. Pros and cons depend on the suggestion, except for: Con: Non-standard or lesser used system. A Wikisource-specific system would offer the greatest flexibility, this simplest form of which could just be an alphabetic list of portals on Wikisource.

No system would be the easiest to implement as it involves doing nothing. Pros: No implementation; No maintenance. Cons: Portals would lack any organisation other than Category:Portals; Browsing and navigation would be difficult.

Examples, using Portal:British Museum:-

a) DDC: Portal:Index - Portal: Sociology (Class 3 Sociology) - Portal: Associations and Institutions (Division 6 Associations and Institutions) - Portal: Other Associations and Institutions (Section 9 Other) - Portal: British Museum (Classification 369)
b) LCC: Portal:Index - Portal: General Works (Class A: General Works) - Portal: Museums (Subclass M: Museums) - Portal: British Museum (Classification AM)
c) Other: Portal:Index - Undefined - Portal: British Museum
d) None: Portal: British Museum

So, what option would people prefer? Personally, I like (and am more familiar with) the Dewey system but I think Library of Congress Classification would be better for Wikisource. - AdamBMorgan (talk) 17:57, 23 August 2010 (UTC)

Part of me says that a Wikisource-specific structure would be simpler, but on the other hand, in the interest of being more like a "library", we should have similar systems in place. Personally, I prefer using LCC because it's newer than the 19th century Dewey, and I feel that it's more rigorous. That said, I'm not opposed to going to a deeper level than just two layers—if the need arose for using one or even two decimals in some LCC categories, that would be fine with me. —Spangineerwp (háblame) 13:48, 26 August 2010 (UTC)
For a more detailed look at how LCC can be implemented, I've created this user subpage. - AdamBMorgan (talk) 18:23, 3 September 2010 (UTC)
The questions in my mind would be:
1. Which of these systems will be most intuitive for readers/browsers - is there one that is more popular than the other? (From a British perspective, DDC is much more common that LCC.)
2. What happens to entries that don't fit under the LCC/DDC systems - would we end up extending the systems until we essentially had our own? (possibly not a downside - LCC/DCC would give us a solid starting point to expand on.)
3. Would we aim, as a community, to have all of our works listed in the portal system (along with the author pages), such that we would identify and classify all works? (I'd love to see such rigorous organisation, but I'm not sure a) whether wikisource is ready for that yet, and b) whether it fits in the 'wiki way'.)
3a. If so, might a category-based system rather that a page-based system be preferable for ease of maintenance? (This is slightly off topic, I'll admit, but it's something that should be considered before creating large numbers of portals. The cons of a category-based system are that you can't do lists e.g. Wikisource:Astronomy, and you can't monitor changes, but they are a lot easier to add/remove works from.)
Mike Peel (talk) 22:35, 1 October 2010 (UTC)
Sorry I missed this reply. I've made some other posts elsewhere and there doesn't seem to be a any consensus about this so far. Anyway, my answers would be:
  1. Personally, I find DDC the most intuitive (I'm also British) but LLC is simpler and, while I find the category selection a bit odd, it is fairly straight forward.
  2. There is a precedent for expanding LLC for local use; The National Library of Medicine classification system (NLM) does so. The 19th century DDC system also has gaps that can be used for local adaptation, which will be necessary for computing and other subjects. In the latter case, however, there is a problem that new classification would not match the modern DDC equivalents (and if they do, then it raises copyright problems). For LLC, I have tentatively added two categories to make everything fit: Class I (Texts by Country) because the existing Portal:Texts by Country was hard to categorise otherwise (is is Geography? History? Law? Literature?) and Class X (Wikisource) for any Wikisource specific portals like the current WikiProject portals.
  3. I don't really intend to change the use of the Portal namespace with this system, so that would be a separate proposal. However, a category-based system would not fit the use of portals on sister projects; matching portals between projects in one of the intentions of further use of this namespace. Further use will, I feel, create further confusion if the portals are not organised in some way.
In addition, I have another user page, LCC Index, to demonstrate the LLC system in action (I may use this for an actual portal at some stage, which would be the most basic way of implementing LLC). - AdamBMorgan (talk) 17:24, 18 October 2010 (UTC)
After trying to direct someone to this space today, finding no logical start point, or ability effectively navigate (still.again/whatever) and there being no other suggestions or work being done about how to organise, I would heartily encourage you to get into the Portal namespace and to organise. Definitely more an organisational aspect rather than recreating parts of the hierarchy unnecessarily. I would suggest a ready means to identify pages that have been "sorted" and those that are newly created that may have not an alignment to a framework; this being that it makes sense to know what has been poked into a place, against something that appears in a place for no rhyme or reason. Especially need a few landing pages to direct people onwards. — billinghurst sDrewth 05:42, 4 November 2010 (UTC)
OK, I've started doing this. So far, I've made two landing pages: Portal:Portals (top) and Portal:Index (bottom). I've incorporated navigational templates into {{portal header}} and classified all the portals I've found so far (some were in the Portal: namespace but not the category). Navigation isn't complete: Portal:Index links to everything but there are gaps in the "chain" from Portal:Portals downwards. I'm not sure how far to go. I created Portal: General Works for the top level of Class A and I have tried to make it work as a portal in it's own right rather than just a link between other portals. I will probably continue until everything is linked up (again, making any additions valid as standalone portals). "Sideways" links between similar portals exist sometimes but could be expanded as well (usually text links at the bottom of a page, although Wikipedia and at least one Wikisource portal uses images). - AdamBMorgan (talk) 02:10, 7 November 2010 (UTC)

Change {{smaller}}, et al., to percentage-based sizes

A few times in the last few months I've noticed that the different browsers interpret text size differently. Template:Smaller gives smaller text when looking in Firefox or IE than in Chrome. For evidence, look at this image.

From the image, it looks like Template:Smaller is 75-80% of full size in Firefox, and 85-90% in Chrome. The difference may seem slight, but it results in pretty dramatic differences in readability. Template:X-smaller is miniscule in Firefox and IE, but still fairly readable in Chrome.

The same thing happens in reverse for Template:Larger and its cousins. In Chrome, the sizes do not get as big as in Firefox or IE as quickly.

My proposal is to change all these size templates to use a specific percentage rather than a relative term like "smaller" or "larger". From my testing, it appears that doing so will make the text size consistent for all browsers. This is how it is done at Wikipedia—the standard "small references" class in their MediaWiki:Commons.css is 90%, not "smaller".

I suggest reducing the amount of difference between the successive templates for our Firefox and IE-using readers. Thus, I recommend that we make the following changes:

Current Size
(in your browser)		 Proposed Size
(for all browsers)		 Geometric Size
(20%)
Xx-Smaller
60%
58%
X-Smaller
75%
69%
Smaller
90%
83%
Normal
100%
100%
Larger
120%
120%
X-Larger
150%
144%
Xx-Larger
200%
182%
Xxx-Larger
250%
207%
Xxxx-Larger
300%
249%

If you can, look at the above table in multiple browsers before commenting. —Spangineer (háblame) 00:32, 28 October 2010 (UTC)

There was a discussion in May that went the other way Wikisource:Proposed deletions/Archives/2010-05#Absolute font size templates — billinghurst sDrewth 04:01, 28 October 2010 (UTC)
Apparently "absolute" doesn't mean what I think it means. To be clear, I am proposing that we use specific percentages (font-size:90%, font-size:150%, etc.) rather than absolute (font-size:small) or relative (font-size:larger). I don't think this option was brought up in the previous discussions.
{{smaller}} makes text dramatically smaller for many readers, and the view is inconsistent between browsers. For standardization of viewing, I feel that percentages would be a significant improvement and would allow smaller differences in text to be rendered and still be readable.
For example, see Page:Contemporary Opinion of the Virginia and Kentucky Resolutions, p2.djvu/23 and Page:State Documents on Federal Relations.djvu/25. Writers often use a slightly smaller font to separate two types of text (in these cases, editorial comment and quoted text). If I use {{smaller}} in Chrome, I get a satisfactory result, but those who read in Firefox or IE get something significantly smaller. —Spangineer (háblame) 11:25, 28 October 2010 (UTC)


I have no objection to this, but I think the numbers ought to grow smoothly (i.e. a geometric progression), rather than showing sudden jumps: if "larger" is 25% bigger than "normal", then "x-larger" ought to be 25% bigger than "larger", etc. I say 25% because it best fits the figures you've proposed above. In this case the sequence of sizes would be 51%, 64%, 80%, 100%, 125%, 156%, 195%, 244%, 305%. I guess I'd prefer a smaller range, say 20%: i.e. 58%, 69%, 83%, 100%, 120%, 144%, 182%, 207%, 249%. Hesperian 12:39, 28 October 2010 (UTC)

That would be fine with me. I've used the 20% numbers and added a third column to the above table. —Spangineer (háblame) 13:40, 28 October 2010 (UTC)
I would like to see the proposal put into some works or parts of works and seen side-by-side to see what the impact of the formatting, especially some book front pages as that is often where we see the varied usage of different size templates. If we are getting to some of this, it would be nice to see if we can also look at some of the aspects of line height, and its variability, which has been problematic with some of these size templates. — billinghurst sDrewth 21:52, 28 October 2010 (UTC)

I have set up more examples. To compare two book front pages in your browser, go to User:Spangineer/font comparisons. I tried to get a sampling of the various font sizes.

I also took screenshots in the two most popular browsers: IE (7) and Firefox (3.5). The firefox image is available at File:FF 3.5 font comparison screenshot.jpg, while the IE image is below:

  • In IE (above image), notice how {{smaller}} and {{x-smaller}} give much smaller results than other browsers and the proposed solution. {{X-smaller}} gives almost unreadable text, and {{smaller}} would be uncomfortable to read more than a sentence or two (note that these are all caps; a paragraph of text is more difficult: see State_Documents_on_Federal_Relations/7n2 using IE 7, for example). Additionally, IE renders larger text smaller than other browsers and the proposed solution.
  • Firefox is much closer to the proposed solution, but its {{smaller}} is slightly smaller than proposed.
  • In chrome, the current and proposed sizes are the same (to my eye, at least).

I think it's pretty well known that editors of Wikimedia projects tend to use IE much less than do readers of Wikimedia projects. Hence my concern that editors who use Firefox and Chrome (like me!) are setting fonts to what "looks good" to them, without checking what it looks like for others (especially IE). If the proposed fixed-percentage solution is put in place, this issue would be addressed. —Spangineer (háblame) 14:28, 1 November 2010 (UTC)

I implemented the geometric sizes idea to these templates yesterday. If there are any problems feel free to bring them up. —Spangineer (háblame) 17:41, 24 November 2010 (UTC)

Other discussions

Questions

Why line breaks are removed?

Hello!

I'm having a problem when I try to format some pages.

Here is an example: If we disable javascript in the browser and go edit some page, we see something like this: 

<noinclude><pagequality level="4" user="Angelprincess72" /><div class="pagetext">{{rh|iv|PREFACE.}}


</noinclude>more accurate expression, as a problem, by ...

and if we add line breaks (pressing "ENTER") between "</noinclude>" and "more", like this 

<noinclude><pagequality level="4" user="Angelprincess72" /><div class="pagetext">{{rh|iv|PREFACE.}}


</noinclude>

more accurate expression, as a problem, by ...

, and then click in "Show changes", we see the addition in the diff as expected.

But if we enable Javascript, and then edit the same page and add the same line breaks in the beginning of the text in the editbox, and then click in "Show changes", the diff shows the addition but in the editbox there is one line break less than we added. So if we save the page the result will not be what we expected (although the diff is right).

Does anybody knows what script is removing the line breaks between the beginning of the wikitext and the header text and why is that happening?

Should this be reported at bugzilla:? Helder (talk) 13:36, 25 October 2010 (UTC)

I'm not sure why it does this, but there are easy workarounds. Most of the time when we want a line break, it's to mark a new paragraph. To do this, put {{nop}} at the bottom of the previous page (the page on which the paragraph ends). Then just start the new paragraph on the second page normally.
If we do want line breaks at the beginning of a page, there's the <br /> tag. Repeat it as necessary; it won't disappear when you save the page. —Spangineer (háblame) 13:44, 25 October 2010 (UTC)
you can also put the {{nop}} at the beginning of the page. ThomasV (talk) 14:17, 25 October 2010 (UTC)
The convention (current consensus) is to preserve the blank line at the end of a paragraph, forcing it at the bottom, rather than the top of page. It was convenient to adopt one way over the other. cygnis insignis 17:19, 25 October 2010 (UTC)

Thanks for your suggestions. My intention was just to mark a new paragraph, as pointed by Spangineer.

What I don't understand is why the behavior is inconsistent: when saving a page, with or without javascript enabled, the result should be exactly the same. But this doesn't happens if the page in question has those line breaks in its beginning (intentionally put there by some previous editor), so if I user for example review such a page, and just want to update its status to "validated", it will make a unwanted change, even if according to the diff he saw, the edit was ok (doing nothing). The script which is causing this effect should be fixed. Helder (talk) 00:36, 27 October 2010 (UTC)

Perhaps I didn't understand the trouble... but try with two break lines. One break line is always ignored from html conventions (outside poem taged text obviuosly). I apologyze if I did a banal observation from misunderstanding. --Alex brollo (talk) 16:01, 27 October 2010 (UTC)
If someone add two line-breaks, and the next user to edit the page just validate it (maybe fixing some typo), some script will remove one of the line-breaks. This shouldn't happens, since this is not shown to the second user, even if he preview the changes (the diff will show nothing). The point is that this problem only happens for those wich javascript enabled (most of users). I've reported this as a bug in bugzilla:26028. Helder (talk) 19:43, 20 November 2010 (UTC)
I believe that it is part of the Proofread Page script and is probably more of a feature rather than a bug. I am neither sure why you would want to add uncontrolled blank lines at the top of a work. If they are wanted and to be retained then it makes more sense to add them explicitly otherwise the next proofreader is just as likely to remove them anyway. In the sense of converting from book to web it doesn't make sense to me. — billinghurst sDrewth 03:26, 21 November 2010 (UTC)

Match and split (1)

It.source (as you see here) has lots of "naked" texts, but recently we are doing a huge effort to convert them into proofread texts, and you can see the result at the right of the graph: naked texts began to decrease while "with scans" texts are growing. A different pattern can be seen here where en.source works are represented: bot "naked" and "with scans" texts are growing (so I presume that a similar huge effort to convert naked into with scans text is not presently going on). We are developing tools to automatyze the "match" that is, by experience, the most annoying part of the work, particularly when sections are small or very small. I'd like to share tricks if some of you is interested. You can find an example of "autoMatch" here: it:Myricae. All the match tags have been loaded into sections by a bot. Just to make your work a little easier if you consider to start with a large "conversion" project. like fr.source.  :-) --Alex brollo (talk) 16:08, 27 October 2010 (UTC)

We have found that match and split is something that needs to be undertaken mindfully and with some precision. For English-language works, there has been found to be sufficient elements of variance between editions, be they simply later or earlier, or the more complex situation of British English vs American English. Add to that we have found that significant numbers of works that were brought over from Gutenberg are not readily tagged with the edition history, so it has been a slower process. All up it has just made it a slower process, and one that we are getting to rather than focusing upon as the priority. So many works to choose from, so little time to get to the works. Also, many of our more recent works added that are considered 'naked' are legal cases where the image files are not readily available. C'est la vie. — billinghurst sDrewth 03:47, 28 October 2010 (UTC)
Yes, it.source too has lots of books without an appropriate IA source, coming from Gutemberg or other free sources. Nevertheless the number of IA books is fastly growing, and we found many books perfectly matching to our text (sometimes the same edition!).
This my possible contribution: if any of you finds a Internet Archive source of a en.source book, and your community agrees, tell me by a message into my talk page and I'll try to run autoMatch() on it. I'm very interested to run it into other projects, to test it. If you dislike the result, you'll simply rollback the bot edits and the test will not leave any garbage. I drive here an unflagged bot, so I'll use a slow throttle, more than 60 sec/edit, as en.source community states; al least, I hope I'll remember to do so... :-( --Alex brollo (talk) 06:57, 28 October 2010 (UTC)

A Book of Nursery Rhymes

nyone who needs something to do can go here and work on this book:

http://en.wikisource.org/wiki/Index:A_Book_of_Nursery_Rhymes.djvu

I need people to proofread/validate it so we can get it done. - Tannertsf (talk) 10:12, 1 November 2010 (UTC)

class="prose" has changed

I haven't touched Wikisource for a few months and I noticed that on pages that i formatted using <div class="prose"> the text is window-wide and has no proper margins as it used to. For example, on Gesenius' Hebrew Grammar/95. Paradigms of Feminine Nouns.

The biggest problem with this, at least for this book, is that the paragraph numbers, inserted using {{number}} overlap with the text.

The strangest part is that when i try to edit a page, it looks correctly in the preview.

What can i do to fix that? --Amir E. Aharoni (talk) 23:52, 1 November 2010 (UTC)

As I understand it, a decision was taken to put these layout decisions in the hands of the reader rather than the editor. Therefore the "prose", "indented-text", etc classes now do nothing, but you will find a "Display options" section in the sidebar, which you can use to cycle through various layouts. Hesperian 00:00, 2 November 2010 (UTC)
A 'decision' you say??? Can you point us to that discussion, please? George Orwell III (talk) 00:04, 2 November 2010 (UTC)
Wikisource:Scriptorium/Archives/2010-10#Dynamic layout Hesperian 00:54, 2 November 2010 (UTC)
Ah; my mistake. I was looking at the Proposal and Announcement sections - for an announcement or even a proposal -- Never thought to go right to Questions. Thanks. George Orwell III (talk) 01:25, 2 November 2010 (UTC)
I tried to cycle through them and they are all screwed up. --Amir E. Aharoni (talk) 00:10, 2 November 2010 (UTC)
I think this can be corrected by changing {{number}} to use the sidenote-left and sidenote-right classes described in MediaWiki:Common.js, but I can't experiment with it because the dynamic layouts system apparently only kicks in on saved edits in the main space. Someone who's more familiar with the usage of that template, please look it over. Prosody (talk) 03:32, 2 November 2010 (UTC)
The only possible value for argument class at {{number}} is lefttext and i don't see how it is useful for this page... or for any other. --Amir E. Aharoni (talk) 16:19, 2 November 2010 (UTC)
I changed {{number}} as I proposed above. I don't know how Genesius was formatted previously, so please check if it's now satisfactory. Note that it will still be broken in the Page namespace unless {{sidenotes begin}} and {{sidenotes end}} (see the Usage notes for a brief explanation) are added to the header and footer. Hopefully that will be rendered unnecessary in the near future. Prosody (talk) 18:52, 2 November 2010 (UTC)
Thank you! It looks better now (more detailed reply at Template talk:Number.)
Is it possible to make "Layout 2" the default for this book? It looks best with it. (Best = most similar to the appearance in the printed edition to which most of its readers are used.) --Amir E. Aharoni (talk) 18:58, 2 November 2010 (UTC)
I don't think that's possible yet. But if your problem with Layout 1 is the bordered inline sidenotes, maybe an admin reading this will consider editing Commons.js to standardize on the simple Layout 2 sidenotes, leaving additional styling to templates and such. Prosody (talk) 21:00, 2 November 2010 (UTC)
It is a problem for this particular book. These notes may be OK for other books. Everyone should be able to choose what's appropriate in each case.
I am going to show a presentation of this digital edition of Gesenius' Hebrew Grammar to a large group of members of The Academy of the Hebrew Language next week and i will feel awkward telling them: "Now, to see this book nicely you must click 'Layout 1' on the right". --Amir E. Aharoni (talk) 21:33, 2 November 2010 (UTC)
Can I recommend against sidenotes bits as they can get really ugly, and there has been some issues with them, especially as right sidenotes are problematic in a web environment where we shouldn't be enforcing a right margin. We should be looking to replace {{number}} with {{page break}} and utilise the left numbering option, and then use class=indented-text. — billinghurst sDrewth 05:00, 3 November 2010 (UTC)
I use {{number}} for paragraph numbers. There are also page numbers, which are inserted using {{page}} - they usually appear on the left, too. If they can both live together nicely on the left-hand side, i'm OK with it. --Amir E. Aharoni (talk) 05:36, 3 November 2010 (UTC)

Preface to Curieuses Natur-Kunst-Gewerck- und Handlungs-Lexicon 1712 needs some love

This page needs some research and some love, as it seems to be ye olde contribution that no longer meets our style, if it ever did. If someone has some time it would be good if someone could tidy it up and fix the shortcomings. Thanks. — billinghurst sDrewth 04:38, 3 November 2010 (UTC)

I did a little. It doesn't seem Olaf Simons explicitly released the translation under a permissive license, though the "By saving, you agree to irrevocably release your contribution under the Creative Commons Attribution/Share-Alike License 3.0 and the GFDL. You agree to be credited by re-users, at minimum, through a hyperlink or URL to the page you are contributing to. See the Terms of Use for details." thing might have done it for him. Does that call for emailing him? Also, do we still do bilingual side-by-side texts in the age of the crosswiki matching thing (imperfect though it may be)?

Is there a free software java solution for converting printed text --> searchable PDF?

I have a printed text and a scanner (Lexmark X2330).

Is there a free software, pure java (i.e. platform independent), solution that will:

  1. Let me make a searchable PDF-file.
    1. That is still photographically true to the original.
    2. With clickable links back and forth between the main text and footnotes/reference list and the table of contents.
    3. With the page numbers in the PDF file corresponding to the page numbers in the printed text.

Such a software package would seem to match, exactly, with the spirit of Wikisource. Has it been made yet? --89.9.84.179 19:45, 3 November 2010 (UTC)

Password question

I received an email from wiki today saying that someone from my ip requested a new password. I ignored it because I had not asked for a new password. However, since then my account has been logging out during my edits more that usual. Is there a connection between these two events? Is there something I should do? I don’t want to change my password for no reason as I’ve had it for a while and can remember it. —unsigned comment by Mattisse (talk) .

Someone has kindly (not) hit the [E-mail new password] button from the login screen, so you will need to use that new password, login and change it back to your preferred password. If someone continues to do that, then one of the CheckUsers can investigate a reported problem. — billinghurst sDrewth 05:14, 9 November 2010 (UTC)
Is it normal for an account to log out several times a day in the middle of an edit? I don’t know why my account has started doing this, but it seems to be getting worse. For years I never had trouble, then it started a few months ago to log out once a day, and now it logs out many times a day. Mattisse (talk) 14:33, 10 November 2010 (UTC)
No, not unless your password has changed (like this case). The button described above resets your password, and accordingly your browser isn't talking the right password to the system, and that is akin to logging you out. So, go back login with the reissued password, and then reset your password as you want it to be. You should then be right to stay logged in. — billinghurst sDrewth 12:42, 11 November 2010 (UTC)

How to put together a book

I have downloaded and proofed Index:Travels with a Donkey In The Cevennes.djvu but I can’t seem to put it together. Is there anywhere that explains how to do this? I have tried to copy what others are doing but nothing is working for me. Thanks, Mattisse (talk) 14:31, 10 November 2010 (UTC)

You're off to a good start. The thing you got wrong with Chapter I is that <pages .../> goes and fetches data from wherever the index= says the index is. On the mainpage of the work, you put index="Travels with a Donkey In The Cevennes.djvu", which is correct--Index:Travels with a Donkey In The Cevennes.djvu is where you'd find the index. But on Chapter I you put index="Travels with a Donkey in the Cevennes (1905)". The Mediawiki program goes to look for Index:Travels with a Donkey in the Cevennes (1905) and doesn't find anything, so it gives an error. Unless you're doing a work that spans multiple volumes, it's probably easiest to just copy and paste the <pages ... /> thing once you've got it right, and then just change the to= and from= parameters.
A few other minor pointers: in the header, the author is automatically linked, unless you add an authoroverride parameter (useful for some weird situations like more than one author). I think <div class="indented-page"> is automatically applied to articles in the Main: namespace (i.e. not User: or Page: or Wikisource: etc.) which use <pages ... />. Prosody (talk) 16:02, 10 November 2010 (UTC)
I’m afraid what you are saying is all Greek to me. I have copied many difference codes from other books, but nothing works for this one. Mattisse (talk) 16:33, 10 November 2010 (UTC)
For those new to the site, this is another explanation of how Travels with a Donkey in the Cevennes (1905) pulls the transcript using the <pages index="Travels with a Donkey In The Cevennes.djvu" from=9 to=17 />
  • index="Travels with a Donkey In The Cevennes.djvu"
  • from=Page:Travels with a Donkey In The Cevennes.djvu/9
  • from=Page:Travels with a Donkey In The Cevennes.djvu/17
See also Help:Proofread. —cygnis insignis 16:59, 10 November 2010 (UTC)
  • Thanks for the tips but this particular one is beyond me. Part of the problem is that this is the only version of "Travels with a Donkey in the Cevennes" on the site that has a scan with it. None of the other versions have a djvu. Anyway, I can’t figure it out. So I am giving up on it. Sorry! I have managed to figure out others by copying code etc. , but this one is beyond me. Mattisse (talk) 21:32, 10 November 2010 (UTC)
It is the {{PAGENAME}} component that is important, so here {{PAGENAME}} = Travels with a Donkey In The Cevennes.djvu so …
Namespace Transclusion
  • File:{{PAGENAME}}
 File:Travels with a Donkey In The Cevennes.djvu
  • Index:{{PAGENAME}}
 Index:Travels with a Donkey In The Cevennes.djvu index="Travels with a Donkey In The Cevennes.djvu"
  • Page:{{PAGENAME}}
 Page:Travels with a Donkey In The Cevennes.djvu/m
Page:Travels with a Donkey In The Cevennes.djvu/n 		from=m
to=n

See the alignment required between three namespaces. Now we do not or cannot have to have that same alignment into the main namespace, hence why we have to be explicit in the transclusion, rather than rely on the alignment factors. Is that more helpful? — billinghurst sDrewth 12:20, 11 November 2010 (UTC)

Thomas Wyatt's poetry

These two poems are identical: The Lover Showeth How He Is Forsaken of Such as He Sometime Enjoyed and Vixi Puellis Nuper Idoneus.... One should be redirected to the other, but which is the correct title?--Longfellow (talk) 16:12, 10 November 2010 (UTC)

Whatever the source says. cygnis insignis 17:02, 10 November 2010 (UTC)
Neither poem is sourced.--Longfellow (talk) 21:52, 10 November 2010 (UTC)
Page:Oxford Book of English Verse 1250-1918.djvu/93 cygnis insignis 22:29, 10 November 2010 (UTC)


I believe Wyatt's original was untitled. It was probably known by its incipit, as even today a Google search suggests that most web versions of it are under the incipit "They flee from me that sometime did me seek". It was first anthologised in w:Tottel's Miscellany, the first ever printed anthology of English Poetry, wherein Tottel gave it the title "The Lover Showeth How He Is Forsaken of Such as He Sometime Enjoyed". Quiller-Couch later retitled it "Vixi Puellis Nuper Idoneus..." when he included it in The Oxford Book of English Verse.

If we didn't have a scan to hand, I would favour redirecting both titles to the incipit, but as Cygnis has found a scan, I agree with his suggestion that the scan by followed.

Hesperian 23:41, 10 November 2010 (UTC)

Thanks; I've done that.--Longfellow (talk) 10:50, 11 November 2010 (UTC)

Nupedia

restarting this discussion

Hi all. Nupedia was an encyclopedia published in the 2000s (you know... ; )). Why do not save it in Wikisource? There are some articles in Internet Archive. The articles can contain useful info, of course, and Nupedia is the predecessor of Wikipedia, "our history". Regards. Emijrp (talk) 09:58, 18 August 2010 (UTC)

Not sure why we would want to focus on a compiled information that may or may not have had peer review, versus the works that we know did have peer review, with some of the earlier encyclopaedia and biographical data. — billinghurst sDrewth 01:32, 19 August 2010 (UTC)
Take a look at the Wikipedia article - there was a lengthy reviewing process for articles. Only 24 article exist in full form (i.e. having gone through the whole review process), in brief and long formats. I think it's worthwhile hosting an archive copy of those articles here, if only for their historical value as the articles of the predecessor to Wikipedia. Mike Peel (talk) 09:11, 19 August 2010 (UTC)
That's the point. Emijrp (talk) 11:11, 19 August 2010 (UTC)

This sounds like a great idea. Is it against any current wikisource policies? What is needed to make this happen? The Internet Archive's version of Nupedia is rather hard to navigate, and feels incomplete -- it would also be nice to know what the final set of articles was when Nupedia stopped accepting new entries (and which of the early wikipedia entries were in line to become Nupedia articles!). Perhaps one of the old-timers such as Magnus or Ruth could help with that part of reviewing the final source-collection. Sj (talk) 19:39, 12 November 2010 (UTC)

I have seen now that the Nupedia license was GFDL 1.1, any problem? Emijrp (talk) 21:23, 12 November 2010 (UTC)
This has been rejected before. It violates WS:WWI. John Vandenberg (chat) 22:09, 12 November 2010 (UTC)
How so? I would take original Nupedia articles as historic documents. BD2412 T 04:08, 13 November 2010 (UTC)
Historical documents is for source documents which are relevant to understand history. An email about Nupedia penned by Jimmy or Larry is a historical document. The output of the Nupedia project is not. Nupedia was not traditionally published and consists of WS:WWI#Original contributions and are a snapshot of WS:WWI#Evolving works. John Vandenberg (chat) 06:07, 13 November 2010 (UTC)
John is right, I'm afraid. Moreover, the terms for GFDL to CC-BY-SA relicensing have expired and we would need an exception to the Terms of Use to import GFDL-only text.
However, I think that a solution can be found. How many pages are to be imported? If they're not many, we could put them under m:Meta:Historical or in en.wiki Wikipedia: namespace. If they're many and we need Wikisource templates and facilities, we could put them in some existing or new namespace, so that they can avoid following general rules (because they wouldn't be mixed to normal content). --Nemo bis (talk) 08:46, 13 November 2010 (UTC)

Erm ... huh? Am I correct in interpreting this discussion as a) saying we can't accept works freely licensed under the GFDL, and 2) that Nupedia - the predecessor to Wikipedia - does not count as a work helping people to understand history (in this case, the development of Wikipedia)? Neither of those interpretations make any sense at all to me. Mike Peel (talk) 20:26, 13 November 2010 (UTC)

If Nupedia articles cannot be hosted in Wikisource, where can I save them (a wiki project)? Emijrp (talk) 16:01, 18 November 2010 (UTC)
As noted, beside the archives for the 24 articles, they are already linked from the wikipedia article, in the wikipedia namespace. cygnis insignis 19:33, 18 November 2010 (UTC)

commons categories

While standarizing category names on commons Somebody attempted to remove information that specific books are used in wikisource projects. Please comment here if you need. Ankry (talk) 11:52, 18 November 2010 (UTC)

I have created these two categories in order to include all English books used in Wikisource projects and the same thing for the French ones. Is this correct? --Zyephyrus (talk) 13:14, 18 November 2010 (UTC)

Request for help

I am asking for some pointers to help pages that describe how to deal with such pages as Page:Book of the Riviera.djvu/182. Also, I would very much appreciate some directions to help pages explaining how to format "Table of Contents" and "Illustrations" pages. Thank you very much. Mattisse (talk) 21:54, 18 November 2010 (UTC)

Regarding your Riviera problem, no such help pages exist. I solved this problem at Page:Don Quixote (Cervantes, Ormsby) Volume 1.djvu/30 by wrapping the entire thing in <tt> to ensure a fixed-width typeface, and then using the standard Unicode box-drawing characters, together with spaces and hard line breaks. It was difficult and took ages. Hesperian 23:52, 18 November 2010 (UTC)
For genealogies I have cheated and copied it as an image and added that, eg. Page:The life of Matthew Flinders.djvu/34. Then on the talk page I have added the names so that a search engine can find them and just then link through. A little issue is that it links to the Page talk namespace, and I haven't done anything about pulling that to the main namespace talk page. — billinghurst sDrewth 00:13, 19 November 2010 (UTC)
I have used a combination of {{familytree}} and html to replicate the diagram fairly well, but it was a bit time-consuming! --Eliyak T·C 07:36, 19 November 2010 (UTC)
  • Thanks guys! I have to admit that I have never used Unicode and have no idea how to go about it. I am not a techie person, so I am unfit for a lot of the tasks Wikisource requires Mattisse (talk) 16:34, 19 November 2010 (UTC)
    • You don't have to grok Unicode to copy-paste box-drawing characters. Hesperian 23:06, 19 November 2010 (UTC)
Everything I do is copy/paste. I have spent several days trying to copy/paste a certain format or a box-drawing without success. Maybe I’m not proficient enough for Wikisource? Mattisse (talk) 23:19, 19 November 2010 (UTC)
Only you know the answer to that question. I don't know whether you're looking for someone to criticise you or stroke your ego, but either way you're not going to find it here. We don't go in for that shit on Wikisource; that's more of a Wikipedia thing. Hesperian 05:22, 20 November 2010 (UTC)

What is being done about Category:PD-manifesto ?

Could you please tell me what is being done about the above which is currently under possible copyright violations. In particular I'm asking because there are speeches by former Prime Minister of Australia John Howard in this category. --kathleen wright5 (talk) 22:39, 19 November 2010 (UTC)

Presuming that you have read the dialogue about removal of {{PD-manifesto}}, those that are copyright violations are slowly being deleted. If there are any works that have that tag and can be tagged with another appropriate PD tag, then they should be updated, if they cannot, they will be removed. Jusjih has been moving those that are non-compliant with US though compliant with Canada copyright law. — billinghurst sDrewth 03:40, 20 November 2010 (UTC)

OCR generator tool

The toolserver OCR generator tool is no longer linked in the Page: namespace editing toolbar; I've posted on this at Wikisource:User experience feedback, but nothing has happened. —innotata 01:52, 21 November 2010 (UTC)

It is showing for me in both monobook and vector. Do you have it turned on in your gadgets? — billinghurst sDrewth 03:19, 21 November 2010 (UTC)
It doesn't show for me in either skin, and in preferences there is an opt-out option, which I don't have ticked. It might be a problem with my browser or something like that; regardless, using the new editing toolbar without integrating the old buttons probably is in part to blame. —innotata 14:49, 21 November 2010 (UTC)
Ah yes, turn off (at lest when you want to OCR) the beta toolbar and it should come back. Well, when I turn mine on, I see it momentarily flash and disappear. — billinghurst sDrewth 17:34, 21 November 2010 (UTC)
I found an option to remove the new toolbar in preferences, but I don't remember adding it for Wikisource and would never choose to, and I believe it was changed by default, a bit after the change to the vector skin. Furthermore, not all the buttons that used to be in the toolbar for the Page namespace are there (though all the useful ones are). In any case, shouldn't OCR be opt-out for all skins and editing toolbars? Do you know who to ask on this? —innotata 22:25, 21 November 2010 (UTC)
Would suggest that you point ThomasV (talk • contribs) to this conversation. He is the knowledge base for this stuff, it being his tool, and that he did some work around vector with it all. — billinghurst sDrewth 01:22, 22 November 2010 (UTC)

History of the prophets and kings

I was wondering whether or not http://en.wikipedia.org/wiki/History_of_the_Prophets_and_Kings could be added on to here. I know we would have to find good scans. - Tannertsf (talk) 23:00, 21 November 2010 (UTC)

If it meets the criteria as at WS:WWI then yes. — billinghurst sDrewth 01:25, 22 November 2010 (UTC)
The original Arabic can be found at ar:تاريخ الطبر. The English translation appears to still be under copyright, so Wikisource could not host it at this time. --Eliyak T·C 04:39, 22 November 2010 (UTC)

Scanned page doesn't show up

I downloaded Index:The Amateur Emigrant-The Silverado Squatters.djvu but the OCR page doesn’t show up. If I click the OCR button for a page, a garbled version of the page pops up that is difficult to proof. Is there a way to fix this? (I tried to choose a clean djvu version to down load.) Thanks! Mattisse (talk) 13:04, 22 November 2010 (UTC)

I purged the file at Commons, and the text layer is now presented. — billinghurst sDrewth 13:45, 22 November 2010 (UTC)
That’s great. Thank you so much. Mattisse (talk) 13:48, 22 November 2010 (UTC)
Would you be willing to delete Page:The Amateur Emigrant-The Silverado Squatters.djvu/24 as that is a garbled version of the page? Then I could start the page over with a clean scan. Mattisse (talk) 13:55, 22 November 2010 (UTC)
Done Deleted the existing, and returned with the underlying text layer. — billinghurst sDrewth 14:41, 22 November 2010 (UTC)

Odd Hebrew Bug

This code 

<span style="line-height:200%; font-size:200%; font-family:Ezra SIL SR" dir="rtl">קִטֵּל</span>

shows:

קִטֵּל

The dagesh (center dot) is to the left of the letter ט, not in the center. The other diacritics are also shifted left. When I do not specify Ezra SIL SR as the font, it displays just fine. The problem appears to be with the way my browser(s) are displaying Ezra SIL SR, which is a great font otherwise. This issue arises because Wikisource's Hebrew language templates (specifically the ones used by Gesenius' Hebrew Grammar) specify Ezra SIL SR as one font option, and this font is in fact recommended at the top of the Gesenius' Hebrew Grammar page. I am using the latest Firefox and Chrome on Ubuntu 10.10, and this issue was also noticed by a user in Firefox on Windows XP. Any ideas?

I would also appreciate it if people would chime in to confirm whether they see this bug or not. --Eliyak T·C 05:07, 23 November 2010 (UTC)

It probably also has something to do with the way MediaWiki saves the Biblical Hebrew text. It may make certain changes on the way to the database (i believe that it's called "Unicode normalization", but i'm not sure; experts are welcome to correct me). For example, if you try to type the same word on the same computer in the same font in OpenOffice, it will likely look correctly.
The frustrating thing about it is that Ezra SIL SR is an excellent font for Biblical Hebrew, but that MediaWiki breaks it, even though the regular (read: shitty) Hebrew fonts, like David and Arial, display this particular thing correctly. The regular fonts cannot, however, display the Hebrew accents, which are required for presenting Biblical Hebrew.
In Windows Vista and 7 it looks fine - these operating systems fix the display back. (BTW, in Windows 7, the regular Hebrew fonts can even display the accents pretty well.) --Amir E. Aharoni (talk) 10:09, 23 November 2010 (UTC)
I'm using Vista and it appears just fine, as well (on both Chrome and FireFox).—Zhaladshar (Talk) 16:00, 23 November 2010 (UTC)
Looks fine in XP with FF 4.0, well maybe that should be they look the same. — billinghurst sDrewth 11:05, 24 November 2010 (UTC)
Hmm, uninstalling Ezra SIL SR and installing SB Hebrew makes this example display in the default font, and Gesenius' Hebrew Grammar look pretty. I guess the solution for certain systems is to install the SBL Hebrew font. I will note this at Gesenius' Hebrew Grammar. --Eliyak T·C 02:53, 28 November 2010 (UTC)

Hi everyone, the bug is here. Dovi (talk) 03:47, 28 November 2010 (UTC)

From what I've seen, this bug is only with the Ezra SIL SR font, possibly only on certain systems. A test on Browsershots.org gave no issues on all major browsers and OS's. However, I could see that the fonts on those systems were not Ezra SIL SR, which is necessary to display the cantillation marks in addition to the nikkud in Gesenuis' Hebrew Grammar, and perhaps other works. --Eliyak T·C 07:38, 28 November 2010 (UTC)

Making one of the layouts the default for a certain book

Look at Talk:Gesenius' Hebrew Grammar#Page numbers in left margin.

A reader is complaining there that he can't see the page numbers.

I do see them, logged-in and anonymous, but maybe there is a problem, indeed. And in any case, i would really like to have Layout 2 as the default for that particular book. Is there still no way to do that? --Amir E. Aharoni (talk) 10:02, 23 November 2010 (UTC)

We would need an answer from ThomasV, it is his adaptation. — billinghurst sDrewth 11:01, 24 November 2010 (UTC)

"Split without match"

I'd like to share an IMHO undocumented feature of Match and Split tool. When image source has no text layer, Match can't be launched obviusly; nevertheless a patient contributor can add manually Split codes into Ns0 text, marking the beginning of Page: pages. The "split codes" haven't anything "magic", they are simply links to the Page: pages into h2 tags in new lines, something like == [[full name of the page]] ==. Only take care to close poem tags before the code, and to open a new tag poem tag after, if page break falls inside a poem. The advantage is that text is moved into nsPage in a clean way when Split function is launched, and that it's cleanly replaced by a pages index tag into Ns0. --Alex brollo (talk) 09:10, 24 November 2010 (UTC)

The unusual applications of the tool—perhaps the name is misleading—takes advantage of its most useful feature: moving a section of text into the page namespace. I have used it to move a text layer from one file to another here, or from archive.org, by using subst: and {{Page}}. Another use is splitting corrected sections of ocr text, which may suit some peoples work-flow if there a large number of tedious fixes. (or missing chunks … ") cygnis insignis 10:36, 24 November 2010 (UTC)

Page:Hoyt's New Cyclopedia Of Practical Quotations (1922).djvu/26

Page:Hoyt's New Cyclopedia Of Practical Quotations (1922).djvu/26 is not scanned properly. Is there a way I can fix this, or does a repair require some technical permission? BD2412 T 23:24, 24 November 2010 (UTC)

For me, pressing the OCR button gives the result "undefined", and as it works for other pages on site, all I can guess is that it is struggling with something in the work. Looks like it will be a manual typing job. <shrug> — billinghurst sDrewth 03:01, 25 November 2010 (UTC)
I also had an "undefined" result when trying to OCR this page, which was generated by djvulibre's c44 function. I'm not sure if that could affect anything. In the end I just typed it up by hand. Anyone else had an "undefined" result from the OCR function? Inductiveload—talk/contribs 22:29, 28 November 2010 (UTC)

Is there a trick to doing interwiki links for left hand side to oldwikisource? Tried to add one for The faith of a Belarusian and it just sticks in the bottom as a plain link. — billinghurst sDrewth 17:20, 25 November 2010 (UTC)

Interwiki links to or from oldwikisource don't work, which is why other means like {{wikisourceold}} have to be used instead. A workaround is asking the developers to redirect a specific language subdomain to oldwikisource – for example, eo.wikisource.org redirects to wikisource.org, causing interwiki links with "eo:" to work correctly (example). There's no redirect in place for Belarusian, though... Jafeluv (talk) 23:42, 25 November 2010 (UTC)
bugzilla:26124 — billinghurst sDrewth 00:32, 26 November 2010 (UTC)

Prevent space between transcluded pages

Hi all. Is there a way to prevent a space from being added between two transcluded pages with the <pages> syntax? For example, if the first page ends with an em dash there should be no space between it and the next word. An example would be Page:Pierre and Luce.djvu/18, transcluded here. I've looked through the formatting templates but couldn't figure out how this could be done. Thanks, Jafeluv (talk) 21:10, 27 November 2010 (UTC)

Cheat. On the first page, add the text— to the bottom <noinclude> section, and then wrap the same text inside <includeonly> on the next page. Worth adding a comment inside <!-- --> on the first page explaining what you are doing. — billinghurst sDrewth 01:21, 28 November 2010 (UTC)
Genius! Thanks, Billinghurst. Jafeluv (talk) 01:38, 28 November 2010 (UTC)
Another way, essentially the same, it to use {{hws}}/{{hwe}}. cygnis insignis 03:38, 29 November 2010 (UTC)
I thought about that, but it would have produced an extraneous hyphen in the page namespace in addition to the dash. Jafeluv (talk) 09:45, 29 November 2010 (UTC)

bad scan

Index:Decline and Fall of the Roman Empire vol 2 (1897).djvu is a bad scan, and I was wondering if someone could find another scan and upload it? - Tannertsf (talk) 01:20, 28 November 2010 (UTC)

Have you checked archive.org and books.google.com to see what is around, especially noting variances of editions? — billinghurst sDrewth 01:22, 28 November 2010 (UTC)
Yes. I have found other editions, but not the ones with the sidenotes, like the edition we have on here (the bad scan). I'm looking for a sidenotes edition. - Tannertsf (talk) 01:24, 28 November 2010 (UTC)
I've re-uploaded a higher quality version from the same source. However, instead on relying on the IA's often sloppy transcoding, I used djvudigital (part of djvulibre) to transcode the original PDF to DjVu at a higher quality/lower compression ratio. Since there are no pages done yet, I've also removed the Google page at the front. Inductiveload—talk/contribs 22:26, 28 November 2010 (UTC)

Thank you! - Tannertsf (talk) 22:43, 28 November 2010 (UTC)

Xmas news and greetings

"Merry Christmas to one and All" was included in one of the extracts on the English Wikipedia mainpage for xmas day from wikisource. One of them got nearly a 1,000 views. The DYK jook said "Did You Know ...... that the Robert Haven Schauffler book for Christmas 1907 (pictured) included prose by Dickens and Washington Irving and an article on whether there is a Santa Claus?" I say this so others know that wikisource can get some marketing this way. Cheers Victuallers

Retrieved from "https://en.wikisource.org/w/index.php?title=User:Sanbeg/Wikisource:Scriptorium/Archives/2010-12&oldid=14665247"