From Wikisource

[edit] Announcements

[edit] New Typography templates

Introducing some new typography templates: Sam Wilson's {{Long s}} template, based upon which I have added {{Ligature Latin AE uppercase}}, {{Ligature Latin OE uppercase}}, {{Ligature Latin ae lowercase}}, {{Ligature Latin ct lowercase}}, {{Ligature Latin ff lowercase}}, {{Ligature Latin ffi lowercase}}, {{Ligature Latin ffi lowercase}}, {{Ligature Latin fi lowercase}}, {{Ligature Latin fl lowercase}}, {{Ligature Latin oe lowercase}}. I agree with Sam as he says in Template_talk:Long_s that this sort of approach is the way to go for editors who wish to include these characters in content. In the short term, it makes it easy to decide site-wide whether to use archaic or modern typography. In the long term, we really need something like this in-place and in content if we were ever going to create functionality that would allow someone to switch the archaic typography on and off on a per-document basis or in the user preferences to change their view of the site. See the Long s and ligature templates in action in (unfinished) The Periplus of the Euxine Sea. And now, my magum opus typography template: {{dropinitial}}! Used with parameters {{dropinitial|L|2.4em|0em|.05em}} within a block of Times New Roman text. L orem ipsum suas propriae ne nam. Duo etiam omittam ea, ex mei nostrud interesset. Sea no idque aliquyam, cu utamur impedit usu. Has te falli explicari disputationi, in ius decore denique torquatos, id usu harum similique cotidieque. Splendide consequuntur ex quo. Ut qui primis alienum. At ignota consetetur moderatius qui. Et eam habeo mediocritatem, iisque neglegentur sed ut. Tempor apeirian moderatius ad sit. Everti iriure an nam, duo aliquip tamquam et, ne tollit graeco his. Et eum vidisse maiestatis. The text immediately above is with the default settings, just {{dropinitial|L}}. But you can vary the font size and margins with other parameters. I cross-browser tested the default values a bunch, but I need individuals who are looking at this with Macs and in Windows Vista (not XP, I already tested that) if in the default settings example above, do you see two lines wrapped around the initial (like in the image) or three? --❨Ṩtruthious ℬandersnatch❩ 11:36, 10 April 2008 (UTC)

One of the problems with including these pretty typographical flourishes is that it makes a search in the text for occurrences of certain words impossible. Thus if I am looking for occurrences of the word "ship" and "erect" in the Periplus text noted above I cannot find them by simply using "Find in this page". I presume too that a Google search will fare no better. Textual studies are more likely to be interested in an author's use of specific expressions than in typographical frills reflecting aesthetic sensitivities of another time. Eclecticology 01:13, 20 April 2008 (UTC)

The problem is in the search engine or browser you're using, not the content. For example, Google will return results for "æ" if you search for a word containing "ae" just fine, the same as it will return results containing "à" for a search involving "a". Voilà. Of course, without these "pretty typographical flourishes" there's no way to find occurences of ligatures at all. The preferences of people doing textual studies is no reason to remove the aesthetics which most of the people who read and used the text in history actually experienced. And of course, there's no reason to kick the people doing typographical studies in the teeth either. Heck, if the Wikisource project is about "correcting" the aesthetics and typography of the texts being digitized I ought to go into the Periplus and "correct" all of the instances of "shew" to be spelled "show" - I mean, it's the same word, after all. And we can go over to French Wikisource and remove all of the circumflex accents from the old documents - even the French know they don't need it now! They'll love that. Most of the point of using templates for this is because at some point we ought to be able to provide the option to automatically replace ligatures with modern type conventions, as a matter of personalization or as a switch in the document page, to address the needs of those who get all puckered up when they see ligatures. Or we could provide separate search content to search engines that can't handle ligatures.--❨Ṩtruthious ℬandersnatch❩ 10:37, 22 April 2008 (UTC)

Special:Search/æ finds all occurrences of "æ". I dont see the point of providing a template for a single unicode character. Why not also have a template for every non-ascii character? John Vandenberg ^(chat) 10:46, 22 April 2008 (UTC)

Using that search, I came across A Dialect of Donegal/Introductory, which uses {{Unicode}}. That template tells the HTML renderer that a few fonts are going to be necessary to view the text. John Vandenberg ^(chat) 10:59, 22 April 2008 (UTC)

But the only reason why that search can find occurances of æ is because that character is actually in the text. I was responding to Eclecticology saying that ligatures, etc. - "pretty typographical flourishes", as he says - shouldn't be included in texts because some search tools don't do the translation back and forth. If, as he suggests, a Wikisource author "corrects" all of the ligatures in the text to modern typography then Special:Search/æ won't find anything. Didn't we already have the discussion of why to have these templates, John? By doing it this way it will be possible to some day have javascript code or something that allows a user browsing the text to choose between seeing the ligatures and original text or the modern non-ligatures typography. Eclecticology's textual studies people and people interested in fidelity to the original text could both have their way. So, the reason not to have a template for every non-ascii character is that you wouldn't want to have an auto-replace feature for every non-ascii character. --❨Ṩtruthious ℬandersnatch❩ 14:48, 22 April 2008 (UTC)

Please don't assume that the the discussion has been had and completed, when you are just starting the discussion now.

It's not just old texts that use some of these ligatures. Modern texts continue to use them, but nobody pays much attention. Thus a very high proportion of modern works using the word "software" will include the "ft" ligature, but why would anyone insist on maintaining that ligature in our copies of such texts. Also let's not confuse the role of accented letters, or the "æ" digraph with structures whose purpose is purely typographical.

It's not about the "shew/show" distinction, which is orthographical rather than typographical. That distinction, furthermore, does not present any search difficulties. It's not about one's browsers or search engine either; searching for "æ" is one thing, but searching for a long "s" is quite another. In response to my first comments in this thread you did not show how to search for "ship" in the Periplus text so as that it will reveal both uses of the long "s" and the capital "S".

If people want the æsthetic feel of the historical original, they are just as well off with a pdf file. There is no need for pedantic tinkering with the typography. For me the important thing about Wikisource is the presentation of information and old texts that are not easily available to most people. There is no shortage of such material. When I add extracts from my copy of the 1701 Collier I have absolutely no intention of preserving the long "s"'s that I find there. Eclecticology 17:19, 22 April 2008 (UTC)

You point out that Google searches work irrespective of the ligatures on the page; I pointed out that internal search work on the actual text. We already have the best of both worlds. If we need better search engines, then eventually someone will build them.

Yes, we did have this discussion, but I am now noting my objection to these templates here as part of the general discussion. If Wikisource is to ever introduce display ligatures as anything except for the actual intended character, I would expect that it would be done in the software itself rather than using templates. If we did need to implement it using templates, it would be far simpler to run a bot to do this, as that would be required in any case -- it is extremely unlikely that simply having these templates will mean that they are uniformly used.

