Wikisource:Scriptorium: Difference between revisions

Hoşgeldiniz - Benvinguts - Benvenite - Croeso - Velkommen - Willkommen - Welcome - Bonvenon - Bienvenidos - Bienvenue - Wolkom - Benvidos - Fáilte - Salve - ברוכים הבאים - Dobrodošli - Benvenuti - ようこそ - 잘 오셨습니다 - Welkom - സ്വാഗതം - Bonvenied - Witajcie - Boa vinda - Tere tulemast - Tervetuloa - Bun venit - Добро пожаловать - Mirëserdhët - Добро дошли - Välkommen - Üdvözlet - Sveicinti jaunum - Veköm - Selamat datang - Xin chào! - 欢迎 - 歡迎

da : Dette er det primære sted, hvor man diskuterer ethvert emne der vedrører Wikisource. Det er også stedet hvor man kan bede om hjælp. Brug det eller de sprog, du kender, og oversæt de indlæg du har lyst til at oversætte.

de : Dies ist eine zentrale Stelle um alle Themen um Wikisource zu diskutieren und ein Platz um nach Hilfe zu fragen. Benutzen Sie die Sprache(n) die sie können und übersetzen Sie wenn und was ihnen gefällt.

en : This is the central location to discuss any issues with Wikisource and the place to ask for help. Use the language(s) you know, and translate when and what you like by others.

eo : Jen la centra diskutloko por ĉio, kio rilatas al la Wikisource kiel vikio. Uzu la lingvo(j)n kiu(j)n vi konas kaj traduku laŭplaĉe tion, kion aliaj redaktis.

es : Este es el lugar central para discutir cualquier asunto de Wikisource y es el lugar para pedir ayuda. Use los idiomas que conozca, y traduce lo que creas necesario que otros sepan.

fi : Tämä on keskeinen paikka jossa keskustella asioista jotka liittyvät itseensä Wikisource puhtaasti Wikinä. Käytä mitä kieltä/kieliä osaat ja halutessasi käännä toisten viestejä toisille kielille.

fr : C'est ici le lieu de discussion central pour ce qui a un rapport avec le Wikisource en tant que Wiki. Utilisez la langue ou les langues que vous connaissez, et traduisez ce que vous aimez postés par les autres.

fy : Op dizze side kin men diskusjearje oer alles wat mei it Wikisource te krijen hat, en oaren om rie freegje at men der sels net út komt. Men kin alle talen brûke dy't men wol, en hat it frij om bydragen fan oaren oer te setten yn in oare taal.

hu : Ez a központi helye a Project Sourceberggel kapcsolatos ötletek megvitatásának és a segítségkérésnek. Használd azt a nyelvet, melyet értesz, és tetszés szerint fordítsd le a mások által írtakat, amikor azt célszerűnek látod.

ja : ここはプロジェクトについて議論したり、質問がある時に尋ねたりするための場所です。お望みの言語を使って書き込んで下さい。他の人の書き込みを翻訳して下さる方も歓迎です。

pl : To główne miejsce dyskusji o sprawach związanych z Wikisource i miejsce uzyskiwania pomocy. Używaj języka/ów, które znasz i tłumacz co i kiedy chcesz, co zostało napisane przez innych.

ro : Acesta este locul central unde să discutaţi în exclusivitate afaceri despre Wikisource şi rolul ei ca şi un Wiki independent. Folosiţi limbile care le cunoaşteţi, şi traduceţi ce vreţi.

sv : Detta är den huvudsakliga platsen där alla typer av frågor rörande Wikisource diskuteras och där nya frågor kan ställas. Använd de språk som du kan och översätt när och vad du vill av andra.

vi : Đây là chỗ chính cho nói chỉ vấn đề chính xác của Kế Wikisource với chỗ cho xin giúp đỡ. Dùng những tiếng mà bạn biết, với dịch lúc nào bạn muốn cái gì bạn thích mà người khác làm.

zh-cn : 这里是讨论与维基资源有关话题和寻求帮助的页面。使用您所了解的语言留言。您也可以在任何时候把他人的留言翻译成您熟悉的语言。

zh-tw : 這裡是討論與維基資源有關話題和尋求幫助的頁面。使用您所了解的語言留言。您也可以在任何時候把他人的留言翻譯成您熟悉的語言。

Moved Discussions

Wikisource and Project Gutenberg to Wikisource:Wikisource and Project Gutenberg.
Name of this project to Wikisource:Votes
Copyright to Wikisource talk:Copyright
Cataloging to Wikisource talk:Index
Infoboxes to Wikisource talk:Infoboxes
Precursor discussions to meta:wikisource
Postal codes to Talk:List of postal codes
Discussions about individual involvement to the User talk: page
Discussions about a particular article to the article Talk: page

Forum

Name of ws namespace on wp

Is there a namespace for the wikipedia to link here, e.g. [[Sources:Some text's title]] ? MrJones 19:19, 13 Jul 2004 (UTC)

The namespace is "Wikisource," as in Wikisource:Scriptorium. From the Wikipedia, Wiktionary, or any other external MediaWiki project, you have to precede it with the Wikisource: namespace, so the link would be [[Wikisource:Wikisource:Scriptorium]]. Similarly, to link to the Wikipedia Community Portal from here, you have to use Wikipedia:Wikipedia:Community Portal.

A regular source such as Constitution of the German Empire will simply be linked from the Wikipedia as [[Wikisource:Constitution of the German Empire]]. --Ardonik 07:31, 19 Jul 2004 (UTC)

Sources headers

Please check out the header of Manifesto of the Communist Party to see if it's appropriate. I advise to add a head part like "English > Texts > XXXXX" to every text so that we can return to the right mainpage as fast as possible. --Samuel 02:51, 9 Feb 2004 (UTC)

What you have done at the Manifesto is just fine. It started off with all the text in one place, and is now being divided by "chapters". I'll leave it alone while the person doing that is working on it. I am, however, changing Frederick Engels to Friedrich whereever I see it. Your idea of a tracings statement is a good one, but I doubt that people will do it. I would probably even omit the piping for this. My Primary Categories scheme would fit very well with that. Eclecticology 07:49, 9 Feb 2004 (UTC)

Great idea! I like it and even used it in The Story of an Hour. :) --Maio 02:46, 10 Feb 2004 (UTC)

(A small quibble: isn't it more useful to list texts with a title of the form "The X" as "X, The"?) MrJones 19:33, 13 Jul 2004 (UTC)

Well, i just find it inconvenient if we don't have these headers: every time when i want to go back to the mainpage, i need to go back mutil-language mainpage first, then English... this idea is not new, which is used by Chinese sources at the first beginning, and is adopted from Wikipedia Esperanto. i don't know if everyone likes to do that, but if that's convenient for people, sysops have to do their jobs. ;) --Samuel 01:39, 11 Feb 2004 (UTC)

I've had similar frustrations. I wonder if links to the other languages could be in the sidebar. I don't oppose tracings; it's just a matter of developing new habits. Eclecticology 05:43, 11 Feb 2004 (UTC)

Well... personally, I think that it's visually unattractive. I'd be much more inclined toward providing meta-information in an infobox, along the lines of many series of Wikipedia articles. For example:

Manifesto of the Communist Party
Written: Karl Marx and Friedrich Engels,
late 1847
Published: February 1848
Language: English, translation (1888) from German by Samuel Moore
Type: Non-Fiction Texts
Wikipedia Article

- Jehanne 00:32, 18 Feb 2004 (UTC)

See regarding infoboxes. A standard template is on the oven me thinks. --Maio 00:53, 18 Feb 2004 (UTC)

I've followed that; templates are developed for each project distinctly; I see no reason why Wikisource has to wait on any particular WikiProject. -- Jehanne 01:42, 18 Feb 2004 (UTC)

Just as a test, I put an infobox in The Adventures of Huckleberry Finn. I'm not entirely satisfied with its appearance either, but it is an alternative to be considered. - Jehanne 15:48, 18 Feb 2004 (UTC)

The general Infobox idea seems attractive. I had some involvenent in the early development of the taxoboxes for taxonomy, and a similar one for battles. I thus strongly support the further development of the idea. Further discussion is required, notably over what these boxes should include, and what should be linked. Eclecticology 21:51, 18 Feb 2004 (UTC)

I have removed the "align=right" parameter from the infobox in The Adventures of Huckleberry Finn - this places the index under the box, wich gives a much better appearence. --Christian S 09:23, 11 May 2004 (UTC)[reply]

cross languages links

Which style do u guys like? this one(top and btm) or this one(btm)? keep the languages' names original ones or using translation names?(see the difference between top and btm here) (oh, my poor English!) then we can write it in Guide to layout and style --Samuel 02:00, 11 Feb 2004 (UTC)

I think that what you have on the Chinese language page is the more attractive format. Use the original language names to attract people who know that language. Don't worry about poor English; what matters for you here is being able to edit the Chinese. Eclecticology 05:43, 11 Feb 2004 (UTC)

maybe we should discuss the layout and meet an agreement now? oh, BTW, we should make sure that we have the right categories for all kinds of texts, or we will have a lot of work to do with the headers when it becomes a fixed style and the categories happens to have be changed unfortunately.. :P --Samuel 02:31, 13 Feb 2004 (UTC)~

Wait a few... this can be done server side (ie: by the software), but it needs to be discussed first with the developers first. [1] --Maio 05:11, 13 Feb 2004 (UTC)

I'm in no rush. There are some layouts that are taking shape, but they may still need a bit of refining. The real test is whether people use them. The categories too need to develop over time. That was why I kept the number down in my own scheme. There would always be a place for new ones when they became needed or when the "None of the above" became too full. Keeping the number of categories down at this time will help us to avoid massive changes in the future.

I worked on Author:Dante Alighieri when I found an orphaned German version of the Divine Comedy. Mav had previously suggested the link format wikipedia:en:Dante Alighieri, which works. Unfortunately, using the same format does not work for the other languages. Some agreed format should be decided for these kind of links. I would also like some views about how we are going to handle namspaces for other languages. We already have an instance of Usator:... for user:... being tried for Interlingua. Eclecticology 07:35, 13 Feb 2004 (UTC)

According to Brion, that should be fixed now, cf. http://mail.wikipedia.org/pipermail/wikitech-l/2004-February/008456.html. Yann 16:38, 16 Feb 2004 (UTC)

Sport results.

The results of an international sports tournament - would they belong here, or would wikipedia be more appropriate? Abigail-II

Wikipedia would be more appropriate. Eclecticology 20:55, 13 Feb 2004 (UTC)

Verification procedure

I believe there should be a procedure that each page goes though of checking. Maybe some pages to log it (Wikisource:Verification). The procedure will go something like this:

Data entered |Source of information|
Data conflict checks |Sources of information|
1st Verification by person 1
2nd Verification by person 2
3rd Verification by person 3
Data Verified.

Possbly on each page cold have a note saying what procedure the data is at:

The source below is currently being verified for the second time.

The data below has not yet been checked for possible errors.

-Fonzy

Good idea, unfortunately due to the nature of s, I don't think it is feezable; as anyone can edit a source at any given time. There are not too many sources right now, but when it grows how do you plan to verify each one of them when you rely on volunteer/hobbie work? By the way, all sources are covered for No Guarantee of Validity by Wikisource's Disclaimers. --Maio 01:48, 17 Feb 2004 (UTC)

I'm not going to hold my breath while I dream about this great idea. For now I would be satisfied with getting people to put enough data to allow verification that what they are adding is in the public domain. Eclecticology 01:52, 17 Feb 2004 (UTC)

It would be quite easy for people to put "proof read by X on Y" notices on the discussion page having compared the text with a print copy and corrected any typographical errors. MrJones 19:41, 13 Jul 2004 (UTC)

Wikisourcerors?

Would there be any support for calling those of us who live at Wikisource Wikisourcerors? It would reflect the magic that we are performing with these tests. :-) Eclecticology 21:24, 18 Feb 2004 (UTC)

Hehe, that sounds like Harry Potter! ..for me that means NO :p --Maio 02:59, 19 Feb 2004 (UTC)

It's... cute. And I usually don't go for cute. But it'll do, in a pinch. -- Jehanne 14:06, 19 Feb 2004 (UTC)

Page size/breaking up texts

Is there a current consensus or argument for/against breaking up "large" works? I notice that this has been unevenly done: some long works have chapters divided into separate articles, others have everything in one single article (my initial preference). -- Jehanne 22:44, 18 Feb 2004 (UTC)

And speaking of breaking up pages... what about separating individual (even short) poems onto their own pages, rather than "Poems of" a particular author? -- Jehanne 02:43, 19 Feb 2004 (UTC)

Long texts SHOULD be provided in both schemes, broken and as a full text. Not everyone browses the web with fast connections, having all sources as full text would be detrimental for the project. Check for example Manifesto of the Communist Party (broken) and Manifesto of the Communist Party (full text). They both link to each other.

About poems: hmm, where is that? Poems should be located on its own page, see On Lucy, Countess of Bedford for an example.

Thanks for expressing your concerns Jehanne! :)

