Wikisource:Scriptorium/Archives/2013-04

Announcements

Wikisource top page hits for works 2011-2012

Ever notice when you look up page access data for a Wikisource page, sometimes you get a ranking? Have you ever wondered where the full ranking list is? If you have any ideas, drop me a line, because I don't know.

Anyway, we haven't had a list of top page hits for works for a while. Here is a list of top pages accessed in 2008-2009 based on 363 analyzed days and a 2011-2012 list based on two days.

2008-2009

1. Industrial Society and Its Future (1995)
2. Additional amendments to the United States Constitution
3. Constitution of the United States of America (1787)
4. United States Bill of Rights (1789)
5. Barack Obama's Iraq Speech (2002)
6. Washington's Farewell Address (1796)
7. The Science of Getting Rich by Wallace D. Wattles (1910)
8. Zodiac Killer letters
9. United States Declaration of Independence (1776)
10. "Because I could not stop for Death —" by Emily Dickinson (19th century)
11. "The Raven" by Edgar Allen Poe (1845)
12. "I Have Just Been Shot" by Theodore Roosevelt (1912)

2011-2012

1. United States Bill of Rights
2. Additional amendments to the United States Constitution
3. Constitution of the United States of America
4. Zodiac Killer letters (1960s-1970s)
5. "For the Fallen" by Laurence Binyon (1914)
6. Gettysburg Address by Abraham Lincoln (1863)
7. Korean Armistice Agreement (1953)
8. "I Have Just Been Shot"
9. Industrial Society and Its Future
10. Chinese Secret Societies by Frederick Boyle (1891)
11. Executive Order 13526 [Classified National Security Information] by U. S. President Barack Obama (2009)
12. Daphne and Apollo by Ovid (8 CE)

Dictionary of National Biography

Now here is a list of the top 26 25 most-accessed DNB articles from the same two days from 2011-2012:

1. Reid, David Boswell (DNB00)
2. Tenison, Thomas (DNB00)
3. Bucknill, John Charles (DNB01)
4. Shakespeare, William (DNB00)
5. Reynolds, Joshua (DNB00)
6. Edward (1453-1471) (DNB00)
7. Cameron, Charles Duncan (DNB00)
8. Field, John (d. 1588) (DNB01)
9. Bowes, Martin (DNB00)
10. Dacre, 23rd Baron (1814-1892) (DNB01)
11. Howitt, Mary (DNB00)
12. Lowe, Hudson (DNB00)
13. Pendlebury, Henry (DNB00)
14. Pillans, James (DNB00)
15. Taylor, Thomas (1758-1835) (DNB00)
16. Wordsworth, William (DNB00)
17. Carlyle, Thomas (1795-1881) (DNB00)
18. Ferguson, Richard Saul (DNB01)
19. Laud, William (DNB00)
20. Parkes, Harry Smith (DNB00)
21. Scott, Walter (1771-1832) (DNB00)
22. Sigebert (d.637?) (DNB00)
23. Southwell, Robert (1561?-1595) (DNB00)
24. Townsend, George Henry (DNB00)
25. Wallis, John (1616-1703) (DNB00)

ResScholar (talk) 05:29, 20 March 2013 (UTC) corrected 18:41, 21 March 2013

Popular Science Monthly

The top 21 articles from the same two days in 2011-2012 from Popular Science Monthly:

1. The Visions of Sane Persons - (August 1881)
2. Dr. Livingstone - (January 1873)
3. Sketch of Dr. Henry Maudsley - (March 1875)
4. Lace and Lace-Making - (March 1876)
5. Sketch of Thomas Alva Edison - (August 1878)
6. The Races of Mankind - (July 1881)
7. The Glass Sponges - (September 1873)
8. The Significance of Human Anomalies - (October 1884)
9. Professor Rudolf Virchnow - (October 1882)
10. Anthropology at the World's Fair - (September 1893)
11. Water-Waves and Sound-Waves - (June 1878)
12. Origin of the Plow and Wheel Carriage - (February 1881)
13. Plant-Cells and their Contents - (July 1882)
14. The Development of American Industries Since Columbus: Wool Industry II - (July 1891)
15. Moral Life of the Japanese - (July 1893)
16. The Growth of the Steam-Engine III - (January 1878)
17. The Growth of the Steam-Engine V - (March 1878)
18. On Radiant Matter I - (November 1879)
19. Optical Illusions of Motion - (February 1881)
20. The Longevity of Trees - (July 1873)
21. Biology for Young Beginners II - (March 1875)

ResScholar (talk) 08:08, 31 March 2013 (UTC)

Reflections on the Formation and the Distribution of Riches by Anne-Robert-Jacques Turgot, Baron de Laune released

Like many amateurs interested in the field of economics, I've studied a particular book on the history of economics called The Worldly Philosophers by Robert L. Heilbroner, which has sold more than four million copies, and even has a Cliffs Notes commentary dedicated to the work. But The Worldly Philosophers (the fourth edition at least) begins in 1776 with Adam Smith.

Reflections on the Formation and the Distribution of Riches by Anne-Robert-Jacques Turgot was written in 1770 and laid the groundwork for Adam Smith's Wealth of Nations in its treatment of how different economic actors add to the price and income of various income-producing properties as well as the medium of exchanging these properties, and like Smith's work, was intended to be read by generally educated adults of his time.

Turgot did not consider himself an economist, but his brief and broad analysis of the emerging market system of his time got it right the first time, perhaps because the market system of his time was not complicated by distracting exceptions to what was analyzable then.

With perhaps the exception of David Hume, with whom Turgot corresponded, Turgot may have been the first to explain the market system at large in the form of articulated general theories. If not, Reflections on the Formation and the Distribution of Riches at least serves as a valuable stepping stone for those wishing to go backwards from Adam Smith to understand the more isolated work of his predecessors in the scientific study of wealth. ResScholar (talk) 05:48, 6 March 2013 (UTC)20:05, 7 March 2013 (UTC)

Request for Comment on annotations and derivative works

A Request for Comment (RfC) page has been started for Annotations and derivative works. This is intended to determine the detail of Wikisource policy regarding annotations, translations, comparisons and any other form of derivative work. From the Derivative works proposal, there is a consensus that some form of derivative works are within our scope in general. This is intended to define the detail.

Anyone is encouraged to comments on any of the topics on the page. The topics are based on comments made in the derivative works proposal and in past discussions. Anyone is free to add new topics to the RfC if required.