If the community is divided on whether or not to use ligatures, the default outcome is that the person who contributes a text makes the choice. John Vandenberg ^(chat) 16:33, 22 April 2008 (UTC)

Oh, definitely. Please don't either of you take this as anything other than the announcement of the availability of these templates and their purpose, so that the people contributing texts can choose to use them and understand the reason for doing so. I'm not trying to dictate policy or anything, I'm simply advocating for what I think is the best solution among several. If these templates never do anything more than give me control of typography display within the documents I put on Wikisource myself, that's still great from my point of view. Eclecticology, it's great that you're totally uninterested in aesthetic aspects of old works, but the Wiki projects aren't single-purpose outfits. You can have your corrected-typography documents and I can have my typography-faithful documents. It seems to me that there's greater value in having a document that can either be viewed in a typography-faithful mode or a corrected-typography mode, but I'd still by far rather have the corrected-typography versions of the works you add be available! The work being done here is waaaay more important than this minor issue. You two each have your own approaches to this, Sam Wilson and I have this one, so any given Wikisource user has a variety of options. As John points out, it's a fairly simple technical issue anyways, even if in the end fancier features were implemented with a search-and-replace (hmmm... that would actually be a nifty feature to implement in the browser itself... maybe something to mention to my contacts at the Mozilla Foundation.) The sort of approach he's talking about would work with these templates just as well as it would work on documents that have a specific representation hard-coded into the content. Personally, I like this solution just for the fact that if the Unicode consortium or some other standards body ever gets around to coming up with a standardized representation of the ct ligature, I can implement it in all my documents simply by changing the associated template, no regex or PHP coding and testing needed. One other little thing... are either of you guys on a Macintosh or on Windows Vista? If so, does the dropinitial example above look basically okay? --❨Ṩtruthious ℬandersnatch❩ 09:00, 23 April 2008 (UTC)

The computer that I am now editing on is equipped with Windows 98, first edition.

At least we can agree that it's up to the contributor to decide, and that that person's choice should generally be respected. I also take due note that this set of templates is presented on an availability basis only. Perhaps we should have an "Available options" page where this, and a number of other proposals that have been made by various people can be listed for interested people to try. The real proof of the value of any of these proposals is the number of editors that actually use it. Presenting something as an "Announcement" on this page can have the effect of giving that subject more weight than appropriate; it too easily appears as a dictation of policy even if that is not the proponent's intent.

One technical question: Why can't these ligatures simply be added to the special characters menu at the bottom of the page?

The term "corrected-typography" is yours, not mine. I would prefer something like "modern typography", as something more readable. Frequently, in these old texts it is difficult to distinguish between the long "s" and the "f", the distinction often only being a matter of a full or partial crossbar. It is not unusual to find that typesetters have simply used the wrong one. This is problematical where both words can be meaningful in the context. Eclecticology 17:24, 23 April 2008 (UTC)

Yeah, "modern typography" is a better term. I apologize if it was forward of me to put the above notes here in announcements; I originally put them at the very bottom of this page but then I realized that meant I'd put them in the "Questions" section, or so it appeared to me. Anyone who wants to move the notes and discussion elsewhere in the page is welcome by me to do so. --❨Ṩtruthious ℬandersnatch❩ 07:39, 25 April 2008 (UTC)

Sam Wilson here. I think I've changed my mind about using templates to solve this issue: I am certainly resolved to use the correct characters (ſ, æ, or whatever), but I think that they should just be included in the text. They can still be globally replaced (per-page, per-view) if the user wishes — but this should be something the browser does (through Javascipt?) much in the same way it does with lj/lj and other ligatures (at least, FF on a mac does). The main reason I don't want to use templates for typography is the editing process: the text gets all cluttered up with template code and it's much harder to proofread (or course, this can be solved with other editing tools, but that's another discussion…).

The following comes from the Unicode FAQ:

