Wikisource:Scriptorium/Archives/2011

Login link to secure login

Would an admin be so kind to edit (create) Mediawiki:Loginend to add a link to the site's secure login. If it helps …enWS's . Thanks. 112.213.211.216 22:41, 4 January 2011 (UTC)[reply]

done, regards -jkb- 23:51, 4 January 2011 (UTC)[reply]

WikiProject Translation

Announcing the creation of a new interlingual cooperative WikiProject- WikiProject Translation! The goal is inter-wiki collaboration with the aim of making source texts available in multiple languages. The project is very much in the formation phase, and would benefit from voices giving input. Please feel free to express any ideas, concerns, or questions at the project talk page. If you don't speak English, you have two options: Use Google Translate, or start your own WikiProject Translation at your local Wikisource. (This is recommended in any case.) If we pool our resources we can accomplish great things! --Eliyak 15:10, 10 January 2011 (UTC)[reply]

bureaucrat

As of today, I am no longer a bureaucrat at ws.org. Please send your requests to User:Eclecticology, or elect a new bureaucrat. ThomasV 12:33, 20 February 2011 (UTC)[reply]

Wikisource copyright policy

Sorry for my possibly bad English.

I just saw Russian translation of GNU General Public License in ~~ruwikiquote~~ ruwikisource and wanted to see English original in ~~enwikiquote~~ enwikisource, but found out that it deleted there “as it is under copyright.”

The text of this license is distributed under the following terms: “Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.” De facto, this is the Creative Commons Attribution-NoDerivs, right?

Why we in Wikiquote can’t allow the use of texts distributed under such licences?

Wikiquote is a library of texts. Texts, in theory, should correspond to their originals, ie they should not change.

I think it would be quite correct to use Attribution-NoDerivs in Wikisource. What do you think?

~ aleksandrit 17:30, 21 February 2011 (UTC)[reply]

CC-Attribution-NoDerivs is not 'Free'. John Vandenberg 17:35, 21 February 2011 (UTC)[reply]

To complete John answer, that's different, it's only our internal policy to disallow changing a text, but our text can be modified by anyone who want to do it until he does that outside wikisource and he comply to its local law so we can't present GPL because it's NoDerivs. Phe 17:44, 21 February 2011 (UTC)[reply]

Thank you for the reply, I got it. Okay, so I’ll ask ruwikisource admins to delete above mentioned page. ~ aleksandrit 18:17, 21 February 2011 (UTC)[reply]

The statement from the licence does not necessarily make it ND. It all depends on the perspective from which you interpret "changing it is not allowed.” Is it about changing the text, or is it about changing the licence? If it is about the licence, the changed version, or any complete translation of the entire licence for that matter, would be a new document and could not be called a CC licence. Eclecticology 08:54, 9 March 2011 (UTC)[reply]

If you think about licences, you are not authorized to change any one (including licences for free contents), because they are necessarily copyrighted and signed (otherwise it becomes impossible to assert that a free content is licenced to some specific terms).

What this means, is that derivatives are allowed, but only in copies that are labelled differently. But all references from allowed free contents to their licence must remain stable.

We probably need a specific namespace in all Wikimedia projects, where we can store Licence documents which, once they have been proofed, will remain stable and unmodifiable at that location, and then referenceable as such from any free content.

In my opinion, this namespace should be shared across all Wikimedia projects, and probably hosted by Commons. These documents would have an essential status: (1) "Modifiable" means that it is still not usable as a valid licence for other contents. And (2) "Frozen" where it can be used as a valid reference to the licence (when it is frozen, it has to be digitally signed by his author, and it must never be renamed, that's why freeing a licence should only be made by an admin).

Currently, licences are managed through a nightmare of templates, which are very hard to verify, notably across wikis.

This "Licence:" namespace should avoid transcluding any unfrozen templates ; their presentation don't have to be unified, and only technical edits for rendering compatibility should be allowed (or corrections of typos if the text was actually imported from another source), or metadata edits (such as categories).

All contents in this namespace would be fully copyrighted, according to the terms specified in themselves. If this text allows derivations, derivations will be done into other pages in the same namespace, but with another name.

All pages stored in this "Licence:" namespace should work like templates : i.e. when viewed directly, you get the full text, but in transclusions, you get only a view such as a box built over a layout template, which it self would be translatable. But the licence itself should not be translated. We could use the noinclude section for the frozen text and for transcluding an unfrozn subpage containining the metadata, and the includeonly sections would contain the transcludable view (exactly like the existing licence templates visible in Commons in the description page of free medias). Verdy p 02:32, 4 June 2011 (UTC)[reply]

Dragging into djvu text layer

After some talk into wikisource-l, I'd like to open here a page covering the topic of djvu text layer manipulation. I'd like to share links, scripts and ideas.

I'm an active user into it.source and en.source, but I don't know at all policies into this community, so I thought better to ask your opinion about.

Could be "Wikisource:Djvu text layer" a good page name? Have you a better suggestion? Thanks. --Alex brollo 23:36, 21 February 2011 (UTC)[reply]

Of course it's a good name. If it isn't just rename it ;) -Aleator 23:53, 21 February 2011 (UTC)[reply]

Ok, thank you. So, I'll create Wikisource:Djvu text layer page and I'll upload locally a "dummy" djvu file with a good text layer, just to have a shared file to work on and to use for running examples, screenshots and test. --Alex brollo 07:49, 22 February 2011 (UTC)[reply]

All is ready to start: therea are

a main page: Wikisource:Djvu text layer
a Category:Djvu text layer
an example, locally loaded djvu file for running examples and screenshots: File:Poems.djvu.

OK? --Alex brollo 09:01, 22 February 2011 (UTC)[reply]

On which template/language and to which address the author can send his permission ?

Help me, please. I tend to include article from newspaper(2010) (Nogai language) to Wikisource. Suppose, the author want to give his permission on it. But previously I must know a template for corresponding text and I must know the rule: at which language (Russian , English) text must/can be written? Where I can find answers on these questions? And more: to which address this text must be sended by e-mail? Thanks. Владимир aka Winni 12:16, 11 March 2011 (UTC)[reply]

If you have the author's permission to use the text, you can send the confirmation email to the volunteer response team at permissions@wikimedia.org. There are both English- and Russian-speaking OTRS volunteers, so either language should be fine. Remember to indicate what free license the author has agree to use for the text. Jafeluv 13:03, 29 March 2011 (UTC)[reply]

new section behaviour

I just went to add a new section to a Wikisource: name page by clicking on "New section", and ended up starting a new talk page instead of adding it to the project page. This seems like a bug to me. It seems to work correctly if the talk page already exists. Eclecticology 10:36, 12 March 2011 (UTC)[reply]

I cannot find it. I saw you edited and deleted Wikisource talk:Proposal, but on the page Wikisource:Proposal there is no button or "add new section"; in last days there are still some not expected changes due to the last upgrade of the software - maybe this was one. -jkb- 13:40, 12 March 2011 (UTC)[reply]

hmmm! It seems to be skin dependent. I have used the Cologne Blue skin from the beginning when I modernized from the Classic skin. (I still keep my WP skin at Classic.) I haven't checked if this is happening outside the Wikisource: namespace. In Cologne Blue the "New Section" button is retained in the sidebar. If the talk page does not exist it will start it. (Thus my deletion.) If it does exist it will add the new section at the bottom, as expected. Strange! Eclecticology 22:36, 13 March 2011 (UTC)[reply]

button in the sidebar?? I guess it happens because of the skin as other skins has not been updated for a long time; it never happened me with Vector (or Monobook earlier). -jkb- 00:02, 14 March 2011 (UTC)[reply]

Thanks. Looks like I'll just have to live with it. Not too serious now that I know what's happening. Eclecticology 09:02, 16 March 2011 (UTC)[reply]

New projects

Since the new projects have opened, I wonder when the pages here can be deleted.

sah: seems ok (I imported the pages myself and all seems to be complete), someone should ask whether the importing of eo: and sa: are done as well. -- Prince Kassad 23:46, 26 March 2011 (UTC)[reply]

Could you be a bit more precise? With some links or more description. Thanks, -jkb- 00:45, 27 March 2011 (UTC)[reply]

Three new language domains were recently created: sah.wikisource, eo.wikisource, sa.wikisource. The corresponding categories are Category:Sakha, Category:Esperanto and Category:Sanskrit. Jafeluv 14:32, 27 March 2011 (UTC)[reply]

Please don't delete those pages from eo: until we finish the importing process and confirm that it's complete. We can ask their deletion here in Scriptorium or by putting {{delete}} in the category. We won't forget that, I promise. CasteloBranco^msg 02:12, 28 March 2011 (UTC)[reply]

All right, CasteloBranco, we will wait for your signals. --Zyephyrus 07:34, 28 March 2011 (UTC)[reply]

Ok we’ll wait for eo, what about sah and sa ? Could we start the deletion ? Cdlt, VIGNERON 16:54, 28 March 2011 (UTC)[reply]

Sah: can be deleted per Prince Kassad above, I think. As for sa:, I've left a note on Shijualex's talk page so he can comment on it himself. Jafeluv 08:33, 29 March 2011 (UTC)[reply]

The import is done for Sanskrit. I have imported all the pages that I could locate. Please let me know in case if I missed something--Shijualex 09:45, 31 March 2011 (UTC)[reply]

The import is done for Esperanto, too. Thank you very much. CasteloBranco^msg 11:29, 3 April 2011 (UTC)[reply]

Category:Esperanto deleted. --Zyephyrus 14:57, 3 April 2011 (UTC)[reply]

Please add information to Wikisource:Subdomain coordination whenever information is available. As Sakha is spoken in Russia and Sanskrit is spoken in India, perhaps these two new subdomains should consider the Russian and Indian copyright laws to develop their copyright policies, such as pre-1923 works still copyrighted there.--Jusjih 07:54, 5 April 2011 (UTC)[reply]

There are still several Esperanto pages on wikisource.org (check out Category:Aŭtoroj, for example). Are they needed any longer? -- Prince Kassad 16:24, 14 April 2011 (UTC)[reply]

Category:Aŭtoroj, as well as everything else in the now-deleted parent category, has already been transferred. Compare Category:Enhavtabelo (red link, but still has content) with s:eo:Kategorio:Enhavtabelo. Jafeluv 22:16, 5 May 2011 (UTC)[reply]

What about Sanskrit? The import of these pages is done as per Shijualex' comment above, so it should be okay to delete them now. -- Liliana-60 12:59, 14 August 2011 (UTC)[reply]

Template namespace initialisation script

Hello. Some years ago, developpers used Template namespace initialisation script to move some pages from the MediaWiki to the Template namespace, and left some useless redirects.

Consequently, the following pages should be deleted :

For more informations, please see this request (meta).

Thanks -- Quentinv57 11:34, 16 April 2011 (UTC)[reply]

Done. Candalua 16:56, 18 April 2011 (UTC)[reply]

Block request

Would an admin please indef-block User:Jared's Ballsack? He's only made one edit, but it was offensive vandalism, and it's definitely an offensive user name. Thanks! —An gr 09:11, 17 April 2011 (UTC)[reply]

I see the offensive vandalism and block the user for 2 hours, but please explain how offensive the username is, before a longer block. Thanks.--Jusjih 15:06, 19 April 2011 (UTC)[reply]

"Ballsack" is vulgar slang for the scrotum. —An gr 05:05, 20 April 2011 (UTC)[reply]

Done the request for infinite block.--Jusjih 04:01, 21 April 2011 (UTC)[reply]

Speedy delete request

Please delete File:Oileain na mBlascaod.png as I accidentally uploaded it here instead of at Commons. It is at Commons now under the same name. Thanks! —An gr 21:21, 26 April 2011 (UTC)[reply]

Done VIGNERON 21:04, 1 May 2011 (UTC)[reply]

Include pages (and possibly indexes and authors) in official article count

See also mailarchive:wikisource-l/2010-January/000658.html, en:Wikisource:Scriptorium/Archives/2010-04, mailarchive:wikisource-l/2011-April/000964.html

I propose to request to set $wgContentNamespaces to array (0, 102, 108, 110) on all Wikisources which have such namespaces so that pages in Page:, Author: and Index: are considered for the official article count shown on Special:Statistics and {{NUMBEROFARTICLES}}, which is currently greatly underestimated on most projects. Pages are without doubt content; I think that the same applies to index and author pages, which are like lists on Wikipedia or rather galleries on Commons (both part of a content namespace). Anyway, they're way less. What do you think? If there's consensus, I'll request it on bugzilla. (I've wanted to do so since more than a year ago but I forgot...) Nemo 20:36, 30 April 2011 (UTC)[reply]

I've nothing against this proposal but people must be aware than for statistical purpose and for wikisource using widely the Page: namespace, the most reliable statistics are [1], especially [2], using NUMBEROFARTICLES as statistics can mislead people. Transclusion habits vary a lot among wikis, some wikis prefer tiny page, some other medium page, some other huge (meaning you can transclude a book by chapter, by part or as a whole book in only one page). Another problem is transclusion dynamically generated like L’Encyclopédie/Volume_1, we have only 17 pages in namespace 0 for 70K articles of the Encyclopédie. Also a technical point, you can't use (0, 102, 108, 110) for all wikisource, the namespace number vary over wikisource. See MediaWiki:MatchSplit.js for namespace number for Page:, I'm unsure where to find the other namespace number. Phe 23:35, 26 May 2011 (UTC)[reply]

Thank you for your reply and the correction about numbers. I know that we should mostly use ThomasV statistics, but I think it's still useful to make the "official article count" more similar to the reality: the use of Page: namespace varies less among Wikisources, so adding such pages would mitigate the effect you described. Nemo 06:03, 27 May 2011 (UTC)[reply]

It is also quite important for recording the number of edits. If you have a look at the pages from http://stats.wikimedia.org/wikisource/EN/Sitemap.htm you will see the edits on those pages grossly misrepresented. The main ns may be where the bulk of edits are done at WP, however, for the other sites, they utilise their namespaces differently. I support the proposal. billinghurst sDrewth 14:02, 27 May 2011 (UTC)[reply]

I've collected some data around; the actual configuration would be User:Nemo_bis/wgContentNamespaces (!). Nemo 16:13, 27 May 2011 (UTC)[reply]

Sounds logical s:he:User:Ori229 -- אוֹרי 08:49, 27 במאי 2011 (IDT)

I like it, but first we should get same id for a "Author:" namespace in all subdomains (where it exists, of course). This table was composed in 2010:

Language	"Author:" namespace
en	102	Author:
fr	102	Auteur:
cs	100	Autor:
hu	100	Szerző:
ko	100	저자:
la	102	Scriptor:
pl	104	Autor:
it	102	Autore:
hr	100	Autor:
pt	102	Autor:
bg	100	Автор:
hy	100	Հեղինակ:
sv	106	Författare:
da	102	Forfatter:
no	102	Forfatter:
tr	100	Kişi:

Looks like id=100 and canonical namespace name = "Author:" will most acceptable. -- Sergey kudryavtsev 20:20, 27 May 2011 (UTC)[reply]

This is not possible. As written above, we just have to adapt the configuration for each wiki. An updated table is on User:Nemo bis/wgNamespaceAliases. Nemo 12:52, 28 May 2011 (UTC)[reply]

The bug has been fixed by JeLuF. Nemo 06:28, 24 June 2011 (UTC)[reply]

Search Index and Author namespaces by default