--Maio 03:02, 19 Feb 2004 (UTC)

Honestly, I'm a bit hesitant about this, too. Although we *could* be all things to all people, is it really beneficial? I'd rather add new content rather than multiplying forms of existing content... so I guess I'll leave that up to you, Maio :). As for multiple poems by one author on the same page, see Bilac's poems and Poetry of Emily Brontë. -- Jehanne 03:29, 19 Feb 2004 (UTC)

I'm having hardware problems, so my I answers may be irregular in the next couple days while I sort this out. Big texts should be broken up. Putting all of the Divine Comedy into one 710kb file was bound to create difficulties on some browsers. Choosing how to break that up into three parts was easy. Currently, at about 540kb the Huck Finn file is the biggest one in Wikisource; that's much too big. We perhaps need to determine a maximum file size after which breaking it up would be essential. For Wikipedia I would consider breaking a file up after after 30kb, but here I think we can handle a bigger number maybe up to 100kb. In determining short term priorities we can begin with the biggest ones and bring the maximum size down when we have the time. Some, like π to 100,000 places, may defy all logical treatment.

The other extreme on some web sites is having each printed page as a separate file, even if it means breaking up a sentence. To a user that's just annoying. Breaking up a book of poems into its separate but distinct components is a reasonable approach, but it's often going to be a judgement call where we can be flexible in dealing with it on a case by case basis.

I don't think that having both a full text and a divided text serves a very useful purpose as with the Communist Manifesto, but If someone feels that both should be there I'm not going to argue about it.

One very important thing when a work is broken up, is to make sure that all the parts work together, and that has been going well so far. The contributors who have been entering Kropotkin's Conquest of Bread in Greek, ant The Book of Mormon in Interlingua seem to understand this. Eclecticology 18:33, 19 Feb 2004 (UTC)

I think that's quite reasonable. We don't need multiple copies of the same documents -- that poses problems for those who need to correct typos and the like. 100kb max divisions sounds good to me. What adopt something like the "series" infoboxes from Wikipedia to link the various sections of a single work? -- Jehanne 20:32, 19 Feb 2004 (UTC)

I broke the nearly-600k Huck Finn file into six parts, all smaller than 100k. Any thoughts? -- Jehanne 21:07, 19 Feb 2004 (UTC)

Looks fine. I understand that how we break such things up is arbitrary, but I don't think that there is any way around that. Eclecticology 21:23, 19 Feb 2004 (UTC)

Less, less! should be splitted into a "by chapter" version! >_< a good start tho! ^_^ --Maio 01:19, 20 Feb 2004 (UTC)

I still want to emphasize that one of the advantage of having source material on a Wiki (over an semi-static archive like Project Gutenberg) is that it allows for easy correction of typos and errors in the transcribed text. Generating multiple copies of the same content (e.g. broken by chapters and full text) does not forward these ends. I propose that we settle on a single standard one way or the other. I'd prefer full-text all the way, but Eclect has already pointed out the drawback of that. The two basic alternatives are 100k (or other arbitrary-size) chunks, or by "chapter" or smallest natural subdivision. -- Jehanne 02:11, 20 Feb 2004 (UTC)

By chapter & full text: try to submit a 100K article on a 56K modem then come back and tell me how much you hated it. I don't understand what's the disadvantage of the by chapter version... in order to edit the full text you just need to copy/paste the chapter that you edited into the sub-section of the full-text version. *shrug* --Maio 05:30, 20 Feb 2004 (UTC)

Certainly there are strong valid arguments for files that are much smaller than 100K, and I don't mind if you have the energy to divide the files up that way. Neither Jehanne nor I should feel obliged to do the work of making that breakdown. Also, if you want to add the full text versions feel free to do so. Your cut-and-paste solution may seem straight-forward but the guy with the 56K modem who was having trouble downloading a 100K file, is not going to be inclined to download a 500K file three times (the normal and edit versions plus the normal version again when he saves his changes) just to co-ordinate a typo correction. The two version scheme will rapidly get out of sync. Eclecticology 08:41, 20 Feb 2004 (UTC)

Yeah, I thought about the problem of synchronization also. The software could handle that too, but it is much more complicated and would require more time to code, test and debug. I'm not saying that you are obligued to submit it that way, that is why I used the word 'should'... as in, we should provide but schemes. This is a wiki and we can't restrict how things are submitted, but if you want to submit it both ways and have the time to do so, then you should submit it in both formats. --Maio 14:06, 20 Feb 2004 (UTC)

I'm starting to form the opinion that we should break up texts into their smallest constitutent units only (i.e. chapters, scenes, etc.). This poses two challenges, though, right off the top... 1) facilitating browsing once someone reaches the bottom of the page -- perhaps a navigation footer/box like those being implemented on Wp is also in order, although I cringe at the possiblity of adding more markup, because that increases maintenance time. 2) creating potentially dozens of pages for a single work artifically inflates the "document count" on the main page. I mean, we don't current have 600+ documents; I'd guess we have on the order of 100; but some take up dozens. The Christian bible has only 1000 chapters (which is the logical way to break it up here), but is one "document." I'm not sure how to deal with that difficulty. -- Jehanne 15:45, 20 Feb 2004 (UTC)

I don't think there is any one solution to this. Often the work itself will dictate the best way. I've broken one of the Shakespeare plays As You Like It into acts, and don't see much value at this time to breaking it down further into scenes. The 100K that I suggested before is an arbitrary amount, above which almost anything should be broken down. Our Interlingua version of the Book of Mormon is being divided into chapters, and we'll soon see how that turns out. The effect on document count is certainly accurate, but I see that as much less important than document navigation. Eclecticology 18:12, 23 Feb 2004 (UTC)

I realise I am very new to this project (not one usefull contribution yet), but as a user, I would prefer full text only when downloading the text. Normally, a chapter breakup is much easier. If you make sure there is always a page with all the files listed, someone can always download the entire article by using DAP, GetRight or something alike. That might be a good temporary solution before someone can actually code a synching system into the source. -- User:Kasperl:Kasperl 16:31, 5 Jun 2004 (UTC)

I'm not familiar with the software packages that you mention, but I accept what you say about their apparent usefulness. I am also intrigued by your offer to provide a synching system. I also look forward to your becoming a registered user who is making contributions. Meanwhile, your reader-only perspective is helpful because it gives a focus on issues that is too easily lost when a person becomes a contributor. I support breaking up lengthy works, but there is a bit of an art in breaking up those works, which don't always have obvious subdivisions like chapters. Thanks for giving your comments and welcome to Wikisource. Eclecticology 17:26, 5 Jun 2004 (UTC)

Woops, thought I logged in before posting that.... I'll edit out my IP into my name.

