ChoralWiki:Operation and implementation issues/Archive 3

From ChoralWiki
< ChoralWiki:Operation and implementation issues
Revision as of 03:48, 21 April 2014 by CHGiffen (talk | contribs) (Text replace - "Chuck" to "{{User|CHGiffen|Chuck}}")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

This page archives topics from the Bulletin board forum Operation and implementation issues

Archive 3

Administrative remedies to mitigate current (July 08) spam storm?

  • Posted by: Kkroon 20:42, 11 July 2008 (PDT)
 Help 

An observation that struck me as I was looking through the Recent Changes for pages that needed to be reverted: all of the perps appear to have ten-character usernames, the first and sixth characters of which are capitalized.

Is there any way to use this information to disallow (for example) the creation of userIDs with that format (for the time being)?

Signed, An occasional volunteer who's been annoyed with these spates of Wikispam ever since they started.

Kkroon 20:42, 11 July 2008 (PDT)

 Help 

Unfortunately, there is no such mechanism for disallowing the creation of UserIDs with a particular format. It is indeed a bothersome situation for all of us, especially admins who try their best to keep up with reverting the spambot edits and blocking] the offenders. When (and if) we ever get a new version of the wiki software, it is hoped that it will come equipped with visual confirmation requirements (such as Capcha) that would prevent a bot from being able to register. In the meantime, thank you very much for your concern and also especially for your help in reverting the spam edits.

  • Posted by: Kurtis 23:42, 13 July 2008 (PDT)
 Help 

And none of these admins (except maybe Mr. Ornes) can install an extension like http://www.mediawiki.org/wiki/Extension:ConfirmAccount ?

Sure, it would cause some administrative overhead -- confirming or declining an account application. Maybe it would help ... but what do I know?

Kkroon 16:37, 13 July 2008 (PDT)

 Help 

Some other suggestions to implement, in case any of the admins can reach and edit LocalSettings.php: Preventing access and Usercan Hook. With these we could restrict a bit the attacks to fewer pages, by protecting entire namespaces as User:, Category:, ChoralWiki: and Template:.

 Help 

Unfortunately, only Raf Ornes (User:Admin) has direct access to the database and other system files, hence none of the rest of us admins is able to access and edit LocalSettings.php or install MediaWiki extensions.

 Help 

Chuck, what if we all wrote to Raf asking him to do something, or at least to grant one of us permission to do it in his place? If he keeps silent even after being warned, then I guess I'll start having big concerns about the future of this project and the time and effort we all put into it.

 Help 

I'd definitely like to see some Capcha style protection on this wiki so if you've got the time, please go ahead and make your request to Raf, Carlos. It may be prudent to suggest to Raf that you're not expecting instant action, but a short reply which details when he may get the chance to update the wiki software and add the Capcha addon. I'm sure we'd all be please to hear of any reply you get. I'll probably send an email to Raf soon and then write to him every week till I get a reply...

 Help 

I'll do that, Rob! But I believe the more people write him, the more he'll feel the urge. Should I use the email at his user page or do you know of any personal email he checks more often? Thanks.

  • Posted by: --Choralia 06:16, 15 July 2008 (PDT)
 Help 

Carlos & Rob, as we discussed via private email in the past, I'm also rather concerned about the future of this project. Please let me know if you want me to also write to Raf. If you don't get any response from Raf, I think we should contact the administrators of the server farm where CPDL is hosted, and find some workaround to preserve CPDL as a significant music asset that cannot be lost. Apparently, the hosting server is ccarh-www-2.Stanford.EDU (IP address 171.67.229.80), at the Stanford University. Let's consider this as a back-up solution in the case you cannot get in touch with Raf. Regards. Max

 Help 

Has anyone tried calling Raf at his church? If something has happened to him, they would likely know. His number as published on the church website is (650) 851-8282 x106. I glanced through the church news, but didn't see any mention of him being indisposed or away. I'd be surprised, though, if he was willing to let CPDL fall into disrepair, and clearly the spambot thing is a major problem.

Category:New works added to Template:NewWorks

 Help 

Some of you have noticed that I modified Template:NewWork so that it, in addition to adding a category of the form yyyy-mm-dd (used by ChoralWiki:LatestScores and the ChoralWiki:yyyy-mm-dd_Scores pages to provide listings of new editions posted), the template now also places a page in Category:New works, sorted by the posting date passed to the template. This latest feature should make it easy for us to remove "stale" instances of the NewWork template. I have tentatively stated that instances which are more than two years old can be safely removed. Currently there are somewhat over 500 instances of NewWork being applied to editions which are more than two years old. I see that Rob has begun removing such templates, and I shall do more of the same in coming days/weeks (holidays and other things have intervened for my getting much of a start).