I apologise for the long-winded and over-detailed nature of this discussion (Wikisource's first RfC of this kind). However, the topic was very contentious in the past and will likely cause problems in the future if we don't do something. At least this way we will know where we stand on the matter. If nothing else, we will be able to point future users to this page for reference. - AdamBMorgan (talk) 21:48, 6 March 2013 (UTC)

I am still reading through the work, but great job Adam! JeepdaySock (AKA, Jeepday) 11:49, 7 March 2013 (UTC)

Having read through it twice now, FANTASTIC JOB ADAM! That was no easy task, thank you for taking it on and doing such a great job of putting it together. Jeepday (talk) 02:30, 9 March 2013 (UTC)

Absolutely agree. This must have taken a great deal of time and effort.

And without detracting from the credit due to Adam, I'd like to add that in some online communities, it wouldn't matter how good a job Adam did, there would still be unconstructive quibbling over meta-issues like whether the right questions were being asked, whether the RFC was framed in a fair way, whether it had been advertised appropriately, et cetera ad infinitum. The constructive engagement we have seen here reflects very well on the health of our community. In short, we're awesome! Hesperian 02:38, 9 March 2013 (UTC)

MediaWiki 1.21/wmf12 due today

Fortnightly code update is due today for the Wikisources. My quick glance through the list doesn't show anything ground shaking for us. This notice is primarily to alert people to changes, and if they see that things have broken that they let the community know here so that we can report back to the hackers.

I note some aspects to mw:Extension:Score that we should really have someone nicely prodding people to get up to speed for a rollout here. I also note that there is a small addition in the left toolbar when in User: ns (mostly benefit for admins and especially 'crats). There are some coding changes under the hood of Special:AbuseFilter so those who watch that may wish to check for errors, or expected filters working as planned. — billinghurst sDrewth 00:45, 20 March 2013 (UTC)

Problem identified in wmf12, so they have rolled back to wmf11 in the past day. — billinghurst sDrewth 21:55, 22 March 2013 (UTC)

Problem has been resolved, and wmf12 will be reintroduced to the phase one and phase two wikis, which includes enWS imminently — billinghurst sDrewth 02:04, 23 March 2013 (UTC)

Proposals

Derivative works

The following discussion is closed:

General consensus is in support of derivative works in theory. Now on to the second part to determine the detail. - AdamBMorgan (talk) 21:36, 6 March 2013 (UTC)

This is the first of a two-part proposal. The second part will involve haggling over details. This is just a simple support/oppose question: Does Wikisource allow certain derivative works?

Derivative works are new, user-generated works based on other, pre-existing works. They are generally about making use of the wiki format to add value to these works. This would be a slight departure from Wikisource's stated policy of only allowing sourced, faithful reproduction of pre-existing texts. The list of allowed derivative works will be controlled; the current list is:

1. Annotations - examples: Category:Wikisource annotations (many wikilinked texts not included here)
2. Comparisons - examples: Category:Comparative texts
3. Translations - examples: Category:Wikisource translations

All three already exist on Wikisource but we do not yet have any agreed policies. Annotation (everything from wikilinks to additional maps and diagrams) in particular has been disputed for over a year now. That dispute is the reason I am making the proposal in this way, so we can resolve the yes/no question first and, if yes, move on to debating specifics when it is clear we are going to do this at all. For the others, Translation has remained just a proposed policy since 2006 and I only created the Comparison page a few days ago based on comments in a previous proposal.

Again, this is not about how we should do this, the question is if we will allow this or not. Please support, oppose or comment below. - AdamBMorgan (talk) 19:32, 13 February 2013 (UTC)

Opinions

• Support as proposer. - AdamBMorgan (talk) 19:32, 13 February 2013 (UTC)
• Comment — I'm all in for discussing all of them but my support or opposition to formally allow one or more of the three classes would hinge on the specifics eventually reached by the community for each. One may consider this a Support vote if that is the prerequisite majority threshold needed to secure the discussion phase however. -- George Orwell III (talk) 21:55, 13 February 2013 (UTC)

  I'm going to take this as a weak support, on the grounds that it theoretically supports derivatives in general (in a non-binding sense, pending further discussion). - AdamBMorgan (talk) 13:32, 14 February 2013 (UTC)

• Per George. If it were clear to me that links are not regarded as annotations, then I would probably oppose. Hesperian 01:00, 14 February 2013 (UTC)

  This I am taking as oppose, as noted. - AdamBMorgan (talk) 13:32, 14 February 2013 (UTC)

• Three distinct
  • Translations, in my observations has widespread community approval, numerous discussions have supported the retention of Wikisource translations here. Support promotion to a policy, under the belief that community approval exits, though as always details on the policy page may need minor updates. JeepdaySock (AKA, Jeepday) 12:00, 14 February 2013 (UTC)
  • Annotations Needs definition of scope, may fall into b:WB:WIW#Wikibooks_includes_annotated_texts. JeepdaySock (AKA, Jeepday) 12:00, 14 February 2013 (UTC)

    The scope was part of the problem last time: neither Wikisource nor Wikibooks really defines it, nor where the tipping point should lie between the two projects. Nevertheless, that's for the second stage, if we decide that at least some derivatives are theoretically acceptable here under certain conditions. - AdamBMorgan (talk) 13:32, 14 February 2013 (UTC)

  • Comparisons = Oppose Out of scope, a scholarly comparison would/could/should meet b:WB:WIW and should be hosted there. Anything else would be more appropriate at Wikipedia, or privately hosted. JeepdaySock (AKA, Jeepday) 12:00, 14 February 2013 (UTC)
• Support in principle the ability to have annotated works, though not to the detriment to the display of the original work in the main namespace, and similarly the output into exported books (electronic or paper). The technical ability may defeat the principle. For a purity sense, I would like for us to consider another namespace (Derivative: ns???) where we can house such works, though that comes with riders (not fully formed, and not even sure that completely technically possible). Further discussion held pending. Crowd-sourced translations have been determined to be housed here, and I can see that crowd-sourced annotations may too (conditions conditions conditions) providing we can find the right form to not detract from the original works. — billinghurst sDrewth 13:22, 14 February 2013 (UTC)
• I would not treat them the same way, too.
  • Translations: Support as long as there are not many user-made translations of the same work. We should specify their maximum number (just one of each work in my opinion), and make exceptions only after discussion.
  • Annotations: Oppose since they are accepted on Wikibooks.
  • Comparisons: Oppose since versions are listed on the version page and can be opened, downloaded, or printed as you like.--Erasmo Barresi (talk) 14:25, 14 February 2013 (UTC)
• I would support this proposal, but only based on my interpretation of the underlying classifications. Translations of a source text into English for hosting here would be acceptable only if they match the intent of the original without the injection of bias. Comparisons would in my mind be like what is described on the linked page, with different versions of a text shown side-by-side with differences highlighted; no analysis—this would simply be a useful tool. Annotations is the tricky one between Wikisource and my home project Wikibooks. Analysis and expansion of a source text's content in annotations in order to educate on a particular subject would be, in my mind, the realm of Wikibooks. What I picture at Wikisource would be annotations that help the reader understand the original on its own without going to a very high level. For instance, words that have changed in meaning since the original work's publication or words no longer in common usage could have notes as to what they would have meant when first written. If I'm looking to pin down a "tipping point" between Wikisource/Wikibooks annotations, one might be denotation versus connotation. The former at Wikisource, focusing on definitions, and the latter at Wikibooks, focusing on associations or suggestions. Adrignola (talk) 03:01, 15 February 2013 (UTC)
• Thought bubble about 'comparative. What could well be possible is to look for a 'twist' to the implementation of mw:Extension:DoubleWiki. The extension is used to compare two language versions of a work (interwiki), maybe it is possible to implement a comparative intrawiki, two side-be-side versions of the work as a display function, rather than as an artificial construct. If it could be done easily, then great, if a whole lot of work, and it doesn't prevent works being done. — billinghurst sDrewth 10:08, 15 February 2013 (UTC)

  I was thinking along the same lines but held off on mentioning it until some obvious issues were addressed. First and formost, this extension is another ThomasV abandoned step-child left to nobody-in-particular's care without much notice or guidance left by the coder. Thanks to that, it is woefully behind the latest changes and greatest advancements. In spite of all that, the extension still "works" pretty much as advertised -- but since there are no agreed upon standards & practices between the various language WS wikis -- its usefulness has been hit or miss. Its been under-utilized in general since its introduction.

  For those unfamilar with the extension, see an example with it in action using one of our local versions of Poe's, The Raven, see HERE. The functionality might render better for some if viewed from the French Wiki as the primary site back to us instead... see HERE for that option. In short, this extension might open up options on more than just the comparison front and deserves further attention. -- George Orwell III (talk) 00:56, 16 February 2013 (UTC)

• Support Annotations, Translations and Comparisons. Annotations: I support wikilinks and deannotations, which George classes as an annotation. As for regular annotations, I only remember seeing one here, The Annotated Strange Case Of Dr Jekyll And Mr Hyde. I don't remember the concept ever taking off, but would be glad to examine any more examples available to view. ResScholar (talk) 10:22, 15 February 2013 (UTC)

I found the Annotations category and added a link to the category (along with the others) to serve as examples next to the C-A-T list, then added seven more annotations (which have wikilinks only). ResScholar (talk) 09:50, 16 February 2013 (UTC)

• Support all. WS should be open to some text supplimentation, that does not meet the standard of a seperate WB.--T. Mazzei (talk) 02:48, 22 February 2013 (UTC)

Two-factor Actions

Personally I consider one of the bedrock strengths of WikiSource is the use of the ProofreadPage model where the agreement of at least two users is required before a page may be considered "acceptable."

I don't want to go too overboard with this, but what is the communities feeling about extending this idea into other areas?

We already have the concept of "unreviewed" Portals (although on a personal level more guidance on how to "complete" reviews would be nice to have!)

May I be so bold as to suggest a two/three-step model for block reviews. A recent example might illustrate:

1. I (a user) happened to note an odd "anonymous" edit to these pages: Author:Banjo Paterson and Author talk:Banjo Paterson. Suppose I (somehow) raise a "please review" request.
2. An administer acts upon this and perhaps decides to block said user. They raise a "please block" request.
3. A second administrator sees the block request and review justification and acts upon it.

The first step may be omitted if the initial observation was by a supervisory individual (as in fact happened in the case of this example―thanks Beeswaxcandle!)

I reiterate, I do not wish to go overboard with this, and mandate program enforcement of these things. Simple procedural rules for "normal exceptions" might be quite adequate; with suitable let-out clauses for genuine emergency situations. Guidelines please―not bureaucracy!

Is this worth pursuing at all? MODCHK (talk) 05:18, 5 March 2013 (UTC)

Discussions about proposals to vary the blocking policy would be best at Wikisource talk:Blocking policy, and a note here if we are having a stronger attempt at an update.

In short, to me a block is a few steps down the defence line, not the first. I wouldn't favour the approach as default, but would always encourage admins to err on the side of safety, and try to eliminate wherever possible collateral damage. All users, and especially admins, patrolling/looking through Special:RecentChanges should see account blocks, and have a glance, for interest alone, let alone light review. Good for users as we love to spread the joy and promote them to admins; and for admins as that overview is beneficial element in a community. [I removed the "in long"] — billinghurst sDrewth 06:36, 5 March 2013 (UTC)

Addendum. The admins have the tools, and trusted by the community to do certain things. Relying on admins is not the purpose nor the benefit, as all community users are able to do undo, discuss, and recommend for deletion. As I believe that I have said before, the tools are a hierarchy, the people are not; we don't want a high bar to jump to be an administrator; it is knowing when to use the tools, and when not to, and to know how to use your local understanding of the wishes of the community,; our trust in people to keep within their limitations. We don't get it right every time, and as we are all humans, that has to be okay, and understood, as we look to intention and purpose. — billinghurst sDrewth 06:46, 5 March 2013 (UTC)

I would also add that any autoconfirmed editor who notices a bad edit can undo it and any editor can tag a page for speedy deletion with {{sdelete|reason}}. Putting this template on a page will bring it to the attention of an administrator who will evaluate the request and act on it as appropriate. Beeswaxcandle (talk) 06:49, 5 March 2013 (UTC)

At the risk of dragging this discussion back to its origin, I seriously meant should the community think about how to utilise the strengths of check-and-balance procedures for all sorts of situations. Perhaps using the block case was a mistake at this moment in time. I meant to generalise the issue, not bog down in sensitive matters. MODCHK (talk) 06:51, 5 March 2013 (UTC)

From a purely logistical point of view, requiring two admins for a block is problematic. Because we don’t have 24/7 coverage with two admins here. Nor is there anyway to know at any given time how many admins are available. Jeepday (talk) 12:14, 5 March 2013 (UTC)

I reiterate, the intended purpose of this proposal was neither sanguinary, nor to make life difficult in cases where backup truly is temporarily unavailable. ("I did this; when somebody else gets a chance would they please approve the action" is an entirely acceptable workaround.) I merely wish to draw attention to the great strength that (small, intelligent) group action has over that of individuals.

On the other hand, I would fight tooth and claw against over-expansion. (Committees may be good at policy but not necessarily action.) MODCHK (talk) 22:19, 5 March 2013 (UTC)

┌─────────┘
Oh, and the other aspect is this idea which I realise I completely omitted to express:

• This is a golden opportunity to disseminate knowledge!

In reviewing any given action, both parties are effectively bouncing ideas off one another, and the more experienced member is being reminded why and how their otherwise seasoned (unthinking? habitual?) response is the proper one in the given situation.

Blue sky or what? MODCHK (talk) 22:48, 5 March 2013 (UTC)

The block logs are available for public review. There is more then one avenue of accessing them, the easiest would be through the link Special:BlockList which is available from the Special:SpecialPages link in the toolbox of links. There is also the block log which is available via Special:Log and selecting Block log. All it takes is a desire to review. It requires admin access to actually block a user, and all are accountable to the community for actions taken. The tools is fairly robust and it looks like I (as Jeepday) have blocked 2 users here, (and a few hundred at Wikipedia, wow). There is no hard fast rule for when to block or decline, nor any strict guidelines on how long to block for. In every case, there is a volunteer who has been given the admin tools trying to make a guess at what will have the most positive impact on the project as a whole. If you have an interest I would encourage you to discuss any questions you have about a block with the blocking admin. I get questions at w:User talk:Jeepday fairly regularly, though usually the question is "why did you not block user:foobar for life?". And of course if you don’t get a satisfactory response you can bring your questions to Wikisource:Administrators' noticeboard. JeepdaySock (AKA, Jeepday) 11:47, 6 March 2013 (UTC)

I was loosely aware of said logs, but thank you in any case for the links.

However, I still feel there is a world of difference between:

• "The world could/might(not?) have looked at this action; and thus far has not actually complained about anything," and
• Another party has actually stepped forward and announced "I also approve of this action."

Obviously I have used slanted language to emphasise the point, but the first alternative could be accused of encouraging any dubious party to hold their peace for fear of ridicule; whereas is there is a culture of the latter then a lack of response indicates a degree of community reserve.

As an aside, as a user comparatively unfamiliar with the use of the logs I sometimes find I confuse log updates of this nature with updates to a page: Something pops up in a watchlist; my mind fleetingly notes (if I am paying enough attention) the change comment and then I confuse myself by not being able to find the associated change. Eventually the message filters into my tiny mind to check "View logs for this page" and there is the "missing" entry. (Personal early-onset Alzheimer's or is this a common experience? Others may judge.)

I trust this goes some way to explaining my attitude. If there really is a consensus this proposal is likely to be too onerous in practice I am of course happy to let the idea slide. MODCHK (talk) 16:08, 6 March 2013 (UTC)

And (sigh!) for the third time «It Isn't All About Blocking.» I would like to maybe trigger some thought about extending the existing review culture for Author: pages; for Portal:s; for ... basically everything on WS outside of User:, talk and Page: space. For both item integrity and training purposes. Do I need to put this in idiotic management language for the message to get through? Mentoring relationships (I think I shall go off and be quietly ill now.) MODCHK (talk) 16:54, 6 March 2013 (UTC)

In any case (blocking, Author or Portal) every edit/change is publicly available. For new editors they show up on Special:RecentChanges as un-patrolled until someone feels they have sufficient experience to generally make the best choice and promotes them to auto-patrolled. No matter what level of volunteer. There is progressively less ongoing oversight (though all remains available) because we assume at the next level you will make the best choice you can, and ask for help if your not sure.

We don't have a structured mentoring program, though it has been implemented here and there, now and again. The w:Wikipedia:Mentorship exists but, I only occasionally see it put to use.

Again it comes down to logistics, at every level we have significantly more tasks then resources. To expand validation as a mandatory task you would need to start with rationale on why it is required (voluntary and background validation, are present and functioning). I hear your frustration and I hear you have an idea that could result in higher quality in some areas of Wikisource. But I am not hearing about a specific list of problems that need corrected. You would also need to create motivation for volunteers to spend time on this instead of other tasks. You might want to look at w:Wikipedia:Approved article revisions which deals with a similar idea for validation.

In short you have an idea that would benefit Wikisource, but you have not shown a cost benefit analysis that convinces anyone to support it. Do we have room for improvement? = Yes. Is there a specific problem that needs to be addressed and rationale sufficient to neglect other tasks in pursuit of the new task? = Unclear. JeepdaySock (AKA, Jeepday) 18:06, 6 March 2013 (UTC)

No problem. This argument and criticism I completely accept. Apologies regarding frustration―I was beginning to feel people were fixating on the specific at the cost of the general, and buzzword introduction frequently invokes if not nausea then at least healthy revulsion.

In my humble experience mentoring is rarely ever paid anything more than mere lip service. Also interesting that your other link is all but tagged as a dead article.

I unconditionally withdraw the proposal. MODCHK (talk) 18:37, 6 March 2013 (UTC)

There is nothing stopping you from setting up a Wikisource Mentoring program. In my experience successful programs require three items.

1. An established program that offers the opportunities for Mentors and Mentees to meet.

2. A group of willing Mentors

3. One or more Mentees.

JeepdaySock (AKA, Jeepday) 19:47, 6 March 2013 (UTC)

Only three disabilities from my personal perspective:

1. No ability.
2. No patience.
3. I could not keep a straight face.

(O.K. I accept nobody need know about the last one. MODCHK (talk) 19:57, 6 March 2013 (UTC))

Other discussions

Enhanced editing toolbar

Do any of our experienced users use the beta feature "enhanced editing toolbar"? I would like it to be removed from the options to select as it causes far more problems than it's worth. Custom buttons don't work with it; and it often doesn't behave in expected ways in the Proofreading extension. I have been recommending users who are having problems to turn it off and the problems have gone away. Is anyone successfully using it? Beeswaxcandle (talk) 18:35, 20 January 2013 (UTC)

I've been using it since I think the Vector rollout without problems. It's possible to add custom buttons, it just involves different code. If you'd like I can try to convert any specific buttons. Prosody (talk) 21:43, 20 January 2013 (UTC)

If there are specific problems it could be helpful to check if there are already bug reports about them: https://bugzilla.wikimedia.org/buglist.cgi?component=WikiEditor&resolution=--- --AKlapper (WMF) (talk) 13:15, 24 January 2013 (UTC)

Hi Andre, it is just a beast to customise. At enWS we have numbers of specific code often templated or tags, that we can add, some related to a specific set of large works, so we can have something like <section begin="blah" />text<section end="blah" /> (for which I have buttons in the old toolbar via Special:mypage/common.js (obviously mine though), and we have copyable code/examples at Wikisource:Tools and scripts/More editing buttons.

Krinkle pointed me to mw:Extension:WikiEditor/Toolbar customization which may be right, but for those of us less js competent, it isn't necessarily helpful. After I whined, he created m:User:Krinkle/Scripts/InsertWikiEditorButton which he seems to have refined since I last looked. We did have some early specific early problems with the toolbar that Brion had to do some work to add things like header/footer toggle due to some of the coding of Proofread Page]]. In the end, I think that many of us gave up and just kept our old toolbar, it suited in conjunction with tweaks to mediawiki:edittools, and the new toolbar was just "meh!" Of course, we could all just be dinosaurs.

Can I also say that I believe that it is really should no longer be labelled beta feature as Brion and all have stated that it is now the toolbar and we aren't going back. — billinghurst sDrewth 16:47, 24 January 2013 (UTC)

For what it's worth, I feel somewhat vindicated. I studied and tried implementing all the help links referred to above, and finally gave up. By now I accepted that custom toolbar design and implementation is a very complicated process, especially in a [mostly] volunteer supported free software. Adding to this the variety of text editor versions offered, and preferred, success will elude developers and users as long as an advancement leapfrogs another.

It would have been nice to implement some wiki code based custom buttons, but since there are constant problems, I recommend Windows users wanting keyboard macros to install AutoHotKey because they work everywhere. I can help with the basics and when don't know the answer, I will say so and where to find the answer.

While the lack of necessity hasn't forced me so far, I am planning to study and implement both Ubuntu/Linux and Mac OS X based keyboard macro tools, having recently acquired access to both. — Ineuw talk 08:22, 20 March 2013 (UTC)

poem gap

I've made mention about this (skirted around the subject) a couple times in the past, but I was wondering if it was possible to create a poem gap ({{Pgap}}, e.g.) that would be based on the emspace (one emspace by 'default'), but could be manipulated much like the {{gap}} is, where you can set the width manually. This would give more flexibility with poetry indentation, and the benefit with using an emspace as the basis is that it renders more accurately than the current {{gap}} when copying/pasting text. Any thoughts? Londonjackbooks (talk) 22:49, 19 February 2013 (UTC)

gap is meant to be able to be utilised for the situation that you described, so it would be better to fix what we have, rather than create a different solution and then have to retrofit. Hesperian derived the original logic, and for the life of me I cannot remember why this was the evolved solution. Maybe he can comment. — billinghurst sDrewth 11:53, 20 February 2013 (UTC)

Sounds good. There's no "problem" with the {{gap}},—It does what it is designed to do here visually. It is possible to use {{gap|1em}} for a shorter width, but it is primarily the copy/paste issue that I was wondering about which the use of emspaces seems to solve. {{gap}} as it stands renders one space in copy/paste per gap; emspaces render one emspace per emspace. Just an example of me being picky again. Londonjackbooks (talk) 13:22, 20 February 2013 (UTC)

If I understand LJB's proposition correctly, what you want is an em-space variation of {{bar}}? This would not be hard to create (simply copy {{bar}} and change the constant from "—" to " " in the {{loop}} call); but modifying {{gap}} would be next to impossible, the problem being what exactly would {{gap|1}} mean―a 1px »«, 1em »«, 1en »«, 1% »« etc. space gap? If the poor template cannot be coded to figure out what to produce (currently: »«), how can a sensible cut/paste result even be reasonably expected?

Although I know this solution is not popular with some editors; I have in the past used {{em}} as shorthand for {{gap|1}}. However this would have (even worse) cut/paste characteristics than {{gap}}. Any further arguments for/against? MODCHK (talk) 22:42, 2 March 2013 (UTC)

What to do?

Greetings all,

"We" are in the process of proofreading a work, Index:Eight chapters of Maimonides on ethics.djvu, where the last section, about 50 pages, is a supplement to the main topic making up the majority of the rest of the book. It is primarily in Hebrew, which is a language read from right-to-left. The oddity causing an issue in this case is that the page progression for this last section starts at the end of the Index: and works its way back towards the front until it meets with the end of the primary body of text.

I'm assuming this is (or was) the proper way to read the text of a right-to-left based language such as Hebrew and that is why it was published that way originally. The Hebrew portions (the majority in that supplemental section) is annotated in both English and Hebrew but still follows the back-to-front layout.

A contributor has marked the Index: as having a structural issue with its associated source file and that it needs fixing in order to properly continue proofreading the work. At face value, this seems to make sense since there is no way to "reverse" the transclusion order using the normal <pages> tag - we'd have to use 50 some-odd individual commands in reverse page-range ordering to keep the top-down reading aspect of these pages when they are ultimately transcluded to the mainspace. Re-ordering the page progression for this section is possible with some effort but maybe the use of 50 some-odd page tags is unavoidable regardless in order to 'stay as true as possible to the original work as published'.

Any thoughts on how (& why) "we" should proceed here? -- George Orwell III (talk) 12:13, 27 February 2013 (UTC)

Having little actual knowledge, I would lean towards leaving the index as is. I would assume that a person who is reading right to left would push the "<" button to get the next page the same as I push the ">" when reading left to right. Not sure how the main space alignment would be. Does the top of djvu/176 go above or below djvu/175? JeepdaySock (AKA, Jeepday) 16:42, 27 February 2013 (UTC)

The bottom of djvu/176 should be "touching" the top of djvu/175 the way I see it. I like the rationale you laid out though - if we were reading the physical book in our hands, we'd have to flip to the last page to start reading that section from it's begining so your arrow logic makes sense that way too. -- George Orwell III (talk) 01:02, 28 February 2013 (UTC)

Either shift the whole work (en and he) to oldWikisource as a multilingual work, or we just do the English pages, and mark the others as empty for interwiki. The former means that we shift the problem, the latter would allow for a mixed and shared solution. I don't see why we would be too concerned about a RTL (right to left) component that we are not transcluding. Wikis configs are set per RTL language (Aeb/Ar/Arc/Arz/Azb/Bcc/Bqi/Ckb/Dv/En_rtl/Fa/Glk/He/Khw/Kk_arab/Kk_cn/Ks_arab/Ku_arab/Mzn/Pnb/Ps/Sd/Ug_arab/Ur/Yi) which is by language setting. — billinghurst sDrewth 21:55, 27 February 2013 (UTC)

The "concern" was over the usage of that particular Index: status and this discussion was started to support the eventual removal of that status. The solutions, which I totally agree with, that you've laid out deals with the continuation of the proofreading process after the bang to stop proofreading is removed however. I'm trying to change is the status back to something that allows for those solutions to move forward.

The only point I'm not clear on is if a RTL is suppose to be transcluded so the that resulting effect would not only be reading right-to-left but from the bottom of the screen up towards the top as well. If that is acceptable (or the application of 50 some odd pages commands in reverse in the mainspace is acceptable), I can wash my hands of the notion that the file needs structural adjustment in good conscience no matter where it winds up being fully or partially transcribed. -- George Orwell III (talk) 01:02, 28 February 2013 (UTC)

A quick check on heWS would suggest that top down is fine. The real challenge will come for Tpt's export tool when there are sequences of pages in LTR and RTL in the same transclusion. Beeswaxcandle (talk) 02:25, 28 February 2013 (UTC)

Hello! A few notes from the person who suggested the change:

• This edition of Eight Chapters by Maimonides was edited by Joseph Isaac Gorfinkle, and is based on the translation of the original Judeo-Arabic to Hebrew by Samuel ibn Tibbon, in the late 12th century. It includes three parts: An introduction, an English translation of the Hebrew translation (with notes), and a critical edition of the Hebrew translation by ibn Tibbon with English notes.
• Hebrew is read from right to left and top to bottom: if we have the Hebrew text as part of the work, then having the file transcluded in its current order would make it impossible to read normally.
• Another problem with the current file is that it makes the page numbering in the index file is mistaken, since the Hebrew section has separate numbering than the English.
• I don't know what the rules for inclusion are: However, wherever the Hebrew pages are going to be typed, whether here, in the Hebrew Wikisource, or in the Multilingual Wikisource, the file would need to be changed, since it is in the wrong order even with a Hebrew interface.

Inkbug (talk) 17:40, 2 March 2013 (UTC)

Table within body of text similar to a Table of Contents

How would I go about creating the Wikisource version of the table in the middle of this page from Practical Treatise on Milling and Milling Machines? I recall seeing some sort of Table of Contents template before that would do something similar, but I can't recall its name or find it, and I'm not even sure if it would work. Advice? —Kierkkadon ^{talk/contribs} 19:43, 1 March 2013 (UTC)

I would do it as an ordinary table and not worry about the leader dots, but the templates you're thinking about are {{dotted TOC page listing}} or it's alternative {{TOC begin}} and {{TOC row}}. Beeswaxcandle (talk) 20:16, 1 March 2013 (UTC)

Oops. I just employed {{dotted TOC page listing}} on this page as an example. Feel free to remove if you don't like the result. MODCHK (talk) 18:05, 2 March 2013 (UTC)

Link do Wikidata

I added into User:Alex brollo/common.js a tool slightly modified from the version suggested into wikidata; it adds a link to wikidata item for pages when an entry to wikidata exists (with the same pagename of a ns0 or nsAuthor paga here) into Toolbox; but it saves too the whole object read by ajax call to wikidata into a $("body").data() container. It seems to run (I tested in some Author pages) and perhaps you'll find it useful. Similar tools are running into it.wikisource, Commons, it:wikivoyage and old.wikisource. --Alex brollo (talk) 17:51, 4 March 2013 (UTC)

OCR for music ?

Whilst talking with the Musescore Community about various things someone mentioned that MuseScore 2.0 may have features for Optical Music recognition.

In the disscusion one the Muescore devs also mentioned Audiveris - http://audiveris.kenai.com/

Does anyone from Wikisource want to do some pilot tests, with a view to getting the Wikisource Music collection into formats other than Scans? (like MIDI).

I appreciate I'm not exactly flavour of the month at the moment, but thought the community may be interested in possible technical innovations that might be useful to the project. ShakespeareFan00 (talk) 23:02, 6 March 2013 (UTC)

You might want to search the Scriptorium archives for previous discussions on this. From memory there have been several discussions around installing extensions etc, but nothing has ever come of it. That's not to say we can't have a fresh discussion about it now; I'm just letting you know that there is context that you might like to familiarise yourself with. Hesperian 01:23, 7 March 2013 (UTC)

As group we tend not to hold grudges, and try to value each suggestion on it’s own merits. As Hesperian has suggested look though the Scriptorium archives, to find old discussions you may find user with an interest that have moved away from Wikisource but are still active on other projects. As I recall most of the past conversations have been about technical difficulties of posting music here. As long as the copyright is ok, music would fall into Wikisource:WWI#Analytical_and_artistic_works. JeepdaySock (AKA, Jeepday) 11:39, 7 March 2013 (UTC)

There was some code added to replicate Lilypond, and the bugzilla request is listed at oldwikisource:Wikisource:Wishlist — billinghurst sDrewth 14:25, 7 March 2013 (UTC)

bugzilla:33193 — billinghurst sDrewth 14:26, 7 March 2013 (UTC)

seems to be waiting on bugzilla:43388 which seems to have had a patch this week, so my guess will be that it will be put onto test in the next round, and if all goes well, it may be out with 1.21wmf12 or thereabouts

The main problem at the moment with music OCR is that there's currently nowhere here for the output to be accepted, interpreted and then reproduced. There's also the problem of poor scans as music OCR needs scans of a reasonable quality. I've been holding off on doing music for the extension that Billinghurst mentions. Beeswaxcandle (talk) 18:19, 7 March 2013 (UTC)

Find and replace

I've started using Firefox add-in FoxReplace to assist proofreading/fix common ocr errors. It works fine. Just wondering if anyone else uses it or something similar. Moondyne (talk) 07:34, 7 March 2013 (UTC)

I use Fire fox find (out of the box function) to find things, but I manually copy and paste corrections. JeepdaySock (AKA, Jeepday) 11:32, 7 March 2013 (UTC)

I am still utilising scripts based on P/child's old regex script with my customisations (initially stolen from Hesperian). — billinghurst sDrewth 14:22, 7 March 2013 (UTC)

Tanakh pages

In the interest of cleaning up Bible, I'd like to clean up our two Tanakh pages. Tanakh was apparently copied from [1], and Bible (Jewish Publication Society 1917) was copied from [2], and is being slowly migrated to a set of djvus. Both of these websites have the Jewish Publication Society translation of 1917 as their source, which is also what the djvus are. I think Tanakh should be a translations page to disambiguate these two, and it should be linked in a section of Bible. My question is, what should Tanakh be moved to? --Jfhutson (talk) 15:45, 7 March 2013 (UTC)

On second thought, it appears that Tanakh contains comparison with Hebrew. I suppose the outcome of the current derivative works discussion will bear on whether this should be kept, but perhaps Tanakh should be moved to something like Tanakh (interlinear) if it is to be kept. --Jfhutson (talk) 16:55, 7 March 2013 (UTC)

We have implemented our first Lua module

I have implemented {{raw image}} as a Lua module; see Module:RawImage.

(If you have no idea what I'm talking about, see Wikisource:Scriptorium/Archives/2013-03#Scribunto extension roll out planned for February 18 above for context.)

Just letting the community know that we have dipped our toes in and have some some experience and a working example to draw upon. I am happy to help out while we are building capacity; just let me know what you need. Hesperian 05:43, 10 March 2013 (UTC)

WoW!! The new extension(s) look to be very promising - Congrats.

Can it be utilized any to cut down on our current reliance on some of the more heavily used local/imported old-time javascripting (.js) around here? By now I'd give my left nut to have MediaWiki:PageNumbers.js divided up into its separate functions (or phased out entirely if possible) for example. -- George Orwell III (talk) 06:38, 10 March 2013 (UTC)

mw:QA/Browser testing/Search features March 13, 2013 at 17h UTC

I am not sure whether anyone is able to be in IRC at the above indicated time to assist developers, but if someone can that would be great. Personally I will be unable to attend, wrong time of day/night. — billinghurst sDrewth 07:21, 13 March 2013 (UTC)

This is important for enWS as this is because the text for our transcluded pages do not show up in internal searches of the main namespace. The reference on the linked page t <pages index=".djvu" from= to= fromsection="" tosection=""/> is ours. — billinghurst sDrewth 07:23, 13 March 2013 (UTC)

Meetup & videostream tomorrow - focus on Lua

Tomorrow's meetup at Wikimedia Foundation headquarters in San Francisco focuses on how Lua as a templating/scripting language improves our sites, and includes a brief introduction to Lua. It'll also be streamed live on the web, and the video will be posted afterwards. Please feel free to visit or watch! Sumana Harihareswara, Wikimedia Foundation Engineering Community Manager (talk) 15:46, 13 March 2013 (UTC)

United States Reports needing aligning to style

Looking at United States Reports/Volume 1, the style looks to be a little at variation from the current style (well, as I was believing that we were looking to do). The works are not subpages of the volumes they are all sitting at top level. Where the subpages are not transcluded there is a link to openjurist.org. Volume 1 is all proofread but is in need of further transclusion, and looking at the work there doesn't appear to be a rigour to the process. Seeking other opinions, especially from those more familiar with the work and the project. — billinghurst sDrewth 08:47, 15 March 2013 (UTC)

<Sigh>... I've brought this [now realized] eventuality up with the "other" USSC Project contributors once or twice before and never did get a concrete path forward on this from the group. Part of my POV back then, one that was was shared in general at the time, was not to sub-page any of the U.S. Reports' published court-opinions until we had an entire volume or two transcribed & PR'd against actual scans rather than starting to do that break-out (re)using the bulk-importations that make up the majority of the pages already created under that project even today. Obviously, that has happened now with the opinions from Vol. 1.

Beyond that small, initial agreement, several questions remained on how best to name each opinion so that (in priority order - to the best of my recollection) a.) external search engines would absolutely recognize and incorporate the case name or names we applied as part of the list of the most-likely-to-be-searched ones for the best search results; b.) mirror the Wikipedia project (or projects?) well enough so that wikilinking to specifics within an opinion hosted here would just be a matter of setting up some templates to handle that over there; and c.) coming up with a new manual of style that did away with the "custom" navigation templates as well as the current practice of using additional subpages for per judge concurrence/dissents/etc. among a few other Wikisource specific issues that also needed resolving.

Using the "proper" full case-names (ex. Galactic Pecker & Company vs. Woode, Stiffey, Polle and Wang, LLC) wasn't a popular choice for a standard because some proper case names are too ridiculously long to be considered universally practical. The "common" or "short" case-names (ex. Pecker vs. Woode) wouldn't do well in terms of a.) (above) apparently and most likely run into disambig issues here because some shortened names would tend to repeat. Using the case volume/start-page citation (ex. 102 U.S. 257, Pecker vs. Woode) as a prefix, suffix to the short case-name or by itself wasn't agreeable for much the same reasoning as before - even with all the combination of redirects being built at the same time. So while I agree its time to finally decide on an approach - I have little in the way of a supported recommendation to add here unfortunately. -- George Orwell III (talk) 03:36, 16 March 2013 (UTC)

I think that they belong to the published work, so should be produced as part of the published work, hence as subpages. If someone wishes to create redirects to the subpages as a root name, and from a disambiguation page at the root, that is their prerogative, after the works is transcluded as a work. — billinghurst sDrewth 12:02, 21 March 2013 (UTC)

US Legislation

is there interest with teaming with the Cato Institute w:Wikipedia:Meetup/DC/Legislative Data Workshop to work with; upload their legislation data with xml in a systematic way? Slowking4 (talk) 16:24, 15 March 2013 (UTC)

To flesh this idea out a little: Cato is creating (separate from Wikimedia) a system for marking up bills as they go through the U.S. Congress. We're exploring ways to use this project to enrich Wikimedia content. This could mean Wikisource pages for significant bills, and also Wikipedia articles about the most notable ones. We're still in a brainstorm mode, but interested to know if there are Wikisourcers interested in working on something like this. Have there been any similar efforts in the past? -Pete (talk) 17:43, 15 March 2013 (UTC)

Putting aside the issue of proposed legislation being considered as works "still in flux" or "ongoing" we might have here on en.WS, the idea sounds interesting enough but maybe for slightly different reasons.

First off, this sounds an awful lot like www.GovTrack.us which pretty much already does a fair if not good job of tracking recent/current legislation. That, and the existing Library of Congress' THOMAS site, make it seem like your collaboration won't be anything new or different compared to those two already popular, long-established legislation web-portals.

The only point that comes to mind on however-we-would-wind-up-hosting-similar-stuff-here not currently being serviced by those type of external legislation sites would be the ease of anchoring & wikilinking to a specific section or sub-section(s) being hosted here that would further illustrate, illuminate or validate some point being made/added in the main WP article there. Right now, most good WP citations link to a copy of the legislation and gives the Division, Title, Part, Section, Sub-section, etc. in question but leaves it up to the reader to find that sub-division on their own and assumes the reader is familiar enough with legal formatting to successful do that at the same time. By using anchors and wikilinks, we have the advantage of easily directing the user's browser from WP right to the line(s) being cited there on WS, while the other sites make duplicating that an adventure in itself at best. -- George Orwell III (talk) 04:59, 16 March 2013 (UTC)

my understanding is that Cato is adding xml coding to the GovTrack, to make bill language machine readable, and key word searchable. but it's in their database. so what would a Cato <-> wikisource mapping look like. i note we have a United States Statutes at Large; and Portal:Acts of the United States Congresses. how could we standardize the bill templates and metadata upload? rather than do by hand, since hands can do the historical backlog. is this more suited for wikidata? Slowking4 (talk) 22:53, 16 March 2013 (UTC)

I cannot speak to what Cato claims or actually does but having an XML formatted copy of the legislation really isn't all that big of a deal (see a typical XML example linked HERE on a THOMAS sub-page for a recent bill for instance). Its how that XML was/is parsed into something WikiWhatever & the WikiCode can recognize and render that is the key to unlocking all this. Since most bills/laws follow the same basic format and layout over and over again, all those 3rd party entities (and maybe Cato as well) have developed their own specialized .DTD files to automate most of the converting/editing needed to always make Bill content "fit" the various print or electronic end products out there. We would need to develop something along those same lines; to read, recognize, reformat and render as needed but defined specifically to automate any conversion/editing needed to work with the current wikicode instead. And I don't think any of this falls under WikiData's scope or mission but I'm not all that familiar with them to be 100% sure about that. -- George Orwell III (talk) 00:26, 17 March 2013 (UTC)

Vanishing header and footer content

Whenever I edit a Page: namespace page, whatever was in the header and footer vanishes and I have to type it in again. Is anyone else experiencing this?

This occurs for me even if I am logged out. But it doesn't occur when I use a different browser. I am using Aurora 21.0a2 at the moment — Aurora is the alpha version of Firefox. I am wondering if any of the mainstream browsers are behaving this way too. If not, then I guess it is a bug in Aurora.

Hesperian 14:09, 21 March 2013 (UTC)

With firefox 19.0.2 is OK for me.--Mpaa (talk) 18:14, 21 March 2013 (UTC)

Ditto for me. This page has intact header data for me. Have you turned off your javascript and see what is currently on the page? Or even just looked at the source code to see whether it is a complete vanishing act, or a display issue? — billinghurst sDrewth 09:11, 22 March 2013 (UTC)

Confirming problem exists for me on that example page. No, it isn't a display issue; if I save, the header and footer are removed. I guess it's an Aurora bug. Hesperian 11:09, 22 March 2013 (UTC)

William Robert Maurice Wynne of Peniarth (1840–1909), lord lieutenant of Merioneth,

Was anyone aware that William Robert Maurice Wynne of Peniarth (1840–1909), lord lieutenant of Merioneth, had an illigitmate son? His name was Francis Howard and he was raised by the then Lady Harlech. He grew up alongside Lord Keynon of Gredington, though 'Frank' was older. His daughter, Eve Howard was my mother and she died on 27 February 2013. Her stepmother destroyed much of the paperwork relating to grandfather's parentage as he was very secretive about it. (It was a big slur in those days, and he was a career naval officer). We still have a copy of a letter written by his mother Katherine Cox, whom he thought was his godmother, explaining what had happened. She died soon after the letter was written.

Hilary Legard a great grand daughter of William Robert Maurice Wynne. Ps My mother had a love and knowledge of history, may be she had this gene from her grandfather!—Preceding unsigned comment added by 92.24.129.147 (talk)

I'm not sure what connection this has with Wikisource?--Prosfilaes (talk) 05:11, 22 March 2013 (UTC)

Blackletter

I've changed the template {{blackletter}}: Now it displays text like this, using webfonts, which many more people can see and does not require custom modifications to anyone's personal CSS. The font is UnifrakturMaguntia, which was added to webfonts a few months ago after I requested the function at bugzilla. I've only just updated the template because I was waiting for it to be added to the webfont list before doing so (it still hasn't been added). I'm writing on Scriptorium because I suspect a lot of people who use this template are not following its talk page, where I proposed making the change a few days ago, and this will change the way lots of existing pages are displayed.