Getright and DAP are download managers, enabling someone to automaticly download a list of links to one file. I am not offering to make a synching system, I am suggesting one. The easiest hack would seem to be to make a page showing the contents of the pages used. One would need to acces the raw texts of the chapters, and use something like a php include to simply throw them all into one page. Makeup would be retained, if you do the collecting before the normal parsing. How to do this is way behond me, since I never learned PHP behond the include command, and have no knowledge whatsoever on wiki code. Editing the full text would perhaps be harder to make, but isn't the main goal. No one would be willing to edit a 740kb file in one run, if you ask me. I do try to contribute to Wikipedia and Wikibooks, and I would try to help Wikisource as well, but my time is limited. -- Kasperl 17:36, 5 Jun 2004 (UTC)

Markup question

Hello! I wasn't able to figure out how to insert raw html anchors in to the text. I am mainly interested in inserting "clickable" footnotes, something like

but as you see it does not work. Apparently the program automatically escapes the "angle" characters, is there a way to "de-escape" them?

Is this the right place to ask such questions BTW? Dr Absentius 05:58, 6 Mar 2004 (UTC)

I know what I don't know, and this is one of them. If the project weren't so small you probably would be OK to post here. I've copied the message to the Wikitech mailing list. Perhaps somebody there will be able to supply an answer. Sorry that I can't help any more than that. Eclecticology 08:27, 6 Mar 2004 (UTC)

We don't currently have a pretty way to do this, but you can put an id attribute on one of the HTML tags we do allow, such as at 1. --Brion VIBBER

Thank you for your answers and sugestions 2. I think that this is an important issue for wikisource: if we have long, complicated and dated works, we need a lot of notes to make them accesible to the modern reader and it is not always possible or even advisable to refer to encyclopaedia articles -- sometimes all that is needed is a short explanation. And of course all the sources here will eventually become dated, so that the future "wikisourcians" will need to add notes to make the texts available to their contemporaries. Dr Absentius 16:56, 6 Mar 2004 (UTC)

Footnotes

<li id="footnote1">
And the suggestion does work!

Proposal: Wikimedia Commons

As Angela noted above, I have written a proposal to share media among the various Wikimedia projects, and to develop a central repository for freely licensed content. I call it the Wikimedia Commons. I have posted the proposal to the wikipedia-l mailing list:

I invite all interested parties to participate in the discussion about whether we want to do this. The discussion about and roadmap for the implementation will be moved to Meta-Wikipedia if a consensus develops that we do.

This project would have significant overlap with Project Sourceberg, which would probably end up being merged into the Commons. The key differences between PS and the Commons:

All types of media are allowed
Easier interfaces for use of these media within the various Wikimedia projects
Not just public domain and FDL, but other free content licenses as well (although FDL/PD recommended for texts)

Your project would be greatly affected by this change, so I realize that I need your cooperation more than anyone else's to pull this off. I am very much interested in reaching a consensus with you, and please do not believe that this is somehow intended to be decided over your head.

Please read the whole proposal before you read on.

...

Thanks. Now that you have a better idea of what I am trying to accomplish here, I'd like to address some possible concerns. Again, if you find these silly, these are just the ones I can think of.

"PS is about texts. This will lead to an invasion of multimedia that has nothing to do with what we are trying to do."

On Wikipedia, mathematicians work happily together with Star Trek fans and political activists. People with different goals generally do not need to cross their ways. Sure, Special:Recentchanges will become less text-centric, but we can come up with filters here to make it work better (adding filters on top of RC is no big deal, we already have lots of them). The same goes for the structure - there will be different spaces within the commons for text, images, music etc.

"This will become a file dump for anything people consider valuable."

The same concern could be leveled at the current Sourceberg, or at Wikipedia, or any other wiki. We will of course develop rules for inclusion. The key guideline I have proposed is: "of possible interest to any Wikimedia project".

"Keeping texts and other material separate is good, as the people who work on these things are different."

My experience with Wikipedia is that people will often work on subjects that they have had no visible interest in before, because they notice them on Wikipedia or are just looking for something to do. Uniting media will enlarge the current community substantially, and I believe that the text content that is here will inevitably benefit greatly from that. What is currently a relatively small community could eventually become as gigantic as Wikipedia itself. Frightening, perhaps, but also very promising.

"Allowing different licenses will lead to incompatibility."

We will have to carefully choose which licenses we want to allow. Maybe we will agree that only the FDL and the public domain are acceptable for texts, but I believe that, for example, the Creative Commons Share Alike license should be compatible with the FDL. For images, the situation is slightly different, as these are separate works, and the FDL allows aggregation with materials that are non-FDL. Of course we only want free material to be on the commons, although for artistic works it might not always be possible to get permission to create derivative works, so I believe that is perhaps a freedom that we have to sometimes do without.

"We have worked hard to build this community, we shouldn't have to give it up."

Abandoning what has been done so far will not be necessary. The name change can be largely automated, and let's face it, "Project Sourceberg" is not a killer brandname. Beyond the software changes, what would effectively happen is that things like the Main Page would have to be redesigned to accommodate different media, but current content could in many cases simply be moved to new locations. Compared with, say, the change of the Italian Wikipedia from UsemodWiki to Phase III, the changes would be mostly cosmetic, especially thanks to the great internationalization work you have already done here.

These are the arguments I can think of. I will follow any responses here, but would also invite you to participate in the mailing list discussion if at all possible.- - Erik Möller

The principle is good, but the approach isn't the better one IMO. First of, I have never understood why the fuck do we have to register for every fucking project of MediaWiki: they should all be integrated, which is what I think you are alluding to (is that right?). I beleive that WikiSource should remain as a project of its own, with a future possibility of either (1) sharing content with Project Gutenberg or (2) totally merging the two projects. There is a lot of people that like to contribute in editing free sources, and the only reasons why WikiSource has remained occult is because of its poor integration to the Wikipedia Project and its troglodyte interface for source editing.

See Manifesto of the Communist Party for one of our best examples of what can be done in WikiSource that can't be done in Gutenberg. By combining the project to a larger repository, it loses its unique characteristic. The ideas are good, creating a repository of files, media, etc. However, from my experience, it seems that the user (the general public) likes to use sites that are specific to one thing, because they provide a team that is focused on one theme only, working on it heavily. See Wikipedia for an example and the dotcom crisis for another.

From my point of view, Wikipedia should be the parent project, encompassing all the other smaller projects under its tutelage. In other words, Wikipedia should become the Wikimedia Commons that you have proposed: a broad project as main root that gives birth to many smaller projects: sources, images, lyrics, musical compositions, whatever.

In other words, Wikipedia should provide a way to automatically link all the smaller projects automatically. Lets say that for example, Shawn Michaels has an FDL lyric: Wikipedia should automatically provide a link to the image gallery and lyrics of Shawn Michaels on its encyclopedia article. The same thing should happen when the users visits Michael's image gallery: it automatically links back to the encyclopedia. This is something that should be handled by the software, not by the editors.

To refute your argument, yes mathematicians work together with Star Trek fans on Wikipedia, because afterall they are all working for a common goal: an encyclopedia. A "repository of all types media" implies a goal too bride. See Google Image Search for an example — it is unidirectional in a sense but incorporates all the other Google projects.

This could very well be a primitive interface of your proposed Wikimedia Commons:

Enciclopedia

Image Gallery

Lyrics

Music

Sources

This is the encyclopedia article of Shawn Michaels.

Enciclopedia

Image Gallery

Lyrics

Music

Sources

This is the image gallery of Shawn Michaels.

#pd: thanks for your invite to the mailing lists, but for me they are so Stone Age... especially when we have the Wikimedia Boards.

--Maio 05:29, 19 Mar 2004 (UTC)

Private, unpublished papers......

Moved to Talk:The Charles Henry Gauss Family Papers

Bible

For discussion on naming Bible texts see Wikisource:Bible

Source code

Would certain algorithms and such be appropriate to include here? Would they have to be GPL'd or what licenses would the code have to be released under? Dysprosia 05:04, 9 Apr 2004 (UTC)

Algorithms and other mathematical procedures in principle would certainly be welcome. The specific term "source code" may be somewhat narrow in describing what that section is all about.

I assume that the algorithms that you have in mind are copyrightable in the first place. If not they would be in the public domain, and there is no problem. That would also be the case if you had the right to put the material into the public domain, and chose to do that. The general licensing regime with the various Wikimedia projects has been the Free Documentation License, which is in some respects similar to the GPL, but I would not want to mislead you about what could be my misunderstandings of the similarities. In principle we want the downstream users to be able to use the material in whatever way they wants. Copyright issues are a matter of ongoing, and mostly inconclusive debate. Eclecticology 07:42, 9 Apr 2004 (UTC)

Ok, if I'll contribute these algos and such, they'll be in the public domain :) Dysprosia 10:26, 9 Apr 2004 (UTC)

Naming change in articles

I've proposed at Meta:Babel that we change the names of most modules to avoid conflicts between different language versions; in the most part of cases, this might involve adding "(English)", "(Français)" etc., or some other tag, to the end of the article titles. I tentatively propose that we discuss the topic until 20th April 2004: if the result is in favour, we can start then. See m:Renaming Wikisource and Wikibooks modules. -- Gabriel Beecham 00:17, 10 Apr 2004 (UTC)

I haven't participated in the development of these things in Wikibooks, so what happens there is up to the participants in that project, and I will keep out of that debate.

That being said, I don't see the problem being as big as you fear. I have no problem adding a language name tag when there is a conflict, unless there is a better option available in those particular circumstances. Except for some very short names, the titles in the language itself will provide natural disambiguators. In general I don't see much of a problem. Some areas may still need special attention, and I've raised one such point at Wikisource:Bible. Eclecticology 01:33, 10 Apr 2004 (UTC)

I agree, the problem isn't huge. It's just to keep things tidy for the future. And as you say, it isn't a huge problem at Wikisource given the nature of the titles here. -- Gabriel Beecham 15:26, 10 Apr 2004 (UTC)

The interwiki setting for wikipedia needs to be changed [[Wikipedia:blahblah]] points to the nonexistent www.wikipedia.org/wiki/blahblah and not en.wikipedia.org/wiki/blahblah as it should.

Interwiki links

This might be a simple question. Is there an interwiki link for Wikisource? I have linked articles to pages here and used the full path, but an interwiki would be better. I just haven't been able to find it. -- Mic 08:31, 17 Apr 2004 (UTC)

