Because we have had problems with spam bots, new persons wanting to edit this site must apply by e-mail to accounts[at]wikilivres.ca.


Wikilivres:Community Portal/en

Free texts and images.

Jump to: navigation, search

Add a theme

Forums: EnglishFrenchPolishRussian


Archives


Contents

El Principito

There is no doubt that the original French is in the public domain, but this Spanish translation by Gaston Ringuelet is from a translator who is alive. Do we have any documentation showing that he granted a free licence? How are we tracking such permissions? Eclecticology 19:51, 12 May 2012 (EDT)

This question is for Yann. Probably he knows better. Dmitrismirnov 20:02, 12 May 2012 (EDT)
I had direct contact from the translator who gave his permission. Yann 15:03, 23 May 2012 (EDT)

PD templates

Can anyone explain why Template:PD-old-70-author appears on the pages of very long dead authors such as Shakespeare, Blake and others? Eclecticology 01:03, 15 May 2012 (EDT)

I do not understand what do you mean. Where there appeared in particular? I can't find. We use normally Template:PD-pma-author now. Dmitrismirnov 02:18, 15 May 2012 (EDT)

But anyway, authors could be old, however the translations of their work and articles on them could be newer. Dmitrismirnov 02:23, 15 May 2012 (EDT)
If you go to the author pages for the two authors the box at the bottom still refers "countries where the copyright term is the author's life plus 70 years or less." They should be in the public domain everywhere. The pages for translators Gide and Morozov are correct. The problem may be because the newer templat transcludes the old one ratheer than operating independently. Eclecticology 04:59, 15 May 2012 (EDT)
I am not sure how to resolve this technical problem. Dmitrismirnov 05:09, 15 May 2012 (EDT)
It would be easy enough to create a new template that said that the author's works were out of copyright everywhere. The only problem is that if an author drops out of copyright the template would have to be changed manually.--Poetlister 17:11, 17 May 2012 (EDT)
What seems to have happened at the time these templates were deprecated is that the new template that calculated the status transcluded the old deprecated templates instead of writing a whole new text. The new template should be able to calculate when the author has been dead for more than 100 years. I see no problem with generating texts like "countries where copyright is for 68 yesars or less" even if exactly 68 years does not figure into the laws of any country. Eclecticology 16:09, 18 May 2012 (EDT)

Licenses to phase out

I consider that phasing out non-commercial and non-derivative licenses means that Template:Authorized will also have to be phased out for being too generic to tell whether commercial and derivative uses are too restrictive to be compatible with cc-by-sa and GFDL. I am rewriting Wikilivres:Inclusion policy to consider Template:Authorized not sufficiently good for long term. Some "authorized" works are unauthorized for third-party uses other than fair use. Please advise when the alternate website for works with non-commercial, non-derivative, and similar restrictive licenses is finalized, as I have to report what is happening here to Chinese Wikisource.--Jusjih 13:53, 15 May 2012 (EDT)

Thanks for fixing so many of my typos on the other page. That said, I mostly agree. I had left Template:Authorized because it seemed more permissive than what you now say. The term "some rights reserved" lacks clarity for downstream users. Some discussion of alternative hosting is still happening on the commmunity Portal page of the old site, and will no doubt continue as long as the site remains live. Most of that conversation has been happening in Russian. I hope that those more involved with that will report here when answers are available. Eclecticology 15:20, 15 May 2012 (EDT)
Seeing http://wikilivres.info/w/index.php?title=Wikilivres:Community_Portal/en&diff=134341&oldid=134334 , I just found that all of my contributions through 6 May 2012, including deleted ones, are already here. Next, we will have to plan where to send works with non-commercial and non-derivative licenses.--Jusjih 07:38, 22 May 2012 (EDT)
It was all done as an indiscriminate database transfer. It will still take time to go through it all. Eclecticology 13:22, 22 May 2012 (EDT)

Information organization

I was looking at pages like Fitzgerald which is an orphan that simply disambiguates a husband and wife, Wikilivres:Authors in the English section which looks like it was a good idea at the time, but has suffered from lack of maintenance. The former seems redundant as long as the two names are near to each other on the alphabetical list of authors. Can the latter be updated, or is there a better way of accomplishing what it does? Eclecticology 15:55, 15 May 2012 (EDT)


Jаbbаr Мanaf oglu Маmmаdоv

I think here is a problem. Mr. Jаbbаr Мanaf oglu Маmmаdоv already published his work on the Russian Wikisource: Search. His publication here looks quite extensive. Dmitrismirnov 11:17, 16 May 2012 (EDT)

О_проблеме_«светоносной_среды»

Thank you for the information and link. I do note that the Wikisource page includes a notice that permissions under the OTRS system are on file. I agree with the point you are making. Eclecticology 15:37, 16 May 2012 (EDT)

Translations from Wikipedia

The discussion at Wikilivres:Delete#Articles issus de Wikipedia appears to have stalled last September without resolution. At that time it was entirely in French. There are some important points to be considered.

La discussion à Wikilivres:Delete#Articles issus de Wikipedia semble avoir arreter sans conclusion le septembre dernier quand c'étaient complètement en français. Il y a des points importants à considérer. Eclecticology 19:17, 19 May 2012 (EDT)

Interwiki link updated

Hello,