The advantage of webfonts is that it does not require any local fonts on users' computers and definitely does not require custom CSS changes like the old version of the template. Any casual user, ie. IPs and those not logged in, will now be able to see the blackletter webfont. The disadvantage is that the WebFonts extension is not compatible with IE6, so users with that browser will just see standard text. Nevertheless, I think this means a nett increase in the number of readers able to see blackletter text in a blackletter typeface. - AdamBMorgan (talk) 18:49, 22 March 2013 (UTC)

Fantastic. :-)

Job well done. for IE6, seeing normal text means no loss, just no gain either; plus they really should be getting out of that browser. — billinghurst sDrewth 02:14, 23 March 2013 (UTC)

Very cool. Are there any other stylistically meaningful webfonts on the list? A gaelic type would be really nice, but last time I checked no Free ones even existed. Prosody (talk) 02:37, 23 March 2013 (UTC)

I don't know of any free ones either. Even finding one that's Unicode-compliant is difficult; the only ones that are that I know of are those from Evertype, and they aren't free. Angr 11:26, 23 March 2013 (UTC)

Cool. --LA2 (talk) 22:36, 23 March 2013 (UTC)

Why can't I see the letter "k"? ResScholar (talk) 03:56, 24 March 2013 (UTC)

Lower-case k in Fraktur types can look pretty odd. There are samples of a few on the WP article to compare against to see if that might be the issue. Prosody (talk) 06:22, 24 March 2013 (UTC)

