Wikisource:Scriptorium/Archives/2011 - Wikisource

Wikisource:Scriptorium/Archives/2011 - Wikisource
Jump to content
From Wikisource
Wikisource:Scriptorium
Login link to secure login
edit
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
edit
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
edit
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
edit
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
edit
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
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 ?
edit
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
edit
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
edit
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
edit
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 :
MediaWiki:Sitesupportpage
MediaWiki:Gnunote
MediaWiki:All messages
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
edit
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
edit
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
edit
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
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
edit
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
edit
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

07:25, 20 June 2011 (UTC)
reply
secure.wikimedia.org for WS language subdomains?
edit
Is it possible to access WS language subdomains through
? 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.
). However, these aren't accessible from the multilingual page linked from
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
edit
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

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 ([[:?:]] -> [[w::]]). 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
edit
Hi!
Could someone change the link
to
Helder
13:43, 28 June 2011 (UTC)
Done
Candalua
19:36, 9 July 2011 (UTC)
reply
Interwiki
edit
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

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
edit
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?
edit
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

, 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
edit
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?
edit
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.
.
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
edit
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:

, 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: oldwikisource:Foo. 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
edit
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
edit
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
edit
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
edit
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
edit
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
edit
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
edit
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
edit
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
edit
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
edit
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
edit
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?
edit
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
edit
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
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
edit
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
edit
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
edit
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
.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
edit
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
edit
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 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
edit
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
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?
edit
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
edit
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
edit
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
edit
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
edit
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.
xxx
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
edit
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

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
edit
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
edit
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?
edit
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
, and the
(e)
s are indeed
. Cdlt,
VIGNERON
23:11, 5 December 2011 (UTC)
reply
Template:TopTenCircle
edit
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

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
en
254246
1131682
3522952
41
340917
371
1927
2011-11-28 03:15:02
Russian
Русский
ru
157768
208008
638253
23748
103
569
2011-11-28 03:15:14
French
fr
125376
1041085
2915064
19
22679
175
6344
2011-11-28 03:15:03
Chinese
中文
zh
104522
140280
294909
22447
71
400
2011-11-28 03:15:04
Portuguese
Português
pt
87747
124847
237501
7687
36
19
2011-11-28 03:15:13
German
de
74612
261690
1760226
30
17344
142
3546
2011-11-28 03:15:02
Italian
Italiano
it
50277
224440
1969406
13
10991
112
1358
2011-11-28 03:15:11
Spanish
es
49682
107664
511103
10
20104
69
1072
2011-11-28 03:15:03
Hebrew
עברית
he
33584
240876
481390
13
4807
41
309
2011-11-28 03:15:15
10
Persian
فارسی
fa
21826
25116
60184
3624
38
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

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

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

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
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).
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
edit
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
edit
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
edit
Hello wikisourcians
What would you think about this message for these users on their talk page instead of the welcome message:
Users:
15:54 . . GarageDoorsBellevue41 (Talk | contribs | block) New user account
11:36 . . Instant Payday loans (Talk | contribs | block) New user account
09:29 . . Online Cash Advance (Talk | contribs | block) New user account
08:57 . . Payday loans online (Talk | contribs | block) New user account
00:21 . . Janitorialservicemarysville (Talk | contribs | block) New user account
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
Retrieved from "
Hidden category:
Pages using deprecated source tags
Wikisource
Scriptorium/Archives/2011
Add topic