I would like to announce that the interwiki link [[wikilivres: on Wikimedia sites has been updated, and now point here. The old site will be closed by June 6th, 2012. Yann 15:08, 23 May 2012 (EDT)

To be copied from Commons

Hello,

There are a few thousand works to be deleted on Commons because of URAA. These could be copied here. If anyone wants to take care of that, s/he is more than welcome. See also commons:Commons:Deletion requests/Various PD-Australia after 1945. Regards, Yann 12:02, 24 May 2012 (EDT)

Good points. Perhaps you might give this notice to key people at commons. This might bring a few new people here. :) Personally, I've never been technically at ease working with media files, and I already have plenty to do without taking on that job. My one concern is that this project started as a spin-off of Wikisource, and is thus heavily textual. Media files, such as would be found in Commons, demand considerably more memory for storage. I would be very interested to have an estimate of the memory requirements arising from taking on more commons-like files. Eclecticology 15:37, 24 May 2012 (EDT)
As a very rough estimate, I'd allow 1 MB per file (file size plus various overheads inherent in the wiki software). So 1000 files would require 1 GB of storage. Also, the overhead in file transfers in displaying a picture is much greater than displaying text. If a page is 25k of text and you add 100k of picture, the overhead goes up by a factor of five.--Poetlister 15:02, 26 May 2012 (EDT)
Thanks. It's something to keep in mind binging policy forward. Even if these files are OK from a copyright perspective, it wouldn't do if they crash the site. If some triage must be applied I would give priority to keeping scans of texts not found anywhere else that support a goal of making available writings that are not easily found. Eclecticology 15:29, 26 May 2012 (EDT)
I don't think images would create any problem at this time. 7,195 files have already uploaded. On the old server, Squid was used for caching images, and the first limit would have been the bandwidth if they would have been a lot of downloads, but we were very far from it. If there is a huge load increase, I would also except that Wikilivres gets more support, and can rent a bigger server. Yann 10:11, 27 May 2012 (EDT)
Indeed, and I am not proposing any immediate change of policy. It is still something that I will be watching. The other long term question remains whether the goals of this project remain more akin to those of Wikisource or Commons. This has a lot to do with the vision that we have for this project as something more than a place to conveniently park files. Eclecticology 18:19, 27 May 2012 (EDT)
Yes. Now that the site has been moved successfully, it seems the right time to discuss about a general policy of inclusion. The site started with French texts only, and has then slowly included more and more languages, and then also images. So far, these different categories of documents have been hosted side by side without interference. Then there is also the issue of previous publication, and of texts copied from Wikipedia. Some original texts have been published. Yann 08:24, 28 May 2012 (EDT)
I'm fine with remaining multilingual as long as we have the manpower to do the regular maintenance on what we have. There is work to be done in building a more uniform approach to templates, about which I'll go into later in some other thread. Previous publication is an important criterion. At Wikisource that has been a significant factor in avoiding the endless NPOV disputes that are a plague at Wikipedia. For translations this means previous publication in any language. With a work like Le Petit Prince some key translations remain copyright protected; our own free translations would be a welcome addition. Initial machine translations under a CC0 licence could be further developed using Wiki principles. Importing or adapting Wikipedia files could easily become an importation of their problems. Apart from any space or memory considertion, I think that image files have their own problems of curation and classification; unless we have the right people for that kind of work we would do better to limit ourselves to the kind of file that is needed to support our text files. Please let's develop any of these ideas in separate threads. Eclecticology 21:20, 28 May 2012 (EDT)

When should a work be considered "abandoned"?

I was looking at Mystic Treatises (Isaac of Nineveh). This has not been worked on since August 2010. Before that scans of the book were made, and (presumably all) its pages were uploaded here. All of it also seems available on Commons. It was rejected at Wikisource, perhaps because the translator from ancient Syriac did not die until 1939. Only a handful of pages were OCRed before the project was apparently abandoned.

My question then: Assuming that a work is one that is otherwise acceptable here, when should it be deleted on grounds of abandonment? What will be our criteria: How much of the work do we have? How long since the contributor last worked on it … or on anything else in Wikilivres? How likely is it that someone else will do the work? Are there any stand-alone elements in the work that can be kept even if the rest of the work can be deleted? Eclecticology 15:48, 1 June 2012 (EDT)

I would not delete a page because the author is not active anymore, if there is any substantial work on it. IMO, criteria for deletion should be: available reliably elsewhere, copyright issues, etc., but not that the contributor is not here anymore. Yann 06:09, 3 June 2012 (EDT)
I would only use that criterion in connection with others. What we mean by "substantial work" is a more interesting question. Does copying images from another source and maybe doing OCR on 12 out of 400 pages constitute substantial work? Eclecticology 15:28, 3 June 2012 (EDT)
Correcting 12 pages out of 400 pages is not substantial work, but importing 400 images might be, especially if the original ones are not easily available. Yann 06:35, 8 June 2012 (EDT)
For Isaac of Nineveh this entire work is already on Commons. Eclecticology 15:04, 8 June 2012 (EDT)

Logo disappeared

Hi, The logo on the upper left disappeared today. Yann 06:36, 8 June 2012 (EDT)

I suspect that this has something to do with shutting down the old site. There is likely something in the MediaWiki files that render the logo with a link back to wikilivres.info. I’ll look more into it; maybe I’ll be able to figure it out. Eclecticology 15:09, 8 June 2012 (EDT)
I had difficulties to join the site yesterday. Except the logo everything seems to work smoothly now. --Zephyrus 18:45, 8 June 2012 (EDT)
When I look at the page source I find a link to
<div class="portlet" id="p-logo">
<a style="background-image: url(http://www.wikilivres.info/common/logo.png);"
If I put this into the address line changing the "info" to "ca" I get the logo correctly. This tells me that the image file was probably transferred like the rest of the files. I just don’t know where to go to correct the link.
The only other thing that may still not link properly is the five little page quality icons, but I may be able to change this by changing the common.js file. Eclecticology 21:00, 8 June 2012 (EDT)
I don’t know either where to correct this. Can these explanations help or are they obsolete? --Zephyrus 02:45, 9 June 2012 (EDT)
Alan has made some progress in fixing this, but not for all skins. Eclecticology 00:25, 10 June 2012 (EDT)
OK for me now. Yann 02:40, 10 June 2012 (EDT)
OK for me too. --Zephyrus 19:33, 10 June 2012 (EDT)

There is also a problem with the Template:TextQuality: there is a question mark in a blue square at the top of any page with {{TextQuality|100%}} instead of an image for example: Rondeau de la suffisance. -- Dmitrismirnov 07:06, 11 June 2012 (EDT)

This is how I see it on Safari browser. When I look at it in the IE - everything is OK. This is quite strange... and I don't understand why this is happened. -- Dmitrismirnov 10:57, 11 June 2012 (EDT)
I use Firefox, and haven’t seen this problem. I have just changed a couple of links in MediaWiki:Common.js from wikilivres.info to wikilivres.ca. Let me know if this makes any difference. Eclecticology 12:59, 11 June 2012 (EDT)
Thanks! Now it looks perfect in Safari as well! Dmitrismirnov 13:10, 11 June 2012 (EDT)

Upload limit

Hello,

It seems the upload limit is 2 MB now. Could it be increase up to 100 MB as it was on the old site, and as it is on Wikimedia sites? Thanks, Yann 06:38, 8 June 2012 (EDT)

I’ll pass this message on to Alan. Eclecticology 15:11, 8 June 2012 (EDT)
It works now, thanks. Yann 02:47, 10 June 2012 (EDT)

djvu preview and index-creation failed

I uploaded today an djvu-file but the preview failed. Also I was not able to open an index file with the uploaded djvu. The format seems to be unknown now. I would be happy if this could be repaired (either for djvu or pdf) to avoid a single page uploading. In the past it went fairly well for djvu and only failed for pdf. --Wassermann 07:39, 11 June 2012 (EDT)

There were two changes that I made in the common.js page. One may have addressed this, but I really can’t say for sure. Anyway try again to see if it works. Eclecticology 13:11, 11 June 2012 (EDT)
No, unfortunately still the same error. --Wassermann 16:02, 11 June 2012 (EDT) ... btw. it just occurs for new uploads. The old once are still fine. See Category:Max Schraut ...
The file seems to download OK (at least in Chrome), but won’t open. This seems like something broken in the upload process, or the old files wouldn’t work either. Perhaps someone with more experience can coomment. I’ll keep looking and trying things. Eclecticology 00:27, 12 June 2012 (EDT)
OK, I have made a check with an old file and it did not work either after the upload.--Wassermann 02:48, 12 June 2012 (EDT)
I think you have to reinstall djvulibre and configure Proofread Page for the new site. Marc 04:45, 12 June 2012 (EDT)
Can please somebody check out if Marc is correct. And if so please reinstall both extensions to the site?--Wassermann 12:03, 13 June 2012 (EDT)
I think that's the most probable reason. Yann 12:54, 20 June 2012 (EDT)
This has been mentioned on the Wikimedia Canada mailing list. No response so far, so I’ll repeat my request there. Failing this, I plan to be in Washington for Wikimania, and perhaps I can find help there. Eclecticology 13:28, 20 June 2012 (EDT)

Template:Nick Adams

I am always pleased to be rid of unnnecessary templates whose meaning is only understood by its originator, or other templates that duplicate what was done by someone else merely because the new creator couldn’t be sure of the function of the old one, or worse didn’t even know it was there. Often there is no documentation at all. So I’m looking at doing some housekeeping with minimal disruption.

Template:Nick Adams appears only on the author page for Ernest Hemingway where all it does is add "[NA]" for those stories known as the Nick Adams stories. What’s worse it does not clarify what "NA" stands for. A simple plain text "a Nick Adams story" would suffice in all places where the template appears. Eclecticology 00:24, 13 June 2012 (EDT)

Seems very sensible; I agree.--Poetlister 08:05, 14 June 2012 (EDT)

Photography: Theory and Practice

I have not closed en.ws:Wikisource:Possible_copyright_violations#Photography:_Theory_and_Practice because:

  1. There are so many templates that I have not brought here, when I did not expect them.
  2. There are uncertainty to whether the related pages can really be kept on English Wikisource in Florida, USA.

Would someone please assess whether Photography:_Theory_and_Practice should stay on English Wikisource or be brought here? If staying on English Wikisource, we delete the pages here. Otherwise, some missing templates have to be brought here, but this is a complex work.--Jusjih 05:59, 13 June 2012 (EDT)

From a legal copyright perspective I see no problem with with hosting this work here. There is currently a problem with uploading .djvu files (see above at #djvu preview and index-creation failed). Try as I may the problem is well beyond my understanding.
What concerns me in this is the importation of complex templates applicable to a single work. Are there no generic templates that would accomplish the same result? I already find that we have any number of templates whose effects are obscure and which are completely lacking in documentation. Eclecticology 14:34, 13 June 2012 (EDT)
Thanks. I do know it fine to host this work here in Canada. One possible solution is to import all related templates through en.ws:Special:Export by checking the box "Include templates". If no other comments, I will import all related templates and then delete the pages on Wikisource.--Jusjih 12:10, 20 June 2012 (EDT)
Fine. Still, this is no guarantee that the templates will work properly, or that anyone here will know how to fix them. Eclecticology 13:25, 20 June 2012 (EDT)

Polish authors works on Wikilivres

Is it possible to publish here works of Polish authors who died more than 50 years ago? I read Canadian copyright law and Rule of the shorter term and it seems that it would be possible. There in Poland copyrights last generally 70 years p.m.a. Poland has no paragraph of rule of the shorter term in Polish copyright law but it is a member of European Union and implemented EU directive 93/98/EEC on harmonising the term of copyright protection. Electron   03:58, 27 June 2012 (EDT)

Yes, it is possible. The works could not be published in Poland, but it is allowed under the Canadian law. Yann 15:34, 27 June 2012 (EDT)
Agreed. The other point to be considered is that Canada does not have any restoration rights. Thus, if a work went into a foreign public domain at some time in the past, the rule of the shorter term would come into play at that time; a subsequent restoration in that foreign jurisdiction should not apply in Canada. Also if an EU country has a 25 year rule for posthumous works that rule would trump the Canadian 50 year posthumous rule. Eclecticology 02:56, 28 June 2012 (EDT)
Thanks for the answer. So I am going to start Polish section here :) Electron   07:49, 28 June 2012 (EDT)
Welcome to Canadian Wikilivres. If a Polish work was published in or before 1922, thus public domain in the USA, but it is still copyright-restricted in both Canada and Poland, i.e. its author is known not to have died for more than 50 years, please host it at Old Wikisource. If public domain in Canada and the USA, but still copyright-restricted in Poland and unacceptable at Polish Wikisource, i.e., pre-1923 publication with death of more than 50 years but up to 70 years, perhaps Wikilivres:Copyrights#Where_to_publish would indirectly suggest using Old Wikisource. Splitting works in one language into Canadian Wikilivres, Wikisource subdomain, and Old Wikisource already happens to some languages like Chinese, Czech, and German, as pre-1923 publication does not automatically enter the public domain in China, Czech Republic, or Germany.--Jusjih 09:06, 29 June 2012 (EDT)
Thanks for the explanation. Generally I plan to put here texts by Polish authors who died more than 50-ty but less than 70-ty years ago and these texts are not PD-US-1923. Regards Electron   10:49, 29 June 2012 (EDT)
I regularly find authors who published before 1923, but who were still alive and healthy 50 years ago. Within very limited parameters I want to push the Canadian copyright envelope on some of these in a manner consistent with accepting legal responsibility. Eclecticology 15:24, 29 June 2012 (EDT)
Well, every country has its customs... On the other hand, in my opinion, PD-US-1923 is not a bad idea. There is sometimes very hard to find out the date when an author died. But the date of the work publication is known, usually. I had problem to publish leagally some old works in Polish because I don't know the date of the author death (you know: there in Europe we had rather "interesting" XX century with meny wars and revolution and sometimes we don't know when and where a person was misssing ;) So, fixed PD date is be very useful, sometimes... Electron   16:48, 30 June 2012 (EDT)
Indeed it is much easier to base our decisions on the publication date. I have an interest in periodical publications where knowing how long the author of an article lived is more difficult than with whole books. Many of them wrote all their articles when they were in their 20s, and went on to live for another 60 years or more too much. The 1923 rule needs to be kept in mind informally, but always with the awareness that it is an American rule. Eclecticology 20:54, 30 June 2012 (EDT)

Unable to import pages

Special:Import keeps failing. This has to be addressed, or works cannot be imported from other wikis. Thanks.--Jusjih 10:30, 4 July 2012 (EDT)

It is because this MediaWiki 1.16.2 has slight different format of export files from Wikipedia Mediawiki. From Mediawki 1.19wmf1 the .xml file format has been changed -> from export-0.5 (before) to export-0.6 (now). It is possible to fix files by hands:

There are 2 new marks:

<ns>0</ns> or <ns>xx</ns> where xx=other number of the space names
....
<sha1 />

in the code it looks like:

<ns>0</ns>
<id>88256</id>
<sha1 />

When you get rid of all:

<ns>0</ns>
<sha1 />

it should work. I tried this myself.

We have the same problem on Wikia projects, but Wikia Mediawiki is changing to MediaWiki v. 1.19, now. Electron   11:41, 4 July 2012 (EDT)

I tried your way unsuccessfully. We should not have to fix files by hands to import.--Jusjih 12:42, 4 July 2012 (EDT)
Yes, we shoudn't. But I don't know other way... Other way would be upgrade of MediaWiki to v. 1.19 or higher.
I used myself this way to import some files from MediaWiki 1.20wmf2 to my wikia site (MediaWiki 1.16.5) and it works. But some editors or word proccessors can add some unnecessery formats to xml files. Before fixes:
  1. I changed the end of the file name .xml to .txt,
  2. fixed the file (cut out all <ns>xx</ns> and <sha1 /> from the file by find & replace)
  3. I changed export-0.6 to export-0.5 (but it is not important)
  4. write the file
  5. changed the file name from .txt to .xml.
In MS Word 2003 it works perfectly, but in MS Word 97 it dosn't work - it adds some waste bits to the file.
Others WP I haven't tried.
If you can open such rebuilt file by an internet browser (by Open a file...) it means that it is OK. If not - it ussually means that WP add some waste bits. And better way is to find a very plain WP, that works with plain text. Electron   15:16, 4 July 2012 (EDT)

I appreciate these comments. Unfortunately this all addresses that aspect of managing the site where I am completely clueless. I will ask Alan about upgrading to 1.19, despite concerns about what that could break. Hopefully that won’t be too much. Eclecticology 17:45, 4 July 2012 (EDT)