I just noticed this change recently, as I've never actually seen the template work before, and suddenly it was displaying beautifully. Once I found this thred, I knew whom to thank. Job well done! --EncycloPetey (talk) 01:56, 31 March 2013 (UTC)

Wikisources asked for ideas re: Google Summer of Code

WMF will again be participating in the Google Summer of Code, and we have been asked to put forward any ideas. As this is something that is for all the Wikisources to consider, I have put a note at oldwikisource:Wikisource:Scriptorium#Wikisources asked for ideas re: Google Summer of Code. — billinghurst sDrewth 02:07, 23 March 2013 (UTC)

Missing image maintenance sitrep

Hi all,

I've come to the end of the initial stage of this missing image maintenance project. The outcomes are:

1. Over 6000 hi-res page scans have been uploaded. That's 6000 missing images for which the raw page scan data is a click away. I am hoping that this will make it a lot easier for us to illustrate our texts, and that we'll see that number come down over time.
2. Previously, locations where images were missing were marked by an ugly error box. Now, raw images that are "better than nothing" are displayed to the reader along with an unobtrusive invitation to improve the image quality. We are now serving over 6000 raw images to the reader, and only about 1800 error boxes.

If in the past you have walked away from texts that were finished except for some missing images, can I invite you to consider revisiting them and knocking off those missing images once and for all.