My choice of two years was a bit arbitrary (mainly because I was not wanting to offend anyone). If hindsight and the holiday weekend provide any retrospect, it might be that two years could be further reduced, say, to one year. But I'm posting this here to get feedback.

If anyone wants to help pruning the stale instances of NewWork, just New works, click on a page near the top of the list, find the stale template and remove it. It would further help CPDL if you check through any such page for errors, corrections, and any other improvements, such as formatting and proper application (ie. read the instructions) of such templates as Edtions, Composer, Voicing, Language, etc.)

 Help 

Hi Chuck! To be honest, I don't see much sense in adding to a page something that we know that will have to be removed anytime later. I'd like to recommend a change in the way this template works, adding a bit of "intelligence" to it: we could make it compare the entered date with {{CURRENTYEAR}}, {{CURRENTMONTH}} and {{CURRENTDAY}} and dependind on the results, make it show or not the "NEW" icon on the score page, besides including or not the page in "New work" categories. We'd only have to change the template to also accept the format {{NewWork|yyyy|mm|dd}}, and adding the logic would be quite easy (I can help with that). The best of the worlds would be if we could deal with the date strings in use now ("yyyy-mm-dd"), so that we wouldn't have to remove or edit the stale instances, but I couldn't find on Wikipedia any function that breaks a string in smaller parts :(( Do you know of any?

 Help 

Hi Carlos. Unfortunately, we don't have the MediaWiki ParserFunctions and StringFunctions. The Template:Switch is a template kludge for the MediaWiki #switch, and I don't see any easy way to kludge other such functions. Without these, it would be next to impossible to implement the scheme you suggest (which we have thought about and wished for before!).

 Help 


Edit: The follow post is obsolete, the Template:NW having been deleted.