So I vote for (and I know this isn't a formal voting process, of course):

1. maintaining fidelity to the source typography;
2. including the long s (etc.) in the 'special character' menu;
3. not using templates for typography;
4. if a character exists in Unicode then we take it that it is a distinct character, and not just a certain way of displaying some font. If you see what I mean?

—Sam Wilson ^{contrib's | talk} 23:13, 24 April 2008 (UTC)

Yeah, I came across that note on Unicode.org... it seems weird and inconsistent to me that they created separate codes for so many of the ligatures in English except ct, the note makes no attempt to explain why. The one point I disagree with you on, Sam, is that I don't think we ought to let the Unicode consortium dictate things, especially since they're basically a ginormous super-committee and there may actually be no rhyme or reason whatsoever behind which ligatures or typography effects get represented and which do not. I can understand that some people might want to avoid templates for code-readability reasons. I don't add the templates until the end of my editing process when the text is otherwise perfect. My preference for the template solution probably stems from the fact that I've done a fair bit of programmatic text processing, where I've learned to be careful; it's easy to do a replace on a large amount of text or across many files or a database, and realize whoops what you did is one-way and can't be reversed. With the templates the typography effect can be represented any way at all, as non-ligatured characters with a font tag wrapped around them for example, or the non-ligatured characters with a graphic overlay that creates the appearance of the ligature, or a block of CSS code that adjusts the web typography like the {{dropinitial}} above, etc. and there's no worry about ever having to write code to remove or undo the representation code as there would be in a bot replace solution. I agree with you that the view-switching ought to be a browser feature, in fact I've tinkered around with a user script to do so, though I haven't put the time in to really get anywhere. --❨Ṩtruthious ℬandersnatch❩ 07:39, 25 April 2008 (UTC)

The ct ligature definitely exists. Look at The Discovery of New Brittaine and go down to the heading that begins with "October." (In IE, this ligature won't show up--at least it doesn't for me--but it appears in FireFox.)—Zhaladshar ^(Talk) 15:12, 25 April 2008 (UTC)

• I'm using Firefox and it gives me a question mark; the same happens on the edit page. Eclecticology 18:58, 25 April 2008 (UTC)

Actually, if you read the whole note on Unicode.org, they're quite clear that the existing ligatures are there for "backwards compatibility" only (i.e. round-tripping to other fonts), and that no new ligitures will be created.--T. Mazzei 17:30, 25 April 2008 (UTC)

Here, it renders as a Chinese glyph. What was used was Unicode character U+E707, which belongs to a Unicode private use area. Hence, there will be no uniform rendering of this character.--GrafZahl (talk) 19:41, 25 April 2008 (UTC)

Unicode is not a font, it's a superset of the character encodings UTF-8, UTF-16, UTF-32, etc. But Zhaladshar, I think the reason you're seeing a ligature has something to do with the fonts on your computer. If you edit that page the "c" and the "t" are two separate characters, not one. --❨Ṩtruthious ℬandersnatch❩ 16:54, 26 April 2008 (UTC)

I've already replaced the faulty U+E707 glyph with ct[1].--GrafZahl (talk) 09:39, 29 April 2008 (UTC)

By using the same concept as is used in {{annotations}} above, it is possible right now to create templates that would allow users to switch between an original typography and a modern typogaphy view. I have been contemplating attempting such a project, but I haven't gotten around to it.--T. Mazzei 16:54, 25 April 2008 (UTC)

It's not clear what the annotations template does; it has no documentation. I would personally be disinclined to use any template unless I know what it does.

I very much believe that it's important to be able to search for all instances of a word on a page. If we want to find all occurrences of "October" or "August" on a page, the search results should not depend on the typography. We could still have a template like {{type|p1|p2|...}} where the parameters are for the different desired typographical features. It would allow for text otherwise entered in a modern canonical typography to be optionally viewed in whatever antique way is desired. For the long "s" it would then replace every non-terminal instance of an "s" with the long form whenever the reader wants. Eclecticology 18:58, 25 April 2008 (UTC)

Sorry, I meant {{annotation}}. The concept behind the annotation template is simple: the template displays one version of the text on the page where it is entered, but when that entire page is transcluded to a specifically named subpage, the template displays different text. The {{annotation}} template displays no text on the original page, but when that page is transcluded to a subpage named "annotated", it displays the text's notes. This could be easily adapted to a template, say {{s}}, which would display a "ſ" on the original page, but when the page is transcluded to a subpage named "modernized", would display a modern "s".

There are varying stages of modernizing a document: modernizing typography (s for ſ), modernizing spelling (show for shew), or replacing archaic/obsolete words with modern equivalents (alchemist for spagyrist), etc. Using templates with the method above would allow us to do none, one, or all of the above, as well as keeping a document as close as possible to the original, without having to maintain the multiple separate files.

Having two (or more) separate files, at least one of which does not have any of the troublesome ligatures, would eliminate your issues with modern textural textual analysis. However, regarding textural textual analysis, I recall seeing one done regarding where within words long s appeared (the only hard rule was never at the end). This type of analysis cannot be done if we convert all of our texts to modern typography, or have a program simply "replace every non-terminal instans of an "s" with the long form whenever the reader wants".--T. Mazzei 21:44, 25 April 2008 (UTC)

Eclecticology, I think that search tools should return accurate results too, but it definitely is not the responsibility of Wikisource people to fix things that Google, Microsoft, or the Mozilla Foundation have dropped the ball on. As I demonstrated with the Google search for æ above it's by all means technically possible for a search tool to handle ligatures properly. That's the great thing about a template solution... even though it's not our responsibility to work out issues in the web browser or in Google, we actually could, via something like the graphical overlay or CSS typography approach I suggested above. In a document where templates are used for the ligatures we can easily adjust the HTML code that renders the ligature so that it compensates for flaws in any search engine or browser - or in new versions of an existing browser. And one little nitpick T. Mazzei before anyone else jumps on it: textural analysis is the analysis of textures, it's textual analysis which Eclecticology mentioned. --❨Ṩtruthious ℬandersnatch❩ 16:54, 26 April 2008 (UTC)

Oops, my bad. My brain was saying textual...--T. Mazzei 17:00, 26 April 2008 (UTC)

I did of course mean "textual", but variant typography nevertheless gives a different "texture" to the material. :-) Eclecticology 00:23, 27 April 2008 (UTC)

If you think I'm argumentative about typography, I would likely be far more vocal about attempts to dumb down by treating "alchemical" and "spagyrical" as exact synonyms.

The test for the "annotation" templates will be whether people use them. So far it's only there in relation to a single work. Let me know a year from now how many people have used it.

I'm always happy to blame Microsoft for what's wrong with software, but what ball did they drop here? Template based solutions need to be kept to a minimum if you want to maintain the involvement of the less geeky among us. Keeping things looking as much like the original could just as easily be used to argue for maintaining the original text justification and hyphenation. Is all that additional complexity really worth the effort? Eclecticology 00:23, 27 April 2008 (UTC)

Well, the ball I'm assuming that Microsoft, the Mozilla foundation, et al. dropped is that, from what you say, I assume they didn't work out ligature-matching in the browser search function that comes up when you press Ctrl-F. Just like with Google, you should be able to go to the Periplus page in the browser, press Ctrl-F and type "Athenae" and it should match instances of "Athenæ". (And there probably ought to be a checkbox that turns ligature matching on and off.) That ought to work at least for the standard Unicode characters; the "ct" ligature will definitely have to be a custom solution in any case, thanks to the namby-pambies at the Unicode Consortium. (I wish I new more about ligatures in other languages, I wonder if this has been solved in general.) I think whether the effort is worth it will probably depend entirely on the user who's executing the project. When I began working on the Periplus I was frustrated that I couldn't find a solution like these templates (except for Sam's long s template) which caters to my engineering mentality and web software skill set. Now the templates are there and I think your objections have appropriately created a good paper trail of community analysis, so it's all here for the next person like me to find. Funny you should mention original text hyphenation. The first work I worked on here, A Concise History of the U.S. Air Force actually does maintain the original text hyphenation of words broken across pages in the individual transcripted .djvu pages in Index:A Concise History of the U.S. Air Force.djvu. I also put the correct HTML code in to properly indent every paragraph. Or in Carter Presidential Directive 59, Nuclear Weapons Employment Policy I matched the fonts and font sizes from the original document, included struck-out text, properly indented the blocks of redacted text, maintained most of the head and page footers... of course, it helps that I know exactly what HTML code is necessary to do those things. I actually wouldn't mind hearing what the distinction between "alchemical" and "spagyrical" is; I checked out the wikt entry for "spagyrical" but I wasn't able to figure out what the precise difference was. --❨Ṩtruthious ℬandersnatch❩ 18:56, 27 April 2008 (UTC)

a spagyrist is a particular flavour of alchemist, a follower of Paracelsus, more interested in the medicine then in transmutation. It was a poor example, but the only archaic word I could think of off the top of my head.--T. Mazzei 00:43, 10 May 2008 (UTC)

It seems that people are going to do whatever they think best for each project. Some will maintain linebreaks, while some will fix spelling -- most will do something in between. Is that a fair thing to say?

I prefer using the unicode characters in the text, and not templates, just because it's so much easier to write (and read whilst editing). But I take back what I said before about trusting the Unicode Consortium to determine what characters we can and cannot use — I am currently transcribing Terræ-filius, and I want the ſt (that's a long s joined to the top of the t) ligature! Anyone got a solution to that?

Which makes me think: say we decide to use archaic typography in some project, what do we do if some character is unavailable?

Finally, should we put something in the Style Guide about ligature use?

—Sam Wilson ^{contrib's | talk} 20:34, 27 April 2008 (UTC)

I have created template redirects to save on typing for people who want to use the ligature templates and would be entering them manually: {{ls}} for the long s, {{AE}}, {{ae}}, {{ct}}, {{ff}}, {{ffi}}, {{fi}}, {{fl}}, {{OE}}, {{oe}} As far as the ſt ligature, I of course would advocate that you create a template for it, and put the two separate, non-ligatured characters in there for now. As long as you get the template into the text, anyone at any future point can come up with a "real" (i.e. fancier) solution and apply it easily. It seems like talking about the different options we've discussed here and perhaps the arguments in favor of each might be appropriate in the style guide but I certainly see no need to mandate or even recommend a particular solution. People who are particular enough that they're even trying to reproduce the ligatures from the original text will probably have their own preference. --❨Ṩtruthious ℬandersnatch❩ 21:36, 27 April 2008 (UTC)

[edit] Election Notice

The 2008 Board election committee announces the 2008 election process. Wikimedians will have the opportunity to elect one candidate from the Wikimedia community to serve as a representative on the Board of Trustees. The successful candidate will serve a one-year term, ending in July 2009.

Candidates may nominate themselves for election between May 8 and May 22, and the voting will occur between 1 June and 21 June. For more information on the voting and candidate requirements, see <http://meta.wikimedia.org/wiki/Board_elections/2008>.

The voting system to be used in this election has not yet been confirmed, however voting will be by secret ballot, and confidentiality will be strictly maintained.

Votes will again be cast and counted on a server owned by an independent, neutral third party, Software in the Public Interest (SPI). SPI will hold cryptographic keys and be responsible for tallying the votes and providing final vote counts to the Election Committee. SPI provided excellent help during the 2007 elections.

Further information can be found at <http://meta.wikimedia.org/wiki/Board_elections/2008/en>. Questions may be directed to the Election Committee at <http://meta.wikimedia.org/wiki/Talk:Board_elections/2008/en>. If you are interested in translating official election pages into your own language, please see <http://meta.wikimedia.org/wiki/Board_elections/2008/Translation>.

For the election committee,
Philippe Beaudette

[edit] Petition on Meta

Hello,

I would like to notify you of a petition against the recent decision by the board to reduce community representation. Please find it here. I am sending this message to most English Wikimedia projects as I think it is important the community is informed. If you have any questions please ask me at my Wikinews talk page.

Thanks,

Anon101 (on Wikinews) 20:27, 28 April 2008 (UTC)

(Note- I did not create the petition)

[edit] Goodbye header2: transition complete!

The {{header}}→{{header2}} transition is finally complete after nearly 2 years (see overall changes, changes between modern templates, and the first divergent edit). This finally standardizes two years of development in automating formatting and categories, caching styling, and validating parameters. For example, it's no longer necessary to provide the arrows or parentheses, as has always been necessary with {{header}}; other improvements like the greatly reduced source size with the styling moved to the Common.css were duplicated to {{header}}.

A glance through discussions over the years:

• "Standardized page infobox" (WS:IGD talk, January 2006)
• "Standardized article header" (Scriptorium, January 2006)
• "Reorder parameters in {{header}} (Scriptorium, April 2006)
• "Tweak standarised header" (Scriptorium, October 2006)
• "Implement new header" (Bot requests, March–April 2007)
• "Implement new header format, standardisation and normalisation" (Bot requests, March–April 2007)
• "Categorize subpages" (Scriptorium, March 2007)
• "Transition all pages from {{header}} to {{header2}}" (Bot requests, May 2008)

—{admin} Pathoschild 08:36:52, 08 May 2008 (UTC)

[edit] Proposals

[edit] Wikimedia Radio

I see a few names of users I recognise above, people who'll know me from various mailing lists, and know my home project is Wikinews. We have what I think is an interesting proposal here on the Wikinews Water Cooler. The initial proposal was for a Wikinews Internet Radio station, not realistic, but a thought-provoking suggestion. I've put a little work into raising a number of points on this for discussion and I was gently reminded I'd omitted Wikisource then informed you guys have audio books that could be used.

The idea has, as the heading explains, morphed into Wikimedia Radio and would involve material from all projects (news from Wikinews, "did you know?" and featured article synopses from Wikipedia, recorded workshops and lessons from Wikiversity (imagine running a Spanish course for 2-3 months before Wikimania 2009), material from Wikibooks and Wikisource that's packaged to a radio format, Quote of the Day (with background) from Wikiquote, similarly Word of the Day from wiktionary, and free music from Commons with the option to do a long slot on a particular work of a composer with a bio of the composer and during the interlude a backgrounder on the work.) Put like that it starts to sound like enough to fill eight hours and repeat three times per day.

I've quietly gone about putting out feelers on this to smaller projects (i.e. avoided the 800lbs gorilla that is Wikipedia). This is because there are, from discussion on IRC, some Wikinewsies concerned the whole project would get hijacked by WP and we'd get sidelined.

So, now it comes to the obvious point, are there any Wikisource contributors (what do you call yourselves? Wikisourceologists?) who see potential here. Wikiversity has been kicking around a similar idea since sometime last year called Wiki Campus Radio, and when I fleshed out the proposal in an email to the ComCom list, the proposal was described as "WikiRadio4"; this is a bow to the BBC's Radio 4 channel which is heavyweight, serious, and... well, look up the Wikipedia article, "gravitas" springs to mind.

If you're interested in working on how Wikisource could contribute then there's a section on [[Wikinews:Water_cooler/proposals#Radio|]] to sign up to. Even if you're not going to add your name there feel free to chip in comments and detail any ways you can see Wikisource material being used. I can't think of anything else that would involve so much cross-project collaboration, to the extent that I'm seriously considering taking the whole thing to meta as a proposal for the first project predominantly serving up content without using MediaWiki. --Brian McNeil /^talk 09:12, 23 April 2008 (UTC)

Some quick thoughts

• Personally, I would be much more interested in a "journal" run by Wikiversity, but that takes nothing away from the usefulness of a audio based approach.
• Wikisource is yet to have a "daily" feature, so we are unlikely to be able to feed content into a stream that is up tempo. That said, we could probably push one larger work out per month, and that could be broken up into a daily segment, so listeners end up listening to the entire work over the period of the month. Our audio usually comes from other sources (I havent seen any audio files created by Wikisource users) so it would take a significant effort for us to ensure that we have an audio stream for each featured text. It is hard enough for us to find good pagescans to accompany our Featured texts, that I doubt we are able to also require an audio stream before texts are promoted.

John Vandenberg ^(chat) 10:15, 23 April 2008 (UTC)

It may not be necessary that the texts to be featured to be used for audio output. Of course, volunteers are still needed to read and record the texts. I gave up for English texts, but I might be interested to do it for French texts. Yann 10:24, 23 April 2008 (UTC)

• As to what we call ourselves I have preferred the term "Wikisourcerors" from the very beginning of the original Wikisource. :-) I believe that being able to laugh at ourselves is always a good principle to follow.

• I have certainly been intrigued by the project as presented on the mailing lists, and have no reason to oppose it. Nevertheless, I see it as something for other people to do. I share the same kind of concerns expressed by John and Yann. Most of us will see these initiatives as good ideas, but unless someone is ready, willing and able to maintain them they ain't gonna happen. Note that on this Scriptorium page the "Wikisource News" feature at the top has not been changed since October.

• All that being said, we certainly do not lack for material, such as long lost stories, which would be perfectly suitable for radio presentation. If we were to record this for radio we would also prefer broadcast quality, and not everyone is equipped to do that. In the short term there's a lot of public domain Old Time Radio (OTR) material available on cd for very low cost. Running an Inner Sanctum series could be attractive to many people. Eclecticology 17:21, 25 April 2008 (UTC)

For a daily effort, how about if we found a book with audio recording and then WMF Radio had a chapter read out each day? That way, no additional strain on Wikisource to meet a daily demand, but if somebody would like to see their favourite poem read aloud on radio, they can record a version, and insert it into the queue after the current book is done in two weeks, the poem will be read one day, and then on to a new 21-chapter book, etc. Sherurcij ^{Collaboration of the Week: Author:Percival Lowell} 17:02, 13 May 2008 (UTC)

[edit] Site redesign

How much flexibility does Wikisource have from WMF on general site outlay? I'm just curious, because I wouldn't mind getting a bunch of talents together and trying to make us "stand out" a little more - lends an air of legitimacy, a community-building project and all of that great stuff. For example,

Wouldn't that be neat? I say so! And I'm not aware of any WMF policies that would prevent us from fooling around with the default skin. After all, aren't we the new w:Library of Alexandria? :) Sherurcij ^{Collaboration of the Week: William Lyon Mackenzie King} 07:19, 3 May 2008 (UTC)

I dont mind if radical ideas are explored for the main page, however I do not want pillars taking up screen realestate on content pages. John Vandenberg ^(chat) 06:17, 6 May 2008 (UTC)

the idea of greek pillars is worth turning into a full-fledged window manager skin ThomasV 06:49, 6 May 2008 (UTC)

• This idea sounds like a good idea, but it may not render so well in Opera or Firefox. I use those browsers a lot more than [[:en:w:Internet Explorer|Internet Explorer]], and a large amount of people do as well. The CSS would have to be changed so the font-width is narrower, and that may make it hard to read. Thanks, AP aka --Kelsington 10:15, 6 May 2008 (UTC)

Way to go Sherurcij, you totally jinxed us there. Now the Wikisource servers are going to burn down.  ;^) How about Flash animations? I want to see the Titanic smash into the iceberg and sink. With accompanying audio - "SOURCE DOCUMENT! DEAD AHEAD!" and the foghorn blasting. Just kidding, of course, but a redesign sounds interesting. Maybe the pillars could be in the background somehow? And I'm thinking there could be some watermarked ſs and ffis and æs that figure largely in the design... *makes devil horns sign behind Eclecticology's back, then runs away* --❨Ṩtruthious ℬandersnatch❩ 21:32, 11 May 2008 (UTC)

Nothing in the world an embedded MIDI can't make better! Excellent planning! :Þ Sherurcij ^{Collaboration of the Week: Author:Percival Lowell} 17:00, 13 May 2008 (UTC)

I can't think of any reason Opera or Firefox wouldn't recognise CSS or any other formatting - do you have a specific concern in mind? Sherurcij ^{Collaboration of the Week: Author:Percival Lowell} 17:00, 13 May 2008 (UTC)

[edit] Standardization run

Pathosbot has been transitioning pages from {{header}} to {{header2}} over the last few days, and is almost done. Next we'll replace {{header}} with {{header2}} and switch pages back to {{header}}, completing the upgrade. On the most part, this will simply involve changing "header2" to "header".

Jayvdb pointed out the opportunity for other expensive standardization and page analysis, since the bot will be making the edits anyway. If there's any standardization you think should be done, please comment.

A few ideas:

• Synchronize all pages with new {{header2}} parameters (like 'translator');
• generate a list of possible poems without <poem> formatting (based on the proportion of line breaks per line);
• generate a list of possible translations without the 'translator' parameter (based on the pattern 'translat(ion|ed|[eo]r)' in the 'notes' parameters).

—{admin} Pathoschild 05:34:44, 06 May 2008 (UTC)

The migration from header to header2 has been painful, but I dont see that we need to migrate to back to header as quickly, as the two templates will be equivalent, making it much less painful to explain why there are two. Some contributors may copy existing usage of header2, however that can be addressed by patrolling. So I think we can take our time; simply altering all 100,000 pages replacing "header2" with "header" is not worth doing.

One of the expensive changes I think would be beneficial is for subpages to use a template which is mostly automated; see Template talk:Header/Archive 1#Subpages. {{subpage-header}} achieves this for simple cases, excepting that it doesnt display the author. I see three solutions:

1. add more params to {{subpage-header}}; I dont like this idea
2. the author value on the main page is defined as a labeled section (i.e. LST) and all subpages slurp that section into the header.
3. a header template is created for each work which acts as the header, and it is transcluded into the subpages

   this is already done with larger works, such as EB1911, NSRW, etc.

   for many works, the specific template for each work would call a generic template which has the appropriate logic. i.e. for all works which have Arabic numbered chapters, the template would be something like {{header-arabic-chapter|author=...}}

On subpages, some thought needs to be given to prefaces by someone other than the author, as that is a common occurrence.

Another change is that I would like the header on every work to include more detail, like the German Wikisource template de:Vorlage:Textdaten. I am torn on how much detail we want to present (see here), but what we have is definitely insufficient, and putting {{textinfo}} on the talk page has never struck a chord with me. I would like to see more detail on the main page for our works, but do not like the unsightly German box on the right hand side - that is too much. My preference would be to display a minimal subset like we currently do, and add a "display option" to show the additional edition information. However I am not suggesting that all of the textinfo fields should be in the header; the source and contributor information is not valuable in identifying our edition, except where our edition is not uniquely identified and needs to be investigated.

As we move text to the "Page" namespace, the main-namespace page for works will become more like a bibliographic entry. Long term, I would like each work to have COinS, MARC records, and/or a International Standard Bibliographic Description. Then our pages can be indexed in WorldCat as an Internet resource for any specific edition.

For example, a "wikipedia" parameter would be very beneficial, as we already have {{wikipedia}} or {{wikipediaref}} on most works. Year of publication is another param that has been asked for often, and can often be determined automatically using the categories or header notes field. See Template talk:Header/Archive 1#Date_param. Also, and perhaps a little less expected, is an "oclc" parameter, which is a unique identifier for every work. John Vandenberg ^(chat) 08:18, 6 May 2008 (UTC)

While some of these are good ideas, most either cannot be automated by a text processing bot (like adding links to metadata databases), or require human supervision and should be done separately (like placing {{subpage-header}} or adding data in the header). Do you have suggestions for a short-term automated run with little human supervision?

It would be better to discuss each of these ideas separately, then update pages according to the decisions reached. —{admin} Pathoschild 18:35:56, 06 May 2008 (UTC)

parsing "[[category:dddd works]]" into a "year" parameter is simple. filling a "wikipedia" parameter can also be automated for most of the simple cases. replacing "{{header2....}}" with "{{subpage-header}}" is dead simple, and subpages are the larger part of our page count. (what is the point of changing 10s of thousands of sub-pages from header2 to header if the entire header block is able to be replaced with a one liner)

more importantly, if we are going to modify all pages to replace "header2" with "header", the least that we can do is add placeholders for some new params in the header block of the pages, in order to encourage humans to add the values.

Yes, I agree that we need to discuss these ideas a little more, either here or on Template talk:Header, but my intention is that we should find all of the ideas that have already been discussed to death (and put on hold because of the header->header2 conversion), and roll as many as possible in now, so that any automated update of header2->header is helping us catch up. John Vandenberg ^(chat) 00:59, 7 May 2008 (UTC)

I don't disagree. Some of your ideas are easy to implement, as you've noted, and I'm willing to perform them simultaneously.

However, some of those ideas are not so easily automated. For example, placing {{subpage-header}} would require determining whether the page is a subpage or not (and dealing with cases like "The 1/2 baked apple" which look like subpages but aren't) and comparing the header on each subpage to the main header to find discrepancies (like different authors, notes about a particular chapter, et cetera). This would be a complex transition that is much better to perform separately, so that it is easier to review changes. We could iterate through Category:Subpages easily enough.

If you want to minimize duplicate edits, we could place {{subpage-header}} first (once we achieve a consensus on its use), which would remove them from the list of pages needing a header2→header transition. —{admin} Pathoschild 01:57:09, 07 May 2008 (UTC)

I'd recommend we start the header2->header migration by renaming template:header2, then gradually resolve the redirects. -Steve Sanbeg 16:40, 7 May 2008 (UTC)

Pathosbot won't only resolve redirects; it also standardizes parameter layout, performs validation (invalid parameters, invalid or deprecated parameter use, formatting in metadata parameters, redundant symbols, broken syntax, and so forth), and detects incorrect conversions (bot or human), so there is value in a one-time conversion. Since we encourage users to copy & paste from other pages, it would be beneficial to ensure that pages are using the header correctly, but we cannot easily do this manually or during other bot tasks. I think it would be better to do this in a single run of one or two days and be done with it.

So if we do that, the question is what more can we do while we're editing these pages anyway? —{admin} Pathoschild 21:21:31, 07 May 2008 (UTC)

For starters, it can add new optional parameters to be filled in. Now is the time to make these changes. Lets discuss what new optional parameters we want first, and then tackle the second pass of moving "header2" usage back to "header". Does anyone have a problem with "year" or "wikipedia"; can we think of others? John Vandenberg ^(chat) 01:22, 8 May 2008 (UTC)

I split off a separate thread below, so we can discuss each issue separately. I think this will also invite more comment, since not everyone will be following the above discussion with much fascination. —{admin} Pathoschild 01:57:44, 08 May 2008 (UTC)

For the most part the header template is already too rigid and its operation incomprehensible. It should be simplified rather than having more added to it. Why do we need "override author" when simply leaving the slot blank would be enough? If "previous" and "next" are irrelevant to the page in question, we should be able to remove them completely from the template. If we want to include a lot of additional material in the headers, the burden of adding that material should not be foisted upon the average contributor. Such detailed requirements only work to discourage contributors. While I appreciate that some want formats that will be more consistent with standard bibliographic practice, let them be the ones to add that, perhaps in a separate template.

Enough information to establish the freeness of the text is still important, but it can be modularized out of the header. Eclecticology 08:21, 14 May 2008 (UTC)

It's precisely because header usage should be simple that parameters should not be removed. This way, editors can copy and paste from any page and simply change the values, without needing to dredge through documentation. Usage is simple: fill in what is relevant, ignore what is not.

The "override_author" parameter is for rare special cases where we need to change the author line, for example to say "edited by Billy Joe" instead of "by Billy Joe". It's not needed at all if you just want to remove the author line entirely (just leave the author parameter blank).

I agree that we should minimize parameters, which is why each parameter should be discussed thoroughly to decide the benefits of including it. —{admin} Pathoschild 19:00:25, 14 May 2008 (UTC)

[edit] Add new parameters to {{header}}

comment split from above discussion.

Lets discuss what new optional parameters we want first, and then tackle the second pass of moving "header2" usage back to "header". Does anyone have a problem with "year" or "wikipedia"; can we think of others? John Vandenberg ^(chat) 01:22, 8 May 2008 (UTC)

Perhaps forcing the {{edition}} template in the header, that way users will have to provide their sources in the talk page to avoid a red link in the work page, and we wouldn't need to include a template link in the notes section. And I admit I'm one who forgets to add this template, although I always provide the sources for the work in the talk page. Also, by "Wikipedia", I assume you mean to integrate the {{wikipediaref}} template? It would be very useful when adding notes, since it would separate the background notes about the work and notes about the particular edition shown. They could look something like this:

| Wikipedia info =

| Wikipedia article = (link)

If the article link is inserted by the user but no wikipedia info is provided, could the header default to {{wikipedia}}? Just throwing ideas around. :) - Mtmelendez 13:07, 8 May 2008 (UTC)

My suggestion would be to move the licensing parameter into the header also, to make clear that this is a mandatory piece of information about every work. Subpages could inherit this item from their respective base pages. A lot of the work that winds up getting hashed out in WS:COPYVIO could be avoided if the original contributors had provided licensing information or PD status up front. (I also like John’s idea, expressed above, about including an OCLC parameter, or other WorldCat identifiers, in the header, although those should be optional. The PD/license info ought to be required, IMHO.) Tarmstro99 13:37, 8 May 2008 (UTC)

Some of the licensing templates are very large and would cause the header to take up the entire screen - something I'm against. When people click a link, they should see the text of their story immediately, not have to scroll to find it. Sherurcij ^{Collaboration of the Week: Wikisource:Confucianism} 14:32, 8 May 2008 (UTC)

Maybe we can put the licence into a show/hide box?--GrafZahl (talk) 15:17, 8 May 2008 (UTC)

I like the sounds of that. Sherurcij ^{Collaboration of the Week: Wikisource:Confucianism} 17:51, 8 May 2008 (UTC)

I think we can find a compromise to this. Perhaps a single, simple line saying: "This work is in the Public Domain worldwide.", or "This work is in the Public Domain outside the United Kingom.", or "This work is licensed under Creative Commons 2.0.", and then either provide a link to the talk page with detailed information or the copyright template, or simply continue with the normal format of the copyright template serving as a footer to the work. - Mtmelendez 17:10, 8 May 2008 (UTC)

I definitely like that idea. I'll add it to the template if there's no objections. —{admin} Pathoschild 18:09:44, 08 May 2008 (UTC)

I have been thinking that the license displayed on the page should be a single line (I was thinking it should remain at the bottom of the page), with a "license" tab at the top of every page which shows a more detailed explanation. This license "tab" could be driven by JavaScript; if the user has JavaScript disabled, we could have the more detailed explanation appear on the page (which is why it would be better at the bottom of the page). A show/hide box would also work for me.

I'm not in favour of license information being sent to the talk page; it is a "talk" page. We could add a license namespace attached to each page, but I think that is overkill - users are more likely to add a license template if they can quickly add it to the page they are creating.

Please dont alter the template until we have agreement. John Vandenberg ^(chat) 23:24, 8 May 2008 (UTC)

I definitely think a "year" parameter (or maybe more specific like "year_published"--to avoid those situations where something was published decades after it was actually written) would be great. That way we can automatically do categorization for the Category:YYYY works and even many of the licensing templates like PD-1923, PD-old, PD-70. This would significantly reduce the amount of work the contributor has to do as well as help ensure that our works are not copyvios.—Zhaladshar ^(Talk) 15:18, 8 May 2008 (UTC)

"year_published" or "publication_year" works for me. Thinking long term, I would prefer that our header/bibliographic template had enough raw data in it that we don't need license tags. The license can be inferred in most situations; either with a bit of LST magic, or a bot which reviews new pages (after a day to avoid annoying users?), checking the author pages, etc. John Vandenberg ^(chat) 23:37, 8 May 2008 (UTC)

Why do half measures - how about we port the entirety of the Wikipedia {{citation}} template in here and incorporate it into the header so we cover most of the bibliographic data anyone could want? If the aesthetics of page real estate are a concern I'm extremely handy with javascript and CSS and I'd be happy to whip up and cross-browser-test some code that would elide most of the data (and/or format it completely differently) unless the visitor clicks a twisty or something, à la CategoryTree, and work on the license tab thingie John mentions too. (Maybe a tab for the bibliographic data too, huh? With pre-formatted {{citation}} code ready to cut-and-paste into Wikipedia articles? Excuse me, I'm drooling. But check out what I did recently with Men of 1914 - follow the link in the citation in the Wikipedia article John A. M. Adair, for example - I think there could be much better two-way integration between Wikipedia and Wikisource.) Also, whether or not we go full bore with bibliographic data, it seems like we ought to use or at least alias the same parameter names that {{citation}} utilizes. --❨Ṩtruthious ℬandersnatch❩ 22:00, 11 May 2008 (UTC)

Absolutely. We should seriously include as much bibliographical information as possible. If you do not do that, then the articles lose their potential to be a good citable source. When you click the "Cite this" link on the side, it should present as much info as possible. A while ago I was working on all the possibile parameters that would be of use in a WP citation and started a test template here. Feel free to play around with it (i've gone into self-imposed exile on WP) as the template is still incomplete. 52 Pickup 07:18, 16 May 2008 (UTC)

[edit] License parameter

Discussing these separately, {{header3}} is a working proof of concept for integrated mini license texts. The text is transcluded from User:Pathoschild/Licenses, which uses a simple syntax to define all the templates. This page can contain the full texts without displaying them in the header, so we can link to the appropriate section in a "for more information" link for long license texts. If the license text isn't defined, it returns an unknown-template error.

For example (substituted):

{{header3
 | title      = Sandbox
 | author     = 
 | translator = 
 | section    = 
 | previous   = 
 | next       = 
 | license    = PD-release
 | notes      = 
}}

This also allows us to perform license validation (except on subpages): output a warning and categorize the page if no license is specified, or if a license not applicable to the US is specified without a US-applicable alternative. —{admin} Pathoschild 05:29:08, 09 May 2008 (UTC)

That looks really good. But, there's an issue regarding licenses with detailed documentation, such as {{UK-Crown-waiver}}, and with works that have dual licenses. Therefore, adding a show/hide tab for license messages in that same license sentence seems necessary. The current templates or a text description may appear when the user wants to know more. John's suggestion of placing the license line at the bottom of the page, just before the footer, may also work.- Mtmelendez 14:01, 12 May 2008 (UTC)

This will probably be a very unpopular proposal, but I was thinking that it might be better to have the entire page within a template. The actual page content would have its own field. There would be a number of advantages to this:

• It would be easier to set some global page standards, if necessary.
• You can edit the header AND footer from within one template. Use the same parameters as currently used and simply include references to Template:Header/Header2/Footer/.. so this template does not become too unwieldly.
• Licenses could still be placed at the bottom (where they belong, IMO), using a separate licence field, allowing for validation.
• If all pages (not subpages) use this, it would be easy to set up any future field validation checks than may become useful.

Thoughts? 52 Pickup 07:30, 16 May 2008 (UTC)

There are some semantic metadata extensions that do something like that (example), but there are some technical problems with doing that using regular templates. For example, we cannot use wiki tables in template parameters, and there are some issues with whitespace removal. If we wanted to go that route, it would be much better to go with a full-fledged compartmentalized interface. —{admin} Pathoschild 07:51:38, 16 May 2008 (UTC)

I had not yet seen any articles here that used tables, so I assumed that they were not used. My mistake. It is possible to use tables within a template if you replace all instances of "|" with "{{!}}", although I admit that that might be creating more problems than it solves. The compartmentalised interface is new to me and I like the idea. Definitely worth considering, since it also hides most of the code that would otherwise confuse many casual editors. 52 Pickup 08:24, 16 May 2008 (UTC)

[edit] Main page design (again!)

In reference to this discussion in the archives, I was wondering how the community would feel for a trial run of User:DarkFalls/Main Page 2 for a week or month? —Dark ^talk 06:17, 14 May 2008 (UTC)

I'm all for it. The main page needs sprucing up. At least lose the guy on the ladder.--T. Mazzei 03:15, 16 May 2008 (UTC)

The Three vertical sections look terribly stretched at 800x600 Sherurcij ^{Collaboration of the Week: Author:Percival Lowell} 03:16, 16 May 2008 (UTC)

800x600!! Are there still computers capable of resolutions that low!? :^) Actually a few years ago (~2005) some people asked me to fix some things on their computer. It was only capable of displaying 16 (that's not a typo) colours. But it was cheap...--T. Mazzei 03:57, 16 May 2008 (UTC)

We shouldn't make any assumptions about computer settings. For example, portable devices (with tiny screens) are increasingly popular. How good does it look at 300x300? ;) —{admin} Pathoschild 04:36:53, 16 May 2008 (UTC)

Well any web design would look very "uncomfortable" with 300x300 screens, including the main page we have now ;) I've fixed the problem for slightly lower resolutions here (in 1280px and above, the collab will move to the left, under the featured text, while it will remain in the right, under the categories, for low res) , but it is impossible to fix everything to make it look spectacular with all resolutions... (there will be flaws with every design, such as large spaces with high resolutions) —Dark ^talk 09:40, 16 May 2008 (UTC)

[edit] Standardize index linking

I suggest implementing {{indexes}} to standardize and simplify linking to work indexes (not the ProofreadPage indexes). We sometime use the "previous" parameter, but this provides incorrect metadata, does not easily allow linking to multiple indexes, and cannot be easily used if the previous parameter is already correctly used. The template fixes all these problems. For example:

{{header2
 | title    = An Inquiry into the Nature and Causes of the Wealth of Nations
 | author   = Adam Smith
 | section  = 
 | previous = 
 | next     = 
 | notes    = {{indexes|economic theory}} ''An Inquiry into the...
}}

—{admin} Pathoschild 23:08:59, 15 May 2008 (UTC)

I like the idea. Do you envisage {{edition}} being placed before it, or after it? Irrespective of where we place it now, using this template will mean the template can be easily moved to a different place if we decide to revise the header layout. This will also simplify the usage of the previous & next fields. John Vandenberg ^(chat) 23:28, 15 May 2008 (UTC)

I think it looks better when {{edition}} is placed first, but there's little difference:

{{edition}}{{indexes|economic theory}}

{{indexes|economic theory}}{{edition}}

—{admin} Pathoschild 23:40:23, 15 May 2008 (UTC)

Since it looks very unlikely that you would have anything linking from the right-hand side of the Indexes box, why not place {{edition}} there instead of above or below the box? It would look more compact, too. This could be easy to do if all of these header templates be handled by a single "main" header template. 52 Pickup 09:59, 16 May 2008 (UTC)

[edit] Other discussions

[edit] Statistics

User:Jayvdb/Toolserver

I've written a few simple scripts to assess how many works & authors we have on wikisource. Using simplistic algorithms we have 2610 author pages, and 26130 "works" which excludes disambiguation and sub-pages. In the list there are many works that begin with "M" which are encyclopedia articles which would typically be placed as subpages, however Eclecticology (talk • contribs) is doing things different - I should be able to improve the code to deal with this by looking at the headers.

User:Jayvdb/Works with subpages is the current set of works with more than one page, which is a smaller page to look at, and the results can be sorted. Works with more than 500 subpages are:

1. Catholic_Encyclopedia_(1913) 11281
2. Ante-Nicene_Fathers 7443
3. Nicene_and_Post-Nicene_Fathers:_Series_II 7094
4. Nicene_and_Post-Nicene_Fathers:_Series_I 5286
5. The_New_Student's_Reference_Work 2304
6. 1911_Encyclopædia_Britannica 2296
7. Journal_of_Discourses 1455
8. Complete_Encyclopaedia_of_Music 1436
9. The_Complete_Works_of_Swami_Vivekananda 1364
10. A_Short_Biographical_Dictionary_of_English_Literature 1359
11. The_Rig_Veda 1038
12. Dictionary_of_Christian_Biography_and_Literature_to_the_End_of_the_Sixth_Century 958
13. The_City_of_God 689
14. Littell's_Living_Age 582
15. United_States_Code 560

John Vandenberg ^(chat) 14:41, 4 May 2008 (UTC)

At WS:S(2008-04#100K), GrafZahl reports on February 12, 2008 that TalBot arrived at 24367 unique page titles. The algorithms used may be different; mine requires that subpages are named "<title>/...", which ensures that pages starting with "A Boy" are all counted.

Eventually, I would like to see Special:Statistics report this figure as well as the default, and also report the number of author pages as they are a good metric as well. For a start, a nightly bot could compute the number of works and authors and update a protect page that is transcluded into Special:Statistics. John Vandenberg ^(chat) 05:30, 5 May 2008 (UTC)

Due to some improvements, bug fixes, and pages up to "M" being groups together, we are down to 25824 separate works. John Vandenberg ^(chat) 01:51, 6 May 2008 (UTC)

[edit] How to create a DJVU file

Hello, I started this basic Howto. Please complete and correct. Yann 17:51, 5 May 2008 (UTC)

A great addition. Was surprised it wasn't written yet. I don't have much experience, but most admins do. I'm sure they'll take the time to expand it. - Mtmelendez 18:17, 5 May 2008 (UTC)

[edit] Gutenberg copyright releases

Just now I came across this (huge page) listing Gutenberg IP information collated by David Price, UK Project Gutenberg Coordinator, including release numbers, which I assume to be similar to our OTRS IDs. What caught my eye was that Categories is a "release" rather than "copyright cleared", which means it isnt by nature PD. I think we need to understand this Gutenberg release process, and perhaps add a template to indicate that a work we host is {{PD-Gutenberg-release}}, and perhaps note the number. John Vandenberg ^(chat) 13:22, 6 May 2008 (UTC)

Are you sure it's that what it means? On [2] it says "not copyrighted in the US". I'm not sure, but could it be that "copyright cleared" means the PD status was officially determined, and "released" means that the text is actually published by PG? So that they have a two-stage process: first copyright clearance, then release of the copyright-cleared material to the public?--GrafZahl (talk) 14:06, 6 May 2008 (UTC)

(ec)My mistake; the numbers are the Gutenberg etext number. It seems that the page I linked to doesnt include the "Copyright cleared" date for any etext that Gutenberg has released. Anyway, it is a great big lovely list of PD works. here is what it has under Confucius:

The Analects of Confucius by Confucius, trans. James Legge - released 3330, Project Gutenberg

The Chinese Classics, Vol. 1: Confucian Analects by Confucius, James Legge - released 4094, Project Gutenberg

Chinese Literature contrib. to Confucius, ed. Epiphanius Wilson - released 10056, Project Gutenberg

Sacred Books of the East Vol. 16 - The Sacred Books of China - Part II - The Texts of Confucianism: The Yi King (I Ching) by Legge, James - Copyright cleared 12 Aug 2003 by Confucius, James Legge

The Sayings Of Confucius by Confucius, trans. Leonard A. Lyall - released 24055, Project Gutenberg

John Vandenberg ^(chat) 14:13, 6 May 2008 (UTC)

[edit] CIA World Fact Book, 2004 image evolution creep

The CIA World Fact Book, 2004 relies heavily on maps which are stored on the Commons. The problem is that Commons users may update these maps with newer versions (for example, compare [3] against