If nobody objects, I'll also request to change $wgNamespacesToBeSearchedDefault so that the internal search engine searches by default both Index and Author namespaces, so that users can easily find the author or work they're looking for, even if there's no relevant page in main namespace. I see that all Wikisources which bothered to change this configuration added either Author namespace or both, except de.source which doesn't have an Author namespace and added both Index and Page namespace (I don't know why, this seems a way to get overwhelming search results), so they wouldn't be affected. The proposed configuration is User:Nemo_bis/wgNamespacesToBeSearchedDefault.
This affects the default search with the search bar and the checkboxes checked by default on Special:Search (advanced view) for anonymous users, while as far as I understand existing users will keep their preferences. Nemo 13:02, 28 May 2011 (UTC)[reply]

Definitely add Author, as that is content for the world to see. I am not sure about Index, do you think that it is ready for the world to see without some context? I find that adding a link to Index: pages from the author pages (and at enWS we use en:Template:Small scan link at least a context setter. Otherwise, if you arrive at an index page and there is no indication to what it is, what it means, or how to use it. billinghurst sDrewth 14:35, 29 May 2011 (UTC)[reply]

People will arrive there anyway via general search engines, won't they? With the current configuration, though, users won't find actual content (entire books available on the wiki) unless they know how to search the wiki; at least, in this manner, users will find what's available (instead of thinking there isn't anything) and then they'll click and see or they'll look around to learn more. Nemo 15:32, 29 May 2011 (UTC)[reply]

The bug has been fixed by JeLuF. Nemo 06:28, 24 June 2011 (UTC)[reply]

Questions and issues

I recently imported an Afrikaans translation of the public domain World English Bible from a site I operate to this site at Bybel. I believe I got everything right but encountered several problems along the way:

Subpages appear to be disabled for this wiki, so relative path links don't work like they do on en.wikisource for the World English Bible. I got around this by faking it with titles containing slashes and putting full names in links.
Interwiki links like [[:en:Bible]] link to the English Wikipedia instead of the English Wikisource, and links like [[en:Bible]] don't appear in the sidebar but in the text. I got around this by using links of the form [[s:en:Bible]], but this is really odd.
I'd like to add an interwiki link from en:World English Bible to Bybel, but have no idea how to do this.

Thanks. Dcoetzee 05:17, 20 June 2011 (UTC)[reply]

Interwikis don't work on this wiki, see -> Wikisource:Scriptorium#Interwikis. Electron

^<Talk?> 07:25, 20 June 2011 (UTC)[reply]

secure.wikimedia.org for WS language subdomains?

Is it possible to access WS language subdomains through https://secure.wikimedia.org? I notice that the secure URL for WS uses a scheme in common with other Wikimedia projects which don't have language subdomains. 71.200.137.85 01:18, 22 June 2011 (UTC)[reply]

I found that there are secure subdomains accessible through URLs imitating the scheme of Wikimedia projects with language subdomains (e.g. English). However, these aren't accessible from the multilingual page linked from https://secure.wikimedia.org because the javascript used to rewrite URLs with their secure equivalents isn't used on multilingual. Can an admin here please add the following to Mediawiki:Common.js?

/**
 * Script to rewrite external links to other Wikimedia projects to
 * use the secure server when already browsing from https://secure.wikimedia.org
 */


if ( mw.config.get('wgServer') == 'https://secure.wikimedia.org' ) {
  mw.loader.load('http://en.wikipedia.org/w/index.php?title=MediaWiki:Common.js/secure.js&action=raw&ctype=text/javascript');
}

Thanks. 71.200.137.85 04:53, 22 June 2011 (UTC)[reply]

Come to think of it, it might be better to use

mw.loader.load('https://secure.wikimedia.org/wikipedia/en/w/index.php?title=MediaWiki:Common.js/secure.js&action=raw&ctype=text/javascript');

instead. 71.200.137.85 18:48, 22 June 2011 (UTC)[reply]

Seeking consensus for working interlanguage links

I put up a bug report for one side of the multilingual wikisource interlanguage link problem. The responder wants to verify it's the community's will. Please leave a note here with your take. Prosody 05:19, 23 June 2011 (UTC)[reply]

Support proper IWL (evel everywhere). Cdlt/A galon, VIGNERON 11:28, 23 June 2011 (UTC)[reply]
Support. Electron ^<Talk?> 21:09, 23 June 2011 (UTC)[reply]
Support, there's no reason to have a different behaviour just for this wiki. Thanks to Prosody for putting it up. Candalua 21:39, 23 June 2011 (UTC)[reply]
Support, Phe 23:28, 23 June 2011 (UTC)[reply]
Support. Language links should go to Wikisource subdomains by default (instead of Wikipedia as they do currently) and the interwiki links should be in the sidebar like in every other project. Jafeluv 08:33, 24 June 2011 (UTC)[reply]
+1 for language links with 'source subdomains as default. Do we need to open a separate bug, or can we add this request to the current one? Candalua 08:42, 24 June 2011 (UTC)[reply]
A separate bug, apparently. But someone needs to fix all existing links to Wikipedia ([[:?<lang>:<link>]] -> [[w:<lang>:<link>]]). Will you, Candalua? Otherwise I can do it but I need AnankeBot to be flagged. Nemo 08:07, 26 June 2011 (UTC) P.s.: I found 1269 pages to be corrected with the following command (although there's plenty of incorrect links right now, because people expect language interwikis to point to Wikisource):[reply]
python replace.py -family:wikisource -lang:- -xml:... -regex -recursive -summary:"Bot: removing short interwiki links to Wikipedia per [[Wikisource:Scriptorium#Seeking_consensus_for_working_interlanguage_links|discussion]]" "\[\[:?(aa|ab|af|ak|als|am|an|ang|ar|arc|arz|as|ast|av|ay|az|ba|bar|bat-smg|bcl|be|be-x-old|bg|bh|bi|bm|bn|bo|bpy|br|bs|bug|bxr|ca|cbk-zam|cdo|ce|ceb|ch|cho|chr|chy|co|cr|crh|cs|csb|cu|cv|cy|da|de|diq|dsb|dv|dz|ee|el|eml|en|eo|es|et|eu|ext|fa|ff|fi|fiu-vro|fj|fo|fr|frp|fur|fy|ga|gan|gd|gl|glk|gn|got|gu|gv|ha|hak|haw|he|hi|hif|ho|hr|hsb|ht|hu|hy|hz|ia|id|ie|ig|ii|ik|ilo|io|is|it|iu|ja|jbo|jv|ka|kaa|kab|kg|ki|kj|kk|kl|km|kn|ko|kr|ks|ksh|ku|kv|kw|ky|la|lad|lb|lbe|lg|li|lij|lmo|ln|lo|lt|lv|map-bms|mdf|mg|mh|mi|mk|ml|mn|mo|mr|ms|mt|mus|my|myv|mzn|na|nah|nan|nap|nb|nds|nds-nl|ne|new|ng|nl|nn|no|nov|nrm|nv|ny|oc|om|or|os|pa|pag|pam|pap|pdc|pi|pih|pl|pms|pnt|ps|pt|qu|rm|rmy|rn|ro|roa-rup|roa-tara|ru|rw|sa|sah|sc|scn|sco|sd|se|sg|sh|si|simple|sk|sl|sm|sn|so|sq|sr|srn|ss|st|stq|su|sv|sw|szl|ta|te|tet|tg|th|ti|tk|tl|tn|to|tokipona|tp|tpi|tr|ts|tt|tum|tw|ty|udm|ug|uk|ur|uz|ve|vec|vi|vls|vo|wa|war|wo|wuu|xal|xh|yi|yo|za|zea|zh|zh-classical|zh-cn|zh-min-nan|zh-tw|zh-yue|zu):([^|]+\|?[^]]*)\]\]" "[[w:\1:\2]]"

Ok, I can do it, after this other bug has been fixed Candalua 09:46, 27 June 2011 (UTC)[reply]
Perhaps it's better to do it before, so sysadmins know there will be no broken links (the w: prefix always works). Nemo 17:59, 27 June 2011 (UTC)[reply]
Done for ns0, 457 pages were changed. Candalua 19:27, 9 July 2011 (UTC)[reply]
Support ---Vikiyazar 14:01, 24 June 2011 (UTC)[reply]
Support As noted above, this issue caused me some pain at Bybel. Dcoetzee 12:21, 28 June 2011 (UTC)[reply]
Support, what a great idea. Wish someone had done this five or six years ago. —An gr 12:16, 2 July 2011 (UTC)[reply]
Support.--Jusjih 17:28, 3 July 2011 (UTC)[reply]
Support, and thanks to those who took care of this problem. Dovi 19:56, 3 July 2011 (UTC)[reply]

MediaWiki:Loginend

Hi!

Could someone change the link

https://secure.wikimedia.org/wikipedia/en/wiki/Special:UserLogin

to

https://secure.wikimedia.org/wikipedia/sources/wiki/Special:UserLogin

? Helder 13:43, 28 June 2011 (UTC)

Done Candalua 19:36, 9 July 2011 (UTC)[reply]

Interwiki

I understand that they are working only in one direction, from here to other wikisources. Is there a problem to fix:

[[:oldwikisource:page_on_old_wikisource]]

to work in the same way (I mean as interwiki from an wikisource to the old wikisource, not as a plain link how it works now)? Electron ^<Talk?> 14:33, 18 July 2011 (UTC)[reply]

There's bugzilla:13334 for the general case, and bugzilla:26124 for a language-specific workaround solution. Jafeluv 20:25, 18 July 2011 (UTC)[reply]

There is a work-around that can be used in the interim:

{{Interwiki-info|ar1|(Old Wikisource)}}
[[ar:oldwikisource:{{FULLPAGENAME}}]]

I chose 'ar' only because it would generally be at the top, any language will work. Obviously {{Interwiki-info}} has to exist on the wiki, but it can be imported. There is no need for it here, but it exists at en:Template:Interwiki-info and there are interwiki links from there to the template on several other subdomains. Most have the same form as above, although 'ru' and 'uk' have local Cyrillic names for the template.
--Doug.^{(talk • contribs)} 09:17, 17 August 2011 (UTC)[reply]

- N.B. - if you aren't in the mainspace, you have to specify the namespace unless it's the same as on here or the above will give you the namespace name on the sending project (e.g. if you link your user page to here from de.ws with the above code it will produce a link to e.g. Benutzer:Doug instead of User:Doug. Just replace {{FULLPAGENAME}} with the wording of the link on this site. Also, there is some difference in the css I think on fr.ws causing this to fail, but you can see my userpage there to see how I've gotten around that. Not pretty but works for a user page.--Doug.^{(talk • contribs)} 10:12, 17 August 2011 (UTC)[reply]
I'm wondering if there is a .css or .js solution to make this display in just Old Wikisource rather than having to display a language first. Thereby making it look like the other language links, in essence emulating the real thing.--Doug.^{(talk • contribs)} 10:15, 17 August 2011 (UTC)[reply]
N.B. - the above relies on the common.js having the proper code. fr.ws has different code and thus behaves differently in this. That code would have to be imported to any other wikis together with the template, which would require at local-admin or steward privileges to be able to edit the .js. I am working on a further solution.--Doug.^{(talk • contribs)} 10:38, 17 August 2011 (UTC)[reply]
New script pending that makes a more complete solution.--Doug.^{(talk • contribs)} 05:37, 18 August 2011 (UTC)[reply]

orphans

I wonder if we could host orphan works here that would belong on a subdomain but for being rejected there for technical reasons. A few examples that come to mind:

Works that don't have scans and for which none are likely to become available anytime soon on a subdomain that requires scans
Works that are in the public domain in the United States but not in the country of primary readership where the language of a subdomain is largely spoken: two examples from de.ws 1) works seized from the Nazis are generally considered still in copyright in Germany; 2) works published before 1923 but whose authors lived beyond 1940 (a specific example: Hermann Hesse; his works are in the public domain in the United States and would be eligible to be hosted on en.ws if they had been first published in English (even if first published in Germany) and English derivatives (such as translations) are eligible for hosting on en.ws if in the PD or published under a free license; yet the basic works cannot be because of a self-imposed rule).
Other works that are declined by a subdomain for technical reasons (e.g. de.ws rejects works over 50 pages unless multiple proofreaders can be found - to the point of deleting indices so the user can't even work on the project in the background).

I wonder whether we could consider orphans to be within scope and put up such works here. If they later came into scope for a subdomain, they could easily be transwikied.--Doug 00:32, 14 August 2011 (UTC)[reply]

I just noticed that the system message when I went to add some content (actually on user talk) reads:

You are about to create a new page. This is the multilingual Wikisource. Please note that Wikisource now has language subdomains for the following languages:
ar - az - bg - bn - br - bs - ca - cs - cy - da - de - el - en - eo - es - et - fa - fi - fo - fr - gl - he - hr - hu - hy - id - is - it - ja - kn - ko - la - li - lt - mk - ml - nl - no - pl - pt - ro - ru - sa - sah - sk - sl - sr - sv - ta - te - th - tr - uk - vec - vi - yi - zh - zh-min-nan
You should not create your page here if it is written on one of those languages. Exceptions may apply for pre-1923 work still copyrighted in its home country and forbidden in the specific language subdomain. See also how to submit a text for further information.

That implies that we can allow #2 above, at least; so maybe the others could be allowed by analogy.--Doug 07:23, 14 August 2011 (UTC)[reply]

Furthermore, I note this work Słownik_geograficzny_Królestwa_Polskiego, just as a recent example, that shows this is being done, so #2 appears to be accepted practice. How about the others by analogy?

Any work that is within scope of Wikisource and in the public domain in the United States but not eligible to be hosted on a subdomain for any reason, may be hosted here ??

--Doug 13:28, 14 August 2011 (UTC)[reply]

See also this discussion: la:Vicifons:Scriptorium#Interproject_transclusion, involving a case of an multilingual work being outright rejected on de.ws (per this discussion and related case here de:Wikisource:Skriptorium/Archiv/2010/April#Agricola. Because it's impossible to set such works up in anything but page/index space there might be the possibility of transcribing the non-latin text here under the third case above. Though I'm not sure of this result, the ones above seem more certain to me, these multilingual works could reside entirely on the one language. But la.ws seems even more like the wrong place for the German text and some subdomains might have a problem with the idea of transcription of works outside their language. I don't really have a position on this one but list it here only for further background/discussion.--Doug 12:19, 15 August 2011 (UTC)[reply]

I don't understand this proposal completely. If you consider it just a trick to circumvent local community policies, it would work, but I don't think it's a good idea. If you think it might be useful to avoid respecting some local laws, I don't see why the domain should matter: the servers and the people are the same; we usually respect local laws as well because contributors and readers reside in that country although the servers don't, and this wouldn't change. --Nemo 10:14, 17 August 2011 (UTC) P.s.: Don't call them "orphan works" or people will understand another thing.[reply]

The only part that has to do with any local laws is the copyright issue which old wikisource specifically allows (it's also discussed at Wikisource:subdomain coordination). That is because of a WMF policy relating to projects that have the majority of their readership coming from a particular country. The rest are matters where local projects have made internal decisions to exclude certain works that are otherwise within scope.--Doug.^{(talk • contribs)} 17:15, 17 August 2011 (UTC)[reply]

BTW, this wasn't intended to be a proposal so much as trying to get some feedback on how to deal with works that subdomains don't want/don't allow for reasons peculiar to the subdomain. The alternative is to put such works off project, such as at Wikilivres, but that seems entirely unnecessary when the work is within the scope of wikisource and PD at least in the United States. That's all. --Doug.^{(talk • contribs)} 17:25, 17 August 2011 (UTC)[reply]

I've found works in German that are PD in Germany already here. Although it could be argued that they should be moved to de.ws they meet my criterion 3 above, in that they would be immediately deleted at de for lack of permission to transcribe them. So, even if it's arguable that we may not wish to encourage such works here, we probably shouldn't delete such works until they reach a point where they would be acceptable on de.ws.--Doug.^{(talk • contribs)} 12:11, 20 August 2011 (UTC)[reply]
- Unfortunately, I am discovering numerous works and navigation pages that have been deleted when the pages were erroneously moved to subdomains (where the works were soon deleted for violating the local copyright rules). I would like to make an effort to bring these works back.--Doug.^{(talk • contribs)} 13:44, 26 August 2011 (UTC)[reply]
Hosting works on ws.org which are legal in US but not wanted in the appropriate subdomain, for other copyright reasons (e.g. de.ws not wanting works illegal in Germany), is worth considering, however we need to consider it carefully - each case should be evaluated separately. Hosting works on ws.org in order to avoid the processes and policy of the subdomain (e.g. de.ws requiring permission to start projects) is not a good approach. John Vandenberg 08:22, 27 August 2011 (UTC)[reply]

Valid point, I think maybe it was overstated by me above. It's more that certain works are simply prohibited by some subdomains. I could also see setting a work up here in the above case where it's bilingual and the choice is between putting it here or putting text on the "wrong" language subdomain. However, see discussion below about problems with the process of splitting works up anyway.--Doug.^{(talk • contribs)} 09:07, 27 August 2011 (UTC)[reply]

Part of the idea here is that we must be cognizant of local rules. I have found a number of pages moved to de.ws that were subsequently deleted because they didn't meet local rules. Although we may not want to advocate putting new works here now that don't meet local requirements, it's a very bad idea to cause works to be deleted; especially as some of the local rules and the WMF policy that supports them may have post-dated the transcription here. We may want to suggest that if works are moved and found to later violate local subdomain rules, that they could be moved back here rather than deleted. This might not be desirable where the work is nothing but an index and OCR, but if transcription/proofreading has taken place it would be preferable to losing works.--Doug.^{(talk • contribs)} 07:38, 8 September 2011 (UTC)[reply]

interwiki coordination, where and how?

Do we have a place dedicated to finding ways to make cross-subdomain work easier. Although the subdomains bring in a lot of editors who might not feel comfortable on a multilingual project, in part because it would tend towards work in a few major languages, particularly English; subdomains also Balkanize us. This is immediately apparent if you start doing cross-subdomain work because of issues like differences in templates, differently named templates, different formatting policies, and special rules that require users to set things up according to a particular guideline or even request permission before setting up a work. I have no difficulty transcribing French, German, or Latin (or any other language with a largely latin derive alphabet); however, I understand the first two only a little and the last one not at all - I can't read policies written in German or French and I can't find templates unless they are interwiki linked. Some things that can be done:

we could establish a core set of templates (like center, underline, etc.) and work to ensure that they exist on all projects with redirects from major language names and interwiki links
work to establish major language translations of core policies on subdomains, the way mw does; el.ws has done a good job on this but has low usership so maintaining such things is hard.
ensuring system messages and the sidebar menu, etc. are translated
identifying deficiencies such as a clear understanding of what to do with multilingual works and how best to set them up

For just a few of the many issues. Thoughts? And again, if we have a special place for this sort of thing, please let me know.--Doug 01:07, 14 August 2011 (UTC)[reply]

On Wikisource:Subdomain coordination there are some useful infos, we could start from that. Especially your point 1 seems to me like a good (and not too difficult) thing to do Candalua 10:37, 14 August 2011 (UTC)[reply]

Great, persisting troubles in interwiki transclusion, and lots of multi-lengual books, suggested me by a long time that wikisouce should be something like Commons, i.e. a big, unique, large multilingual project. Obviously this would solve any trouble; and I presume that a bold try to keep such a revolution into account would be a great goal.

I think that it's an almost impossible task to keep template aligned among projects. The same, more subttly, happens with css: very good templates are unuseful without specific css settings. I agree that a core of common, shared templates & associated css settings would be useful; my suggestion is, to avoid translation of name of templates and parameters so that they could slowly get a feature of "common source syntax"; nevertheless, as long as interwiki transclusion is a dream, the only real solution would be, a common, unique, multilingual source project. --Alex brollo 14:23, 14 August 2011 (UTC)[reply]

Well, I am quite interested in this kind of issues, but I am torn between the technical and the political POV. I'm more inclined towards the second ones, but I'll try to understand and suggest what I can.

As far as the first point is concerned, I'd like to see some effort to compile the "best" synthesis of common.css and common.js: I think that many hidden treasures should be shared and that a lot of legacy code could be stripped. In an ideal state a single common.css/js should be used: It's already working with Wikisource:Shared Scripts...

As for the policies, I'm afraid that Wikisource:Subdomain coordination is currently the best effort with little margin for better definitions. every user should know that before uploading a new work there must be a check-in from local users, otherwise he should be ready to face deletions, warnings and so on: It's a matter of common sense. On it.source non acceptance of collaborative translations is seen as an anomaly, while on de.source there is a strict policy about the quality of the source which prevents the upload of existing transcriptions... I see no problem in it until there is wikilove and an approach aiming to dialogue and explanation.

I'd like to propose something like sk:Wikisource:Embassy, a place where users from other projects can ask about policies and so on.

As for Templates, I quote Candalua (see Template:delete working on almost every WMF project). - εΔ ω 14:50, 14 August 2011 (UTC)

I whole heartedly agree with Alex brollo, strategically speaking, although the subdomains have been great for getting works added and maintaining harmony over issues of what language to use, the subdomains have also become our greatest weakness. Multilingual works are held back and these are some of the most important works as they help expose people to ideas from other cultures and promote the study of language. I suggest these as baby steps and the core templates idea as just a point of departure, together with the thread above which discusses a (very trivial) scope clarification to ensure there aren't works that could go on an WMF project but are not allowed only because of a local rule.

I also think we need to develop and promote best practices in cross-subdomain work; such as is {{iwpage}} the best solution for a truly multilingual work and how exactly can it best be implemented to leave room for future developments; just as an example.

OrbiliusMagister, what do you mean by the technical and the political POV"?

--Doug 15:21, 14 August 2011 (UTC)[reply]

By the way, I appreciate the link though I don't see much discussion there; just a chart. I also note that many of the links are incorrectly formatted and result in linking to non-existent wikipedia pages. I'll work on that.--Doug 15:24, 14 August 2011 (UTC)[reply]

I have updated it, the problem was with the form of some links creating links to wikipedia and/or language links unintentionally.--Doug 09:57, 16 August 2011 (UTC)[reply]

An example of a problem is here s:fr:Livre:Satires d'Horace et de Perse.djvu. half the pages are in latin and should be on la.ws. User:ThomasV started to move them but got an objection from the major editor. He deferred the matter until import was enabled on la.ws. It was enabled and I have now imported all of the latin pages here s:la:Liber:Satires d'Horace et de Perse.djvu. This one was not too bad but still I found the editors on fr had used s:fr:Modèle:Titre2ModePage and s:fr:Modèle:Titre3ModePage. I don't want to create these on la.ws and with some templates (not these) there could be conflicts. So, I replaced all of these templates with equivalent html/css (cf. s:fr:Page:Satires d'Horace et de Perse.djvu/244 with s:la:Pagina:Satires d'Horace et de Perse.djvu/244). I don't really like the formatting used but the pages are already in use on fr, so I don't want to change them. That is two problems: 1) I can't improve it because I might mess up the other project's mainspace and 2) I can't even see that the page is in use elsewhere. Another problem is that fr has corrected the work! There is only one case but it is not something we do on la.ws: s:fr:Page:Satires d'Horace et de Perse.djvu/303 (changing dans le tribu Véline in the original to dans la tribu Véline). We can only fix this on fr and the editors there may object. These are just a few of the many problems one encounters.--Doug 09:57, 16 August 2011 (UTC)[reply]
More coordination is always a good thing; I just wanted to say that the decision to open subdomains has been taken long time ago and with good reason. I don't think that Commons is a good example, it's always failed to involve users of all languages and/because it's impossible to make it truly multilingual; and this despite having the obvious advantage over Wikisource that images are (usually) not language-dependent and that most of the content is self-published and in a CC license (which is more or less the same worldwide). --Nemo 10:20, 17 August 2011 (UTC)[reply]
en: I agree, coordination is a good thing but it shouldn’t be imposed in a authoritary maner.

fr: Je suis d’accord, la coordination est une bonne chose mais elle ne doit pas s’imposer autoritairement.

de: Koordination ist eine gute Sache, aber es sollte keine autoritär.

br: A-du on, kenurzhiañ zo un dra vat met arrabat bezañ re greñv.

it: Sono d'accordo, coordinamento è una cosa positiva, …

zh: 我同意，协调是一件好事，…

Beginning with the template is a very good idea. I just discover there was no interwikilink in this template anywhere. I add some of them on the french template (fr:template:Centré) but it’s a bit of a shame it wasn’t already done. Moreover, templates Center don’t use exactly the same code so odd behaviour may occur. So I think we must start somthing like Wikisource:Shared templates.

For me, another good point is to stop uploading files locally. Commons is a better place for files (especially for multinlingual files).

By the way, I think that the first phrase is a good example to prove that being truly multilingual is an hard thing! Merge all the projet like on Commons could solve some problems but it will create new problems too. In fine, I’m not sure it is a good idea. Moreover, with the breton wikisource, I’ve seen that since the project is independant it grows far much faster !

Cdlt/A galon, VIGNERON 23:56, 17 August 2011 (UTC)[reply]
I agree, I don't mean to suggest the re-consolidation of the projects (or at least not to argue for it), but rather that the subdomains cause issues that need to be recognized and addressed. You're right, templates are a mess and {{center}} (which apparently doesn't even exist here) on other projects is among the worst (some have the divs on above an below which creates padding, some are affected by indentation, some use the deprecated <center></center>, etc). I have taken to using a priority of choices: 1) wiki-markup, 2) html4.0/css, 3) templates. Using the latter only for convenience or when the html would make the page really messy, such as to underline individual words throughout a page.--Doug.^{(talk • contribs)} 10:30, 18 August 2011 (UTC)[reply]
So, where should we list these issues and take further discussion? It is already becoming too long here and Wikisource:subdomain coordination is just a big table, the talk page seems like a place to discuss whether the table is accurate, not how to make the process better. Shall we implement Wikisource:Embassy as suggested by User:OrbiliusMagister?--Doug.^{(talk • contribs)} 08:15, 25 August 2011 (UTC)[reply]

DougBot

Do I need to request permission to use DougBot here? The above job would be a small botable job, but others would occur if I start setting up works, which I intend to do. DougBot operates flagged on en.ws and la.ws currently and is a pywikipedia bot running a few custom scripts, mostly developed with help from Inductiveload.
Could I get a flag for DougBot?
--Doug 15:27, 14 August 2011 (UTC)[reply]

What job, sorry? --Nemo 10:17, 17 August 2011 (UTC)[reply]

ha! Sorry, I forgot to say what I wanted to do. I was going to use it to fix some links, but found there were fewer than I thought and fixed them by hand. I use the bot on en.ws and la.ws to bot in the ocr and then clean up the work, removing stray characters and applying standard formatting to an individual work that I am working on. I find this greatly aids in proofreading, especially with poetry as most of the formatting can be bot-ed in and one must only check for spelling and the like. I also use the bot to run reports, so it may write to my userspace, particularly reports on backlinks. I can use the bot for more general replace.py jobs but on en.ws and la.ws this is normally only on request. At the moment, I am intending to set up several of the shorter works of Hermann Hesse, which are out of copyright in the United States but still in copyright in Germany, thus they must be hosted here until about 2033. Thanks.--Doug.^{(talk • contribs)} 10:48, 17 August 2011 (UTC)[reply]

I have seen Doug's work on the English and Latin Wikisource using a bot. He does a good job. I think he should get the bot flag. He would use it responsibly. --Mattwj2002 23:16, 19 August 2011 (UTC)[reply]

If there are no objections, I will begin using my bot unflagged at slow speed. My bot always works supervised and is normally formatting works or making other edtis to works I will be working on shortly, if not already.--Doug.^{(talk • contribs)} 14:54, 24 August 2011 (UTC)[reply]
No objection from me. Yann 16:56, 27 August 2011 (UTC)[reply]
Support bot flag. John Vandenberg 08:06, 24 September 2011 (UTC)[reply]
Sorry for being late, I support this request too Candalua 20:49, 19 October 2011 (UTC)[reply]

Closed: A clear consensus. The bot flag has been given. --Ooswesthoesbes 18:57, 23 October 2011 (UTC)[reply]

Annotations?

Hi all,

Here’s a translation of what we have on the French « Qu’est-ce que Wikisource ? »

There are a few possible cases of non-neutrality: as long as we faithfully reproduce and cite text, we don't violate the principle of neutrality. In contrast, highlight parts of a text, or copy only a portion can be considered as a point of view. We aim the sober presentation of full texts.
Introductions and explanatory material in the most general case are not accepted, but if it is necessary to have them, they should always be written in accordance with this principle.

</Translation>.

We intend to create a system in order to accommodate annotations on Wikibooks and texts without notes on Wikisource, offering readers a button to see the text and the notes or the text alone. It hasn’t been done yet. And you, have you tried some solutions like that? I believe ThomasV has been making something of the kind but hasn’t achieved it as far as I know. We were looking for some means to show different notes in different colors when the annotators were multiple. -- Try Options d’affichage here in the left menu-- We wonder if this might be a possible tool. Any ideas? -Zyephyrus 09:00, 16 August 2011 (UTC)[reply]

We are discussing similar topics at s:en:Wikisource talk:Annotations and other pages listed there and User:Inductiveload has made a script to change all interwikilinks to black so they won't show unless you mouse-over them; though it has not yet been adopted. I have also noticed a mention of annotations by User:Dovi at Wikisource talk:Subdomain coordination and wonder what system they have at he.ws. I think it would be good to make regular notes here about the progress of this on different projects so we can all learn from each other.--Doug 09:41, 16 August 2011 (UTC)[reply]

Hi, to answer your question, we have a special namespace for annotated texts at Hebrew Wikisource. Dovi 16:56, 18 August 2011 (UTC)[reply]

Thanks, Dovi. How does it work with pages for which you have scans? Do you subst them into the annotations namespace? Do you copy over formatting and then do the annotations? Could you provide some links to some good examples?--Doug.^{(talk • contribs)} 23:16, 19 August 2011 (UTC)[reply]

Hi, I more or less answered these kinds of questions in the parallel discussion here. It would be great to see further discussion, and I'd be pleased to help in any way possible. Dovi 18:10, 22 August 2011 (UTC)[reply]

Oh, thank you! I had missed your comments there until you mentioned them here.--Doug.^{(talk • contribs)} 08:44, 23 August 2011 (UTC)[reply]

You're welcome. I added a further point and some examples too. Dovi 21:34, 23 August 2011 (UTC)[reply]

New Script to Display Language Sidebar Links to Old Wikisource

As a follow up to the discussion above: User:Kingpin13 and I (well, mostly Kingpin), have developed a script to display language sidebar links to old wikisource. Three things are required: 1) the script, 2) an extra language link (I recommend an Arabic link at the top of the list with a note so that it won't be accidentally removed) on the page you want the link, and 3) a line of html in the form: <span class="interwiki-oldws" id="ar1" title="Foo" style="display:none;"/>, where "Foo" is the full page name (page name and namespace) for the target page here. This could of course be templatized but I am leaving the instructions showing the html to avoid issues with translation of templates, etc. Full documentation is here. The script is currently in the common.js on both en.ws and la.ws and links are showing on the main page and scriptorium of both subdomains. Note that you will initially see two Arabic links, the first of which should quickly be replaced by a link to "Old Wikisource". The script is fully compatible with ThomasV's script (used with {{Interwiki-info}} on several projects) to add notes after language links, so long as you don't try to declare the same links as having both a note and a link to here; if you do, the link to here will take precedence.--Doug.^{(talk • contribs)} 10:10, 18 August 2011 (UTC)[reply]

Well, thanks for the effort, but honestly I don't like it. This "fake interwiki" will probably interfere with interwiki bots. Moreover, it looks like there's an easier way to achieve this. Any link like [[oldwikisource:Foo]] renders in html as: <a href="http://wikisource.org/wiki/Foo" class="extiw" title="oldwikisource:Foo">oldwikisource:Foo</a>. So maybe you can just look in the content body for every a.extiw node with title beginning with oldwikisource, move it to the sidebar and modify it to make it look like an interwiki. (Anyway, the best solution at all will be to fix it at bugzilla, but...) Candalua 11:15, 18 August 2011 (UTC)[reply]

Well, I have an interwiki bot too and they are not easy to run on wikisource for many other reasons that are a lot more of an issue than this script. I welcome improvements to the script and easier ways to do this but I think you'll find that it's not easy to simply "move [links] to the sidebar", at least not the language sidebar. But if you can do it, please do.--Doug.^{(talk • contribs)} 12:19, 18 August 2011 (UTC)[reply]

Look here! You'll see that using jQuery helps a lot! :-) This script creates the "other languages" section if there isn't one, then finds every link to oldwikisource and moves it to the sidebar. Now I will do some more testing, if it works well I think I'm going to put it into Wikisource:Shared scripts. Candalua 13:32, 18 August 2011 (UTC)[reply]

Excellent! Well, I'm glad I inspired you at least! ;-)--Doug.^{(talk • contribs)} 14:45, 18 August 2011 (UTC)[reply]

In Wikisource:Shared scripts you find OldwikisourceInterwiki.js with instruction to install. There's just a small problem, that [[oldwikisource:Foo]] and [[:oldwikisource:Foo]] produce the same result, so with this script will not be able to use plain inline links. On MediaWiki:OldwikisourceInterwiki.js I suggest some workarounds. The best solution at all will be to have a mul: prefix like proposed in bug 13334 Candalua 09:35, 19 August 2011 (UTC)[reply]

Of course, but talking about the bug is not particularly useful; unless we can get the kind of response that came up (finally) re the babel extension. For the time being, even that still requires a work around as is used on meta and la.ws.--Doug.^{(talk • contribs)} 11:15, 19 August 2011 (UTC)[reply]

Hmm, I don't like this. The replacement of links in the form [[:oldwikisource:Foo]] is a critical error. This should not be implemented. Also because it has previously not worked we'd need to search for old links in the wrong form and make sure they were correctly formatted for their intended use. My method, although awkward and possibly a problem for your bot is at at least an express solution that doesn't affect old links in the wrong form and gives a workable link. I also think the bot problem can be easily worked around.--Doug.^{(talk • contribs)} 12:40, 17 September 2011 (UTC)[reply]

I have developed simpler script - pl:MediaWiki:Gadget-iw-fixer.js. It replaces links to a certain languages with link to oldwikisource. It does not affect the way the link is displayed (be it inline or interwiki). I plan to put it in pl:MediaWiki:Common.js on pl.wikisource. Beau 06:38, 21 August 2011 (UTC)[reply]

Iwpage problems and thoughts

See my comments here for background: s:la:Vicifons:Scriptorium#Questions_about_multilingual_works_and_template_iwpage

Iwpage looks like the best thing we've got at present to many but I am finding more and more problems.

when I tried to set up an English/Latin work it became more trouble than it was worth to get the formatting the same and the previously applied formatting on en.ws is going to have to be ditched (though that wasn't very far along, there are examples from fr that appear much worse). The same templates don't exist on each project, when you import them then you find there are significant differences in css, etc.
following on the above, some projects allow annotations, others do them actively, others prohibit them. If the work is annotated, it will come through annotated. To change it, you have to go to the other subdomain, which leads to the next problem
above I was speaking of so called "user annotations", but many works have published annotations that are PD and indisputably belong on a wikisource project; however, often the works are written in one language but annotated in another or the work is a side-by-side (or over under) work in which only one language is annotated. There are also mixed pages in many works.
the scans may be supporting works on multiple projects. Frequently the side-by-side translation is the best scan available in the original language. If you set it up to fit the original language subdomain and then someone changes it to match a use through iwpage, or vice versa, there may be damage done to mainspace works.
many projects have {{iwpage}} but not so many have {{iwpages}} or {{iwpageSection}}. Without the latter two, they cannot transclude the work to the mainspace. None of these templates are not well documented.

My suggestion is that the best practice is to avoid all use of {{iwpage}} and kin and instead, transcribe locally (or import and format to local standards) all pages that will be transcluded locally into the mainspace. I don't like the idea of transcribing twice (though import saves a lot of work) but I believe this may be simply a cost of subdomains.

I would be happy to move this discussion to Wikisource:Embassy if we want to create such a page. Though traffic would likely be even further reduced.

Thoughts?--Doug.^{(talk • contribs)} 12:54, 25 August 2011 (UTC)[reply]

All the trouble you are pointing comes from the fact the work has been done first on the wrong wikis. It's perhaps a bad idea to import existing works, except if the importer do all things needed by the import, fixing template and comply with local rules but besides that I doubt it's a good idea to increase so much the amount of work to do on bilingual works. Note I'm talking about works with even pages in a lang, odd pages in a second lang. — Phe 16:31, 25 August 2011 (UTC)[reply]

Although you are right that #1 involved a couple of pages begun on the wrong wiki, it is still a lot of trouble to get the two to match and would have been trouble had it been started on two wikis using {{iwpage}} from the beginning. #2 doesn't involve works started on the wrong wiki at all and actually is a special case of a broader class where the style or other rules on one wiki won't allow the content that is on the other wiki (or will allow much more but it can't be added on the other wiki where it belongs). #3-5 also have nothing to do with works started on the wrong wiki; 3 & 4 are simply cases of inflexibility in the template and case 5 has to do with the templates not existing on wikis at all. Importing a work isn't much of a problem because, unlike the use of only local crats can give local importer rights, so the importers should know how to set the work up according to local practice and if they don't they can answer to their local community. The sending project loses nothing. Additionally, some of the works I mentioned on the thread on la.ws are actually french at the top and latin at the bottom of the same page (or vice versa, I don't remember).--Doug.^{(talk • contribs)} 17:43, 25 August 2011 (UTC)[reply]

An alternative (and possibly preferable) way to set up a multi-lingual work: fr:Chansons_populaires_de_la_Basse-Bretagne/Bilingue. Though this would require more coordination between projects than is often found.--Doug.^{(talk • contribs)} 06:22, 26 August 2011 (UTC)[reply]

Wikisource:Copyright policy updates

I just made 2 major updates to Wikisource:Copyright policy and one minor one:

references to GFDL updated to reference CC-BY-SA
reference to works that are PD only in the US added
spellings standardized for some words that were inconsistent

I'm posting here due to the low traffic on this site.--Doug.^{(talk • contribs)} 13:41, 26 August 2011 (UTC)[reply]

Looks good. Thanks, John Vandenberg 08:05, 24 September 2011 (UTC)[reply]

Author namespace

The Author namespace is not a valid namespace on old.ws. That's problematic. Shall we "make it so"?--Doug.^{(talk • contribs)} 08:51, 27 August 2011 (UTC)[reply]

I'm not (yet ?) an active contributor on "this" WS, but I think that separating the Authors from the Texts can only be a GOOD thing : easier to search, easier to maintain, no confusion between the Author's page and a text which Title is the author's name - and more accurate statistics :) --Hsarrazin 10:04, 27 August 2011 (UTC)[reply]

En: As you can see on Wikisource:Subdomain coordination, there is a lot of Wikisources without Author namespace. And (for me) that’s a really bad thing (I agree with Hsarrazin). Especially for big Wikisources like old or de. We can’t do anything for de, but it will be a good to do create it here (with aliases will be great).

Fr: Comme vous pouvez le voir sur Wikisource:Subdomain coordination, il y a de nombreuses Wikisource sans espace de noms Author. Et (selon moi) c’est une très mauvaise chose (je suis d’accord avec Hsarrazin). Particulièrement pour les grosses Wikisources comme old ou de. On ne peut rien faire pour de, mais ce serait bien de le créer ici (avec des alias se serait génial).

Cdlt/A galon, VIGNERON 11:22, 27 August 2011 (UTC)[reply]

I completely agree Candalua 15:41, 27 August 2011 (UTC)[reply]

bugzilla submitted.--Doug.^{(talk • contribs)} 07:36, 3 September 2011 (UTC)[reply]
- Done [3]; they put it at ns:108, even though 102 was open, so 102 remains available. I only asked for the namespace in English; I did not ask for aliases because I didn't have any idea how many to ask for or which languages. It seems that since the languages that are most used here are the ones without subdomains, someone would have to specify what the proper word is in languages like Singhalese, Gaelic, etc. If someone would come up with a list, I'd be happy to file a new bugzilla.--Doug.^{(talk • contribs)} 18:03, 7 September 2011 (UTC)[reply]

Well done. How do we proceed now? Do we want to move all author pages to Author:? For the aliases, let's add them below: Candalua 22:19, 7 September 2011 (UTC)[reply]

Those that were named "Author:Foo" were automagically moved, after a slight hitch, by the dev who handled the bugzilla. If we have others at what will become aliases, I think the best would be to manually move them to a holding area unless there are a lot.

I suppose we need the aliases for existing subdomains too, since works that are PD in the US only (under the pre-1923 rule) have to go here still, absent local policy.--Doug.^{(talk • contribs)} 05:28, 8 September 2011 (UTC)[reply]

I’ve add some local aliases. There we’ll be a little problem for some author like : Victor Hugo, how to deal with the same name in différent languages ? Currently the page Victor Hugo is in Volapük ! (nothing against the Volapük but very strange to see this french author here).

Should there not be a meta-cat for all the author cat ? (like Category:Main Pages for the Main pages).

Cdlt, VIGNERON 16:37, 8 September 2011 (UTC)[reply]

Good point! I guess an important question is "is this author page created primarily for current navigation or for eventual migration?" If it's for future migration, then separate author pages are necessary for each language in which we hold works, but only those languages, thus a French version of Author:Victor Hugo is unnecessary but a French version of Author:Hermann Hesse is needed and there should be no english author pages as all english works can be on en.ws. If for current navigation, we should develop a style for language information, possibly either with /en format or with a css solution to display one's preferred language but contain code for all languages (ideally). The former exists on el.ws, the latter exists on some meta pages and is an idea that I'm developing for use on la.ws.

I am not sure what the best method is for tracking via cats and I'm not sure what your plan is but I think there needs to be a common language category in order for everyone else to find them.

We should keep in mind that some languages may never have their own subdomains and there may be times when no one who is literate in the language is available.--Doug.^{(talk • contribs)} 08:25, 9 September 2011 (UTC)[reply]

List of aliases of Author

Occitan: Autor
Belarusian / Беларуская: none yet ? (but there is a cat : Category:Аўтары)
Georgian / ქართული : ავტორი ? (cat : Category:ავტორები)
Hindi / हिन्दी: none yet ? (the only page Author I found seems to be ओ हेनरी)
tatar / татарча: non yet ? (cat. Category:Авторлар is unempty but doesn’t exist !)
Volapük : none yet ? (cat : Category:Lautans)

Main page variants

I stumbled across some moves of navigational pages to Singhalese today and raised the issue here: User_talk:Singhalawap#language_categories_and_main_page_variants. I noted that there were two variants of the Main Page in the form Main Page:Foo and pointed this out to the editor but I then discovered that this appears standard on here (see prefix=Main&namepsace=0). Why do we do this? Main Page:Foo would be for a namespace called Main Page:. The standard method (prescribed on meta and used on subdomains such as el.ws, which has its mainpage in three languages) is Main Page/lang. Thus Main_Page:සිංහල should be Main Page/si, I believe. It would seem problematic, or at least confusing, to have a pseudo namespace for mainpages.--Doug.^{(talk • contribs)} 20:40, 5 September 2011 (UTC)[reply]

Hi, This is history. It was created that way in 2004. Yann 07:32, 6 September 2011 (UTC)[reply]

Sure, but why do we keep it organized in this way?--Doug.^{(talk • contribs)} 07:51, 6 September 2011 (UTC)[reply]

No, because it’s not “organized” right now. Problematic point #1, some main pages are in this pseudo-namespace but some are not (eg. Tuisblad) and worse (#2) some are not even categorized in Category:Main Pages (eg. НапэкӀуэцӀ нэхъыщхьэ:Адыгэбзэ where I just add the category today). finally (#3), in the history of oldwikisource, it seems to allways been an unorganized mess : Category:Old Main Pages.

There is 3 solutions : ask to create a real namespace (again, the devs will hate us :D), persist the statu quo existing mess, create subpages.

I like subpage system (simple and easy to create or to maintain) but I dont like the ISO code. Could be redirection a solution ? Eg. Main Page/si redirecting to Main_Page/සිංහල.

Cdlt, VIGNERON 17:01, 8 September 2011 (UTC)[reply]

I like the idea of using the subpages for the reasons VIGNERON states plus it's the meta standard and is in use on some of the subdomains (I am not aware of any that use a different method, they either use the meta method or none at all). I also have no objection to VIGNERON's redirect suggestion as the languages should show in the native form (though maybe it should redirect to the phrase "Main Page" in the respective languages - thus, from the example above, НапэкӀуэцӀ нэхъыщхьэ:Адыгэбзэ is moved to НапэкӀуэцӀ нэхъыщхьэ/Адыгэбзэ with a redirect from Main Page/ady - we might use the form Main Page/Адыгэбзэ as a temporary solution if we can't determine the proper words for "Main Page" in that language but it wouldn't seem to have much utility normally and I don't think we'd need it as a standard redirect).

I would not support a namespace unless the languages themselves were the namespaces, e.g. "/wiki/si:Main Page" (arguably the way all language subs should've been done in the first place).

The status quo is the worst possibility.

--Doug.^{(talk • contribs)} 08:08, 9 September 2011 (UTC)[reply]

I like the subpages approach. I do prefer ISO language codes, but I do not mind if the ISO code is only a redirect. John Vandenberg 08:02, 24 September 2011 (UTC)[reply]

Template licensing and categorization problems

In addition to the above noted mainpage variants, I found many pages categorized inappropriately into Category:සිංහල, such as navigational templates and pages that were not in Singhalese and were unlikely to even be used on Singhalese works - but even if they were, certainly weren't peculiar to them. There were also three variations of the mainpage, only one of which was Singhalese. On further investigation I found that a number of the templates appear to have been copied from other projects without noting where they came from (without even an edit summary). This is problematic as templates are more licensing significant than most of the texts we work with here (since most of the works themselves are PD and the formatting isn't itself copyrightable). Several are identical to those on en.ws and other projects and were created with a single edit. They should have been imported or at least have said where they were were copied from, preferably with a permalink to the edit copied from.--Doug.^{(talk • contribs)} 21:25, 5 September 2011 (UTC)[reply]

You can always add that information if you want. Eclecticology 07:39, 6 September 2011 (UTC)[reply]

Request for Transwiki Importer rights

I request transwiki importer rights. I have am working on several works that require templates from other subdomains. I'm making repeated requests for admins to import these for me and there aren't very many admins to bug about this. I am a trustworthy user, being an admin on three projects, and I have experience with the tool, having used it a lot on la.ws and some on en.ws.--Doug.^{(talk • contribs)} 12:31, 17 September 2011 (UTC)[reply]

BTW, I understand that this right can only be granted by stewards for reasons that don't make a lot of sense for the wikisource family, still consensus here will be necessary and I will start a thread proposing this authority be given to crats here.--Doug.^{(talk • contribs)} 10:01, 18 September 2011 (UTC)[reply]

Support Doug is very good at making cross-domain and multi-language works work well and is very careful to ensure compatibility, I'm sure he can use this tool effectively here as he has on laWS. Inductiveload 13:38, 17 September 2011 (UTC)[reply]

Support Candalua 11:05, 19 September 2011 (UTC)[reply]

Support John Vandenberg 07:56, 24 September 2011 (UTC)[reply]

Strong support (but you will have some surprise, $wgImportSources is not allways well defined) VIGNERON 12:02, 25 September 2011 (UTC)[reply]

Support. —An gr 21:32, 6 October 2011 (UTC)[reply]

Discussion closed. No objections, so we agree. You can ask for your importer rights at meta:Requests for permissions. --Ooswesthoesbes 18:58, 23 October 2011 (UTC)[reply]

And rights granted by PeterSymonds. Thanks.--Doug.^{(talk • contribs)} 09:18, 24 October 2011 (UTC)[reply]

Proposal to grant crats the ability to promote to unbundled sysop rights

As I understand, currently, crats can promote to sysop but cannot grant some unbundled rights, most importantly Transwiki Importer. I propose we authorize (and submit bugzilla to enable) crats to grant all unbundled rights that are normally part of the bundled sysop rights. Transwiki Importer is particularly important on wikisource as our projects are more closely tied than wikipedia's, being rather different sections of the same vast library. Frequently Transwiki rights are needed to import templates or to import pages of transcribed multilingual text. For example, I have frequently imported (as an admin) latin text from fr. or en. to la.ws and I have many more pages to do so with. I have also made very regular, nearly continuous requests to admins for imports of templates here and with the very small number of admins this is slow and probably wears on their patience (many of my requests have been made via IRC and don't show here and several are waiting for the current requests to be acted on); thus I requested the rights above. Additionally, there are many users on the various projects, who, like myself, don't do much vandal work and only occasionally see a need for a deletion, but frequently need to import. Sometimes these are highly trusted users on other sites but are only involved in a small issue locally and don't warrant sysop privileges and they need the rights quickly. So, the proposal again: --Doug.^{(talk • contribs)} 10:11, 18 September 2011 (UTC)[reply]

That bureaucrats shall be authorized to grant all unbundled rights that are normally part of the bundled sysop rights and that a bugzilla shall be submitted to enable this right

To further clarify, this would appear to include only transwiki importer group, which holds only the importer right. The associated importer group has an additional right (importupload) that admins do not have and thus is not included.--Doug.^{(talk • contribs)} 03:55, 19 September 2011 (UTC)[reply]

I think it would be better to establish a temporary sysops program. John Vandenberg 07:57, 24 September 2011 (UTC)[reply]

Well, the thinking was that this would be for people who are here regularly enough to need permanent rights but maybe not regularly enough or not long enough to be a permanent sysop. Basically, just like my own request above. My understanding was that temporary sysop was available anywhere - I was unaware that there are projects with policies or procedures around them, if someone has examples, I'd like to take a look as I certainly don't object to such a plan. I also want to further clarify that there is no intent here to unbundle rights that aren't currently unbundled, only to make transwiki importer awardable locally, which, I think, is valuable in its own right. Why we would want to go to a steward to get a right awarded that is just a component of the admin package is completely beyond me.--Doug.^{(talk • contribs)} 15:42, 25 September 2011 (UTC)[reply]

Image filter

A meta RFC draft (started by me) about the image filter can be found at meta:Requests for comment/Image filter on Wikisource. --John Vandenberg 08:00, 24 September 2011 (UTC)[reply]

Wikibooks/Wikisource triage

As Wikimedia Foundation's Bugmeister, I'm going to be holding a bug triage on IRC this coming Wednesday, September 28. The purpose of this meeting is to discuss and prioritize issues on the Wikibooks/Wikisource projects within Bugzilla, raise awareness in the WMF so we can try to be more supportive, and coordinate volunteer developer's efforts so they will be more effective.

The meeting will be held in IRC, so you're participation is requested.

Where	When
#wikimedia-dev or freenode's webchat	1300UTC, 2011-09-28

If there are issues in bugzilla or on the wishlist that you think it is important that we cover, please add it to the etherpad. -- MarkAHershberger 00:18, 25 September 2011 (UTC)[reply]

How to ask for a translator/transcriptor in a foreign (non latin) language

Hello,

I hope this is the right place to ask the question : when, in a book, there is a part of the text in another (non latin) language, it is generally very difficult to find someone to "transcript/correct" the text on the original WS of the book (fr in my case). Is there a system, or a place, to ask for a person who can help to "finish" the book - going on the WS of the foreign language concerned (arabic for example) is obviously of no help, because it is impossible to understand the contributors of that site (and even to understand where to go on the site) ;) - thank you for your help --Hsarrazin 06:45, 25 September 2011 (UTC)[reply]

There was some discussion (cf. supra) about create an « embassy ». It was not create yet (hopefully, it will be soon).

Otherwise, there is the babel system that can help a little (but babel is for language and there is nothing about the script).

Cdlt, VIGNERON 07:36, 26 September 2011 (UTC)[reply]

You both users of fr-source should know it :) because fr:Catégorie:Mots manquants is a very good aproach. I would try to contact someone of the "other" Wikisource for suggesting to add a link to the specific category and wait for any interested user (e.g. "we need your help at fr.source; look at fr:Catégorie:Mots manquants en arabe" in some ar-source community page).

One question about multilingual books: Imagine a 500 pages book in e.g. French, and just 1 page is in a foreign language, e.g. in Arabic: I would transcript that page also at fr-source without creating a whole book at ar-source. The same if Arabic pages are 5 or 10. But, what to do if they are 50? Do we have to create 450 empty pages at ar-source? And 100? Should we stablish some standar of threshold for using iwpage? If we have separated domains and the main difference is the language (fr, ar, etc.), then it is uncomfortable to have texts written in a language that "belongs" to the other domain. Iwpage is a good aproach for a 50% bilingual book but it is odd for other percentages, isn't it? -Aleator 14:56, 30 September 2011 (UTC)[reply]

See discussion above about serious problems with iwpage. You can't assume the other subdomain will transcribe the work or even accept it (viz. de.ws strict scope and other rules). It also means that your work which was intended by the author to be a unified bilingual work, is now subject to changing formats and templates at different sites. I recommend using babel to find a local user who knows the language in question or posting in a common language (French, English, Spanish) on the other subdomain asking for help on your home wiki. Many native speakers of Arabic know English or French well enough to explain the problem.

As for the embassy. I'm waiting for us to have a plan for what it would do. If it's just a list of users and the languages they speak as it appears to be on meta, then I don't really see the point. Such lists are usually badly out of date and looking for an active user with appropriate babel templates is normally easier. If, however, the embassy would be used for actual discussion of inter-language issues, then it could be very, very valuable.--Doug.^{(talk • contribs)} 10:10, 1 October 2011 (UTC)[reply]

It’s seems obvious to me we shouldn’t do just a babel-like list of people. You could see lot of examples on m:Wikimedia Embassy, there a lot of people lists (but people involved, not just a list of speakers) and some places to talk.

For me, this embassy could be something beetween a translation projet (for the “languages” side) and the Wikisource:Subdomain coordination (for the “technical” side). Indeed, I see this more as place to link people from differents wikisources than a place to talk. But there some talk to have to (for instance : how to deal with multingual books ? @Aleator : 50 % is not a very good indicator ; eg. this book s:br:Collocou Gallec ha Brezonnec is 50% french and 50% breton but there is no way to put french on fr.ws and breton br.ws)

Cdlt/A galon VIGNERON 12:48, 5 October 2011 (UTC)[reply]

@VIGNERON: Well, isn't it? The french is on fr.ws and brought over with {{iwpage}} the same way this was: s:la:Liber:Horace - Œuvres, trad. Leconte de Lisle, II.djvu done, so I'm not sure what you mean; however, I don't think either one is a good idea. {{iwpage}} is squirrely enough without splitting pages. I've pointed out elsewhere my dislike for the process but when used to split a page the potential for the work being ruined by changes on one subdomain are multiplied many times over and the ability to fix such problems complicated by all the extra code in the pagespace. The gain is minimal. And on some subdomains it's simply not allowed (you could not create a German/French or German/English or German/anything book on de.ws in excess of 50 pages without permission and you'd have a hard time getting permission.

This is the darkside of subdomains and why they should have been done as namespaces instead of subdomains long ago - but what's long done is long done. Hopefully an embassy can help to address such issues and I very much support the concept if we can make it useful. I am particularly leery of a list as it becomes impossible to maintain. We didn't even have an accurate list of administrators or bots until today and the latter hadn't been updated since 2005. If it's a center of discussion, then it could be useful.--Doug.^{(talk • contribs)} 13:24, 5 October 2011 (UTC)[reply]

Non-source text pages in mainspace

What is this project's policy on mainspace pages that are not actually sourced documents? I just came across Greek numeric, which was apparently imported here from somewhere, probably some Wikipedia page, and which had some old vandalism by a banned cross-project vandal sitting in it uncorrected for several years. I fixed the worst of the misinformation, but I can't figure out why this page is even here. Fut.Perf. ☼ 19:25, 4 October 2011 (UTC)[reply]

As you can see when looking at the category attached to the page it is part of the Coptic test project and the "wrong" symbols used were probably Coptic. --Ooswesthoesbes 03:16, 5 October 2011 (UTC)[reply]

No, actually, they have nothing to do with Coptic. They were part of a cross-project campaign of systematic falsification by banned user en:User:Wikinger (see en:Wikipedia:Long-term abuse/Wikinger). The person who created this page accidentally copied its contents from a source that had been contaminated with the Wikinger nonsense, probably from this talkpage post (which came from the vandal's IP). Okay, that is sort of fixed now, but I'd still like to understand how and why such a page is even considered in the scope of this project, because it's clearly not documenting a published public-domain source document. Isn't that what Wikisource is all about? Fut.Perf. ☼ 07:17, 5 October 2011 (UTC)[reply]

P.S.: I now notice Greek alphabet for Coptic has the same problems. It's also copied straight from the same Wikinger talkpage post. It's complete nonsense. It's most emphatically not anything to do with authentic Coptic, but a mad "original research" concoction by the vandal. And, again, it doesn't even pretend to be an actual Wikisource content page. Don't you have some kind of mainspace/projectspace distinction here? Fut.Perf. ☼ 07:28, 5 October 2011 (UTC)[reply]

And more: Νιραν ΄ντε νι΄αβοτ. This one is fortunately free from Wikinger vandalism, but it also doesn't seem like a legitimate Wikisource page. It's just a table of month names of the Coptic calendar. Would be great for a Wikipedia article on the Coptic calendar, but what's it doing on Wikisource? Fut.Perf. ☼ 07:57, 5 October 2011 (UTC)[reply]

I agree, these are out of scope for mainspace on any wikisource and should be deleted. They have been around a long time and apparently nobody ever really noticed them. They may be suitable for project/user space but really should be deleted. If sourced they'd belong a pedia not here as ws is for the source itself as you correctly point out. The source for these, if found and if PD, would appear to belong on en.ws as they appear to be intended for English speakers based on the notes, though that would depend on the source; but again, that's just theoretical, the works are not source works and should be deleted.--Doug.^{(talk • contribs)} 09:44, 5 October 2011 (UTC)[reply]

Tagged and deletion proposed at Wikisource:Proposed_deletions#Out of scope greek/coptic reference pages.--Doug.^{(talk • contribs)} 10:06, 5 October 2011 (UTC)[reply]
- Thanks. Fut.Perf. ☼ 10:33, 5 October 2011 (UTC)[reply]

can I "steal" some texts?

Hi folks. On Italian Wikisource we already host many texts written in vernacular languages spoken in Italy, like Sardinian (and its varieties). In order to have all texts in these languages in a same place, I would like to move to it.wikisource these texts in Sardinian, and then delete them from here. If you know of any reason against doing this, speak now or forever hold your peace. :-) Candalua 21:20, 12 October 2011 (UTC)[reply]

I'm not pro. Sardinian has its own code and therefore should get its own subdomain. All pages in Sardinian should be on the oldwikisource (here) and in the Sardinian category. --Ooswesthoesbes 17:04, 13 October 2011 (UTC)[reply]

In theory you're right. But in the past years no one has actively tried to get a subdomain. And moreover, these texts are written in different varieties of Sardinian, that have different language codes, and, depending on the rules of the new hypotetical subdomain, some of them could even be rejected from it. The policy of it.wikisource is to accept all vernacular texts from the Italian-speaking area, and recently I've created a portal dedicated to vernacular texts to give them more visibility. Here, these texts are simply lost in this babel of languages. But anyway, we can simply leave the texts here and create duplicates on it.source. Candalua 18:45, 13 October 2011 (UTC)[reply]

That would indeed be a good solution. I can understand the Italian policy and indeed it would make the texts more visible, but they should at least remain here, because interest for a Sardinian subdomain can arise at any moment. --Ooswesthoesbes 05:07, 14 October 2011 (UTC)[reply]

I support the referenced works being moved to it.ws. Candalua makes good arguments for the works being at it.ws and if they are within scope there that's not our business to interfere with. The argument that a subdomain could be desired at any time could just easily be raised (and probably would be a lot more likely to be discussed thoroughly and to even come about) at it.ws. Keeping the works here is not within the normal scope since they are apparently within scope of a subdomain and thus in theory out of scope for us - as I understand the general theory of mul/old wikisource scope. On the other hand, I don't favor so limiting our scope, so I don't object to a deviation in this case. BTW, Middle English and Old English have their own language codes, but both are hosted at en.ws not here (though ang was once a separate project) or for a 'living language', I'm pretty sure de includes gsw in ~~it's~~its scope.--Doug.^{(talk • contribs)} 08:05, 14 October 2011 (UTC)[reply]

Actually, they are not within scope of that subdomain; the subdomain thinks they are. Sardinian, unlike Old English, is not a dead language and can therefore still get a subdomain. If someone would include Dutch texts at li.wikisource, because Limburgish people can read Dutch, would that be a reason to delete the texts at nl.wikisource? In my opinion, the pages should remain here, but can be copied to or linked from it.wikisource. --Ooswesthoesbes 13:35, 14 October 2011 (UTC)[reply]

Again, no complaints with it staying here. I'm not sure it's within our competence to state what is or isn't within the scope of an existing subdomain, except to the extent that we might be aware of consensus there. But again, I don't have a problem with duplication.--Doug.^{(talk • contribs)} 13:54, 14 October 2011 (UTC)[reply]

I did a little research about how to do the import or who to ask. I found nothing useful, even on meta. But then one of my fellows at it.wikisource suggested that we could just use interwiki transclusion, so here we are :-) And there's also the added value of side-by-side comparison (try to click on the ⇔ icons on the left in one of the texts) Candalua 19:23, 14 October 2011 (UTC)[reply]