Hesperian 15:34, 23 March 2013 (UTC)

Hugely impressive work, Hesperian. This is a great improvement for the readers' experience. Hat's off. Prosody (talk) 02:08, 26 March 2013 (UTC)

Trailing gaps

Just a curiosity: Why do trailing gaps no longer work as they used to for poetry?

Some background info: This poem renders fine in IE, yet in Chrome (& I suspect other browsers), the second line wraps. Applying a trailing gap used to take care of the problem (the wrapping issue having to do, if I recall, with the length of lines coupled with drop initial use?), but now it creates an unwanted blank line space after the line it is applied to.

I may have asked this question before in some form, but can't remember an answer. Also, is there a current/newer solution to the wrapping? If no, I won't lose sleep... As I said, it is only an issue in some browsers. Thanks, Londonjackbooks (talk) 18:05, 24 March 2013 (UTC)

Same with fireox. Add a trailing gap to the first line, long enough to make the first line longer than the second one. My wild guess is that the size of the table is computed on the longest line (in this case the 2nd). Then, when the line is moved to the right due to the drop initial, it wraps as it does not fit the table anymore (it hits the table right border). So whatever you add to the 2nd line will not help, as when it is shifted right it will always exceed the table width (which is the length of the line before it is shifted). But it is just a guess, and probably in IE it works because the table width is computed differently.--Mpaa (talk) 20:40, 24 March 2013 (UTC)