Texts of Ivan Illich

I am wondering about the possibility of posting texts, Deschooling Society and Tools for Conviviality on wikisource. They were made publicly accessible at Penn State until his death in 2002 when they were taken off line. Electronic copies of these two works and others continue to float around the web but have a number of errors. [2] [3] [4] [5]

Copyright has never been formally alienated (as far as I can tell), however Illich certainly approved of the dissemmination of his out-of-print texts and must have authorized the Penn site. I'm trying to follow up with Carl Mitcham, who administered the Penn Ivan Illich Studies Web Site to determine how they were able to post his texts. So, what do you all think?

You raise some very important issues that whose potential go well beyond the importance of this Wikisource project and its sister projects. You have evidently considered the copyright issue, and this alone makes your comments worth cautious attention. My experience here has been more commonly with the oblivious who are scarcely able to answer the simple question, "where does this come from?" and lack the skills to make a meaningful comment about the copyright status of the passage in question.

The prima facie situation is that these works are copyright. Piercing that veil requires that all the appropriate homework MUST be done. Looking at the hard copy of Deschooling Society that I have I see that the copyright is in Ilich's own name rather than that of the publisher. That's good. What licensing arrangements did he have with the publisher? Did he have a will, and if so could that will be interpreted to determine the disposition of copyrights? Did his religious order require a vow of perpetual poverty which would require that all his property (which would include copyrights) belonged to the order. In case of an intestacy were there any relatives in a position to claim these rights? Whose law applied to the distribution of his estate? There is a need to address these questions and probably more.

I believe that much of copyright law has come to favour those few whose greed is in the best position to be recompensed. It is simplistic to base a copyright status solely on the age of publication. My contention is that a copyright is a property right, and that such a right is a nullity in the absence of a person to own it. This would effectively throw many writings by deceased persons, or owned by a bankrupt and disolved corporate entity into the public domain. If no-one has the standing to challenge a copyright it should be possible for anyone to re-publish the work with impunity.

Given Ilich's philosophical views, I think that his work would provide an excellent collection for testing this hypothesis. Before proceeding, however, the factual support for this must be rigorously in place. Eclecticology 02:55, 26 Apr 2004 (UTC)

Sub-title

If you use the Cologne Blue skin, and look at the very top of the page where it says "Wikisource", then right under it there is the sub-title "The Free Encyclopedia". This should be changed. I'm looking for suggestions about what this should say. Eclecticology 16:46, 18 May 2004 (UTC)[reply]

What about "The Free Source Repository"? --Christian S 19:51, 18 May 2004 (UTC)[reply]

Good. One thing that I thought about after I wrote the above was "The Free Source Source" :-) Eclecticology 22:29, 18 May 2004 (UTC)[reply]

I'm not happy with the sound of "The Free Source Source" - it looks to me as if it should have been "The Free Source" (which is another possibility) and the word "Source" has turned up once too many by mistake. But maybe that's just a matter of taste... I still think the first suggestion is the best :-) --Christian S 05:19, 19 May 2004 (UTC)[reply]

New namespace - Country:XXX or State:XXX?

Due to the ongoing discussion amongst some users about country pages, let me suggest the use of the namespace Country:XXX or State:XXX for those pages. State:XXX is perhaps the most general. These pages are, as I understand it, intented to be listings of sources relevant to any country/state, and there are arguments against making those pages in the author namespace (states are not "real" authors) as well as without a namespace (they are not sources). Making short informative titles for such pages in the Wikisource namespace may be difficult. --Christian S 11:40, 20 May 2004 (UTC)[reply]

I think that this is the best solution. I'm not too fussed either way though, whether country or state is used. Ambivalenthysteria 11:48, 20 May 2004 (UTC)[reply]

I'm not sure the term "country" is applicable to for example the individual U.S. states, but country pages could be relevant for those as well. On the other hand, "state" is applicable both to independent countries and states as well as non-independent states in a union. That's why I see State:XXX as the most general namespace. --Christian S 12:22, 20 May 2004 (UTC)[reply]

Yeah, I think you're right. Could be a little vague, but avoids potential issues down the track. Ambivalenthysteria 12:39, 20 May 2004 (UTC)[reply]

What about corporations, churches and other 'Corporate Authors?' Further wouldn't a page lising all documents concerned with (say) the American Civil War be useful? Perhaps a classification called ((ABOUT:XXXX)) would be the best way to handle it. [[PaulinSaudi 12:58, 20 May 2004 (UTC)]][reply]

You've got a point there. I think Subject:XXX would be a good possibility (I personally like it better than About:XXX). --Christian S 13:37, 20 May 2004 (UTC)[reply]

I too like the "About:" name space, its far more flexible. eg: About:Child Poverty. or maybe About:Little gnomes that control the world in their underground firery layers. ok maybe not that one but you get the idea. :-) -fonzy

The Wikipedia crowd has been favoring "Category:" but there's no reason or obligation to use the same term. Perhaps it's better if our term is distinct from theirs. As between "About:" and "Subject:" I do favour "Subject:" because a noun says more, and it has more kinship to the Subject Classifications in a library. Is there a better term still that could be accepted across all languages.

The debate in Wikipedia, in Meta and on the mailing lista has been going on for about a year. It has been characterized by a recognition that the wheel was such a great invention as to merit frequent rediscovery. I can appreciate Paul's first effort with "Country:" or "State:", but we really need to think further ahead than that.

We need to remember too that Wikisource is a single multilingual project. If we go ahead and set up a series of English language subjects that process will need to be repeated for each language that we wish to serve. A search in a coded classification system can give us a list of all relevant articles without regard to the language of their texts. Eclecticology 20:56, 20 May 2004 (UTC)[reply]

I think the idea having a Subject namespace isn't bad. It's probably wiser to go for a broader option than State. Ambivalenthysteria 00:00, 21 May 2004 (UTC)[reply]

Thank you for your kind words E. Are we reaching consensus at this point? If so, when and how should we act? I am standing by to do the work once we have made a decision. [[PaulinSaudi 04:56, 21 May 2004 (UTC)]][reply]

A coded classification system would be best. One possible way to build up this system could be pages named "namespace:code" with a multilingual header in the text stating what the subject is in multiple languages. This would require a list of subject codes, probably one for each language. This way only one subject page per subject would need maintainance, along with one list of subject codes per language. This leaves us to the problem of finding a namespace for these pages acceptable to all languages. --Christian S 11:18, 21 May 2004 (UTC)[reply]

I must admit that I do not understand the technicalities of this. It seems to me a page entitled ((XXX)) is just as useful as one labeled ((ABOUT:XXX)) or ((SUBJECT:XXX)). This 'namespace' stuff is mystery to me. [[PaulinSaudi 13:48, 21 May 2004 (UTC)]][reply]

For more about namespaces see http://en.wikipedia.org/wiki/Wikipedia:Namespace What we are talking about is more in the nature of pseudo-namespaces. Eclecticology 21:26, 21 May 2004 (UTC)[reply]

I think we are on the verge of various consensuses about the [pseudo-]namespaces. If I'm completely off base I'm sure you will all be quick to let me know.

The [Author:] namespace functions in a manner similar to an author listing in a library catalog, and should continue to be used in that way.
It remains to be determined if that English word can be used for all such spaces for all languages. Can the structure of an author page be put in a sufficiently generic style as to obviate the need for corresponding pages in other languages?
The [Subject:] namespace functions in a manner similar to the subject catalog of a library. Aside from the word "subject" itself which should be made standard, the available titles are very much language dependent, but this does not prevent them from listing items in other languages.
Is this the work that Paul is looking for?
The [Class:] namespace functions in a manner similar to the Library of Congress or Dewey Decimal classification of books. A defined class should apply to all applicable articles without regard to the language of the article.
Even if we all agree to the principle the [Class:] namespace is not quite implementation ready. How do we allow for multiple overlapping classification systems in a way that recognizes the system to which any given piece of code belongs? I believe that both the LC and DD systems should be available for us, and so too should other systems used in other countries.
The manual production of lists in any of the three areas above is not particularly efficient. Scalability to an automated search should be a design criterion; author, subject and class metadata should be an integral part of any article. The previously proposed info-boxes may be a good medium for implementing the orderly application of these measures.

I think that Wikisource is small enough to allow this sort of thing to be developed with relative ease. It will then be easier to tell developers exactly what we want the software to do. For Wikipedia, with over a quarter million articles to be adapted, the task is daunting. Eclecticology 22:57, 21 May 2004 (UTC)[reply]

The suggestions of E looks fine. About the [class:] namespace: the easiest way to tell the classification systems apart would probably be the use of "pre-codes" for the classification systems, something along the lines of LC-XXX for LC classification codes and DD-XXX for the DD classification codes. If several classification systems are to be implemented, will the texts then need to be classified with respect to all classification systems, or just one of them? In any case a set of classification guidelines would be nessesary (I for one is not familiar with the LC and DD classification systems). --Christian S 11:38, 22 May 2004 (UTC)[reply]

Thanks. Do we agree to the format [Class:LC-XXX]? If so I can begin a Wikisource:Classification systems page to start the development of pre-codes. The DD and LC systems are well known in the ISA and Canada where the LC system is mostly used by university libraries and the DD by public libraries. What European standards are there for such classifications? Ideally every article should be classified under all the systems, but that's not realistic at all. We'll end up with as much classification as people are willing to do; no-one should ever be faulted for failing to add classification numbers.

There is still the issue of infoboxes. See above for one that was designed for the Communist Manifesto, and see also The Adventures of Huckleberry Finn for examples. Just how much can go in these remains an open question, but we should be flexible. Does anyone want to develop an easy to use template? I think I've already created more than enough work for myself with the classifications. Eclecticology 19:21, 22 May 2004 (UTC)[reply]

Buggy links and altlangs

Since yesterday, I've been seeing all Wikisource namespace links as red, even when there's content there, and they lead to the edit pages. There's also been some weirdness concerning altlangs. What's going on? While I'm here, could someone archive some more of the old talk? Mozilla really ain't liking this huge amount of text. Ambivalenthysteria 02:15, 23 May 2004 (UTC)[reply]