If Special:Import remains malfunctioning unfixed, I will have to ask Chinese Wikisource to find a new website in Greater China to move Chinese pages out of here without traditional and simplified Chinese converter.--Jusjih 11:07, 10 August 2012 (EDT)
Just for the record: on my PC I have the (very old) version 1.7.1, on my laptop there is 1.18.3. On both I tried to import (by import upload of course) an article from the Czech wikisource and from here (a chinese one) - both succesfull. the I tried to import an article from the Czech wikisource up to here - no result, neither transwiki import nor import upload. -jkb- 12:39, 10 August 2012 (EDT)
I still cannot import from Chinese Wikisource, whether with Mozilla Firefox or Internet Explorer.--Jusjih 17:12, 28 August 2012 (EDT)
I still cannot import from Chinese Wikisource. Would someone please fix the problem?--Jusjih 12:48, 21 September 2012 (EDT)
I am afraid that there is not other way (despite I described above) to fix the problem than upgrade Mediawiki to version 1.19 or higher. The curret version you can chack there -> Special:Version. Electron   03:48, 22 September 2012 (EDT)
I'm really not sure if it depends on the MediaWiki version here. See above - I have 1.7.1, on my PC and 1.18.3 on my laptop. I can import on both, even from the Chinese Wikisource (tested), but no import upload is possible here with the version 1.16.2 (which is in between). It probably depends in the installation preference of the MediaWiki of WL, which are not editable for us. Somebody who has the access to the files like LocalSettings.php and other config files should have a look there. -jkb- 09:02, 22 September 2012 (EDT)

Wikilivres:Inclusion policy - what about CC-BY?

I read Wikilivres:Inclusion policy and there is no:

  • CC-BY licese that is more free than CC-BY-SA...

It was omitted knowingly and wilfully or it was omitted by oversight? Electron   16:04, 4 July 2012 (EDT)

The normal presumption is oversight unless there is evidence to the conntrary. Simple CC-BY does not appear to have been on any historical versions of the page. I suppose you’re right about a simple CC-BY being more free in that it does not have the viral feature that derivatives must be under the same licence. It does impose a condition on the downstream users. I am prepared to consider adding it, but would like to hear other opinions first. Eclecticology 17:35, 4 July 2012 (EDT)
As I understand it, the only real condition is that you must acknowledge your source, which any CC licence requires. I am happy to allow it.--Poetlister 08:33, 8 July 2012 (EDT)
Any free licenses should be fine, including CC-BY. Yann 05:49, 17 July 2012 (EDT)

Serait-il possible d’avoir également une page sur le statut de Wikilivres : qui l’héberge, à qui le site appartient, comment le projet est géré, etc. ? Merci. Marc 07:15, 18 July 2012 (EDT)

Fair dealing

In the wake of 5 fantastic decisions affirming user rights by the Supreme Court of Canada, I am taking a close look at fair dealing, and how it could affect the future of the site. Eclecticology 01:56, 13 July 2012 (EDT)

Wsexport

It would be great to be able export books in EPUB form. Is there any possibility of implementing Wsexport in Wikilivres? I don't know how much work is involved in porting it, so apologies if it's beyond current resources. Chris55 06:19, 23 July 2012 (EDT)

I don’t know anything about this either. I’ll wait for more technically minded people to respond. Eclecticology 14:12, 23 July 2012 (EDT)
I should have put this link which has links to most things. Chris55 14:24, 23 July 2012 (EDT)

Fishta now on the Oldwikisource

2009 I imported some 9 works by Gjergj Fishta from the Oldwikisource to here as it was a copyvio there (69 years p.m.). Now they have been restored on the Oldwikisource, see here and here. Should they to be deleted here or not? I think yeas and I can do it, but to ask first is better. I would keep the author's page anyway and I wouzld provide a link. -jkb- 13:03, 10 August 2012 (EDT)

I agree. That’s my short answer. In general I wouldn’t apply this as an absolute rule. In this case the material was imported, and there is no-one here with a direct interest to maintain it or, for that matter, anything else in the Albanian language. For some other material where the contributor appears to have a broader plan I would give them wide latitude on this rule. Eclecticology 17:33, 10 August 2012 (EDT)
Yes, the texts were not originally uploaded to Wikilivres, but imported from Oldwikisource, so I think I will delete them (nine texts by Gjergj Fishta: 28 Nanduer 1913, Dëshmorëve, Gjuha Shqipe, Kanuni Parathâne, Marash Uci (Kënga e Dymbëdhjetë), Shqipnia e Lirë, Shqypnia, Shqypnisë, Çohi të Dekun); there are another two texts by Faik Konica (Analiza e Doktor Gjilpëra, Vepra), that will be free by January 1st 2013 and can be deleted later on. I will keep the author pages anyway. -jkb- 03:40, 14 August 2012 (EDT)

PD-pma

I have been looking at {{PD-pma}} and experimenting with {{PD-pmx}}. This is mostly with a view of eliminating the need to link through an otherwise deprecated template. The study is ongoing, but comments are welcome. Eclecticology 01:57, 24 August 2012 (EDT)

It seems good, the code is shorter as well. I do not use PD-pma as I integrated the code into the template {{Infodole}} which contains another informations on the work (the parametre "Rok" = Year), but I guess I will change the code there for your new one as it is better (and mightbe the link to the licence durations on enWP is usefull). -jkb- 03:25, 24 August 2012 (EDT)
P.S. When finished, the text "This work is in the public domain in countries where..." etc. should be transladed in Wikilivres:Localization. -jkb- 05:13, 24 August 2012 (EDT)

I’m also wondering whether we really need separate templates for the works and the authors. With a little adjustment to the wording the same one could be made to apply for both.

Your integrated approach with "Infodole" is basically a sound idea, and could be applied in a similar way to other languages. What I have found here is that people draw their formatting inspiration from the Wikisource in their own language. These have often gone on very different paths, each of which works well in its own context. The question becomes one of how to balance uniformity with the innovation that benefits from diverse experience. Eclecticology 15:57, 24 August 2012 (EDT)

We have discussed the problem of similar templates in different languages quite short sometime 2006 or 2007. It is difficult.
1) it could be that different languages (i.e. different culture traditions as well) needs different items that are not necessary in other languages
2) On Wikilivres (quite similar to Oldwikisource) the cooperation between the active editor is not as close as in a Wikipedia projects, where every shitty little problem must be discussed seventeen times before it can be solved [:-)]...
That meens: the editors who develop here the language sections are like to be initiative from the beginning, without big discussion on every item with the others. Very often it concerns the specific concept of the language section, that can be different from the others, and you need some specific templates etc.
Now, after this developed this way a longer time it could be rather difficult to reach a unifying "backwords". For example: you made a draft for the template PD-pma/x, which is good and I would support unifying where it is possible. But, 2006, as I started the Czech section, I wanted to have an information box for different items, thus I developed the template {{Infodole}} (that means simply "information on the bottom", as I have "Information on the top" as well) and integrated PD-pma into it. It would be no improvement for me to start usig the new PD-pma/x, and I think you will find similar situations here everywhere.
On the other hand there is a lot of things that we should try to keep unified in every case: i.e. the new PD-pma/x in sections, that have no sufficient alternative fot it, the same author page (in every case!) etc. Anyway, let's keep on discussing it. Regards -jkb- 06:24, 26 August 2012 (EDT)

The endless discussions of little details is certainly one of the issues that drives people away from Wikipedia, and into projects like this. Even discussing that problem becomes yet another endless discussion. A lot of that seems to be editors insisting that they have the only right way of doing things. Sometimes dictatorial powers are very handy, but should be used only where absolutely necessary.

Working in an open-ended multilingual environment is indeed a challenge. That kind of environment is what I envisioned on the very first day of Wikisource. Libraries store books about the same topic together irrespective of the language in which the books are written, and there certainly are books written that include multiple languages. The risk in such an environment is to take on more than we can handle, and to impose a level of standardization that just won’t work. Introducing another language won’t work unless there is someone willing and able to curate material in that language. That was my point when I commented about the Albanian material, and my criticism would be even stronger when it comes to the Georgian material.

When it comes to templates I believe that they should be kept to a minimum. Those that remain should be clearly understandable by those people who became active long after any given template was designed. This would discourage inventing new templates just because the newcomer can’t find the one that he needs. I would avoid multilayered transclusions that are nearly impossible to trace. It’s probably easier to standardize the lower level modules like PD-pma than the higher level ones like Infodole. The higher level templates can include lower level modules, but they can also include culturally specific details. Eclecticology 15:21, 26 August 2012 (EDT)

Beside the fact that we probably means two different thing with the term "culturally specific details" Iagree that there are plenty of templates that are not really needed (beside the fact that some of htem have colours that I cannot look at :D). And, additionally, the use of them is partially wrong. The best it woud be you make a proposal how to change it and what to change. The great challenge will be that more users here will participate on the discussion and on the changing the status quo. By the way - I will never make such a mistake like the import of the albanian and georgian texts again. The user promissed me to work here a bit and to provide the documents with our templates, but nothing happened (georgian). If you think it would be better to delete them, so it would be OK for me, they are deleted on the Oldwikisource where they can be restored when PD. Regards -jkb- 10:24, 28 August 2012 (EDT)

I have looked at some of the other details for the template and find that they don’t do much that is usefull. The top section seems to do nothing but put that icon at the top right of the page. It’s redundant if it’s already in the notice. I’m also questioning why the copyright notice is at the bottom of the page; it would be more sensible to make it discretely a part of the page header. I do like the idea of having colour-coded headings for different kinds of pages, though your difficulty with some colours make me hesitate. I would not want to be causing epileptic seizures. Eclecticology 04:57, 5 September 2012 (EDT)