Don't really know the why, and doesn't really matter. If we are needing a hard positioning, then trying a relative type fix, or some munge is going to fail at some point (browsers being browsers), especially when the right margin issue is always so nefarious. — billinghurst sDrewth 22:30, 24 March 2013 (UTC)

Thanks. I will continue to not worry about it. Londonjackbooks (talk) 23:19, 24 March 2013 (UTC)

A change in how table global style declarations work?

Last night, I designed a table on this page and set the global font size of 80% in the header and 85% for the last row. Previously, I began with [my] standard global table style and format declarations, and changed row/cell level styles as needed but now, this method no longer works. If there is a global font size declaration, changing the font size for a cell or a row, no longer works. I am only concerned about the effect of this change on previous table declarations. Anyone experienced any other change with the software upgrade? — Ineuw talk 17:01, 25 March 2013 (UTC)

What I observe is that cell font-size is proportional to row font size, which is proportional to global font size. What do you mean when you say "it no longer works"? That this is not the behavior you observed before?--Mpaa (talk) 19:33, 25 March 2013 (UTC)

Philosophy	global
Philosophy	global+row level
Philosophy	global+row+cell level

You are correct. I overlooked that global % declaration affects subsequent font size changes. Thanks. — Ineuw talk 22:04, 26 March 2013 (UTC)