I've seen that. Such things always happen when things get upgraded and "improved". This was done during the night, and at one point all the "Wikisource:" namespaces were changed to read "Wikipedia:". That problem was fixed, but I think that the cached data was not fix. I'll be bearing with it for a couple days in the hope that all will be fixed :-) Wikibooks has been having similar problems.

I started to clean up some of the old files, but ran into some difficulties arising from the point above, so some of that will have to wait.

Where possible try section editing instead of full page editing. One thing that really slows down editing is if there is any RTL text (Hebrew, Arabic etc.) in the edit box. It wants to evaluate direction with each additional character you type in. The intro at the top of this page includes some of this. Eclecticology 04:12, 23 May 2004 (UTC)[reply]

Thanks for the tip. Now, two pages I added yesterday are still appearing as red links, and I've just been getting a bunch of database errors...*sighs*. It'd be good to know what was going on. Ambivalenthysteria 18:25, 23 May 2004 (UTC)[reply]

I too have been getting the database errors, and other strange behaviours. But ever the optimist, I'll assume that our technical gurus will get it sorted out over the course of the weekend. Eclecticology 18:59, 23 May 2004 (UTC)[reply]

Proposed Naming Convention

Forgive me if this has been done already. I see Eclecticology is making minor capitalization corrections to "my" presidential speeches. I certainly do not mind, but it seem to me to a waste of time. Certainly the difference between "Grant's Second Inaugural Address" and "Grant's second inaugural address" is small.

Still one or the other must be "right." There needs to be a system. Let me spew out my thoughts on this.

First it does not matter what we call the page itself as long as we have lots of redirects, author's lists and other means of finding documents. Ideally typing in either "Grant's Second Inaugural Address" variant should get the user to the same place. Each page should have a half-dozen or so links

Second, we should use established naming conventions. There is no need to reinvent the wheel.

The AP Stylebook & Libel Manual makes these rules.....

1. Capitalize Principle Words, including Prepositions and Articles of more than four letters.

2. Capitalize any word that begins the name of a composition.

I would add these rules:

3. Use the title the user is most likely to know. I Have a Dream Speech not Martin Luther King's Address to ...

4. Use redirects for common alternative spellings, alternative names and alternative capitalizations.

5. Each document should link to an author's page at least. The more links the better. [[PaulinSaudi 08:42, 28 May 2004 (UTC)]][reply]

Sorry, but I didn't realize that they were "your" presidential speeches; I thought they were made by the named president. Congratulations on your election. :-)

When you complained about my deletion of redirects in the course of re-naming titles, I stopped doing so for most cases. If you want to add more redirect pages, go ahead. For me the principle access to these speeches will be through the author pages.

I agree with using established naming conventions. This is not a problem with your point #2. The two principal identified conventions agree on this. Your #1 does present problems.

The Chicago Style Manual recognizes that titles can be in "sentence style" or "headline style". What Paul describes is the latter. The biggest advantage of the sentence style is that it conforms with what is done in other languages. That being said I still support showing the original capitalization when we are dealing with previously published books.

In the specific area of major speeches CSM states at 8.82, "A very few speeches have attained the status of titles and are thus traditionally capitalized. Others are usually lowercased.

Washington's Farewell Address

the Gettysburg Address

the annual State of the Union address

Franklin Roosevelt's second inaugural address

the Checkers speech

Martin Luther King Jr.'s "I have a dream" speech"

I admit that I was not familiar with the tradition connected to the first item on the list. I haven't done anything with the MLK item, but copyright violation is a bigger issue with that one.

I generally agree with having the material under the best known names, but it is not always clear just what the most common name is. There is even room for argument in the case of some presidents about what the most common name is, though I would avoid diminutive names. Adding middle initials and expanding those initials is certainly debatable. On the other hand but for the entry that Paul has set up I would never have known that Coolidge's first name was John until I was ready to work on that entry.

On #4, go ahead and create all the redirects that you want. Just don't expect me to do it. On #5, I can't argue against something that I've been promoting myself.

Finally, I agree that a system is needed. It's been on my mind for a long time. I should make a priority of starting something. Eclecticology 19:25, 28 May 2004 (UTC)[reply]

If nominated, I will not run. If elected I will not serve.

You know I think I have given up on any hope on imposing uniformity. That is not to say I am upset. It is simply that there are too many good arguments on how to do almost anything in any particular way.

I suspect that is we simply use a bucket load of redirect pages we will be halfway to where we need to be. It is more work for those who compile, but of course this project is really "about" the users. For them this should be a seamless and natural exercise.

Paul in Saudi's Inaugural Address I like how that sounds.

[[PaulinSaudi 11:55, 29 May 2004 (UTC)]][reply]

Sorry, but I couldn't pass up the excellent opportunity that you gave me to be sarcastic. :-) ...but I will resist the temptation to change this one into an "inaugural address".

It's hard to impose uniformity when everyone wants to wear a different uniform. I do like to look on the positive side of things. Of the five points above, we only seriously disagreed on one. I think we also agree that some level of uniformity would be a good thing. It can sometimes resemble an exercise in herding cats. It is about the users, but if we are to consider whether a particular redirect should be used we need to consider whether a user could reasonably be expected to search with that format.

You have been providing some excellent content. That's the important part of your effort, and I have seen very little need to change the content. Our differences have been over the way these things are formatted and linked. I've agreed with some of your proposals, but not others. Attaining uniformity will be a matter of long term convergence rather than imposition. Eclecticology 18:17, 29 May 2004 (UTC)[reply]

New default style

Someone has changed the default style of Wikisource. And this is very unfortunate, because:

the default style should use the default browser font, and nothing else
the style sheet lists Verdana as the font to use (after Bitstream). This is totally unacceptable, because of a serious bug in that font (see Verdana). — Monedula 21:38, 22 May 2004 (UTC)[reply]

Wikipedia and Categories

A couple of weeks ago we discussed creating a new pseudonamespace. However, now Wikipedia has come along and implemented something better, with its category feature. Would it be possible to get that here as well? Ambivalenthysteria 07:40, 2 Jun 2004 (UTC)

How does it work? Is there an explanation somewhere?[[PaulinSaudi 14:14, 2 Jun 2004 (UTC)]]

I've been hesitant to comment on this until I fully understand how it functions. It is in fact fully operational here without our ever asking. I just checked and after about one week Wikipedia managed to generate 2127 categories . There is considerable discussion at . Additionally, there are corresponding pages in six other languages. Brief technical instructions on using categories can be found at m:MediaWiki User's Guide: Using Categories. There are further links from the Wikipedia:Categorization page.

The categories discussion went on for a long time before it was implemented, but the emphasis was more on the general idea, and its technical functioning. The sudden eruption of ~~2127~~ (just looked again, 2140) categories leaves me concerned about how organized the organization process really is. At least the process there needs time to settle down.

The new category system has clear advantages. What we need to consider is how will that system serve to the best advantage of Wikisource. Our previous discussion suggested a developing consensus toward author, subject and class pseudonamespaces. (I'll quickly hear feedback if I'm mistaken on that.) There seems no reason why we can't go ahead as we have with the "Author:" space. The big advantage with the "Class:" space is that it is not language dependant. Where do we want to go from here? Eclecticology 18:40, 3 Jun 2004 (UTC)

Keepig the [autor:] and [class:] pseudonamespaces and using the category system instead of the [subject:] pseudonamespace is, as I see it, the best solution. That gives us the advantages of all 3 systems.--Christian S 20:50, 3 Jun 2004 (UTC)

What about the other way around? Then the name [Subject:] can appear in whatever language is appropriate. [Class:] seems to map more easily into sub-categories. i.e. Category:LC-QAG can appear more easily as a subcategory of Category:LC-QA which is in turn a sub-category of Category:LC-Q. Eclecticology 21:59, 3 Jun 2004 (UTC)

Ahhh! I tried it, and it works. See Wikisource:Class LC- Eclecticology 23:28, 3 Jun 2004 (UTC)

I see your point about using the category system for classes, that would probably work well. I don't see much problem in using it for subjects as well as class. How does that sound? Of course it rules out the possibility of translated pseudonamespaces, which could be seen as a bad thing. Is there any trend or policy to translate the autor: namespace? --Christian S 07:21, 4 Jun 2004 (UTC)

OK, I see where you moved the "Forfatter" pages to "Author". There is certainly no policy, and I have really not checked the Asian pages to see what they are doing. I'm always very mindful of becoming too English dominant, and when that could be seen a oppressive by people in other cultures. I strongly believe in the concept of having this as a single multilingual site. Authors is less of a problem than subjects, since the name tends to be very stable, and having things in a fairly consistent format allows the format to anchor the contents. Subjects can be a lot more complicated if we want them to be understood by more non-English-speaking people, but I'm sure there could be some way of accomodating that in the Category system. Eclecticology 12:14, 4 Jun 2004 (UTC)

I'm not very fond of the idea of organising a Category namespace by LOC or some other organisational system. I think in our case, it would be much more beneficial to create our own categories, according to our own standards, where necessary. The most pressing case, at the moment, it seems, are national and regional categories. Ambivalenthysteria 09:44, 4 Jun 2004 (UTC)

I understand where you're coming from, but I also believe in multiple systems. So LOC would not be functioning to the exclusion of anything else. Establishing your own categories is not as simple as it looks. Wikipedia now has 2382 categories, up by 242 from my earlier posting in this thread! A lot of their categories don't look useful at all, and it looks very much like a reinventing the wheel kind of exercise. I'll keep in mind your need for national categories in what I'm doing with LOC. In that D, E, and F are the classes for history, which can also be used for general material about a country. I do have some ideas about how to develop these, and I can expan on that in the next couple days. Eclecticology 12:14, 4 Jun 2004 (UTC)

I understand where you're coming from, and I think it could work, but I've still got concerns about flexibility. For instance, I'm collecting documents related to some de-facto-independent countries in Asia (such as Abkhazia), and it'd be good to have a category for both those and the related Security Council Resolutions. Where would things like this go in such a system? Ambivalenthysteria 00:38, 5 Jun 2004 (UTC)