No, I don't think so. The upper part of the template just links to the licence information on the bottom. This link seems to be necessary in such cases (and there are many!) when somebody used a wrong (old) title or header template where there is no notice line (see the most old French or English pages). More over, you cannot integrate these informations into the header: which ones yes and which ones not? Licence? Source? Year and place of the edition? Info on impoertant other editions? Many of the works here unfortunately do not have such informations - and I'm about to claim, that e.g. the source must be everywhere. This was the reasen that I started to use the template "infodole" where I can integrate all such informations and some ones more. The additional advantage: I keep the header free off other informations than title and author as I do not think it could be done "discretely" - every additional information in the header does the header complicated for the person who wants to read a text. Additionally, I saw many pages where these informations are on the talk page of the article as well (what I wouldn't favorize neither). But anyway, if you strike the upper part of the template or not, you will get very huge problems to unify this in the articles where there is no licence template. I am afraid that you could not use a bot for this job: I compared some old pages (mostly english or french) and I found many, where the templates header and title are placed wrong or where other templates are in use. You should have to controll page by page - big job. -jkb- 04:40, 6 September 2012 (EDT)

There’s much to think about there, but for now let me address just the upper part of the template. Without you mentioning it, the only effect that I would see from that is putting SemiPD-icon.svg at the top right of the page. There is nothing intuiitive about clicking on it to go to the bottom of the page, and there is nothing in the documentation for the template to tell us that. How is anyone to know that it does that? Eclecticology 15:41, 6 September 2012 (EDT)

this way? :-) (we could surely make it better or in other way ... -jkb- 17:59, 6 September 2012 (EDT)
But you are fully right, it is not the best solution, and more or less not intuiitive. My link in the notice line of the template titleCS or headerCS ist much better as there is not only the icon but a text as well, see e.g. Za sto roků and all the subpages in the content. -jkb- 18:08, 6 September 2012 (EDT)

Yes. Essentially all that template:Infonahoře does is link to the information box at the bottom. This is the same as what the first part of template:PD-pma does. And it is placed in the header! Infodole includes more than just a basic licence statement; it also has other metadata. So generally I agree with that. The problem then with the pma template is that iit tries to perform two unrelated tasks, instead of doing one well. Maybe breaking this up into two different templates in a way similar to what you have done would make more sense. Whether this links to the bottom of the page or to the talk page doesn’t matter much to me. Eclecticology 14:38, 7 September 2012 (EDT)

A link in the header, linking to the information, is OK, the information itself not (my opinion). The advantage is, that on the linked place I can insert as many informations as necessary without disturbing the header. If you put the metadata template on the bottom or on the talk page, it really doesn't matter. I link to the bottom for this reason: Nearly all works in Czech I edited here contains one or more pages with the content but also something like a main content page - see e.g. Řím which is the main page for some 40 single parts. Even if I havfe a work that could issue on one page only I try to make two pages: see Novoroční gratulace 1924-1935 which is the main "content" page for some fourteen very short parts on one page (I link with the help of anchors in such cases). On this way I can insert the template "infodole" with all meta infos on the bottom of the main page, on the other pages with the parts pof the wort there is only a short link in the header linking to the main page - and nothing else. Thus, the work Řím has only one template "infodole", not 40. But, it is quite easy to use this system when you start a language section, it is very difficult when not inpossible to make it later for older works. -jkb- 10:14, 9 September 2012 (EDT)

In principal, I think we agree. In a book of many chapters we certainly don’t need to repeat the same material for every chapter. Doing so would only provide places for new errors to creep in. The main agreement: A minimalist header with a link to a footer (or sometimes a talk page) which can be as long as situations require. One template that seems to have developed great clutter at the top is template:AA. It’s great to have multilingual author pages, but there comes a point where it’s self-defeating. I can attack that problem at a later time. I appreciate the difficulty of making the changes now, but not making them just encourages the problem to continue into the future.

One difficulty I’m having is understanding the "Int:" template, which dooesn’t show up in the list of templates. Is there documentation for this somewhere? Eclecticology 17:14, 9 September 2012 (EDT)

The AA page is OK, I like it. Sure, if we would have twenty languages here then ... :-)
You mean {{int:something - ?? It is no template but a sort of a magic word, a function like subst:, that transcludes MediaWiki / system messages into a page. -jkb- 17:57, 9 September 2012 (EDT)

The AA page is not an immediate concern. There are plenty of other things to do.

The problem with a "magic word" like that is that it is nowhere made clear that it does that and why it’s necessary. It seems a waste of effort to write "{{int:Works}}" when simply "works" will do. Eclecticology 22:53, 12 September 2012 (EDT)

1. ack, AA is not a problem at all, more or less sufficient
2. {{int:xxx}} is something else than {{subst:xxx}} as it is possible to transpond some parameters as well which is not possible with subst; therefore, when you insert "{{int:Works}}" so the word "Works" can be translated into other languages according our localisation (as the localization pages are MediaWiki pages i.e. messages); yes, the first time I saw it was 2009 here and I had to search a long time. Then I found it in de.wiki, see here, but there is no such help in enwiki; as it is a Mediawiki function you can find it on the MediaWiki pages, see e.g. #Localisation.... -jkb- 04:20, 13 September 2012 (EDT)

Thanks for the links. Localisation is very valuable in a multilingual environment, but understanding how it works in the background can be quite challenging.

In experimenting with the anchor at The Albatross it struck me that the link to the metadata could be incorporated into the various header templates. Once this is done the top part can be removed from the PD-pma templates. By adding the "metadata" anchor to the PD-pma template, and later to an "Infodole"-like box, it really doesn’t matter at this stage that the anchor is there twice during a transitional period. This approach should work around eny need to deal with most articles individually. Eclecticology 15:38, 13 September 2012 (EDT)

I’ve made the changes to Template:PD-pma and Template:poem; it seems to be working. I’ll wait to see if any bugs or problems appear before I apply it to the other header templates, or otherwise develop this idea further. Eclecticology 17:59, 13 September 2012 (EDT)

I have to see your tests tommorrow. Just a note: you can either use the anchor targets by inserting {{Anchor|xxx}} or you can do the same with <div id="xxx"> - just what I did in the template "infodole", you can link to both with "#xxx". And, in fact, your test in Albatros on the top was the same what I did in the Template:infonahoře, linking to the bottom (the template:infonahoře [up to yesterday template:informaceCS] is on all Czech header and title pages in the notice line and is linking to the metadata info on the bottom); the only difference is that I do not use simply "#bottom" but "BASEPAGENAME#bottom" so that I can link from subpages to the content page as well - see the notice line in Třetí kniha lyriky (= main content page) and Třetí kniha lyriky/Láska (subpage with a part poem).
N.B. What you have done in the Template:Poem with [[#Metadata|Link to further information]] is just the same what I have in the Template:infonahoře - with the difference, that my text there is localised (and I have there the ©-icon). -jkb- 19:10, 13 September 2012 (EDT)

This is good! I suppose that I avoided the "div" function, because I have yet to understand how it works. I’ll keep in mind the use of "BASEPAGENAME" when I begin to work on subpages. I generally agree that the metadata does not need to be repeated on each subpage. I have no problem with localizing text for the metadata link. I don’t think we really need the ©-icon, since the intent of the metadata section will be to provide more than just copyright information. The PD-pma anchors on "PD", and by putting it on "Metadata" I was hoping for broader application. Eclecticology 13:41, 14 September 2012 (EDT)

P.S. Short to your change in the Template:Poem: as I mentioned yesterday it is very very similar to the link in my Template:infonahoře. I would suggest that we use a template as well: 1. it is easier to make changes, 2. I can redirect my Template:infonahoře to the new template (so that will unify it a bit), and 3. it is easier to localise the text for the other languages (so as my template is). We can name it e.g. something like Template:LinkMetadata, and the link will go to #Metadata, which will be somewhere at the bottom and will contain either "Anchor|Metadata" or "id=Metadata". But: I would suggest to place it in the parametre line notes. Then we can discuss the unifying of the main templates like Header and Title. -jkb- 13:13, 14 September 2012 (EDT)

Sorry about the edit conflict. :) My choice of the word "Metadata" was based on having a modern word that would be understandable across languages. Sometimes it’s hard to know when a term should be the same across all languages, and when it should be localized. I agree with having a general footer template similar to what you have created in Czech. The footer should probably be more open-ended than the header, but what should be in either top or bottom will be the subject of a whole new thread. Eclecticology 14:09, 14 September 2012 (EDT)

Respond to your both edits: Well, the ©-icon is not that necessary; the advantage is, that the licence is still the most important info we can offer there, and it is good to see - but ok. Yes, metadata, metadata-link, metadata-info or something like that is ok for every language indeed. And, as I mentioned before, it should be localized in any case (the translation is ready in fact, see {{Infonahoře}} which gives
Info Simple bw.svg Community Portal: Information and licence SemiPD-icon.svg in all our languages as translated here. -jkb- 12:46, 15 September 2012 (EDT)

In any event these last points about names are fairly minor. I’ve simplified the wording for en, fr and es. If we agree on the principal points the rest of this should be easy. Eclecticology 14:37, 16 September 2012 (EDT)

Well, one point is if we agree (and, in fact, who should agree, as the discussion was held by us two only), the other point is what and how to make it. And, I think, it is not as simple. If we take your new template:pma with the new simplified code (which I like), we became a difficulty with the localization. The text you use now is only in English (is not localized). My personal preferences are Czech, sometimes German here, but the notice on the licence on the bottom is English anyway (i.e. the template is in English in all cases). To localize it is possible but not as simple. The old (comlicated) template:pma had the advantage that it used some other templates (template:PD-old-50 etc.) that are localized yet. The localization of the new pma would need a more complicated system which would have to be tested separately. -jkb- 10:32, 17 September 2012 (EDT)
I had an idea how to arrange the localization of the new pma, and I think I will test it in the next two days. -jkb- 04:10, 20 September 2012 (EDT)

I’ll look forward to seeing that. It leaves me wondering if there is any way to put all the localizations for a given piece of text on the same page instead of a separate page for each language. Eclecticology 03:29, 24 September 2012 (EDT)

Wikilivres:Localization

Is there any reason why, in the sidebar section of this page, there is both a plain and a "url" version for these links? Eclecticology 00:23, 14 September 2012 (EDT)

AFAIK: url is the url of the special page, the plain version is the title of it (each language has both terms localised). -jkb- 03:12, 14 September 2012 (EDT)

Are the "url" versions being used at all? When I looked at MediaWiki:Currentevents-url I found the page was deleted in 2006. Someone feeling the need to generate localizations may just be creating pages that will never be used. My inclination is to delete all these "url" pages. Eclecticology 14:29, 14 September 2012 (EDT)

No, don't delete them, those that are activated wouldn't work. The url's are important for the sidebar. -jkb- 11:21, 15 September 2012 (EDT)

Is there any way of knowing which ones are in fact activated? Eclecticology 16:00, 15 September 2012 (EDT)

I guess not activated (and at present not needed) are those which you can see as a red link in the localization, e.g. Scriptorium in Czech, Chinese etc., and other ones. (But maybe in the future??) -jkb- 09:55, 16 September 2012 (EDT)

Unfortunately, "what links here" does not work for these MediaWiki phrases. :( Using search doesn’t seem to help either. I think some of the translations were often nothing more than somebody thinking this was a good thing to do, and having no idea about how they might be used. It’s difficult to decide between what would break another page, and getting rid of clutter. Eclecticology 15:34, 16 September 2012 (EDT)

Hi Eclecticology, no, tools like "what links here" do not work with system messages; and more over, such system messages (see some more thousands of them in Special:AllMessages) are only the "visible part" of the MediaWiki software and they should be handled with care (they do not bother anyone - do they). Thus, it is better if you don't care of them as a change sometimes can bring some problems later on. -jkb- 10:33, 17 September 2012 (EDT)
Btw. I can translate some of these messages into Polish but there is a problem to put them in MediaWiki space because it can only an admin... Electron   05:25, 21 September 2012 (EDT)

WL very slow

Hello,

Today, Wikilivres is very slow. It takes at least 10 seconds to display a small page, and then again 10 seconds to be able to edit it. Any idea what's the matter? Yann 04:18, 21 September 2012 (EDT)

Not only today. Yesterday was the same... And not only yesterday... Generally the transfer is not very fast, especially if somebody is from Europe. Electron   05:30, 21 September 2012 (EDT)
After I started to edit here again in mid August I had to state that WL is very slow compared with the time before. But in the last (about) 6 days it is extremely slow. 10 seconds to wait??? OMG, I would be happy to wait 10 seconds only :-) -jkb- 06:44, 21 September 2012 (EDT)
You are right. Last time the speed goes down constantly... And if you want edit you should be veeeery patient ;) Maybe the server provider has some problems or doing some works on it that lowed the speed? Electron   07:03, 21 September 2012 (EDT)
I experience slow speed as well.--Jusjih 12:42, 21 September 2012 (EDT)
My apologies for being offline with hardware problems he last few days. I’m on a new laptop now. The slowness appears to be from sharing a server with wikilovesmonuments.ca. Traffic on that has been unexpectedly high. If things don’t get better after month’s end we’ll need to look at alternative answers. Eclecticology 03:14, 24 September 2012 (EDT)

Headers and Titles

I’ve been thinking about the way we add headers and titles to substantive articles. Author pages are not a part of the present discussion. Footers at the bottom of a page will also be a different subject for a later time. It’s enough to say for now that what doesn’t belong in a header would go to the footer, as would also some things that have been put over to an article’s talk page.

In English alone there are at least three separate templates: "Header", "Title" and "Poem". In other languages there is a similar situation, many of these templates imported from the Wikisource in its own language. There is still a great deal of similarity in the way these templates operate. Much of this can probably be reduced to a single simplified template, or at most one for each language.

The first question to be asked is what must be in a header. I would limit this to the title, section, author, translator, continuity of sections, notes and a link to the footer. Anything else? Eclecticology 03:41, 26 September 2012 (EDT)

I find that the Poem template works very well for poems.--Poetlister 17:03, 26 September 2012 (EDT)
I don’t doubt that it does. Others could say the same about other templates with a similar function. Apart from the colour, what makes it preferable to the others? Eclecticology 21:30, 26 September 2012 (EDT)

Author parameter

The "override author" function in these templates does not appear to work on this site, and I haven’t seen any evidence that it has ever been used. We would do well without it I understand that it originated with the notion that simply typing the author’s name would result in the automatic creation of a link to the author page. That’s fine. The awkward phrase "override author" purports to act when we want something other than a simple linked author name. Something simpler, like beginning the data with a "[" as the override could be more efficient. Eclecticology 05:28, 4 October 2012 (EDT)

Upload by URL broken

Hello,

Upload by URL is broken. This is quite useful to transfer files threaten to be deleted on Commons. Since I have a slow connection, it is much faster. Yann 00:50, 10 October 2012 (EDT)

James Elroy Flecker

I am proposing to upload all the poems of James Elroy Flecker. Normally, as he died in 1915, this would be inappropriate. However, what has been done on Wikisource is not right. Apart from the fact that very few poems have been uploaded there, and nothing has happened recently, the mistake has been made of following the "Collected Poems". See my comments here. I should be grateful if people would please confirm that they are content with my proposal.--Poetlister 18:03, 3 November 2012 (EDT)

I agree. While I don’t know anything about Flecker in particular, a lot of poetry-loving editors seem to operate under the misapprehension that what appears in someone’s collected poems represents a unique form for each poem. Many poems first appeared in some magazine, and were only later brought together in collections. This gave the writers the opportunity to make "corrections" to the original text. The order in which the poems appear in a collection is often arbitrary. Eclecticology 07:10, 4 November 2012 (EST)

Canadian copyrights

The revisions that expand users rights in Canadian copyright law have come into effect: http://www.michaelgeist.ca/content/view/6692/125/ Much of this relates to fair dealing, and could be the basis for our own future policy on this matter. Eclecticology 14:01, 8 November 2012 (EST)

Linking from Wikisource

This is just a quick message to let users here know that English Wikisource now supports links to Wikilivres in page headers. If you want to create a link from Wikisource, just add | wikilivres = PAGENAME to the header template and it will appear alongside the links to Wikipedia et al. For example: Author:Gordon Bottomley. - AdamBMorgan 08:11, 9 November 2012 (EST)

Error: no such file

Could please somebody check the reason for the following breakdown of listed projects?

Index:Doktor Haldens Patient.djvu

Doktor Haldens Patient

The single pages still exists ...

eg. Page:Doktor Haldens Patient.djvu/45

Thanks--Wassermann 08:26, 22 November 2012 (EST)

The problem also occurs here Index:Swinnen - Apprendre Python, 2010.djvu, Apprendre à programmer avec Python/1, Index:Diels-Kranz - Die Fragmente der Vorsokratiker, Zweiter Band, 1959.djvu, Index:Photography Theory And Practice OCRed.djvu, Photography: Theory and Practice/Chapter 1 and on each project using pagelist. Can this be fixed?--Wassermann 10:11, 22 November 2012 (EST)
I removed pagelist from my projects and replaced it by [[Page:Doktor Haldens Patient.djvu/1|1]] etc. within the index file and by {{Page:Doktor Haldens Patient.djvu/1}} etc. on the summary project page. However, the djvu preview for the proofread pages still not work. So the problem is may related to the allready above mentioned unsolved subject, too. See Wikilivres:Community Portal/en#djvu preview and index-creation failed. --Wassermann 11:21, 22 November 2012 (EST)

Transcluding a single section fails

I am trying to use the section feature as described on english ws. It seems that ## section label ## is interpreted, but the resulting html code (<section begin=Lysimachos 3/> etc.) not. My sample page is Page:Pauly-Wissowa_XIV,1,_0031.png, and the transcluding page is RE:Lysimachos 3. Perhaps the extension LabeledSectionTransclusion is needed, required by ProofRead Page and in fact installed e.g. on English WS, but not here. Could somebody please help? K67y 23:55, 21 December 2012 (EST)

  • Why is transclusion necessary? Simple copy and paste would work just as well. The results would be more easily searched and annotated. Eclecticology 07:45, 24 December 2012 (EST)
    • Duplication of data can lead to ambivalence, and transclusion is the recommended technique to avoid it; but you are right that the simple method also used in german wikisource is preferable. So I have tried to port the necessary templates from german ws (RE:Lysimachos 3 updated to use them). What do you think about installing also the java tools used at german ws to facilitate proofreading (de.ws:MediaWiki:Common.js and the included de.ws:MediaWiki:ExternImage.js etc.? With these one has image+edit windows as e.g. in this sample. Thanks, K67y 12:32, 26 December 2012 (EST)
      • Thank you for raising these issues; they are fundamental to the future direction of this site. I would welcome more voices on these questions. Regrettably, my weakness is in understanding how the underlying software works. I think there are two features that need to be emphasized about the material we host here: accuracy and usefulness. Transclusion does a lot to insure accuracy, but makes it difficult to develop the static material into an integrated whole. Where dos the tranition occur? For example, I have a copy of W. H. Roscher’s Ausführliches Lexicon der griechischen und römischen Mythologie which deals with much of the same material as Pauly-Wissowa. If were fortunate enough to have both works on this site, how would we draw connections between the two? Both works have a dense system of references built into each of their articles. How do we provide for connections to this other information? How do we relate to similar materials in other languages? I don’t have any particular objections to the German Wikisource as such, but other contributors bring with them experiences with the templates and ideas of Wikisources in other languages. What is our basis for deciding which of these will be best for us in a multilingual environment? Eclecticology 21:18, 26 December 2012 (EST)

Starting import of URAA deletions on Commons

I've developed a private bot that can import files to Wikilivres from Wikimedia Commons that have already been deleted. I'm applying it to any files listed in deletion requests that are PD in Canada, with a special emphasis on URAA-related deletions. You can see my uploads at Special:Contributions/Transfer from Wikimedia Commons bot and some earlier ones at Special:Contributions/Dcoetzee, and see affected deletion requests at "Category:Deleted files transferred to Wikilivres" at Commons. Many templates are missing here, which I'm gradually importing as needed, but I'll need help with the Wikimedia message extensions (see below). Dcoetzee 16:24, 12 January 2013 (EST)

Thanks a lot for that. I would give it the bot flag unless someone objects. Yann 10:33, 13 January 2013 (EST)
The biggest problem with dumping this material here is that we are not equipped to handle and categorize so many media files. Also it is not enough to simply add templates from Commons without documentation, or to justify changes on the sole basis of their conformity to Commons. Changes need to be explained in more detail than that. Eclecticology 21:45, 13 January 2013 (EST)
What kind of information would you like to be added? I have given it the bot flag. Regards, Yann 01:06, 14 January 2013 (EST)
The imported templates should have full proper documentation telling how they work, and how they are used. We already have a large array of templates that make their usage difficult to trace or change. As a simple example there was a change to Template:en to conform to Commons usage without any explanation about what the change would do.
As for the pictures themselves, we need to remember that this project was a Wikisource spinoff, not a Commons spinoff. No system of categories to handle pictures has ever been developed here. Some of the pictures added have no category at all; others have categories so obscure that they cannot possibly help in finding the pictures. Who is going to develop a functioning category system? Eclecticology 05:53, 14 January 2013 (EST)
As noted on my talk page, I'll update all the template documentation (Template:En and the other lang templates are already updated), and assist in the development of the category system, and have recruited other people from Commons to help too. I will not be uploading images at such a fast rate in the future. Dcoetzee 08:33, 14 January 2013 (EST)

Missing Wikimedia messages

In order for my imported description pages from Commons to render correctly (see e.g. File:HC_Baruch_Ponstijn,_when_young,_by_Leo_Gestel.jpg), this wiki needs the extensions WikimediaLicenseTexts and WikimediaMessages. Please install them. This will also fix Template:LangSwitch, which uses "{{int:Lang}}" to pick the language to display, but is not currently working. Once these are installed, I can deal with the remaining templates by manual import. Thanks! Dcoetzee 14:48, 12 January 2013 (EST)

Issue of PD-Art images

A number of the images I'm uploading are PD-Art (simple reproductions of public domain works where we don't have a license from the photographer). Since Template:PD-Art exists I'm assuming they're accepted here, but according to Commons:Reuse_of_PD-Art_photographs#Canada these files may or may not be in the public domain in category (case law is inconclusive). So we should explicitly discuss and agree on a PD-Art policy. Dcoetzee 16:36, 12 January 2013 (EST)

I think we should accept here at least what is accepted on Commons. So any reproductions of paintings are OK, if the painting is in the public domain in Canada. Yann 10:32, 13 January 2013 (EST)
I have no problem with this. While I haven’t reviewed the Canadian cases on this point, this seems a fair position. Eclecticology 19:59, 13 January 2013 (EST)

Unable to upload image files

I can't upload this file (Egger-Lienz - Andreas Hofer - 1923.jpeg, 11 MB) at all. I tried renaming it to a jpg extension, tried uploading it from a computer with lots of upload bandwidth, but all to no avail. I just get back the same upload page with no error message. Upload by URL doesn't work either. I've uploaded lots of other images with no problem. I'm not sure what's wrong but I'm guessing there's some misconfiguration leading to a filesize limit of 10 MB 8 MB or so. Dcoetzee 17:33, 12 January 2013 (EST) Update: I had the same issue with re-uploading the following files from Commons:

  • File:Otto Mueller - Selbstbildnis mit Pentagramm - ca1924.jpeg (14 MB)
  • File:Bouquet Portrait de Le Fauconnier.tif (8.1 MB)
  • Sergei Rachmaninoff - Symphonic dances (1).ogg (11 MB)
  • Sergei Rachmaninoff - Symphonic dances (2).ogg (9.3 MB)
  • Sergei Rachmaninoff - Symphonic dances (3).ogg (9.4 MB)
  • Christian Rohlfs - Erfurt (Dom und Severikirche).jpeg (8.0 MB)
  • Rohlfs - Aus Dinkelsbühl, 1924.jpeg (8.1 MB)
  • Christian Rohlfs - Porträt einer Frau mit Hut.jpeg (12.3)
  • Rohlfs - Engel, der Licht in die Gräber trägt, ca1925.jpeg (8.6 MB)
  • Rohlfs - Kloster Andechs.jpeg (10.6 MB)
  • Rohlfs - Tänzerpaar, 1928.jpeg (10.4 MB)
  • Rohlfs- Spiel am Strand, 1928.jpeg (8.7 MB)
  • Rohlfs - Austreibung aus dem Paradies, 1933.jpeg (8.9 MB)
  • Christian Rohlfs Buchenwald.jpg (17.5 MB)

I had no trouble uploading smaller TIF and OGG files (like File:Bouquet Pégase.tif at 2.8 MB and File:Sergei_Rachmaninoff_-_Concerto_1_in_F_minor,_2nd_movement.ogg at 6.5 MB) reinforcing that it's a file size/configuration issue and the threshold is between 6.5 and 8.0 MB. Dcoetzee 22:08, 12 January 2013 (EST)

Still need help with this. If there are no developers around, I could fix it myself if I had shell access to the server, I would just need the credentials/key. I run several MediaWiki servers and there is clear documentation of how to deal with this issue at Manual:Configuring file uploads: Set maximum size for file uploads. If the site does not wish to increase its limit above 8 MB for whatever reason, please let me know and I'll find a way to work around it. Dcoetzee 23:03, 2 February 2013 (EST)
I must confess that my technical abilities about server issues are non-existent, and don’t have the credentials. I wouldn’t know what to do with them if I did. Alan (awalker@wikimedia.ca) is the one in position. Try contacting him. Eclecticology 00:58, 3 February 2013 (EST)
Thank you! I'll do so. Dcoetzee 02:31, 6 February 2013 (EST)

Michelin maps

There is a discussion going on for the file [1] It wil problably result in a URAA deletion. Can this be transferred to wikilivres? I have other uploads wich are not flagged but probably follow the same delete proces (Category:Michelin maps). Smiley.toerist 08:58, 16 January 2013 (EST)

From a copyright perspective there is no problem as this map is more than 50 years old. My concern would have more to do with the import of 11 Megabite files. Eclecticology 15:20, 16 January 2013 (EST)
I could reduce the size. I'm used to the commons where size is not really a problem. Smiley.toerist 06:53, 28 January 2013 (EST)
As noted above, the current limit seems to be 8 MB. I really hope this can be increased as I have many files larger than this to import. Dcoetzee 23:07, 2 February 2013 (EST)

djvu still reports no such file

It appears that people have experienced the "no such file" error with the mediawiki:Extension:Proofread_Page for djvu files, see examples at Index:Chesterton - The Coloured Lands.djvu and Index:Der weiße Maulwurf.djvu.

Today I uploaded a new djvu file
Error creating thumbnail: /var/zpanel/hostdata/rwiki/public_html/wikilivres_ca/w/bin/ulimit4.sh: line 4: ppmtojpeg: command not found
terminate called after throwing an instance of 'N4DJVU10GExceptionE'
(created with DjVu Solo), but despite all my pokings I could not get the extension to work as it should, and the Index pages report "Database error" messages with the pagelist tag, see Index talk:Chesterton - The Coloured Lands - Pictures From The Paint-Box.djvu.

A similar error was reported at Proofread error: "no such file" but there was no answer.

I am requesting some help at mediawiki here. -84user 18:03, 19 January 2013 (EST)

Update so far the sole response at Extension talk:Proofread Page#no such file at wikilivres was to check the DjVu configuration on wikilivre's server, linking to Manual:How to use DjVu with MediaWiki. -84user 19:18, 23 January 2013 (EST)

Hi, I get a look and I think too you have a configuration trouble, perhaps the extension is mis-configured but you have trouble before reaching the extension, get a look at
Error creating thumbnail: /var/zpanel/hostdata/rwiki/public_html/wikilivres_ca/w/bin/ulimit4.sh: line 4: ppmtojpeg: command not found
terminate called after throwing an instance of 'N4DJVU10GExceptionE'
, only an icon is shown, and mediawiki don't get the size of the first page nor the number of page, this pinpoint a trouble in the installation of djvulibre tool or a mis-configuration of the mediawiki core, not a trouble in the extension. Phe 18:15, 30 January 2013 (EST)

À la recherche du temps perdu

I would like to upload the last three volumes of this work by Marcel Proust in the original French to Wikilivres. They are in five books with a combined size of less than 55 megabytes. They are all match and split jobs with good quality texts from the Bibliothèque Électronique de Québec. The third book also has 84 pages of validated texts. They are Gallimard texts which still have copyright in the U.S. until 2018, 2020 and 2022 and must be deleted from Commons until those dates. ResScholar 19:07, 26 January 2013 (EST)

Thank you. I will ask User:Dcoetzee to see if he can assist the migration. After all, this work, too, is a URAA restoration item. ResScholar 19:00, 27 January 2013 (EST)

Contributing as a Non-Canadian

Hi! Regarding contributions of Non-Canadian citizens to this project (who want to upload works which are still copyrighted in their country): Do you recommend them to contribute anonymously? Is it mentioned at any FAQ-page? --Question2013-05 14:46, 2 May 2013 (AKDT)

This is entirely up to you, and how aggressive your own country is about copyright enforcements. When I review what someone has contributed I always do so strictly according to Canadian law, and I am certainly willing to accept legal responsibility in Canada for what I review. It would take an order of a Canadian court before your identifying details would be revealed, It all comes down to your personal tolerance for risk Eclecticology 04:37, 4 May 2013 (AKDT)

Thanks

I want to extend a big thank you to users Electron, Zephyrus and Luciana for their continuing hard work fighting back against a persistent spam attack. New user Matma Rex has already been a blessing to the project by adding a spam filter and by finding and fixing the extreme slowness that this site has been experiencing. I have also asked him to look into upgrading the MediaWiki software. This may also lead to fixing some of the other problems that have been mentioned in other posts to this page. Eclecticology 11:09, 27 July 2013 (AKDT)

For what it's worth I would still like to participate as a developer. I know how to fix the problems I listed above but require a shell account on the server. There's also a new problem rendering thumbnails, see e.g. File:WLANL - kwispeltail - Mediterranee 2.jpg. Who should I contact? Thank you. Dcoetzee 10:07, 7 August 2013 (AKDT)
Well, I think that Eclecticology can help you. Btw. In my opinion the best way to get rid of the spam bot that creating new user actounts permamantly is to install a strong captcha filter on Sign up page, like is e.g. on Wikipedia. Electron   00:36, 9 August 2013 (AKDT)
I'll look into all this when I get home from Wikimania. Eclecticology 04:22, 10 August 2013 (AKDT)

Spam bot

Ack with Electron, the first step towards reducing the creations of the spam bot accounts would be the installing of a strong captcha filter. On some days it is quite awful. -jkb- 10:43, 15 August 2013 (AKDT)
For today's spamming: see here -jkb- 06:00, 17 August 2013 (AKDT)
Btw. A good idea: before instaling a strong capcha filter to reduce creating new accounts, there can help, a new filter for AbuseFilter that stop creating accounts with numbers in the name. So far it can be edit only by beauroucrats -> Special:AbuseFilter, so I can't help. Some useful filters you can see e.g. on Wikipedia. Electron   03:35, 19 August 2013 (AKDT)

hier I moved my edit from yesterday on the talk page of Eclecticology:

  • I think the abuse filter works well all the time; but notice, the filter works only when new users try to do something, that should be abandoned: the spam accounts, where spamming is added, are not new but "autoconfirmed" (the spam bot is waiting some days and start spamming later)
  • thus a strong captcha for the registration could be the first help
  • this would probably be necessary as the spam bot will try to change the IP (not very difficult, it can use open proxys as well, I guess)
  • if a new situation lieke yesterday accure again, we really need a bot with admin rights; yesterday a started to delete and to block the accounts, but the bot was hardly quicker with spamming as me with my measures. I stopped my action then.

/end of the move; let us discuss on one place/
-jkb- 07:03, 19 August 2013 (AKDT)

  • Thanks; following the threads was confusing me. Eclecticology 22:38, 19 August 2013 (AKDT)
  • To -jkb-:
  1. Generally you are right. But there are no one tools that won the spam at ones; they can only help decrease spam in some percent - but percent plus percent can make a big sum. So the best solution is usually a combination of some tools.
  2. My bot (User:Electron Bot) has admin rights already but I don't know the tools that can block new users automaticly (now I am using AWB and pywikipedia scripts and I am not a script programist). If you known a tool that can help I will try to use it...
  3. Big trable require strong measures, usually. Maybe there is a need to stop let creating new user accounts for IP users temporarily? It is a radical step but during last time, no one of new users is a human. It can be done by adding new fiter to AbuseFilter that can also inform new users that if they want to have account here it can be creating for them by the admin. Of cource, the filter can be switched off as soon as we have other tools that can handle the spam, e.g. a strong captcha. Electron   23:33, 19 August 2013 (AKDT)

I never had a bot so I don't know how they work, i.e. what a sort of a table they need to reed what is to do. When you see the RC every day so you can copy the new users somewhere, might be you can delete some of them whos name is Andrea Smith and not Xsz871ght, and probably the bot could do the job.
Anyway, all the bot created accounts are now waitig for some 3 or 4 days befor starting with the spam, that means that the abuse filter #1 works.
I was very skeptical if we sould need another spam as the spammed texts are pretty different. But since the last night there were some 15 accounts that spammed with the text like "Windows 7 Key". Here we could arrange a simple small filter just like I did on the oldwikisource.
To the last point of Electron: well, when somebody would suppose that on a de- or fr- or en-wiki, it would be a nogo. Some short time restriction in the registration could be done, might be, as there are not such many new users here. If a new user comes here and if he see the recent changes so it is not a good renomée for us. And if we would post a sitenotice or something like that explaining why we do so, why not.
-jkb- 07:23, 25 August 2013 (AKDT)

<il faut bien rire un peu>
Please, Uuxw4e7p, do excuse me: you contributed with only one contribution.


                05:38 . . Zephyrus (Talk | contribs | block) deleted "User:Lztblx049" (content was: "== IThat may be well and agreeable They /definition.html are very ..." (and the only contributor was "Uuxw4e7p"))
                05:37 . . Zephyrus (Talk | contribs | block) deleted "User:Sjxpip743" (content was: "== IThat may be well and agreeable They /definition.html are very ..." (and the only contributor was "Uuxw4e7p"))
                05:37 . . Zephyrus (Talk | contribs | block) deleted "User:Uuxl5d4w" (content was: "== IThat may be well and agreeable They /definition.html are very ..." (and the only contributor was "Uuxw4e7p"))
                05:36 . . Zephyrus (Talk | contribs | block) deleted "User:Uuxm8b8p" (content was: "== IThat may be well and agreeable They /definition.html are very ..." (and the only contributor was "Uuxw4e7p"))
                05:35 . . Zephyrus (Talk | contribs | block) deleted "User:Ir6d6g9r" (content was: "== IThat may be well and agreeable They /definition.html are very ..." (and the only contributor was "Uuxw4e7p"))

This contribution alone came from you, Uuxw4e7p:


                05:35 . . Zephyrus (Talk | contribs | block) deleted "User:Uuxw4e7p" (content was: "== IThat may be well and agreeable Theyo we /definition.html are very ..." (and the only contributor was "Uuxw4e7p"))

Please, Uuxw4e7p, do forgive this unintentional error of mine. Kindest regards,
</il faut bien rire un peu>
--Zephyrus 22:20, 27 August 2013 (AKDT)
New filters of AbuseFiter can stop the spam but if nobody do nothing we have what we have... Electron   03:52, 2 September 2013 (AKDT)
I will do what you tell me to do: you are the expert Electron. Were the deletings I was doing useful or were they hampering the bot's work? Would it be useful if I delete the users categorized spam by your bot or is it better to let the bot delete them? Is it useful that I block these users? Many many thanks for your help ! --Zephyrus 08:38, 2 September 2013 (AKDT)
I think that the most important thing (on this moment) is to stop creating new accounts. It can be done by adding new fiter to AbuseFiler. New account can be created only by admins on an user request. After stoping creating new accounts we should clean the mess done by the spam bot, gradually and think what to do next...
What about my bot: After instaling AbuseFiler I have problem with page deleting with my bot because of an error appearance: ApiErrorException in ApiEdit.CheckForErrors WikiFunctions.API.ApiErrorException: Bot API returned the following error: 'Exception Caught: Detected bug in an extension! Hook AbuseFilterHooks::onArticleDelete failed to return a value; should return true to continue hook processing or false to abort.' I am not familiar with API so I don't know what the problem is. I thing that this is a problem with AbuseFiler or its configuration because I try two bot tools (AWB and pywikipedia) and the both have problems with page deleting. So, on this time, I can only collect all new spam in Category:Spam for the future blocking and deleting. Of course it can be done manually but it is a hard work to do by hands... Electron   04:37, 3 September 2013 (AKDT)
Your suggestion to stop creating new accounts looks the right thing to do now in my opinion too, but perhaps there are faces of the problem that I'm not aware of; so let EC decide, knowing what we think. I will go on blocking spammers by hand if we have no other solution left. --Zephyrus 10:46, 3 September 2013 (AKDT)
OK. But the decision should be taken quickly - the spam bot produces about 300-400 new pages every day... Electron   01:16, 4 September 2013 (AKDT)
As I said above: yes, we should stop creating new accounts in fact immediately, then we should decide, how to create them in the future (strong captcha), and the we must 1) delete all those damned pages and 2) block all spam bot acconts. As there are hundreds and thousand of the, so I think manual deleting and blocking is not a very good idea. -jkb- 14:58, 4 September 2013 (AKDT)
P.S. The most spam edits in the last days contained the wording "?mod=space" etc. This could be used for a single abuse filter. -jkb- 15:40, 4 September 2013 (AKDT)
I think I figured out how to stop creation of new accounts. Somebody try it to see if it works. Eclecticology 16:31, 4 September 2013 (AKDT)
It is very easy to perform. The filter can be looks like this:
Conditions: action == "createaccount" & user_groups != "sysop"
Actions taken when matched:
Flag the edit in the abuse log
Prevent the user from performing the action in question
Block the user and/or IP address from editing
Of course the conditions can be more complex and depend of many other ruls, to precise it. But the spam bot has stopped, now. Electron   23:36, 4 September 2013 (AKDT)
I found from the Media Wiki site that I could add "$wgGroupPermissions['*']['createaccount'] = false;" to the LocalSettings.php Eclecticology 00:47, 5 September 2013 (AKDT)
YES!! I don't know this as I don't need it on my local wiki at home... -jkb- 00:54, 5 September 2013 (AKDT)
Yes, it can be done there, as well. And will make result like the filter. Electron Bot 01:01, 5 September 2013 (AKDT)

Footer for IPs

In MediaWiki:Sp-contributions-footer-anon I created a small footer for anon users: if you see the special paqe of an IP for contributions like here, you will find on the bottom some usefull informations about it. -jkb- 10:07, 5 September 2013 (AKDT)

Great! Now I just need to find out how best to use these tools. Eclecticology 14:41, 5 September 2013 (AKDT)

Well, the Geo IP ist quite good. It doesn't show the city quite properly (but China is great enough...). Sometimes it is good to know the location, although not every Chinese IP is an open proxy (there are another tools to fix them). But when an edit from China, reverted (and user blocked) comes five minutes again from Ukraine, then you can assume... :-) -jkb- 02:20, 6 September 2013 (AKDT)

Blocking the open proxies of the bot

After Eclecticology succeeded to stop the creation of the bot accounts (and, pls, see if my sitenotice is OK), we have now the problem wirh the old accounts that are autoconfirmed and can edit new pages. We can have two strategies:

  • we can check the IPs and block the range block, up to now it was done indefinitely.
  • we can check the actual IP and block this single IP for quite a short time, I guess 1 month is enough.

This afternoon I made a test (see User:-jkb-/sbm) and I think I know how the bot works. He edits with 1 IP (normally OP, today from China), after this single IP is beeng blocked, he starts some time later with another IP - just fully another range (!!) und continues. It doesn't matter if you block the full range or the single IP only.

Blocking the ranges is a bit problematically: if you block a renge like 36.249.0.0/16 (with a 16 on the end), so you block 65536 IPs in the same time! Some points:

  • an open proxy is not an open proxy in the whole future - they come and they go
  • the spam bot has the same behaviouin the both cases - s. above
  • every time he cannot use the present IP he changes to quite another range

Might be blocking of the single IPs could be enough before we have a new filter / filters etc. -jkb- 10:09, 5 September 2013 (AKDT)

The site notice is just fine.
I have been blocking 0/16 ranges indefinitely without feeling guilty about it. :)
When you use checkuser on a user name it will show if he has been editing from more than one IP address. If I then plug each range xxx.xxx.xxx.0/16 and get the edits from that address it will show how many addresses have been used within that range. This includes accounts that were set up but never used; some were set up a month or two ago. I've limited blocking only single IPs to where that is the only IP used from that range.
At this moment there are 1148 items in Category:Spam, plus whatever spamsters have had their work deleted without being blocked, and the sleeper accounts that have never edited. Lots of work still! Eclecticology 15:27, 5 September 2013 (AKDT)
Well, now we have 27756 "users", most of them created by the spam bot... Electron   02:14, 6 September 2013 (AKDT)
Blocking ranges indef: well, soon we have no newbies that could register here :-)... But: We hope we shall solve this problem soon - e.g. with a captcha registration. After this we schall not have such big problems. Thus I thonk we can use the Meta regulation saying, open proxies should be blocked max one year only (I normally use 6 months). When you find one or more OPs in the range xxx.xxx.xxx.0/16, it doesn't mean that all 65 thousands IPs are the same. And, as I said, the spam bot changes the ranges very soon after beeing blocked. -jkb- 02:30, 6 September 2013 (AKDT)
P.S. I have just asked somebody in deWP how to arrange a captcha. -jkb- 02:30, 6 September 2013 (AKDT)