"To be checked"

Folks,

There is an ongoing issue with us uploading a source file, getting started on transcription, then belatedly discovering that the file is faulty e.g. missing some pages. At that point, either there is a great deal of work for someone (i.e. George) to repair the file and realign all the pages, or the transcription progress languishes.

None of this would happen if we always checked our files and paged out our index "<pagelist />" before starting on a transcription. The ProofreadPage extension already supports this: there is already an "Unknown status" index status; we just haven't been using it properly.

I have updated the MediaWiki message for unknown status to say "Source file must be checked (for missing pages, etc) before proofreading", and I have set this status as the default selection on new indices.

I also have a hitlist of around 500 indices that are statused as "To be proofread" but have not been paged out. Unless there are objections, over the long weekend I propose to push those 500 indices back to "Unknown status". If you see me demote an index that you are fond of, I encourage you to page it out and promote it.

This will get the ball rolling, and thereafter it is up to all of us to try to remember not to promote indices to "To be proofread" until the source files have been checked and paged out.

Hesperian 02:00, 27 March 2013 (UTC)

Agree. Sounds like a good idea.--Mpaa (talk) 08:19, 27 March 2013 (UTC)

I also agree it "sounds like a good idea" but I do not fully understand all of the verbiage in all what Hesperian states to the extent where I know what the heck he is saying and how to follow what he is saying. Please see my open plea on your watchlist about missing pages or look at the Index of "Six Months In Mexico.pdf" by Nellie Bly [Elizabeth Cochran] that I started yesterday. I created one once (File->Index) but far too long ago. I followed the instructions on a WS help page but something is wrong because some page images do not appear. Regardless, I have been inserting text pages from an Adobe file on my computer. —Maury (talk) 09:59, 29 March 2013 (UTC)