That may not be as much of a problem as it seems. Look at Wikisource:Class LC- for what I've done with the Middle-East (which I've taken to include Iran and Sudan). The DK class is already available for the former Soviet Union. A third letter can be applied for each of the recognized former republics. A fourth letter can be added to the relevant republic for the provinces and quasi-republics. Eclecticology 03:57, 5 Jun 2004 (UTC)

I'm not convinced at all by this new system, I'm afraid. While the LOC system might be more finite, for our purposes, I think it's terrible. With the categories that have been added to the UN resolution pages, it's patently *not* obvious, either from the resolution page, or from the category page itself, what category it's supposed to be. I don't think someone should need a crash course in Library of Congress organisation before they can navigate our category system. That was the one advantage of the Wikipedia system - it's a lot easier to recognise, and remember, something along the lines of [[Category:United States of America]]. How do we avoid the issue with the mass of white space being caused by the addition of categories? Ambivalenthysteria 05:18, 9 Jun 2004 (UTC)

There's no tecnical problem in creating a category system "the pedia way" to work alongside the LOC categories. We just have to decide to do so. I agree that there is a recognisability problem with the LOC system, this will be the same for other official classification systems. I do see the advantage in "the pedia way", but also a drawback, namely the multilingual problem - one text covering 3 categories represented in 15 languages result in 45 categories, wich is quite a lot. Wether this will be a problem in the long run only time can show, and I am in support of giving it a try. Creating internationally understandable categories "the pedia way" is probably impossible, so multiple language versions of the same category will probably be the long term result.

Eclecticology has done a great job trying out the LOC system. We should not abandon this system yet, as it is still in the testing/build up fase and far from finished. I think the understandability of this system may improve as the system matures. The two systems does NOT rule out each other. Christian S 15:21, 9 Jun 2004 (UTC)

I appreciate the comments. I agree that the categories are not obvious. I don't think they ever would be on the "resolution" pages, but they should become so on the category pages. It's just a matter of time before somebody can get around to the page Category:LC-DOA to add that the category is about Egypt. The obviousness is less important on the page itself, because if one has the text of the resolution in front of him it is fairly apparent if it's about Egypt. I confess that I don't understand the "white space" comment.

My attention lately on the LC categories has been on developing a comprehensive country list in a way that goes beyond the "official" lists where most of this would involve a letter plus number combination. I don't expect that I will need to get into such fine details elsewhere. In some ways working with the country lists may be easier than with other categories. Although there may be some political questions in some parts of the world, most of the country names are relatively stable. This means that the objective categorization, whether by names or by codes, should be fairly easy. In other areas there are bound to be difficult questions about whether categorization should be coarse of fine.

Nothing keeps us from putting any article in multiple categories. If you want to put an article in Category:Egypt nobody's going to put much effort into stopping you. The multilingual difficulties are still there. There are many possible ways to do this. Do we create some kind of a chart relating codes and names in different languages? Can we use a system of redirects to something where there is common agreement. The fact that there is only a small number of us working on these problems may be to our advantage. Eclecticology 19:08, 9 Jun 2004 (UTC)

So as not to over-clutter the individual pages, would it be possible to put pedia-style categories on the pages themselves, and then link to the LOC pages from there? That way, we could still have the LOC system, for those who so desire, but could have recognisable pages from the categories themselves.

While it might be obvious (with the LOC system) with some pages that they are indeed about the country, what about a resolution that say, refers to Egypt, Syria, Israel, Lebanon and Jordan? I'd rather not have to click on all five to find the one country I'm looking for.

Don't worry about the white space issue...I worked it out last night: it appeared on the resolutions you added the LOC categories to, but that's only because you added the category tag at the top. Add it to the bottom, and the ugly extra white space disappears.

Is having lots of multilingual versions of the same category going to be a problem? I wouldn't tend to see it as such. Also something else I just thought of, does the LOC system have any recognition outside of the English-speaking world? If we were use a system of redirects, how would it work? Ambivalenthysteria 03:05, 10 Jun 2004 (UTC)

1. Please set up an example on a page of your choice so that I don't misunderstand what you are saying. I think that the format [[Category:LC-DOA|Egypt]] does not work in the usual way.

2. I would create links for all five countries. Beyond that it depends on #1.

3. OK. Now I know what you meant. It's not an issue for me; I can put tags at the bottom just as easily as at the top.

4. The biggest problem with multiple language versions of categories is likely to be mismatched systems, and the difficulty of access of other language texts. LC is primarily a North American system for academic libraries. Its use elsewhere is very limited. An other system could work just as well if someone were willing to work on its development for our purposes. If LC is accepted as the standard than Category:China, Category:Chine, Category:中国 etc. could all be redirects to Category:LC-DMA. Ideally with this idea we would want the page for the LC category to show all pages that are redirected to it. Eclecticology 08:33, 10 Jun 2004 (UTC)

1. Please set up an example on a page of your choice so that I don't misunderstand what you are saying. I think that the format [[Category:LC-DOA|Egypt]] does not work in the usual way.

It's simple: reversing what's there at the moment. Subject:Egypt would become Category:Egypt, and be linked from the page itself, and Category:Egypt would link to a LOC-style page for Egypt somewhere else..

What would that somewhere else be? Where would the equivalent existing subject pages in other languages be brought together? -Ec

2. I would create links for all five countries. Beyond that it depends on #1.

But it's confusing as hell if the LOC format is used, and it looks terrible to tack it on down the bottom, as is being done at the moment.

So go ahead and just put the subject entry. Ideally that should redirect to the proper category page (whether that's LOC or something else), but so too would an equivalent subject page in another language. If you don't want to add the LC category nobody's going to force you. As for them appearing at the bottom, I was responding (perhaps wrongly) to something that I thought was your previous complaint. Where they appear on the page is not a big concern for me. I liked the info box idea for all of this meta material, but developping that idea is more than I can handle for now. -Ec

4. The biggest problem with multiple language versions of categories is likely to be mismatched systems, and the difficulty of access of other language texts. LC is primarily a North American system for academic libraries. It's use elsewhere is very limited. An other system could work just as well if someone were willing to work on its development for our purposes. If LC is accepted as the standard than Category:China, Category:Chine, Category:中国 etc. could all be redirects to Category:LC-DMA. Ideally with this idea we would want the page for the LC category to show all pages that are redirected to it.

As you said yourself, LC is an Americocentric system. It's not much recognised elsewhere, and yet, we're supposed to be categoring for a global audience, and even users from languages other than English. Which is one more reason why I think using LOC as a basis, is a terrible idea. Ambivalenthysteria 08:48, 17 Jun 2004 (UTC)

Yes, LC is Americocentric, but it's only a starting point from which I'm already seeing the need for considerable deviation. Including "LC-" as a part of the category name was done to allow for the possibility of using other category schemes. Having those three characters omitted would make them a bit easier to type out. If you want to start an additional category coding system, by all means, go ahead and do it. Even if I don't use it myself, I support your right to develop those ideas. I think that an anglophonic word-based category system would be more generally objectionable that an Americocentric that probably even Americans would need to get used to. Eclecticology 10:55, 17 Jun 2004 (UTC)

shrugs. If I'm going to be putting my time into adding resolutions to WikiSource, I object to anyone who uses that page having to click five, six, seven different links to find what they were looking for, when if we'd taken the default system, they'd have been able to find it at a glance. I haven't seen an example so far of multiple systems being able to work - look at the messy test pages that exist already. Put that it in a case with five, six, seven categories, and the result would be a complete mess. I've stated my case, anyway. Have it your way. As it is, I humbly resign my position as administrator. Ambivalenthysteria 12:33, 17 Jun 2004 (UTC)

If I could reject your resignation I would! I'm at least considering changing the title "List of former administrators" to "List of vacationing administrators." In fact, I don't think that you have used that position very much anyway. That doesn't criticize you, but rather the whole matter of why people want to become administrators in the first place. Your contributions have been very important for their content, and it's important to remember that the content matters far more than any arcane techniques that may be devised for finding the article. Without the contents there is nothing to categorize. Some of us who are comfortable dealing with structures and convoluted system may be overwhelmed by the tedium of accurately including well over 1400 resolutions.

Once a reader has an article in front of him, he doesn't need to find it anymore. I know that that's stating the obvious, but it needs to be stressed. Thus, Subject and/or Category links are not primarily there for the benefit of those who have already found the article. They are there so that the article can be automatically included on lists of similar items. If a resolution is about Cyprus clicking on the right link will produce a list of all other resolutions about Cyprus. Eclecticology 19:55, 17 Jun 2004 (UTC)

A large number of multilingual categories is mainly a problem when placed at the top of a text, using a considerable ammount of space. 60 multilingual categories is not much of a problem when placed at the bottom of a text, but could be when placed at the top, though it's unprobable that we'll reach that amount of categories in one text in any near future.

I don't think the LOC system is generally known in Denmark. As almost all danish libraries uses the DK5 system this is the known system in Denmark, but I believe the DK5 system is fairly unknown in other countries. I don't think any category system is known worldwide. Christian S 06:21, 10 Jun 2004 (UTC)

This could be another reason to go with our own categories, rather than any particular system. In terms of multilingual categories, perhaps we could go the way of the 'pedia and Wiktionary, and create subdomains for each language. That would eliminate that particular problem. Ambivalenthysteria 07:30, 10 Jun 2004 (UTC)

I only regard LOC as a starting point. It is intended to be a comprehensive system, and documentation is readily accessible. Any other comprehensive system would work just as well as a starting point. I have no objection to DKS; does anyone familiar with it want to develop it in our direction? :-) That being said, as we move away from our starting point we really are developing our own system.