Captcha

There are two sorts of captcha: the single one, where you must just add a number to another (like 4 + 7 = "?"), and the more difficult one ("Fancy Captcha")like in the wikies now (where you must write a word which is elaborated from letter pictures).

Simple captcha: the extension is on https://www.mediawiki.org/wiki/Extension:ConfirmEdit, incl. some manual and a download link; it must be downloaded, the .gr file must be zipped, and then the .tar file must be zipped, and the result must be saved in the folder ConfirmEdit ind the folder /extensions/ (in the mediawiki structure). Then in the LocalSettings.php two lines must be added:

require_once "$IP/extensions/ConfirmEdit/ConfirmEdit.php";
$wgCaptchaClass = 'SimpleCaptcha';

The captcha is activated now, but it is necessary to change the options

$wgCaptchaTriggers['edit'] = false; // Would check on every edit
$wgCaptchaTriggers['create'] = false; // Check on page creation.
$wgCaptchaTriggers['sendemail'] = false; // Special:Emailuser
$wgCaptchaTriggers['addurl'] = true; // Check on edits that add URLs
$wgCaptchaTriggers['createaccount'] = true; // Special:Userlogin&type=signup
$wgCaptchaTriggers['badlogin'] = true; // Special:Userlogin after failure

where in the line addurl you change it from true to false.