By fixing the default state once an Index is created, all "we" are looking for is for everyone to completely fill out the pagelist before any pages are created. An untouched pagelist will keep getting thrown back into the default status everytime the maintenance script is run. Once that list of untouched pagelists is whittled down to a workable number, I'm betting maintenance will go further and detect incomplete pagelists as some point as well. So the advice being floated here is just to fill out the pagelist to verify the source file before proofreading begins for new uploads and to go back and fill out the rest of the pagelist on older uploads if you haven't gotten around to it yet. Either way - the only way to avoid being downgraded in status everytime the maintenance script runs is to verify a source File: against a completed pagelist in the Index for that source File. -- George Orwell III (talk) 10:24, 29 March 2013 (UTC)

I am at bit at a loss as to how to check. A file on my watch list Index:ICD-10-CM (2010).djvu got the source file must be checked update. Clicking on link takes me to Category:Index - File to check which in part says "Pages should not be created for these books. First check the pdf/djvu file, and enter a page mapping into the tag on the index page. See Help:Index pages for guidance on how to do this.", after getting to the help index it gets kind of hazy. I can figure out that if the pages numbers don’t match 1 to 1 (which mine do) that are directions on how to make them match. There seems to be something of a conflict as category header is telling me not to create the pages until the page numbers are mapped, but it feels like you should create the pages and validate the page numbers, while updating the page list. But that does not seem quite right as that leads us down the path to making problems. I also feel like I should check every page and make sure none are missing, which leads me back to wanting to create them as I check. JeepdaySock (AKA, Jeepday) 10:47, 29 March 2013 (UTC)

Sorry, we need to get the wording right so that it effectively communicates what needs to be done. If you edit an index file, you will see a "pages" textbox that will contain

<pagelist />

This tag needs to be expanded to provide a correct mapping from djvu/pdf pages to actual page numbers; e.g.

<pagelist 1to8=- 9to20=roman 9=1 21=1 />

Documentation on how to do that is at Help:Index pages. Creating that mapping requires a close examination of the work during which it will become evident if there are problems with the file such as missing pages or pages in the wrong order. Hesperian 11:43, 29 March 2013 (UTC)

P.S. for a one-to-one mapping as in your case, you can make that explicit if you want by putting in <pagelist 1=1 />

EDIT CONFLICT

George, I have no qualms what-so-ever in doing as you say in the sentences above. I _prefer_ to do everything the correct way. I don't want errors for my project and myself. My situation is that I do not know all that needs to be done, nor in what order (it is stated that one can "come back" [when specifically] to add further information when creating an Index page). You write of "pagelists" but I have never had to create one. Therefore, presently, I do not know how to create one. I feel sure it is very easy but when one does not know then help is needed. So, _where_ do I look to learn how to create a "pagelist"? Kindest regards to a most excellent administrator. —Maury (talk) 10:50, 29 March 2013 (UTC)

Hopeful clarification

First, I want to clarify the rationale / background behind the need to fix this default status for Indexes that do not have their <pagelist /> fully mapped out yet. This practice should have been clearly put into policy years ago when the whole color coding and proofreading status regime first became part of Wikisource. While it has always been "understood" to be the preferred step to take before actual proofreading begins, it has never had the benefit of a working default status on Index: pages to support that premise (and that sad fact is primarily behind the reason for the omission of this step from the various Help: pages as well). It is unfortunate we are playing catch up now that the default status has been "fixed" but that is the reality we all have to face.

In addition, any idea that the restoration of the default status was in response to something "George", Hesperian or any one else in particular had a problem with in their "endeavors" is a bit misleading to put it mildly. The truth of the matter is English Wikisource has a consistently rather "high" ratio of unfinished Indexes to validated Indexes -- only 1 out of 5 of our Indexes has reached the Done - Validated status (approximately). This means we create far too many Indexes that only get partially worked (if at all) over a good chunk of passing time to date.

This unbalance is not entirely undesirable at the same time. Some Indexes are but one volume in a series or a collection made up of many volumes so it makes sense under a spirit of best practices to upload & pre-set as many volumes as possible for eventual series or collection completeness regardless of one or more of the volumes being worked on at any given time.

The remainder of Indexes however, are basically stand-alone forgotten monuments to overzealous contributors who operated at the time under a now disproved belief that ... if I build it, they will come. It is this misplaced notion to not only upload but create an Index: for any & every source file that remotely seemed interesting at the time - with the yet to really materialize rationale that its OK to overflow one's to-do list like that because someone else will eventually come along and start working on the File: in the interim. That reality is a large part of why we are now looking to streamline and address what we already have by "helping" existing Index: status along through other means.

One of the steps taken in that "streamlining" of existing Indexes (or waking the dead as I like to think about them) to help move the overall status of Index: pages along was the introduction of the bulk-uploading and/or raw-imaging of missing images. After the implementation of this practice had touched more and more previously static Indexes, it became apparent that applying this practice to Indexes that did not have a completed <pagelist /> in place that verified the source file was complete and without structural flaws could be hugely problematic. Without verifying the integrity of the source file by matching the File: /positions to it's <pagelist /> assignments, the naming of the bulk .png image files could be way off as well as the amount maintenance needed to insert/delete/swap pages to correct the issue with a source file to begin with - plus all the .png file renaming / raw-image template adjustments needed afterward. It was that point it became clear that restoring the default status for Index: pages was necessary and the actual trigger for this change. The change, in effect, being a restoration to what should have been practiced all along. -- George Orwell III (talk) 00:43, 30 March 2013 (UTC)

Tips on how to adjust pagelist

Reserved - please don't add anything here until I come back in a bit (meatspace calls).

Here's where I will (hopefully) outline how I use external software (DjVu Libre's DjView or Adobe Acrobat's Reader) to "gallery" or thumbnail view an entire source file to easily determine where a page range starts, ends or is interupted by images & plates in order to adjust the <pagelist /> assignments on the Index: page accordingly. -- George Orwell III (talk) 00:43, 30 March 2013 (UTC)

Question: Before we implement this (which does sound like a good idea overall), can we have a bot generate for us a linked alphabetical list of the works to be affected? This would give editors a chance to check manually that something obvious is not amiss in the list, and might stimulate someone into starting work on one of the neglected items. It is possible, after all, that some of the Index pages are for works that actually start at "page 1" with no need to set the index paination any different than the default, and if so, then we'd need some method of keeping these works from being kicked back automatically. Then, after allowing time for the community to look over the list, I say we go for it. --EncycloPetey (talk) 02:04, 31 March 2013 (UTC)

Once the category is down to manageable size, I see no need for a bot to be kicking them back. But if we did need a way to prevent that, I suggest it would be "<pagelist 1=1 />". Hesperian 03:08, 31 March 2013 (UTC)

Index:Public General Statutes 1896.djvu

Text now complete, As in the table for Short Titles are completed.

However, there is STILL a lot of indexing to be done, and re-formating to use {{cl-act-section}}'s Any volunteers? —unsigned comment by ShakespeareFan00 (talk) .