Well, you know what I think about interwiki transclusion, but I guess if you're on both sides of the transaction it doesn't make much difference and the downside is all to it.ws so it's your problem ;-). Transwiki importing is easy if you have the sources set properly, upload importing is another story. If the transwiki sources aren't set up it can be weeks to get a bugzilla actioned (or hours, it just depends); so if you don't have the multilingual wikisource as a source on it.ws, you may want to submit a bugzilla anyway. --Doug.^{(talk • contribs)} 19:59, 14 October 2011 (UTC)[reply]

~~BTW, I can't see anything at that link.--Doug.^{(talk • contribs)} 20:11, 14 October 2011 (UTC)~~the link was malformed (for here) and I didn't notice, it has been fixed--Doug.^{(talk • contribs)} 03:37, 17 October 2011 (UTC)[reply]

Hi! I can see OK the transclusions at it.source (Firefox 7.0). With IE 8 it shows some runtime error. MediaWiki_talk:InterWikiTransclusion.js#Iwpage_and_Internet_Explorer.

All the suggested actions (leaving it here, transcluding to it.source, moving to it.source, new subdomain, etc.) are OK for me. I'm not able to argue one more strongly than the others (except the new domain, because there is no active comunity, but it.source). -Aleator 14:25, 16 October 2011 (UTC)[reply]