I think that going to multiple subdomains would be an admission of failure. Such choices for Wikipedia and Wiktionary had different purposes. With the former it was important for speakers of a language to write for speakers of that language. For Wiktionary the language itself had to be the focus. Our texts should be relatively stable. No-one can come along and reasonably argue that a 20-year old UN resolution should be completely rewritten. I think that how we access material is as important a focus for us as the material itself. The UN resolutions are dumbly available on the UN's own site, but what makes me most enthusiastic about Ambiv's work on this is the potential for new ways to have access to this material. Eclecticology 09:12, 10 Jun 2004 (UTC)

If we are going to use redirects of similar categories to some "international wikisource system", then we should decide on one coded system, not several. This could be one using latin letters like the LOC system or decimal numbers (XX.x....) like the DK5 system. Does some users have trouble using latin letters? The main categories are more or less the same in most categorisation systems, so which system to use is merely a question of the format of codes.--Christian S 10:21, 10 Jun 2004 (UTC)

Category system - a different approach

What about only adding word-based categories to the text in the language the text is written in, and then make interlingual links at the category pages the same way as the main pages link to each other. You will then get the texts sorted by languages, but this will not be much of a problem if interlingual linking is done properly. As most people understand only a limited numer of languages they will only need to search a small number of pages to find all the texts on a given subject in the languages they can read, and these few pages would be easily accessible by interlingual linking. You could also avoid all the texts in languages that you can't read anyway. This way we can avoid the problem with an anglophonic word-based category system, as categories will exist in multiple languages - if you can read the text you can probably understand a word-based category in the same language as the text.--Christian S 15:37, 17 Jun 2004 (UTC)

Hands up who wants to do Latin and Ancient Greek..... Aside from that, this seems to be a pretty good solution. I see no real objection, aside from the ancient languages who might need some special thinking. --Kasperl 16:38, 17 Jun 2004 (UTC)

Historical American Governmental Documents and Their Organization

I'm certainly not new to the Wikimedia world, but I'm realitvely new to Wikisource. In any case, I've been looking at some sources that might be particularly worthy to import, and of the sources that Wikisource appears to be lacking at least in regards to American History, two primary groups of texts seem missing:

The Federalist Papers
Important Supreme Court Cases

In any case, I was wondering if anyone had ideas as to how best to organize them currently (pending newer organizational schemes a-la Categories, mentioned above) -Pipian 20:37, 16 Jun 2004 (UTC)

The nature of these documents is certainly such that they would have a place on Wikisource. I do regularly suggest that contributors prefer providing less accessible documents. The Federalist Papers are paramount to understanding US constitutional law, but I would imagine they are widely available already. The Supreme Court Cases may be more useful, but their accessibility is likely to vary.

The categorization of this type of material remains to be addressed. Until now I have focused on categorization by countries. Thus Subject:United States and Category:LC-E are warranted. Subject:Supreme Court is a likely subject too as are subjects relating to the particulare area of law treated in the particular case. I would prefer to avoid compound subjects as "United States Supreme Court"; there is more scope for expansion when that expression is treated as two subjects.

I would suggest that you begin with a selection of the most significant cases with subject headings that you consider might best describe the documents. These could very well be changed later as the topic develops, but it will at least give me a better impression of what is needed in the area of law. Eclecticology 09:03, 17 Jun 2004 (UTC)

That sounds fairly reasonable, and I'll begin working on trying to gather full texts of important cases. Should I link cases here temporarily, so that it's easier to gather them into a US Supreme Court category in the future?

Incidentally, with regards to usefulness, The Federalist Papers may be less important (due to several sites, such as the University of Oklahoma, having full archives.) they might still be interesting if they were also categorized by subject matter of each paper. On the other hand, it seems to me that while there are some sites featuring full write-ups on the Supreme Court cases, the great majority of them appear to only be excerpts.

As a side note as well, OYEZ has a nice subject directory for cases. In addition, while they don't have the written opinions, they do have oral arguments, and thus it might be nice to link to them as they have some (possibly copywrited) source materials.

-Pipian 02:35, 18 Jun 2004 (UTC)

I've set up a "Court Decisions" section on Wikisource:Historical documents. This would be a good place to start first linkings to these cases. As more of these appear that heading can be sub-divided in a way that supports what is actually contributed.

Your idea about suject categorization is very good. It's the sort of thing which, if done right, can make our version of the Federalist Papers superior to the other versions. There's nothing special about dumping the same plain text that everybody else has. Eclecticology 04:28, 18 Jun 2004 (UTC)

I've currently added a list of major court cases I intend to port over from The Legal Information Institute which already has a digitized copy of the texts of these major cases. I've currently ported and wikified two cases (Marbury v. Madison and McCulloch v. Maryland) which remain to be proofread (as it appears that there are some minor transcription errors in the digitized copies available at the LII). I intend to do this, and add more cases' texts tomorrow.

As soon as categories can be worked out, I'll add those to the text as well. It may also be interesting to crosslink to the text of the Constitution and other documents when referenced in each case's text, though I imagine it would be better to figure out on a case by case basis as some texts may not exist in the wiki yet, and others don't have a direct name that is referenced and thus easy to make into a link, or do not have suitable internal links that can be used when linking to them. - Pipian

Volunteers wanted: Wikimedia Embassy

Hello, at meta:Wikimedia Embassy we have a list with people of the different wikipedias to contact for questions about their projects. It would be fine to have someone from Wikisource there, too. If you like to do the job, please fill in your name there. --Elian

State Government Election Form Copyrights?

I'm currently investigating a fairly full-featured election details for US Presidential Elections (starting with 2000 US Presidential Election). See that page and the prototype Alabama detail page for more information, but some things I stumbled upon while digging up this research were images of Certificates of Ascertainment and Certificates of Votes. As these appear to be state documents (despite their relation to a national election) does anyone know what copyright restrictions there would be on the text or scans of these? Or do I have to do major research into state law codes to find this out? -- Pipian 23:16, 29 Jun 2004 (UTC)

My first observation was that this material was from a U. S. federal government website. My understanding has always been that these are freely usable unless a restriction is specified. Eclecticology 01:03, 30 Jun 2004 (UTC)

Abstracts

Brehms Thierleben
Original language German
Original title Brehms Thierleben. Allgemeine Kunde des Thierreichs.
Written by Alfred Edmund Brehm
Published: 1883 - 1887
Subject Encyclopedia of Zoology
Class
Wikipedia Reference '
Abstract (english) Brehms Thierleben ist the second edition of the zoological encyclopedia written by Alfred Edmund Brehm. It was written in 10 volumes containing the major groups of animals.

I just wondered if it would be a good idea to post an short abstract in english of not-english-texts at the bottom of the pages or in an infobox at the top. So, what I think about ist: I´m writing on th complte edition of Brehms Thierleben in german. I don´t think, that everyone in here is able to read what this text will mean, so I thought about a box where a short description in english tells everyone about that Text. For example, I would like to know what is written on 臺灣前途決議文, so a short box can tell me. Just an idea, -- Necrophorus 21:52, 9 Jul 2004 (UTC)

It sounds like an excellent idea. I like the idea of info boxes too. See the top of this page where it was attempted for Communist Manifesto and Huckleberry Finn. Too bad that the people who started that didn't stay long enough to develop the idea. The abstract might still be too big for the info box, and the abstracts could be wanted in other languages too. I don't know if an abstracts sub-page would be a good idea. Eclecticology 23:10, 9 Jul 2004 (UTC)

Abstracts sounds great. An abstract sub-page seems like the best way to do it, at least if the abstracts are of considerable length or in multiple languages. If the abstract is just a few lines in one or two languages then it may be better just to put it at the top of the text, perhaps in an infobox (I definitely support infoboxes). Putting abstracts at the talk-pages is a possibility, but, if extensively developed, abstracts may then "drown" other comments and questions about the text. Abstract sub-pages could also be a place for developing user-translations of texts (just an idea). Should suct abstract pages have their own [Abstract] pseudo-namespace to distinguish them from actual sources?--Christian S 16:26, 10 Jul 2004 (UTC)

Some good ideas. On talk pages for contentious items the reverse could happen, and the abstract would be drowned by the debate. Talk pages are also a place for greater freedom of expression, while we would want relatively more stability in abstracts. The translation developments are also another forward looking idea. The pseudo-namespace idea is also workable and easy to implement, but I would wait until we have enough abstracts by different people to convince us that the idea has caught on. The community of regulars is still small: that's great for arriving at a working understanding on many operational issues, but it leaves us short of the manpower needed to make these things happen. Eclecticology 17:20, 10 Jul 2004 (UTC)

O.k., how about this combination of the infobox shown at top of this page with a field for a short abstract or description (placed in Brehms Thierleben). If the abstract is more than these lines we can make a page like Brehms Thierleben/Abstract as i will do it for the chapters too (and have done it with the chapters of Robinson Crusoe). Comments? -- Necrophorus 17:26, 10 Jul 2004 (UTC)

The infobox looks fine. Your abstracts are perfect examples of what I meant by "a few lines" at the top of the text. My POV is that the content of the infobox (apart from abstracts) should be in the language of the text, a translatet version of the box content could be posted at the abstract page if it exists. The format Brehms Thierleben/Abstract is fine with me.--Christian S 18:36, 10 Jul 2004 (UTC)

Good work on the infoboxes! In the first effort the The Adventures of Huckleberry Finn info box had a heading in blue. Do we want some kind of colour coding? I don't know if the boxes will be needed for the chapters, but I will maintain an open mind on that. They would certainly look good there, but the problem is that insisting on too much work could be counterproductive. Still they would be more important on the Thierleben than on Robinson Crusoe. The infoboxes fit well with my ideas on categorization. I've filled them in for Robinson Crusoe, but I see that the subject box for the Thierleben already has "Encyclopedia of Zoölogy": I would be inclined to replace that with Zoölogy. Eclecticology 20:44, 10 Jul 2004 (UTC)

Feel fre to change it, if you like because I´ve filled them as a test. I´m a bit puzzled about the Term "Zoölogy", so I´ve never seen it before. In english it´s zoology (as I know) and in german Zoologie. -- 62.134.72.80 21:14, 10 Jul 2004 (UTC)

"Zoölogy" is an English variant spelling. The diaeresis is used on the second of two vowels to show that they are pronounced separately. Eclecticology 02:26, 11 Jul 2004 (UTC)