Alternatively you can use the extension https://www.mediawiki.org/wiki/Manual:$wgAccountCreationThrottle, which allows one syccount creation in 24 hours only. A manual should be there.

The FancyCaptcha is a bit comlicated as all the images must be uploaded (or generated) first to the server.

Thanks to User:Umherirrender from German Wiki.

Regards -jkb- 07:49, 8 September 2013 (AKDT)

P.S. SingleCaptche and the AccountCreationThrottle can be installed both. -jkb- 10:01, 8 September 2013 (AKDT)

  • Good! For now my priority is to get rid of these sleeping spam bot accounts before they come back to bite. The one block from a group of 4 IP addresses is responsible for nearly 10,000 accounts. I did try something before that tried to impose captchas, but it crashed the site. Once I'm finished with the sleepers, I can take a serious look at the above suggestions. Eclecticology 12:26, 8 September 2013 (AKDT)
Yes, it has not to be done in the next two hours :-)... Moreover, I've got some other suggestions just now, I will post it here tomorrow. -jkb- 13:46, 8 September 2013 (AKDT)
OK. Raymond from the dewiki wrote me some points as well. He say the simple captcha cannot be recommended seriously against spam bots. But I would say we could try it as the first and quick step just to open our registration soon. I would recommend to combine this simple captcha with the Throttle mode (see above) which allows one registration from a IP in 24 hours. If it doesn't help we can do something else, but this is probably not very difficult.
By the way: congratulations to all to this!!! Regards. -jkb- 08:54, 9 September 2013 (AKDT)
That sounds like a workable plan. Some of the accounts that I've been blocking were set up at the same time down to the second. Yes, great work by those who have been working through that spam category! Eclecticology 09:13, 9 September 2013 (AKDT)
OK. All known pages with spam were delated and blocked. Last pieces of them, that was omited by my bot I have found and deleted from this site -> Special:ActiveUsers. Of corse it is a good idea to block all of the new accounts created by the spam bot, but I think that it can be done gradually. Electron   14:45, 9 September 2013 (AKDT)
It takes a while. I've been working through 222.247.36.189's 4000+ accounts. If I do too many in a day it screws up recent changes. Eclecticology 16:54, 9 September 2013 (AKDT)
Recent changes are awful anyway in last days. Wouldn't it be better to create a new account and to grant it the bot status? Then it can be hidden from the rc. -jkb- 01:01, 10 September 2013 (AKDT)
It's a good idea. A bot edition aren't seen on default on RC. Electron   04:13, 10 September 2013 (AKDT)
True enough, but I think that we will be rid of these bad accounts before the bot is written. Eclecticology 10:15, 10 September 2013 (AKDT)
... "before the bot is written..." - I think you do not need to write any bot programm or something like that - it is enough if an account has the bot flag, then it is invisible in the rc, even if you make the edits manually. -jkb- 15:39, 10 September 2013 (AKDT)
OK. I'll try that with my secondary account. Eclecticology 16:51, 10 September 2013 (AKDT)
Great, it works! Eclecticology2 17:24, 10 September 2013 (AKDT)
Great, it works! :-) -jkb- 22:16, 10 September 2013 (AKDT)
After blocking some 10,000 spambot accounts, my mind is numb. Now I can take a closer look at captchas. Eclecticology 23:05, 13 September 2013 (AKDT)