Stale bots and sysops

Is there any reason that User:Wolfbot and User:CSNbot should remain flagged? Wolfbot made 2 edits in March 2005 (user page tests) and the owner, User:Wolfman, hasn't edited here since December 2005. CSNbot made 2 manual edits in August 2005 and the owner, User:CSN, hasn't edited here since September 2005. Both were proposed for de-flagging by User:-jkb- in 2009 (ref Scriptorium archive) but there was never further discussion or action.

Inactive bots can be risks because their edits are not normally seen in recent changes, they can perform a very large number of edits before they are noticed and if their owners are absent they aren't around to notice if their bot is hijacked nor to be asked about edits. If the user returns and wants to use their bot, they can easily request re-flagging.

N.B. with respect to Pathosbot, also mentioned in the archived thread, I contacted the bot's owner, User:Pathoschild, and he indicated that the bot is not flagged for purposes of editing, but for API Queries. Furthermore, the owners is active on this wiki and many, many others both as an editor and in his capacity as a steward. Therefore, I support that bot remaining flagged.

We might also want to look at whether User:ThomasBot needs to remain a sysop. The bot hasn't edited since September 2010 and it has been replaced on all Wikisources by User:Phe-bot for Match & Split functions. It is my understanding that sysops who are inactive for more than six months have historically been de-sysopped. We have four such admins, all of whom probably ought to be reviewed, and ThomasBot is the longest inactive of them.