I have used light gray headings at the infoboxes that I have created (see Bidrag til Professor Jakob Baden’s Levnet for an example). I chose that colour partly to make the infobox more neutral in appearance, partly becourse I had doubts about how the dark background colour used in the Huck Finn infoboxes would appear in B&W print (I haven't testet it, though). I don't think colour coding is needed, the categorisation system and other general information in the infobox should be enough to inform the user what kind of text he is presented to. I'm not sure the categories work properly with the format used in Robinson Crusoe (eg. [[:Category:LC-PNM]]), the Robinson text does not appear at the category pages. Is there no other way to make the category links appear in the infobox and not at the top of the page? Christian S 15:17, 11 Jul 2004 (UTC)

I don't have any strong attachments to the colours. I had noticed it and though that perhaps a fiction/non-fiction distinction had been intended. But the two people who started that aren't active, so we can't ask. Light gray is just fine. I noticed that problem about the categories, and I'll be seeing if I can find a solution. Eclecticology 17:46, 11 Jul 2004 (UTC)

I've mentioned the problem on the Wikitech mailing list; someone will likely respond. Meanwhile, I've tried a workaround on the Robinson Crusoe article. I've changed [:Category:LC-PRA] to read [Category:LC-PRA]LC-PRA. This does put the link back at the top of the page, and leaves a non-linking entry in the box. This should not be a serious problem since people can also link from the subject. I've also changed the "Class" box to read "Category" and changed the colour at the top to light gray. Eclecticology 19:49, 11 Jul 2004 (UTC)

I've had another thought on the colour coding. Could a different colour in an infobox be used to indicate that the page is part of a work. Thus the gray could continue to be used for the main Robinson Crusoe page, and each chapter could have a differently designed box that would apply for chapters. No obligation attached to this thought. :-) Eclecticology 22:10, 11 Jul 2004 (UTC)

Full text page

Contents
("front page")

Chapter page

I like the idea of colour coding pages being part of a work. If done, I think we should use three colours, one for pages containing full texts, one for contents pages and one for chapter pages. I have made a suggestion - other suggestions are welcome. Gray or coloured is no big deal to me, but I do prefer light colours as text background.--Christian S 17:47, 12 Jul 2004 (UTC)

Great! I've brightened the yellow so that it's not the same colour as the background on various namespace pages. See also Template:Infobox Eclecticology 20:39, 12 Jul 2004 (UTC)

I like it too and I have made an Infobox in Robinson Crusoe/Start in Life, a chapter of Robinson Crusoe. Looks fine to me. -- Necrophorus 22:14, 12 Jul 2004 (UTC)

O.k., now there´s a fulltext-coloured infobox in Sououd-e-Melli too and I changed that one in Brehms Thierleben in colour and language. (Sououd-e-Melli is in english, because I´m not able to translate it into the afghan language, but there´s a comment in the edit-Text). I think we can do this with all textes:

create an infobox coloured as shown
choose the used language as a kind of NPOV
try to write an abstract in english and other languages.

I think it will work fine and there are not that many textes in Wikisource, so we will not have problems to make the infbox a standart-used item. Great, -- Necrophorus 22:35, 12 Jul 2004 (UTC)

Do we need the same amount of information on the info boxes for chapters when most of that is already on the table of contents page? The one thing that should be there, however, is links to the chapter before, and the one after. I hope that we can avoid having people so overwhelmed that they just stop using the boxes. Some people on the en:Wikipedia very strongly don't like them. Eclecticology 05:00, 13 Jul 2004 (UTC)

Better this way: Robinson Crusoe/Start in Life? -- Necrophorus 08:11, 13 Jul 2004 (UTC)

Categorization progress report

Since I've undertaken to develop a coded category system using the LOC classification as a starting point, I thought it best to report how that has been progressing. So far, so good. There is still the problem of people understandably not feeling the need to memorize a lot of codes, which I admit are too many for even me to remember. I am still convinced that pages named [Subject:xxx], or its equivalent in other languages, which redirect to the appropriate code will work. Hopefully it will be enough to overcome the difficulty of remembering long lists.

The development status of the categories is thus:

Most of the top level categories have been specified at Category:LC-
The country lists are essentially done. See Help:LC-D, Help:LC-E and Help:LC-F. The only countries not yet specified are the islands of the South Pacific, and a decision still needs to be made for how to refer to Antarctic islands.
A first draft outline of the Law category can be found at Category talk:LC-K. This still needs a bit more organizing before the letters are assigned. Please feel free to add comments; help and the ideas of others are always welcome.
I've done some work on the literature half of the language and literature class. The principal Romance and Germanic literatures can be coded, and I'm wanting to separate language and literature for the others more than is the case in LOC. My next priority will be in the PN class to identify the different genres of literature.
Help needed. The LOC system was first set up over 100 years ago, and only allowed a small section of the mathematics class for mechanical calculating machines. This is wholly inadequate for the modern computer age. I am proposing to use the otherwise unused TB class for Software engineering, programs, source code, etc. We already have a fair amount of this material, and I am very much at a loss about how best to organize this. Any ideas will be appreciated at Category talk:LC-TB.

Eclecticology 22:54, 9 Jul 2004 (UTC)

Dupe Entries

I'll address each of these separately. Ec

I note that: Woodrow Wilson declares war on Germany is the same speech as: President Wilson's War Address Although the two articles do not agree as to the date of the speech. Further, both versions seem the have several acre-feet of typos. What shall we do? Is there an expert on this in the house? [[PaulinSaudi 14:01, 16 Jul 2004 (UTC)]]

I'm inclined to favour the first title, but before I dispose of the alternate version, can you look into the correct date, and possibly resolving the typos in the one we keep. Eclecticology 19:48, 16 Jul 2004 (UTC)

Also: George W Bush's First State of the Union Speech and State of the Union address, 2002 [[PaulinSaudi 14:12, 16 Jul 2004 (UTC)]]

Also: George Washington's First Annual Message to Congress is the same as State of the Union address, 1790 [[PaulinSaudi 14:20, 16 Jul 2004 (UTC)]]

"What is Wikisource?"

http://sources.wikipedia.org/wiki/Wikisource:What_is_Wikisource%3F Doesn't exist as of five seconds ago, according to my browser. This is bad, since it's linked from http://sources.wikipedia.org/wiki/Main_Page:English . I apologize that I'm a new user and don't yet know how to make intrawiki links. Phthoggos 04:41, 20 Jul 2004 (UTC)

The Danish and French versions (Wikisource:Hvad er Wikisource and Wikisource:Qu'est-ce que Wikisource) are gone as well. The histories of these pages have also disappeared. They don't show in the deletion log, so they have not been deleted the ordinary way. I have no idea how these pages have disappeared.

For editing help see Wikisource:How does one edit a page or just follow the "editing help" link at the bottom of the edit page (opens a new window and does not disturb your edit). There you can find technical instrucions on editing (markup, internal links etc.)--Christian S 05:39, 20 Jul 2004 (UTC)

Setting up a new language

Hello. I want to investigate the possibility of setting up a Hebrew WikiSource. Is there any sort of step-by-step guide to setting up a version in a new language? (I am fluent in both English and Hebrew, and contribute mostly to the English Wikipedia despite living in Israel.)

Dovi 15:34, 21 Jul 2004 (UTC)

Welcome. Anybody can do it! (as long as they understand Hebrew) Go to the project's Main Page. Edit the list of languages at the top of the page to include Hebrew; this will create a link to the new Hebrew main page that you will be writing. You should also create a new "HE" section at the appropriate place where you essentially translate the the material that is already there for other languages.

Once you have created the links on the Main Page go to the new Main Page:Hebrew and begin writing. Feel free to use the layout on the English Main Page as a basis for design. I hope this helps you to get started. Eclecticology 06:30, 22 Jul 2004 (UTC)

Thank you very much!Dovi 04:10, 23 Jul 2004 (UTC)

I'm now trying to make sense of the domain names. Are they planned to stay as they are now, or to be moved to "en", "es" etc. like in the other projects?Dovi 04:14, 23 Jul 2004 (UTC)

I hope that it stays as it is now! I look at Wikisource as a unique for all the languages to work together in a single project. That is a very interesting challenge. Eclecticology 05:00, 23 Jul 2004 (UTC)

OK, so I'll try to ahead and set it up where you suggest. Let's see how this goes (and if I have enough time for it). Thanks for the help.Dovi 07:53, 23 Jul 2004 (UTC)

Music

Could people look at the adaptation of the infobox at KV 545. Angela has started (with some reason) to have songs and music included in Wikisource. User:Raul654 has started working on moving material here. I'm hoping to forestall having a lot of orphaned music files dumped on us. Eclecticology 05:00, 23 Jul 2004 (UTC)

Change of domain name

I just moved this wiki from sources.wikipedia.org to wikisource.org. This wasn't possible before because the DNS entry wasn't correctly configured, but now it's fixed. Note that this does make it technically possible to switch to a multi-subdomain site. I'm aware of Ec's opinion on this, and I wouldn't want to force the community into anything, I just wanted you to know that it's possible. -- Tim Starling 08:00, 23 Jul 2004 (UTC)

@@ Line 803: / Line 803: @@
 ==Music==
 Could people look at the adaptation of the infobox at [[KV 545]].  Angela has started (with some reason) to have songs and music included in Wikisource.  [[User:Raul654]] has started working on moving material here.  I'm hoping to forestall having a lot of orphaned music files dumped on us.  [[User:Eclecticology|Eclecticology]] 05:00, 23 Jul 2004 (UTC)
+==Change of domain name==
+I just moved this wiki from sources.wikipedia.org to wikisource.org. This wasn't possible before because the DNS entry wasn't correctly configured, but now it's fixed. Note that this does make it technically possible to switch to a multi-subdomain site. I'm aware of Ec's opinion on this, and I wouldn't want to force the community into anything, I just wanted you to know that it's possible. -- [[User:Tim Starling|Tim Starling]] 08:00, 23 Jul 2004 (UTC)