I have implemented the simple captcha. Matma Rex had commented out the first line as "doesn't help any". The other line also had been commented out with a #, but possibly earlier by some other person. The captcha seems to work now. I have restored account creation, but will be keeping a very close watch on this. I will continue looking at the throttle option for an additional level of security. Eclecticology 19:56, 14 September 2013 (AKDT)

It doesn't look good, the bot is obviously able to register new accounts even if there is the sinple captcha. Just like I was warned. I'm not sure if the throttle would help a lot. In the last hours I was online and I blocked the IPs immediately, but after a time the bot found a new OP. I takes more time but he can do it. -jkb- 02:51, 15 September 2013 (AKDT)
P.S. And there seems to be something new - the user names are not as spam bot like (qprt456x) as in the past, now the bot uses "normal" names mostly. -jkb- 02:58, 15 September 2013 (AKDT)
Well, I analysed a bit the new accounts registered today. The results are on the page User:-jkb-/sbm in the thread 15.9.2013 (as the page contents many personal data and as nobody is invited to read it, I deleted the page; if somebody waqnts to read it, so klick on the last version and see the preview, if adding something so renew the page and delete it at the end). -jkb- 04:24, 15 September 2013 (AKDT)
I guess we have to stop the registration of new user again, and I do not think, the throttle (1 registration avery 24 hours only) would help, as the spam bot uses new OPs every time. Probably a more complicated capthca should be installed. -jkb- 08:29, 15 September 2013 (AKDT)
The human sounding names suggest human spammers. I have been looking at the history from some of these IP ranges, and blocking ranges when more than one address is used from that range. I'm also blocking users whom we missed when we were blocking thousands. The ones that are appearing now did not generate large numbers of accounts, and seldom more than one per day. I agree that the throttle won't help with these. A human spammer that only appears once a day is not likely to be bothered by answering a captcha of any kind. I'm wondering whether some kin of email address verification would work. Eclecticology 10:12, 15 September 2013 (AKDT)
Well, I think it is the question of programming - a bot can generate human sounding names as well, you just have to give him a list of names and surnamen (see: in wikipedia :-) )... What still is a question for me is the fact, that the accounts are obviously registered from more then one PC - see my subpage -jkb-/spm. Anyway, I would favorize a quick suspendig of the registration and a new try with a most complicated captcha. If we allow the registration then nothing changes, we have dozens and hundreds new spam accounts every day. Regards -jkb- 15:03, 15 September 2013 (AKDT)