I propose Wolfbot and CSNbot be de-flagged.--Doug.^{(talk • contribs)} 09:07, 13 October 2011 (UTC)[reply]

I support the deflagging of Wolfbot and CSNbot. Does anyone of you know anything about ThomasV, why he decided to leave, whether he will come back some day...? Candalua 19:56, 14 October 2011 (UTC)[reply]

Phe might know. I've seen his comments on Bugzilla and he pops in quickly now an then on IRC but says little. I think he's just semi-retired - or maybe just tired. I don't know if he's still an active developer or not, but if he is, it's in the background. Also, no idea how active he is on fr.ws if at all.--Doug.^{(talk • contribs)} 20:11, 27 October 2011 (UTC)[reply]

He is involving himself in projects outside of WMF. I would think that the rights should follow normal processes, and if the bit is removed, then ThomasV can easily step through the process to get it reinvigorated. billinghurst sDrewth 00:32, 31 October 2011 (UTC)[reply]

Although I'm not really active on wikisource, but I certainly support de-flagging of such bots on any wmf website, per the unsafety point given above. So, I support the de-flagging.--Siddhartha Ghai 20:07, 27 October 2011 (UTC)[reply]

deflag bots as identified in proposition. billinghurst sDrewth 00:32, 31 October 2011 (UTC)[reply]
With regard to bot flags, I would propose that we set an audit date, eg. 1 Dec each year, and if the bot hasn't been used in the 12 months previous that a request is made on the talk page of the bot operator about its operation, and if they request it continue then it can, if they don't it is deflagged after a month. Keep it simple. Getting them reinstated is not difficult, nor should be made difficult for operators and bots of good repute. billinghurst sDrewth 00:32, 31 October 2011 (UTC)[reply]