I have created a new Template:NW which is an extension of Template:NewWork which (if it replaces the latter) is backwardly compatible with the latter and which (at least, down the road a year or two) could prove useful somewhat in the way that Carlos suggested above ... albeit it is more primitive than we would like (since we don't have MediaWiki ParserFunctions and StringFunctions here).

I have taken the liberty of replacing {{NewWork|2006-02-19}} in Uno spirto celeste (Giovanni Maria Nanino) with {{NW|2006-02-19|2006}}, so that you can see the result - namely, that the "new" icon does not appear, and the categories 2006-02-19 and New works don't appear either.

On Mein gläubiges Herze (Johann Sebastian Bach) I've replaced {{NewWork|2008-07-08}} with {{NW|2008-07-08|2008}} - and the "new" icon does indeed appear along with the categories 2008-07-08, New works, and a new category 2008.

If NW is used exactly like the present NewWork template (ie. with only the one date parameter in the form yyyy-mm-dd), then NW functions exacly the same way as NewWork does. The idea behind the functioning of NW with its second year (yyyy) parameter is that if the year given (eg. 2006) is two or more years older than the present year, then the template does nothing, as in the Nanino example above. As presently configured, the two year trick has to be updated annually (by adding another |case: yyyy= field. At present the only such field is |case: 2006= (since there are no instances of the NewWork template prior to 2006).

When and if we ever get the MediaWiki update required, the template can be changed to do everything automatically and precisely, but in the meantime, it might be a good idea to change NewWork over to an extension which looks something like NW does. If people approve, I'll probably go ahead and make such a change, although I'll probably have the template not add a Category:yyyy (since it is not really needed).

Your comments are encouraged!

 Help 

That looks good to me, Chuck. Thanks for your work. Would it be possible to make the deciding factor for the template a little more accurate, ie. make it dependant on not just the year but also the month and day?

 Help 

Sorry Chuck, I hadn't seen your last message here about the NW template (these bot edits made your reply slip through) when I wrote to you in your talk page. Feel free to move that talk here if you want so. I made that test unaware that you had already offered another solution here, sorry if it looked like I was competing with you, I thought you were still making tests, just as me.

 Help 

No problem, Carlos. Indeed, my thoughts now favor (at least until we can get the right WikiMedia update) your solution using Template:IsNew. Even though it will require more frequent mainenance, it does offer the finer dependence upon yyyy-mm-dd that Rob asked about above.

I think the biggest question now is just how long do we want the "new" icon to remain on an edition - 12 months, 18 months, 24 months, or what? The current setting for 12 months seems alright enough for me.

 Help 

Perhaps we could opt for a trade-off between IsNew accuracy and its maintenance frequency: everytime a maintenance is done, IsNew would be set to test for 12 months behind and 6 months ahead. In the following six months, IsNew time range would grow from 12 to 18 months, until a new maintenance is done again. Another option is to set it to already test dates 2 years ahead from now, and every couple of months we'd only have to delete the trailing block of older dates (though I'm not sure whether the extra 365 x2 test entries would affect its performance). In order to make maintenance even simpler, I treated all months as having 31 days, since it doesn't affect IsNew results.

Testing a new set of Link templates

 Help 

Hi, I know it may sound a bit exagerated, but I started testing 3 new templates to deal with the linking of music files inside composer and score pages. They are {{Link}} (for external files), {{LLink}} (for local files hosted at cpdl.org) and {{LLinkAlt}} (for local files hosted at wso.williams.edu). Perhaps it would be better to have just one instead of three, but then I wouldn't be able to shrink the links well. All of them were temporarily applied to Palestrina's page, the differences can be checked here. The advantages would be more simplicity in adding links and smaller page size. In the case of Palestrina, page size was reduced from 46kb to 32kb with them, almost 50%. Please again, have a look and say if it's something worth to keep developing or if it was just a silly idea of mine.

 Help 

Great work, Carlos! I would suggest that LLinkW (for Williams) is a shorter (hence better) name than LLinkAlt. Also, the three "&nbsp;&nbsp;&nbsp;" are better replaced with " &nbsp; ", and the only other &nbsp;'s should be immediately after the "(" and immediately before the closing ")" ... in other words, between each pair of items inside the "(&nbsp;...&nbsp;)" there should be just one ordinary space. Otherwise, I'm impressed by your work on shortening the Palestrina page ... and ultimately shortening the work of those of us who have to add stuff by hand.

As an additional comment, I would suggest replacing the "&nbsp;&nbsp;&nbsp;''2 editions available''" with " - {{editions|2}}" (and similarly for more editions) as a means of shortening the page, as well as making these additions uniform across the board at CPDL.

 Help 

Please see my comments on my talk page in reply to Chuck as to why I think using Template:Editions on composer pages as well as score pages is a bad idea.

 Help 

... And see my reply/comments to Rob's comments on his talk page.

Edit: Note that using the editions template on the Palestrina page has reduced its size from 32Kb to 29.5Kb.

Lyricist template

 Help 

I am doing some tests with a template that mimics the {{Composer}} template, which I have conveniently called "{{Lyricist}}". Just as the Composer template, it creates a link to the lyricist page and inserts the score page into [[Category:"Lyricist name" texts]]. Please have a look at the test category Torquato Tasso texts and give your opinions. I intentionally left two descriptions in this category because I couldn't find the best wording, am open to suggestions.

Once again, as with the "Text Categories", the idea behind this template is to decrease the amount of editing necessary to keep CPDL up-to-date. Whenever a new score page is created that uses this template, the page will automaticaly appear in the lyricist texts category, and the lyricist page won't need to be edited to include a link to the new score page, because it already has a link to the texts category, which should suffice.

 Help 

That looks good to me, Carlos. Thanks for your efforts. I prefer the second wording. Also, I think it would be a good idea to include all information about a lyricist on the same category page. Good work!

 Help 

Looks good to me, too, and (like Rob) I also prefer the second wording. I'm assuming that biblical and other canonical texts will not have a lyricist assigned to them. Also, in a growing number of instances, the Lyricist field to a works page is just one of at least three references to the lyricist on the page (Lyricist, Description, and Text-translations fields), so I ask: Is this really necessary? To me it seems to verge on overkill. Note that, usually the composer's name generally gets mentioned once (in the Composer field), rarely twice (Description field).

 Help 

I agree, Chuck. Let's have the lyricist/source of lyrics only in one place on the page, under "Composer".

 Help 

Hi guys, thanks for your feedbacks. Rob, the idea of including all the lyricist info on the same category page sounds good to me. I think it will look better especially in those cases in which the lyricist category has only a few entries and that page would look too "empty". And Chuck, what I had in mind was to apply this template at first to only a handful of lyricists, because the majority of them still haven't a biographical page or have just one work available at CPDL. I also agree that there is no need to put extra references to the lyricist; I've been usually using the Descrition field just to inform what work is the text from. As for my phrase wordings, both of you please remember that English is not my first language and always feel free to correct my text translations and phrases that may sound awkward to your ears.

 Help 

Hello John, I saw that you moved all Shakespeare information to the category page, as you suggested. I had done the same for Torquato Tasso, but then I remembered that it would affect the Category:Lyricists and reverted the edit; it divides that category into two kinds of entries (pages and subcategories), and in fact I didn't quite like the way the subcategory entries look like, all ending with "... texts" instead of just the lyricist name. It also breaks the logic of the {{WikipediaLink}} template that follows the biography. Do you think it is worth doing the move even so?

 Help 

It was actually I who moved the info around, Carlos, and yes, I do think that it's a worthwhile change. Having the works listed on the same page as the biographical info makes sense to me - why have them on separate pages, forcing the user to load another page? I agree that the separation on the lyricist cat page and WikipediaLink not working is a nuisance but I think it's a fair trade off given the ease at which a score page is listed on the lyricist page. As for the "texts" title thing, we could just change all the lyricist cats to be "Firstname Lastname", not "Firstname Lastname texts". This might cause a problem when we get to individuals who are both composers and poets though...

 Help 

Take a look at Lyricists now, and you'll see that the "William Shakespeare texts" category no longer appears as a sub category, and there is a listing for "William Shakespeare" under "S" in the "Pages in category..." section. The solution is simple: on the redirect page William Shakespeare, simply add [[Category:Lyricists|Shakespeare, William]] ... and on the William Shakespare texts page, change the "Lyricists" category to something like "Lyricist text categories" (which I have done as an example). This seems to maintain the homogeneity of the Lyricists category.

Edit: This also makes it easy enough migrate a lyricist page to a category, putting the appropriate redirect and category on the old lyricist page after moving the contents of the lyricist page to the new lyricist (text) category page.

Might I suggest one change though? Instead of having, eg. the William Shakespeare texts category, why not simply name the category Category:William Shakespeare (of course the redirect on the William Shakespeare page will have to be changed to point to the William Shakespeare category). This would solve an issue that was bothering me when I first read the above posts ... namely that "texts" seems to imply (to me, at least) that there are links to the actual texts, which is what English texts does, for example.

 Help 

That's a very good solution, thanks Chuck!

 Help 

Hmm I'm not sure that naming the lyricist categories as just a name is the best idea. I mentioned earlier in my reply to Carlos that this might cause a problem when we get to individuals who are both composers and poets... I think it would be good to have another word after the name. Perhaps "William Shakespeare settings"?

 Help 

Bingo!! That's an excellent suggestion! Thanks Rob.

 Help 

I've just altered Torquato Tasso and William Shakespeare as we agreed above. However, I'm not entirely happy with the wording of the overarching category, "Lyricist text categories". Any better suggestions?

 Help 

How about just "Lyricist settings"? I'm not happy with "Lyricist text categories" either ... it shouldn't be necessary to have the word categories in part of the name of a category.

 Help 

Hi Chuck and Rob (not John, sorry for the confusion above), my internet connection was down in the last couple of days and I couldn't follow up the developments you were doing, but the solutions you both came up with are fine to me. I didn't know one could categorize redirect pages! -- CarlosTalk 16:02, 3 July 2008 (PDT)

Semi-automation now available

 Help 

Hi friends, I have some good news, especially for those of you who do a lot of editing. After some unsuccesful attempts at using AutoWikiBrowser (a Wikipedia tool) to implement some automation at CPDL, I finally came up with a satisfactory alternative: UltraEdit Macros! UltraEdit is an excellent text editor that I use a lot, but I had never played with its Macro features before. Then I read somewhere that these macros can execute "Regular Expressions", a very powerful "language" that allows for advanced find/replace and logical operands. I started creating a couple of macros and the results are impressive: As an example, please see the last edit done to Nun will der Lenz uns grüssen (Udo Baake). It was completely automated, the only thing I had to do was to copy the code from the CPDL site, paste it into UltraEdit, run a macro and paste the result back to the score page. I know the work is still in its beginning and will still need lots of refining, but I believe we can already say goodbye to those tedious repetitive edits. :) CarlosTalk 17:02, 14 June 2008 (PDT)

New template - copyright warning

 Help 

After seeing all the new Vaughan Williams scores popping up, it occured to me that it might be a good idea to have a template to sit at the top of composer and score pages to indicate to users that the work is public domain USA, but it may not be public domain in their own country. I've started on this template at Template:CopyrightWarning though I'm not satisfied with the wording yet. Suggestions and alterations are welcome.

How should we handle entries for composite works, where two separate "works" are in the same file

 Help 

The work recently submitted by Sabine Cassola incorporates two sections of "Officium Defunctorum", namely the 5 part SATTB "Circumdederunt" and the 4 part (SATB) Invitatorium "Venite exultemus". Should two entries be put into the composer page both pointing to the "Circumdederunt me (Cristóbal de Morales)" page ? In the current situation someone looking for the "Venite exultemus" section of the work would probably not find it.

 Help 

I suppose it's a question of the work - is it really two separate works or is it indeed a single work which should be on a single score page? If it is two separate works, then a link to one score page from the other should be fine. If it's one work, merge the pages.

How should we handle entries for the second editor

Moved to ChoralWiki:CPDL support, help, and feedback#How should we handle entries for the second editor