results of the blocking

OK, making a very quick and not exact statistic (just going along 500 blocked by 500 blocked in the log) we have this result:

Electron Bot 1 500
Eclecticology 18 000
Eclecticology2 9 500
Luciana 1 500
-jkb- up to 500

so together some 31 000 blocked spam accounts. Not bad, indeed :-) -jkb- 00:57, 14 September 2013 (AKDT)

With Yann's, Poetlister's and mine, 815 more. What can I do now? --Zephyrus 02:14, 14 September 2013 (AKDT)
Oh, so sorry indeed, I was in hurry, my fault. So, we have had :-) some nearly 32 thousands spam accounts. Somebody should say if there are some pages that have to be deleted - the spam category is empty, and if I go through the user log so I see red user pages only (I have just try to see some examples). So the next step should be the captcha and then - no risk no fun - we could try to activate the registration agin... -jkb- 13:10, 14 September 2013 (AKDT)
Good news! So our Main Page's image comes true once more:
Oberon, Titania and Puck with Fairies Dancing
.
Lots of thanks to all the contributors to this. (the 32,000 included?) --Zephyrus 00:40, 15 September 2013 (AKDT)

Look Homeward, Angel

This is the novel by Thomas Wolfe, and there is no doubt that it belongs here. What raised my attention is that the djvu file uses an extraordinarily huge amount of bandwidth, 26.89mb per page. The proofread pages are black, but the OCR side looks ok. It was downloaded from Delhi University Library where it was scanned at 6000 dpi! For a novel 300 dpi should be enough. What's th best way of dealing with this? Eclecticology 17:06, 9 September 2013 (AKDT)

I wanted to download it to my PC and to decreas the pixeling, but I didn't succeed. Another possibility would be to download it from the source once again. -jkb- 00:40, 10 September 2013 (AKDT)

This djvu file is being downloaded multiple times, mostly from Chinese IPs. This accounts for 68% of our bandwidth usage. No other djvu file has such results. I don't know what they are trying to accomplish with all these downloads, but I think there is some security risk involved. The pages have not been proofread, and are unlikely to be proofread soon. We could use the "subst" function to move the content to the relevant wiki text pages, which in turn could be marked as unproofread. These djvu files could then be deleted, closing the security hole. Eclecticology 12:33, 14 September 2013 (AKDT)

next step - ?

Hi. Are there some developments in the case of new captcha? For this small domain I would even wuggest to install the email one. As far as I understood it, we need a wikilivres email address, where a new user sends us a mail, and we set his/her accont free. I think we do not have so many serious registrations, so that we would need some say three or four trustied people who have time and visit this domain often - who would have a look for new mails. Or what are the other proposals? Regards -jkb- 08:28, 26 September 2013 (AKDT)

Yes, what about e-mail - it's a good idea. Electron   06:01, 27 September 2013 (AKDT)
I have access to the e-mail account and can register new user accouts. So, I think that it is time to start... Electron   14:01, 21 November 2013 (AKST)
I still have some difficulties to entry - I will email you tomorrow. -jkb- 14:18, 21 November 2013 (AKST)
Try to instal Mozilla Thunderbird and it finds the e-mail account parameters automaticly. It is advice of Eclecticology and it works in my case. Electron   07:24, 24 November 2013 (AKST)

Search phrase

Can anyone explain why the Russian phrase "заплаканная осень как вдова в одеждах черных", from an Anna Akhmatova poem, is used so much as a search term? So far this month, it has been used 751 times, representing 20% of all searches by phrase. The second most used phrase, "воронежские тетради мандельштам" has been used only 38 times. Eclecticology 00:34, 11 October 2013 (AKDT)

Google Translate says "Fall in tears as a widow in black robes". Yann 01:52, 3 November 2013 (AKDT)
Well, nothing extraordinal -- this phrase seems to be just an ordinal beginning of just one of the ordinal poems written by Anna Akhmatova... However, from the IT and Computer Security points of view, one can imaging the following cases for this anomaly:
  • You should analyze the distribution of the requests for this phrase among IP addresses, subnetworks, probably autonomous systems and periods of daytime.
  • So, if all of them go from a single computer -- this is probably just a tab with this request, saved in a reader browser, who frequently reboots the computer so all the time he opens the browser you obtain this request...
  • However, 751 reboots per month seems to be too high... May be it's a buggy browser at the user side crashing frequently (as I have had at Ubuntu after upgrade to 13.10, hehe -- crashed on almost every page with flash video, so I restarted it multiple times a day, opening all preveously opened tabs again and again), or -- this may be a search phrase entered once at a computer at a school class, then this phares was repeated by some of the nearest students -- so if schoolar computers are shutdown at breaks and up again at every new lesson, reading again and again this search phrase at a saved browser tab... In this case, you should see the appropriate distribution among time and the requests should go from same external IP address...
  • Do you see any differences in letter sencetivity in this search phrase, or different number of commas or blanks? If so, there may be a group of students somewhere deep in Siberia who are forced by their teacher to anaylze this poem or memorize it... So they shared this searchphrase through icq or social network... In this case the requests should go from the geographicaly close subnetworks...
  • The latter case I see -- if you experience a DDoS- or spam-attack during this period of time, this search phrase may be a part of DDoS attempts (as an implementation of attack on wiki-backend, database and applications) or used by the attacking botnet to verify if your site is still alive... In this case you will see the wide distribution of requests among time and locations...
  • By the way, after you published this question here, you may see so-called habr-effect (named on a popular Russian IT blog portal and social network habrhabr) -- there, if someone is asking about problems or attacks on a site, the site then obtains even much more serios DDoS since every reader wants to see what is happening with this site and what this site is... ;-)) So you could probably see similar activity after you published this question (in much less scale since this page seems to be not quite active...). Cheers, Hinote 16:02, 7 December 2013 (AKST)

Meta data placement content and format

This issue has come up in a discussion that I have been having with User:Electron. How do we treat meta data for a content page? Where do we put it? What do we include? How do we format it? How do we balance a common approach here for all languages with something that is reasonably compatible with the Wikisource for the language of the material being presented.

Placement: There are three possibilities here: at the top of the content page, at the bottom of the content page, and on the talk page. I very much prefer having most of the meta data at the bottom of a content page. The top of the page should include only a minimum of essential data: title, author, translator, relation to the rest of the work, and a link to the rest of the data at the bottom of the page. For sub-pages I like the concept now used on Czech pages to lead to the metadata on the higher ranking page. Sometimes other information may go there, but I would view that on a case by case basis. The talk page should only need to be used when detailed explanations or histories are required.

Inclusions: For now this can remain open ended but should include when the work was first published, what edition was used for our version, the source for our version (which could be a hard copy), a copyright notice, the proofread status along with who were the two proofreaders. Eclecticology 20:27, 13 October 2013 (AKDT)

I prefer the bottom of the page. At the top is intrusive, and people don't read talk pages.--Poetlister 08:22, 18 October 2013 (AKDT)

Merry ...

500px-Xmas tree animated.gif Merry Xmas
to all of you from
-jkb-


Thanks!  :) --Zephyrus 10:07, 24 December 2013 (AKST)
Thank you and I wish the same to you :) Electron   10:17, 24 December 2013 (AKST)
Thank you all. I look forward to continue working with you in the new year. Eclecticology 23:18, 24 December 2013 (AKST)

Happy New Year to all! Yann 01:01, 2 January 2014 (AKST)

Thanks and I wish the same to you :) Electron   05:43, 2 January 2014 (AKST)
Yepp, a nice new year without 25000 accounts of a spamming bot!!! :-) -jkb- 05:47, 2 January 2014 (AKST)
The best new year for all the keepers of Wikilivres , (and for the spambots too, but in some other place, some special place created to make the spambots happy...)  ;) --Zephyrus 13:44, 2 January 2014 (AKST)

Newly-PD as of 2014-01-01

hello;

i've started a page (& perhaps a new "tradition"?), for listing newly-liberated authors & works.

it's just a very rough & simple list-text right now, but i welcome improvements... :)

Wikilivres:1963 deaths, therefore now in the Public Domain

Lx 121 08:36, 3 January 2014 (AKST)

Index Pages

Does Wikilivres have any way to add index pages for transcribing, like Wikisource does?--Interretano

Personal tools
In other languages