Deletion proposal for contents of transwiki pseudo space

Transwikispace contains 12 pages and 2 redirects. One is the standard redirect from Transwiki to the log. I have proposed the deletion of the other redirect and all 12 pages at Proposed Deletions.--Doug.^{(talk • contribs)} 14:07, 13 October 2011 (UTC)[reply]

Possible Copyright Violations

I just posted an entry at Wikisource:Possible copyright violations and noticed that there are discussions from last year that have not been closed or even discussed beyond the nomination. Could users please take notice of these and see if we can decide if these pages are violating copyrights - or, at least, decide that they don't have enough evidence that they're free? Thanks!--Doug.^{(talk • contribs)} 14:14, 13 October 2011 (UTC)[reply]

A user with fluency in the language of the work has responded and addressed the problems but admin action is needed to move over an existing page (and probably suppress the redirect), see: Wikisource:Possible_copyright_violations#2002_My_Belarusy_lyrics_contest. Thanks.--Doug.^{(talk • contribs)} 10:50, 19 October 2011 (UTC)[reply]

Line breaks in pages

When saving in Page: spaces, a line break is being inserted at the end of every page when transcluded. Do all of these pages have to be edited to remove this line break? See: "parecidas unas a otras segun la pronunciacion de los diferentes pueblos..." - Theornamentalist 20:58, 18 October 2011 (UTC)[reply]

Yes, it’s in many places: we have been told on the French scriptorium the bug has been found and will be corrected as soon as possible. --Zyephyrus 21:51, 18 October 2011 (UTC)[reply]

Thank you :) - Theornamentalist 21:57, 18 October 2011 (UTC)[reply]

For what it is worth, all the languages sites have this issue, all sites they will need to run a process through where the javascript of ProofreadPage is turned off and remove the errant line feed. I have covered a means to identify the pages and extract them from the AWB that is tuned for anyone with w:Wikipedia:AutoWikiBrowser. My stuff for this fix is at trim trailing LF. If a site does not have the ability to do the fix themselves, then I can look to run it for other language sites where the community requests and approves the maintenance to take place. billinghurst sDrewth 12:36, 25 October 2011 (UTC)[reply]

Just to keep trace, it's bug 26028 Candalua 14:38, 27 October 2011 (UTC)[reply]

Propose we request Billinghurst to run his bot here, flagged or unflagged, es macht nichts. If it were possible to give him global authorization I would say we should. Maybe a Steward could give him temporary global bot privileges or he could simply run unflagged on all subdomains but with a clearer edit summary stating that he's repairing a bug per discussion here, e.g. "cross-subdomain bot repairing bug 26028 per [[oldwikisource:Wikisource:Scriptorium]]". I know our right to authorize such a thing would be questionable but this is a broad technical bug and would seem to fall in the one time global bot run realm rather than saying, "well, if the (choose a language with a tiny subdomain) wikisource wishes to translate and discuss this and grant permission, he can run there". It's one of those w:IAR kind of things.--Doug.^{(talk • contribs)} 14:56, 27 October 2011 (UTC)[reply]

Support, absolutely. I fear that, since this bug requires a change in the source code, the correction will be live only with the next Mediawiki release... it could take months! We can't wait, in the meantime we need to fix it some way: if billinghurst can do it on all, or nearly all, subdomains, it would be great. On it.wikisource I'm already fixing with my bot, so it's already one less. Candalua 16:00, 27 October 2011 (UTC)[reply]

This sounds like a good idea. V85 15:46, 27 October 2011 (UTC)[reply]

Candalua, re your msg at enWS about using your bot, the api query and the replacement are at the above link. It is all simple. It has to be for me to both run the query and achieve the result. To note, that I have attempted to escalate the resolution. billinghurst sDrewth 21:20, 27 October 2011 (UTC)[reply]

Fix has been rolled out across the WSs. I am completing the repair job at enWS at the moment, and will do laWS later. I will look at the little wikis over the weekend, to even scope what needs to be done. From looking at the above commentary I have no need to look at frWS/deWS/itWS. If you positively want me to look at a wiki, or where there is no requirement, then please let me know here. billinghurst sDrewth 21:27, 28 October 2011 (UTC)[reply]

I have been through an identified the start and end conditions for the periods of interest. There were c.17k edited pages in the total Page: ns of these about 13k are in en/fr/de/it/la, which gives about 4k pages to update through the remainder. I will cycle through these with my bot account slowly, though not with a bot flag. The edit summary will point to the account subpage linked above. billinghurst sDrewth 12:27, 29 October 2011 (UTC)[reply]

User:Paulis/de:Benutzer:Pualis has taken care of this on de.ws using Billinghurst's instructions. de.ws was aware of the problem but not the cause nor the solution (viz. de:Wikisource:Skriptorium#zus.C3.A4tzliche_Leerzeilen_im_Footer). We managed to communicate on IRC but my German is ganz schlecht. This emphasizes the need for greater coordination and cross-domain communication. Maybe that embassy idea should move forward.--Doug.^{(talk • contribs)} 17:13, 29 October 2011 (UTC)[reply]

Could you also have your bot do :no:WS, please? V85 20:19, 30 October 2011 (UTC)[reply]

Yes. In the next day or so. I have been running it slower where it is not a bot, though maybe I should have multiple sessions running. billinghurst sDrewth 03:56, 31 October 2011 (UTC)[reply]

As user:SDrewthbot I have done (open account) sl/br/old/hy/pt/ru, (bot) la Others have done fr/de/it/pl/sv/da. Pending is es and that would require a bot account to run and I have a request at esWS. So we can consider this component

Done. billinghurst sDrewth 11:56, 1 November 2011 (UTC)[reply]

Problem with global login

I have recently noticed that when I follow links here I am not logged in. Oddly, if I follow a link from here to a subdomain, I am logged in there, without any further action, even one I haven't been to lately. If I log-in here and leave and then return, I remain logged in here. Is anyone else noticing this behavior?--Doug.^{(talk • contribs)} 10:37, 19 October 2011 (UTC)[reply]

Doug, with the relative protocols now in place, it may be that you have come across circumstance where you are switching between secure and non-secure, or similar. billinghurst sDrewth 12:38, 25 October 2011 (UTC)[reply]

Import upload privileges and bugs with transwiki

Transwiki import from anywhere other than meta and en.ws seems to be broken and my findings are confirmed by the results of attempted imports by Yann and Phe. Even commons had issues. I am submitting a bugzilla to try to get this repaired.

Since that defeats the whole reason I asked for transwiki importer rights, I request "import upload" privileges (importer group), which will allow me to import the older way. I should have thought to ask for this rather than just transwiki import (Importers have both import upload and transwiki import privileges), but I didn't think I'd need it. Import upload does not require bugzillas to designate new import sources. --Doug.^{(talk • contribs)} 12:18, 24 October 2011 (UTC)[reply]

What are you requesting now actually? So: you requested transwiki import, but you want general import rights now if I am correct? --Ooswesthoesbes 12:22, 24 October 2011 (UTC)[reply]

Yes, I requested transwiki import before, thinking that would be sufficient (transwiki import is the normal tool these days and the one that is included in the standard admin package on WMF wikis). However, if you try to import anything from a subdomain other than en.ws you will find that it is very broken (e.g. try to transwiki import de:Vorlage:SperrSchrift or fr:Utilisateur:Doug/Sandbox). It may be a simple fix, but even if it is it could take months to get the bugzilla done. So, I'm requesting general importer rights which gives the import-upload privilege, a different import method that doesn't rely on the transwiki import processes. Considering that the transwiki import tool is broken, I have a current need to import, and I'm generally available on here, e-mail, or IRC, and will gladly fill requests for others, I request the privilege.--Doug.^{(talk • contribs)} 13:06, 24 October 2011 (UTC)[reply]

this is why I usually do the imports by cut&paste... :-) anyway, I support this request, we need the possibility of importing pages in the proper way. Candalua 13:51, 24 October 2011 (UTC)[reply]

@cut&paste: this is actually not even allowed because of our copyright license :) We are definitively in need of an importer and I'm sure Doug can handle the job. --Ooswesthoesbes 06:14, 25 October 2011 (UTC)[reply]

Which page is to be imported?--Jusjih 11:26, 25 October 2011 (UTC)[reply]

Hello Jusjih, the request is more in general that's why I'm asking for the rights. I'm working on a couple of works at present that require some imports as I go. At present I need de:Vorlage:SperrSchrift and there was at least one other that I wanted right now but I've got to go back to the work and look as I put it down several weeks ago for lack of needed templates. But I would like to be able to import when I need to. (For everyone else's benefit - Jusjih has the right I'm asking for, all Stewards do of course, but Jusjih has it locally as well and is currently the only one).--Doug.^{(talk • contribs)} 12:06, 25 October 2011 (UTC)[reply]

Same problem for me (I’m admin though). I tried to import (via special:Import), the page s:fr:Adiu paure Carnaval but I got this error : Import failed: Expected <mediawiki> tag, got. Apparently, there is the same bug on other project : s:fr:Discussion catégorie:Auteurs grecs classiques (on fr.WS in June). On wikibooks too apparently : bugzilla:28277 (same bug as bugzilla:30723 and bugzilla:30235 ?).

Cdlt, VIGNERON 21:36, 26 October 2011 (UTC)[reply]

I finally got around to entering this bug. It's bugzilla:32411. It has been affected by the other bug mentioned below.--Doug.^{(talk • contribs)} 20:32, 14 November 2011 (UTC)[reply]

Terms of Use update

I apologize that you are receiving this message in English. Please help translate it.

Hello,

The Wikimedia Foundation is discussing changes to its Terms of Use. The discussion can be found at Talk:Terms of use. Everyone is invited to join in. Because the new version of Terms of use is not in final form, we are not able to present official translations of it. Volunteers are welcome to translate it, as German volunteers have done at m:Terms of use (de), but we ask that you note at the top that the translation is unofficial and may become outdated as the English version is changed. The translation request can be found at m:Translation requests/WMF/Terms of Use 2 -- Maggie Dennis, Community Liaison 02:30, 27 October 2011 (UTC)[reply]

List of texts every Wikisource should have?

John Vandenberg has created m:List of texts every Wikisource should have. Please take a look at the page and I would also draw your attention to my concerns on the talk page.--Doug.^{(talk • contribs)} 07:47, 27 October 2011 (UTC)[reply]

Impossible. Wikisource may only publish text that are of our license and published previously and we have subdomains that keep to their language. Translations get copyrights as well. --Ooswesthoesbes 09:12, 27 October 2011 (UTC)[reply]

It's not a bad idea, but I would drop the word "every", and call it "List of texts Wikisource should have", in their original language. Candalua 09:27, 27 October 2011 (UTC)[reply]

I don't think this would be very workable. As the list already shows, there is a certain Western (if not even American) bias to it: US Declaration of Independence, US Constitution, Magna Carta, the Bible, 95 theses. Different languages will have different lists of classics. The texts that are "essential" on Norwegian Wikisource will be very different from those that are seen to be "essential" on French or Dutch Wikisource. Norwegian texts tend to focus on Norway and Norwegian issues, and might not ever have been seen to be relevant enough to translate to other languages.

The second, and much larger problem, is that of finding available translations. Due to Copyright, the most recent texts that can be published on Wikisource were, generally, published in the 19th century, or in the first decades of the 20th century. As far as I know, the first translation of the Koran into Norwegian was done in 1980 by Einar Berg (d. 1995), and it will be long before it becomes PD. Although I agree that it would be good to have the Koran on Norwegian Wikisource, it isn't likely to happen any time soon. And the same goes for other texts on that list, such as the US Constitution and US Declaration of independence: I have not been able to find PD translations of them. I suspect on reason is that these simply don't exist: Norwegian living in the 19th century who were interested in foreign books, probably read them in the original German/English/French (or translations into one of these languges). These two specific American texts are quite short, so it might be possible for me to make my own translation, but as Doug mentions on meta: That isn't really what this project is about.

I don't have anything against the idea of this suggestion: Such a list of texts could be useful for knowing where to go next, but I don't think it's feasible, given the scope of the project. I don't think there exists a Norwegian translation of Confucius or of the Koran that will become PD in the next century. So, for the next 100 years, Norwegian Wikisource simply would not have them, although it's something every Wikisource should have.

To conclude, I would like to add that there is one thing missing from that list, and that is the principle on which it is compiled. Why are these texts seen to be so important that all Wikisources should have them? While The internationale is pretty self-evident, as are the 95 theses (at least for a person brought up Lutheran), it is less clear to me why the Japanese and English national anthems are. V85 10:13, 27 October 2011 (UTC)[reply]

@Ooswesthoesbes : possible. I’m not an expert in english grammar and syntax ; but should indicate an advice, not an order. And I think it’s a good advice. Plus, the policy about translation is not the same on all wikisources (see the column Wikisource Translations permitted in Wikisource:Subdomain coordination).

@Candalua : indeed, the word “every” is not a good idea.

@V85 : you first point just show it’s difficult to establish a list and we’ll need to choose carrefully « universal » text (like the Bible, the Coran, the Universal Declaration of Human Rights − write in 1948 but free in 382 languages and so on). For me, the goal is to go beyond. Talk namepaces are made to discuss about it. Your second point is cruelly true but it’s not a reason to try. Plus we could establish the list by thinking of this problem. Then, translations seems to be permitted on most of the project.

I’ll pursue this discussion on meta. Cdlt, VIGNERON 12:46, 28 October 2011 (UTC)[reply]

Image Filter Discussion on meta

This draft page/discussion: m:Requests for comment/Image filter on Wikisource also deserves mention here and arguably belongs on this site as it only relates to wikisources.--Doug.^{(talk • contribs)} 07:54, 27 October 2011 (UTC)[reply]

It applies to all subdomains as well. Whenever possible, images should be sent to Wikimedia Commons.--Jusjih 10:22, 1 November 2011 (UTC)[reply]

Of course, the point is that the above mentioned discussion is purely about the effect on wikisources. Not about where the images belong.--Doug.^{(talk • contribs)} 11:05, 1 November 2011 (UTC)[reply]

Deletion of templates etc associated with subdomains

I've noticed that there is a practice of deleting templates and other items associated with subdomains beyond mere text content. I'm concerned that this may not be the best option because these templates, etc. may be required for material that cannot be hosted on a subdomain because of local copyright policy/WMF copyright policy. Additionally:

we gain no space by deleting these items since the deleted material remains on the servers indefinitely (and, for practical purposes, permanently)
the items are a lot of work to restore because they are harder to locate once deleted
both of the above require admins, making it difficult for non-admins and creating an unnecessary burden on our few admins.

An example, is that in working with German works that are in copyright in Europe but Public Domain in the United States, I have needed author pages, navigational pages, and templates that have been deleted and/or migrated. I think it would be far better to create a template to tag these with, indicating that the language subdomain has been migrated and the project and template space pages are retained, but should only be used for material that can only be hosted here due to local copyright issues.--Doug.^{(talk • contribs)} 15:56, 1 November 2011 (UTC)[reply]

Do consider the fact that most of the templates here are still in the state they were when the language projects left in 2005/2006. Therefore, in many cases they would need updating anyway, so there is nothing gained from keeping the templates. -- Liliana-60 21:31, 1 November 2011 (UTC)[reply]

That is true of templates and I thought of that further when I posted on VIGNERON's talk page shortly after this. However, the deletion of categories, author pages, and navigational pages that index works or authors are a real loss.--Doug.^{(talk • contribs)} 21:59, 1 November 2011 (UTC)[reply]

There is template and template. Some template are real and useful template, some are not (for instance the title navigation book specific template). There no point to keep the second ones. For the first ones, I’m not sure either. Same thing for the categories. For the author pages, there is another problem : in wich language write them ??

Is there a lot of texts here that are not on their wikisource ? And how can we find theses texts ? Main Page and Category:Old Main Pages doesn’t help. Plus, 1. lot of texts that don’t go on fr.ws, go on Wikilivres 2. some wikisources follow the US rules (see Wikisource:Subdomain coordination).

In fine, I think there is a little number of templates/categories

Cdlt, VIGNERON 12:53, 2 November 2011 (UTC)[reply]

I would suggest that we should maintain multilingual navigational information here in any case. What language(s)? well that is a problem. The mess we have created with subdomains continues.--Doug.^{(talk • contribs)} 14:29, 2 November 2011 (UTC)[reply]

I was about to undelete like Template:Rig Veda, Template:Rig Veda2, and template:RG when I became aware of a detail : Sanskrit is a dead language ! In fact it’s an historical language still official in India but : there is pactically no modern modern Sanskrit literature. What is the point to undelete a navigation template done just for one book (the w:Rigveda) ? (this is the same thing for book-specific category). Cdlt, VIGNERON 18:11, 7 November 2011 (UTC)[reply]

Closed Discussions

Would anyone object to me noting discussions that appear to be closed with an archive or closed template as is used on many other projects? That would help distinguish which items no longer need action and help to highlight those that do.--Doug.^{(talk • contribs)} 16:02, 1 November 2011 (UTC)[reply]

no objections Candalua 16:52, 3 November 2011 (UTC)[reply]

Subdomain coordination: some tasks for a global sysop

For the improvement of subdomain coordination, there are a couple of things that would be very useful to be done on every subdomain, but that require sysop rights:

fixing interwiki links on main pages, special pages like Special:RecentChanges and Special:IndexPages, and Mediawiki pages like MediaWiki:Proofreadpage index template
include InterWikiTransclusion.js into Mediawiki:Common.js where this has not been done, so that we can use iw trasclusion from every subdomain. This could be very useful, for example in every local Scriptorium we could set up a section that trascludes the on-going discussions from this Scriptorium, that at this point could really become a central place of discussion that attracts users from all languages.

I propose to ask a global sysop to do them. Candalua 16:51, 3 November 2011 (UTC)[reply]

Excellent idea. Cdlt, VIGNERON 18:26, 3 November 2011 (UTC)[reply]

I've also submitted bug 32189 for fixing interwiki links to oldwikisource, and raised severity for bug 29591 (interwiki link point by default to wikipedia). Please, everyone vote for these bugs and add your prayers and supplications. (The recent experience with the "line break" bug made me regain some faith in bugzilla! They have a heart too, in the end :-) Candalua 19:50, 3 November 2011 (UTC)[reply]

Non controversial? Hardly. On plwikisource we managed to fix the problem with gadget, and your solution will create quite a mess on our project. I sincerely advise you to ask communities and - what's even more important - learn about local solutions, and how your script will interact with them. --Teukros 20:35, 4 November 2011 (UTC)[reply]

The global script can be improved, so it will be the way to learn from each other as you propose. Local sysops are able to revert the change (it's better if they also give constructive feedback), which was performed to save time to us all on wikis where sysops don't know/care (because not everybody can be a JS expert). Nemo 21:03, 4 November 2011 (UTC)[reply]

I apologize for pl.source. Anyway, if you find a better way to do something, you should tell others, not the other way round! :-) It's quite hard for me to explore the js of all 58 major wikisources, or even just major ones. But it's quite easy for you to post a message here, or in this case update Wikisource:Shared Scripts with your instructions :-) Candalua 21:01, 4 November 2011 (UTC)[reply]

This cannot be done by global sysop, however, there's a global editinterface right that should do what you want. It

just needs to be requested by someone. -- Liliana-60 20:11, 3 November 2011 (UTC)[reply]

Thanks Liliana, I didn't know that. To gain time, I've already posted my request, please take a look and tell me if it's okay :-) Candalua 20:38, 3 November 2011 (UTC)[reply]

What is to fix exactly ? what pages ?

@Candalua : did you know if only two weeks will be enough ? (there is 59 wikisources). Did you get in touch with the locals communities ? Cdlt, VIGNERON 14:32, 4 November 2011 (UTC)[reply]

I'm building a list here, you can add others. No, I didn't get in touch, I didn't see the need: I think these tasks are not controversial at all, so it's faster if I just do them, instead of writing and waiting for an answer. I think I will put in the edit summary a link to this discussion. 2 weeks seems enough for me, I will ask for an extension if I need it Candalua 15:17, 4 November 2011 (UTC)[reply]

Ok, fine for me. Thank you for all this work ! VIGNERON 15:48, 4 November 2011 (UTC)[reply]

Well, the script is bad. It has hardcoded http:// protocol in URL, so when you use https:// it gets destroyed. You should have contacted other communities first. Some may prefer gadgets over global scripts etc. This is absolutely not the approach which should be taken. This wiki is not Meta, so is not supposed to decide on behalf of all other language subdomains.
Danny B. 19:26, 4 November 2011 (UTC)[reply]

This doesn't look like a "decision", see my reply above; and by the way Meta can't "decide on behalf of" other wikis either as far as I know. The script can be fixed (and this bug looks easy to solve, by the way); adding it to other wikis just means that a central script will exist and that it will be on this wiki, and this can't be really controversial. Nemo 21:03, 4 November 2011 (UTC)[reply]

I try to answer each point separately:

1) this is the way this script was used everywhere, even by its creator ThomasV. And (for me) it still works if I'm using https (albeit with a warning about running insecure content). I don't see any js error. Ok, you have showed that it can be improved: but from no IW transclusion, to (imperfect) IW trasclusion, I think it's still an improvement...

2) Local sysop can obviously revert it and "opt-out" of this system if they don't want it, or I can do it for them while I have the editinterface right. But I don't see why they should: this change does not actually force any community to use IW transclusion if they don't want, it's just there is someone finds it useful but didn't know how to do it.

3) This wiki is not meta, but it has always been a place of discussion about all-sources matters, with users participating from en, fr, it, etc. If no one from your subdomain (cs, am I right?) is keeping attention, well I guess you should! It does not make sense to post on 58 different Scriptoriums... The activity has also been approved on meta.

4) if you would kindly post your corrected version of the script, I will be happy to propagate the correction on all subdomains. Candalua 20:49, 4 November 2011 (UTC)[reply]

I have disabled the scripts on pl.wikisource.org because they are insecure. They pose a risk to the users. Please, make sure things are secure and working correctly before enabling them for other projects. I have attached a sample. It exploits the following code:

PageDisplayLink.setAttribute('href', 'javascript:displayOptionText("'+optiontitle+'","'+optionstyle+'", false);');

You can click Désactiver on the sidebar to see what happens. You must not create a javascript code (in this example code for href) by using text which can be provided by any user. You should use something like that:

jQuery(PageDisplayLink).click(function() {
displayOptionText(optiontitle, optionstyle, false);
});

Regards, Beau 20:55, 4 November 2011 (UTC)[reply]

On the bright side, I really appreciate the effort to standarize some things and share new features. It is really cool someone thinks about other projects too! As the changes affects other projects, you need to make sure people are well-informed about them in advance. So we can discuss, test and review proposed solutions. I subscribe to Wikisource-l mailing list, but did not see any notifications about the change (I hope my spam filter did not eat that). Beau 21:23, 4 November 2011 (UTC)[reply]

It's true that perhaps a message on the list would have helped (although usually they don't much), but note that this page has as many watchers as the list's subscribers (145 vs. 161), and you can receive notifications of edits to this page. :-) Nemo 21:29, 4 November 2011 (UTC)[reply]

I can watch this page, however it is also about local project matters, which may not interest people involved in other projects. It would be a good idea to set up a separate page for "global wikisource discussion" and announce it using central notice available on meta or by any other suitable means. To be honest I hate mailing lists, but I am subscribed to them anyway. Beau 10:37, 6 November 2011 (UTC)[reply]

Beau, you mean like this, right? You know, I understand your point of view, the fact is: the mailing list has always looked to me like a "hidden place" just for the "élite", that an average user would never find; and when I tried to wrote on the Scriptorium of other subdomains to propose something, most of the times i didn't got any answer at all, not even a "no thanks"... This is why I chose to be bold and just do it. I hope this has not caused too much harm. Candalua 22:18, 4 November 2011 (UTC)[reply]

Yes, that's the right change, though I did not try to find more issues in that scripts. Lack of any response from other wikisource projects is frustrating, however we must bear in mind that most projects are "understaffed" (espescially when compared to Wikipedia). Furthermore there are even less "technical" people, so such change needs to be presented in a way non-technical people and non-native English speakers can understand. Excluding interwiki transclusion I have no idea what those scripts are supposed to do and how to make use of them. Beau 10:37, 6 November 2011 (UTC)[reply]

Last night the script inclusions have been modified on all wikisources (except the ones that "opted-out") following the suggestion by Danny B. Also, the scripts themselves have been made secure like Beau suggested. I apologize for causing some inconvenience, but as you can see the problems you pointed out have been addressed and solved just in a few hours. I hope that the Wikisources that rejected the scripts will now change their mind. Please let me know if there's something else that I can do. Sorry again, and thanks for your patience. Candalua 20:57, 5 November 2011 (UTC)[reply]

Gadgets from Polish Wikisource

Candalua in previous thread encouraged to share some of our scripts, so as a maintainer of gadgets on all Polish projects I'll describe some of gadgets, which may be useful for Wikisource.

First couple of comments about local scripts here.

You should move the code from MediaWiki:Monobook.js to MediaWiki:Common.js and remove the former page. Vector is now a default skin for all projects and the code on MediaWiki:Common.js is executed for all skins.
On all Polish projects I moved non-critical (enhancements) stuff from MediaWiki:Common.js to gadgets. It is a powerful extension which allows enabling scripts by default for all users, so it will be backward compatible. Registered users are given a way to disable those enhancements in case they are annoying, do not work properly or they are testing other scripts which are in conflict with others. It also make tracking errors easier, because a user can disable gadgets one by one, and find the source of problem he/she is encountering. In my opinion scripts on page MediaWiki:IndexForm.js or MediaWiki:Monobook.js can be moved to gadgets enabled by default.
A line * ocr|ocr.js should be removed from MediaWiki:Gadgets-definition as it confuses the users and does not serve any purpose.

Full list of gadgets is on a page: pl:Specjalna:Gadżety.

Historia korekty (A history of proofreading) - add additional tab for pages in Page: namespace, which allows to check who changed a status of the page.
Linkujące z siostrzanych projektów (What links here from sister projects) - enhances what links here page with a button, which shows incoming links from sister projects in the same language (I don't think it will work oldwikisource).
Linki do wikisource.org (Links to wikisource.org) - it rewrites links to a specified language version to point at wikisource.org. For example all be: interwikis are changed from be.wikisource.org to wikisource.org.
Pokazuj link w postaci książki do pokazywania/ukrywania numerów stron oraz link koryguj do poprawiania tekstu - the script shows a book icon, which allows to show or hide page numbers when content is transcluded from Page: namespace. If the content is transcluded from one page a tab "Koryguj" (correct, rectify) allows user to edit the transcluded page directly.
Przycisk do szybkiego wstawiania sekcji (A button for inserting sections) - adds a button which allows to surround a selected part of text by <section> tags.

There are also other useful scripts for MediaWiki users, however I am too lazy to describe them all. If someone want to use those scripts I can modify them to make them easier to translate (by splitting messages from the code like I did on pl:MediaWiki:Gadget-iw-links.js), just send me a message. Beau 11:28, 6 November 2011 (UTC)[reply]

bug 29591

bugzilla:29591 (oldwikisource language links point to Wikipedias rather than Wikisources) has been fixed. (Thanks Roan) John Vandenberg 11:27, 8 November 2011 (UTC)[reply]

Now a bot is needed to fix links, because those starting with s prefix are turning red now and point nowhere. Beau 17:51, 8 November 2011 (UTC)[reply]

Candalua has corrected some of them, see #Seeking consensus for working interlanguage links: but do you mean also in user space? I think all namespaces should be corrected. Nemo 18:27, 8 November 2011 (UTC)[reply]

See example. Beau 18:31, 8 November 2011 (UTC)[reply]

Yes, I know. Candalua previously fixed links only in the main namespace, I was noting that I think all namespaces should be fixed. Nemo 18:36, 8 November 2011 (UTC)[reply]

These are 2 separate issues: 1) links that pointed to Wikipedia and now point to Wikisource (the ones I previously fixed in ns0) and 2) links that used 's:' to point to Wikisource, and are no longer working (the example given by Beau) - note that pages are updating slowly, so they may appear as blue links until you purge the page, and then appear red.

Point 1 is not easy to fix, because many of these links were actually wrong because users expected them to point to Wikisource, and it's not always easy to tell if a link must be fixed (adding w:) or not. That's why I did only ns0.

Point 2 I'm fixing right now in ns0 (nearly finished). I've skipped links like [[w:pl:s:Title]], because they still seem to work and they're too many, but obviously they can be simplified to [[pl:Title]]

I also fixed links in most of ns Wikisource: pages (excluding old discussions and archives), main page, recentchanges, Scriptorium and some important templates. But if someone can give me a hand it will be a great help! :-) Candalua 22:50, 8 November 2011 (UTC)[reply]

I also noticed a strange behaviour: links like [[w:Something]] should point by default to en.wikipedia, am I right? Instead they point to sn.wikipedia which is the Shona language?!? Candalua 22:59, 8 November 2011 (UTC)[reply]

No, in general Wikipedia: points to en.wiki but w: points to the Wikipedia in the same language; probably, an exception for this wiki is missing. Adding a note to the bug now. Nemo 08:37, 9 November 2011 (UTC)[reply]

This has been fixed by Roan as well. Nemo 17:46, 9 November 2011 (UTC)[reply]

~~I absolutely agree, as I noted in the bugzilla, s: should come here.--Doug.^{(talk • contribs)} 13:18, 13 November 2011 (UTC)~~I wasn't paying attention[reply]

In the same language unfortunately means English if you are on mediawiki or meta, it would be better to point to here.--Doug.^{(talk • contribs)} 22:15, 16 November 2011 (UTC)[reply]

This fix requires a lot of repair work. To begin with, it's going to require the repair of most links on here, they now all attempt to go to "en.wikisource.org/wiki/S:" Furthermore, every book template on commons needs to be checked. I may be able to have my bot do that. Finally, links from external to wmf now work correctly (format is [[wikisource:]]; however, old ones probably do the same thing that ones coming in from other wmf projects do, I will check.--Doug.^{(talk • contribs)} 13:18, 13 November 2011 (UTC)[reply]

Candalua seems to have mostly address the above issue on this site. Links coming in from other local sites appear to be unaffected. External links in the format wikisource:xx:s:Foo are killed by the change.--Doug.^{(talk • contribs)} 22:14, 16 November 2011 (UTC)[reply]

Incubation for Marathi Wikisource

Currently Marathi Language on this wikiportal has got two main pages one in english one in Marathi Language simmillerly two categories one in english one in Marathi.Since we want to divert good no. of editors here for incubation of Marathi Wikilanguage Wikisource Please guide us whether we can redirect current english main page for Marathi language to Main Page in Marathi Language and all categorisation in Marathi Language Mahitgar 15:00, 26 November 2011 (UTC)[reply]

en:Wachtelmäre import?

Gday. Would someone with import rights please peruse en:Wachtelmäre with an eye for importing the work. German texts at enW are out of place. Thanks. billinghurst sDrewth 13:45, 27 November 2011 (UTC)[reply]

It should be imported to de: I think, not to here. --Ooswesthoesbes 06:18, 28 November 2011 (UTC)[reply]

True but as far as I understand, ws.de didn’t accept new texts. Cdlt, VIGNERON 11:31, 1 December 2011 (UTC)[reply]

AFAIK de-ws accepts new texts as long as they're backed up by scans, but not texts that have no scans. —An gr 16:53, 2 December 2011 (UTC)[reply]

I agree that we can’t let this text simply disappear; can’t this be an acceptable source for the scan? I don’t understand German so may be it’s not appropriate at all? --Zyephyrus 10:40, 3 December 2011 (UTC)[reply]

The text doesn't really seem to be the same as far as I can see. --Ooswesthoesbes 21:27, 3 December 2011 (UTC)[reply]

The text and the image is (nearly) the same (the text begin after the “rubrique” in the second column). The only difference I seen are ſ instead of s, and the (e)s are indeed e. Cdlt, VIGNERON 23:11, 5 December 2011 (UTC)[reply]

Template:TopTenCircle

Hi! Template:TopTenCircle should be updated from time to time, e.g. now it is more than 20.000 text pages on pl-wikisource... Btw. I think that it can be protected on autoconfirmed level, only. So every logged user can updated it... Electron ^<Talk?> 08:50, 6 December 2011 (UTC)[reply]

The problem is: which figures do we choose? If we take the ones given by this link as it was asked to, what we get is this:

№	Language	Language (local)	Wiki	Good	Total	Edits	Admins	Users	Active Users	Images	Updated
1	English	English	en	254246	1131682	3522952	41	340917	371	1927	2011-11-28 03:15:02
2	Russian	Русский	ru	157768	208008	638253	9	23748	103	569	2011-11-28 03:15:14
3	French	Français	fr	125376	1041085	2915064	19	22679	175	6344	2011-11-28 03:15:03
4	Chinese	中文	zh	104522	140280	294909	5	22447	71	400	2011-11-28 03:15:04
5	Portuguese	Português	pt	87747	124847	237501	2	7687	36	19	2011-11-28 03:15:13
6	German	Deutsch	de	74612	261690	1760226	30	17344	142	3546	2011-11-28 03:15:02
7	Italian	Italiano	it	50277	224440	1969406	13	10991	112	1358	2011-11-28 03:15:11
8	Spanish	Español	es	49682	107664	511103	10	20104	69	1072	2011-11-28 03:15:03
9	Hebrew	עברית	he	33584	240876	481390	13	4807	41	309	2011-11-28 03:15:15
10	Persian	فارسی	fa	21826	25116	60184	3	3624	38	8	2011-11-28 03:15:07

Our texts number on fr.ws gives a quite different figure: 75,552 texts with a magic number {{ALL TEXTS}}, or 134,194 content pages in frws Spécial Statistiques; and if we take pageviews we’ll have to restart from scratch. What shall we do? --Zyephyrus 13:09, 6 December 2011 (UTC)[reply]

OK. If there are more texts on Persian Wikisourse it is better than Polish Wikisourse and has rigts to replace it... Electron

^<Talk?> 13:28, 6 December 2011 (UTC)[reply]

This is not what had been decided in previous discussions: see here. So, if we rely on Pageviews:

Pageviews (November 2011). Source.

Σ	1. English	2. French	3. Russian	4. Spanish	5. German	6. Italian	7. Hebrew	8. Polish	9. Chinese	10. Arabic
+11%, 100.00%, -- 49.6 M	+32%, 23.33%, 1st 11.6 M	+22%, 16.42%, 2nd 8.1 M	+7%, 12.75%, 3rd 6.3 M	-7%, 6.82%, 4th 3.4 M	-10%, 5.63%, 5th 2.8 M	+16%, 4.93%, 6th 2.4 M	+26%, 3.54%, 7th 1.8 M	+36%, 3.29%, 8th 1.6 M	-18%, 2.70%, 9th 1.3 M	-2%, 2.59%, 10th 1.3 M

With the Pageviews criteria, Polish is in the TopTenCircle, Arabic too, but Persian is not. It is not an easy problem to solve.--Zyephyrus 14:54, 6 December 2011 (UTC)[reply]

I don't have my own opinion about the way we should count the pages but on Polish Wikisourse now is about 20 205 pages in the area named "tekst" (the main area for texts on that wiki) and I think that it would be nice to update it. Of coarce, only if pl-wikisource will stay on the template. Electron

^<Talk?> 15:51, 6 December 2011 (UTC)[reply]

The only vote we do have is here: it decided the TopTenCircle would rank the wikisources with the ten highest Pageview results; and would show how many texts each of them had. But nothing was decided about how to count these texts. The tables that count how many pages there are in the main space have a quality: all the languages are treated on a same rule; but a defect: you may have all the poems of a collection on one page, or one poem per page, or many other different ways to present—and to count—them. So this part of the discussion remained undecided.

Will we put the number of pages given by the first of the two tables I’ve brought here to-day? If this is the chosen solution, the French figure jumps from 67,000 to 125,000. --Zyephyrus 20:02, 6 December 2011 (UTC)[reply]

OK. OK. But it is an academical discusion, see here -> The Polish Wikisource has reached 20,000 text units. It is not only my opinion, then. Electron

^<Talk?> 11:52, 8 December 2011 (UTC)[reply]

Of course not, Electron, I’m sure each language has honest criteria, and yours are honest, I don’t doubt that. What I think we need is a consensus about a method, don’t you think so? We can’t seriously impress people with figures if we can’t explain what these figures represent. My feeling is that if we knew what a text unit is, we wouldn’t have so many different results counting them, and that none of us has to be punished for that, neither you, nor me, nor any wikisourcian: I think we are all facing a very new situation.

I’m not sure any specialized person can bring a satisfactory answer about what a text unit is and how it can be defined, we are pioneers and must invent a solution bringing all our variety of experiences together; isn’t it normal that it takes time? So I don’t do it too quickly. --Zyephyrus 15:11, 8 December 2011 (UTC)[reply]

Just a comment: the number of pages from the table above is not accurate, for example they say 50.277 pages on it.source but it's not true, I counted them with my bot and found they're 38.730, which corresponds to the figure given by http://toolserver.org/~phe/statistics.php that seems to be far more accurate.

Anyway, it's true that these numbers do not really mean anything. I don't think we can find a really fair definition of text unit, that does not give advantange to some language or some other. I propose that we simply do not show any numbers on the main page, and that we put around the logo the first 10 languages ranked by pageviews, followed by the list of all languages in alphabetical order. And let's leave it to each subdomain to show their own figures, if they want, and explain their criteria. Candalua 00:18, 11 December 2011 (UTC)[reply]

I think that the wikis should be sorted by pages in mainspace. User/template pages shouldn't count (too prone to simple bloat, while "real" wiki pages (actual encyclopedic pages) are generally monitored and deleted if they really don't belong) and pageviews are too susceptible to bot manipulation. This would put the current top ten wikis as: en (English), ru (Russian), zh (Chinese), he (Hebrew), pt (Portugese), de (German), fr (French), es (Spanish), it (italian), pl (Polish). http://toolserver.org/~phe/statistics.php which is where I took most of these mainspace numbers, doesn't list Arabic, although the Arabic Special Statistics page says that the Arabic wiki has roughly 2k less mainspace pages than the Polish wiki, so I don't think that matters very much. This would also have the side benefit of encouraging all of the various wikis to further encourage real article creation. Banaticus 10:32, 3 January 2012 (UTC) EDIT: I was comparing wikipedia mainspace pages, not wikisource, but I think my rest of my views still stand -- mainspace pages should be the prime determinant. Banaticus 12:37, 3 January 2012 (UTC)[reply]

Main Pages

In the above discussion about Main Pages there was consensus to put them at titles like Main Page/langname with redirects at Main Page/langcode. I think we can do it. Moreover I'd put at the beginning of Main Pages a table like this:

Language info
ISO code	be
English name	Belarusian
Native name	Беларуская

--Erasmo Barresi 13:29, 11 December 2011 (UTC)[reply]

Support. --Zyephyrus 20:16, 12 December 2011 (UTC)[reply]

I've tested the system with Afrikaans: I've

moved the Main Page to Main Page/Afrikaans
putted a redirect at Main Page/af
created Template:Langinfo and used it

Please give me some feedback.--Erasmo Barresi 14:06, 13 December 2011 (UTC)[reply]

I’ve tested with Occitan, it’s seems fine for me :

Main Page/Occitan and redirect Main Page/oc

Just two little things : there should be a main pages redirect category and the template is too big/visible : the green color catch the eye, why not use a neutral gray ? and I think it should be better to put on the box on the right. Cdlt, VIGNERON 13:13, 17 December 2011 (UTC)[reply]

I've used light grey and putted the box on the right. How shall we name the category? I'd name it Category:Redirects to Main Pages.--Erasmo Barresi 20:07, 18 December 2011 (UTC)[reply]

Thank you, it’s far better. No idea for the category name (english is not my first language). Cdlt, VIGNERON 15:47, 19 December 2011 (UTC)[reply]

In the title pattern "Main Page/langname", should langname be the native name (e.g. "Main Page/Беларуская") or the English name (e.g. "Main Page/Belarusian")? Whichever it is, there should probably be a redirect from the other one (except in cases like Afrikaans and Occitan where the English name and the native name are identical). —An gr 21:35, 20 December 2011 (UTC)[reply]

Since the term "Main Page" itself is already English so too should the language name. This helps to insure that everything is accessible by anyone without needing to be familiar with the spelling conventions or script of the other language. This should link (not redirect) to an optional secondary main page in that language where even the term "Main page" is translated. I don't think any purpose would be served by having a separate category for redirect pages. Eclecticology 09:59, 22 December 2011 (UTC)[reply]

For sub-pages' titles I've used languages' native names. My idea is to respect linguistical variety, and not to normalize all in English. This is not totally possible because "Main Page" can't be translated if we want sub-pages, but I think Main Page/Беларуская is good. Who doesn't know the language can use the ISO code: Main Page/be. This system is completely exhaustive. For the redirects' category ask VIGNERON. Until now we've done these:

Main Page/af -> Main Page/Afrikaans
Main Page/ast -> Main Page/Asturianu
Main Page/be -> Main Page/Беларуская
Main Page/bm -> Main Page/Bambara
Main Page/cdo -> Main Page/Mìng-dĕ̤ng-ngṳ̄
No ISO code available -> Main Page/Crnogorski
Main Page/cv -> Main Page/Чăваш
Main Page/oc -> Main Page/Occitan

Moreover I'd delete pages in Category:Old Main Pages.--Erasmo Barresi 11:48, 23 December 2011 (UTC)[reply]

I've moved Main Page:Gaeilge to Main Page/Gaeilge and created redirects from Main Page/Irish and Main Page/ga. —An gr 09:49, 24 December 2011 (UTC)[reply]

Yes, I think that's a good system. I would keep the old main pages though. A lot of them are linked from sites and even papers in order to attract more volunteers. --Ooswesthoesbes 10:28, 26 December 2011 (UTC)[reply]

Music module

After many requests, I'm trying to get interest in music notation on WMF sites going again. The best way to do this, right now seems to be Extension:LilyPond, but there are some security concerns that need to be addressed.

Tim Starling has posted his review of the problems and we need to get those addressed before we can deploy this extension.

Is there anyone here with PHP ability as well as the time and interest to get the code up to snuff? --☠MarkAHershberger☢(talk)☣ 19:20, 14 December 2011 (UTC)[reply]

The german wikisource is strongly interested in having such a module --Joergens.mi 21:52, 14 December 2011 (UTC)[reply]

I'll have a look at the code. I'm not a WMF/MW developer, so I can't promise anything right now.--GrafZahl 16:19, 15 December 2011 (UTC)[reply]

I just had my look on the code. The extension doesn't even work any more with MW 1.18 in its current state (deprecated setup function and reliance on the math extension). Nevertheless, thanks to Tim Starling's review, it should not be too hard to rewrite the whole thing with his suggestions built in, except probably for some portability issues with wfShellExec. I'll ignore these issues for now, for AIUI the thing is to be deployed on WMF hosts, and thosse are running POSIX. Stay tuned.--GrafZahl 22:53, 15 December 2011 (UTC)[reply]

Here: [4], the new score extension. It's still pretty much untested. I'll do some testing tomorrow for for now, I'm getting the yawns. I'll also create an extension page on mediawiki.org.--GrafZahl 03:00, 16 December 2011 (UTC)[reply]

Thank you so much for taking this on! -- ☠MarkAHershberger☢(talk)☣ 17:22, 16 December 2011 (UTC)[reply]

And the extension page: mw:Extension:Score. Who needs to bug whom now to get this installed?--GrafZahl 12:45, 16 December 2011 (UTC)[reply]

GrafZahl, thank you for your work on this! To get this installed ("deployed") on Wikimedia Foundation sites, you'll want to follow these steps, including requesting commit access to our Subversion source control repository. I'll start getting some reviews for you if possible. -Sumana Harihareswara

Sumana, thank you for these pointers. This is quite some process for one little extension. Anyway, I'll try to get the ball rolling. Bug 189 has been open for more than seven years.--GrafZahl 16:22, 16 December 2011 (UTC)[reply]

As the Bugmeister for the foundation, I can walk you through the process, but Sumana gave you the necessary information. The next step would be to apply for commit access. Since there is a FIXME against the LilyPond commit, though, I may commit the code after giving it a looksee. -- ☠MarkAHershberger☢(talk)☣ 17:32, 16 December 2011 (UTC)[reply]

OK, I see you already included the extension in SVN. I also received and merged your pull request on GitHub, thanks. I've applied for SVN access. Until I've got it, I hope it's not too dear to keep GitHub and SVN in sync. OTOH, I read somewhere on mediawiki.org that svn will be replaced by git "by the end of 2011".--GrafZahl 19:53, 16 December 2011 (UTC)[reply]

I'm willing to commit to both for now. Let me know when/if I should pull. I usually get messages on my Talk page before here, though. -- ☠MarkAHershberger☢(talk)☣ 22:26, 16 December 2011 (UTC)[reply]

New users and welcome

Hello wikisourcians

What would you think about this message for these users on their talk page instead of the welcome message:

Users:

Message:

Please do not add advertising or inappropriate external links to Wikisource. Wikisource should not be used for advertising or promotion.

Inappropriate links include (but are not limited to) links to personal web sites, links to web sites with which you are affiliated, and links that exist to attract visitors to a web site or promote a product.

Read what Wikisource includes for further explanations of what is considered appropriate.

If you feel the link should be added to the text, then please discuss it on the text's talk page rather than re-adding it, as doing so may result in yourself being blocked.

See the Community Portal to learn more about Wikisource. Thank you.

Other ideas?
--Zyephyrus 20:16, 21 December 2011 (UTC)[reply]

I have had a couple of these show up at the Wikimedia.ca site. The very short entries there are clearly spam. I responded to the first couple with one sentence to the effect that we do not encourage spam. I don't think that it matters what you say there, so now I just say nothing. I have been tempted to simply speedy delete the accounts without comment. For the moment I am more curious about what these spammers are trying to do; nobody looks at these user talk pages, so it's hard to imagine how they could ever work at selling anything. I'll just keep watching. Eclecticology 00:22, 22 December 2011 (UTC)[reply]