User talk:Feldmahler/archive19


Copyright tagging - a few suggestions

Hey feldmahler. I have been thinking, and I've noticed a few things about the tagging system that could do with changing (although not absolutely necessary)
1. The tag history should probably have undo buttons. One mistype on mass-tagger can cause a throbbing headache of 10-plus submissions in need of retagging. Also, perhaps the mass tags could be grouped as one (with an expansion button) in tag finder?

In such a case, I would suggest to just back up a page using the browser and retagging over the bad tags... having a full history control function for the copyright system is a huge duplication of the wiki system that I would perfer to avoid if possible.

2. For multiple file uploads, could the tags be linked somehow, or grouped in such a way that editing one would change them all? This could save a lot of time, for obvious reasons.

This would theoretically be possible and less complex than #1, but I would still perfer to avoid the mess unless this is a big issue. I generally prefer the system to be as simple as possible to avoid both maintenance headaches and usage headaches for new users, even if it means slightly more work on the part of experienced users. In the long run it is much easier to use and prevent bugs in a simple system.

3. We use 5 tags extremely commonly, and perhaps a link (a sort of "bookmark") on tag edit, or, even better, tag finder, could be useful. The tags are: V/V/V, C/V/C, N!/N!/N!, V*/V*/V*, and V*/N*/V*.

This is ok, though I would rather leave to Leonard to implement once he gets control of the code (I'm currently working on wiki upgrade to Mediawiki 1.14).

These are not immediately necessary, but they're just ideas.-- Snailey Talk to Me Email me 08:52, 3 May 2009 (EDT)

Thanks for the ideas! I always welcome them, even if I can't implement them (or at least not immediately). --Feldmahler 02:32, 4 May 2009 (EDT)


Dear Feldmahler, I don't know if you already are aware of this, but I'd like to draw your attention to it anyway. Two work pages have been edited to include links to porn sites in the Misc. Comments section- 'A Farorite [sic] Lesson for the Harpsichord or Piano Forte', by William Goodwin, and '12 Etudes in All the Minor Keys, Op. 39', by Alkan. The username is Mazyy, and he/she appears to have no other contributions to the site. My view is that this is simply a disgrace. I know that you are up to your neck in this project anyway, but my personal hope is that action will be taken against this juvenile vandal. --KGill 16:43, 13 May 2009 (EDT)

Taken care of (thanks, PML!)-- Snailey Talk to Me Email me 20:55, 13 May 2009 (EDT)

Page size

Hi Feldmahler,

Your name is listed as the uploader of Fantasy, Op.49 (Chopin, Frederic), for which first of all many thanks! I wonder if there's already been discussion somewhere about whether to offer scans at both letter and A4 sizes. It would certainly be nice to at least get a warning! All the best, Richard Mix 17:54, 20 May 2009 (EDT)


Hi Carolus, I have translated the main page in to TRADITIONAL chinese. It is the page 首頁. (The current chinese version is SIMPLIFIED). Please add this into language list. This language is called 繁體中文. Regards,Notnd17:55, 27 June 2009 (EDT)

Thanks for the notice, Notnd. I'll copy your message to Feldmahler and to Leonard, since I'm more involved with the copyright end of things here. Thanks, Carolus 14:22, 27 June 2009 (EDT)
Forgive me; I added it in such a way that sort of works - unfortunately, that seems to be one too many languages for the current layout. I'll leave the fine-tuning to Leonard.-- Snailey Talk to Me Email me 15:05, 5 July 2009 (EDT)

Not dead & CC

Hi Feldmahler, haven't been around much lately (explanation on my user page). Guess I will be very busy for the rest of the summer, hope to be more active here again later this year. Anyway, if there's anything I can help with without investing large amounts of time, feel free to contact me at any time.

Also, you might want to take a look at this: We don't have very much content here on the wiki, but maybe it would nonetheless be a good idea to switch to CC. What do you think? --Leonard Vertighel 14:14, 30 June 2009 (EDT)

I had wanted to switch to CC a long time ago. But the problem is that the copyright is distributed, and thus I do not know if I can switch to CC. GNU did a smart thing by requiring all contributors to transfer copyright to GNU. How did Wikipedia manage to switch? Wikipedia is also right that probably the only reason IMSLP chose GFDL is because of Wikipedia, and so they do have some responsibility ;-)
Also, there is one important thing you can try to investigate. The main page CSS is horribly broken under Mediawiki 1.15. The main problem is that the right hand column is below the entire page instead of where it should be. I'm working on the backend code, so I don't have time to investigate this. May need to force a switch to 1.15 with this bug if it does not get fixed within the next 3 weeks (that's the ETA for the 1.15 upgrade). If you want I can e-mail you a saved HTML/CSS copy of that page. --Feldmahler 15:00, 30 June 2009 (EDT)
Here's some more info from the CC blog. It seems to me that we can do it just like Wikipedia/Wikimedia did -- then again, you are the legal nerd here ;)
I'll try looking into the layout issue. --Leonard Vertighel 16:26, 30 June 2009 (EDT)
My main concern is that IMSLP is actually licensed under GFDL 1.2 with no update ("or later") clause. Hence the section in GFDL 1.3 that allows re-licensing under CC-BY-SA seems to not apply to IMSLP. I still have not figured out whether GFDL 1.2 allows updating to 1.3 without the update clause. I assume it does not. Perhaps you can ask on Wikipedia about this?
The good side of things is that IMSLP is not content-intensive; in fact, much of the content is not copyrightable anyway (facts). And so even if GFDL has weird sections, its impact is minimal. My only concern is that there might be a time in the future when the impact would not be minimal. But what cannot be helped cannot be helped. I'm not sure why I did not have the update clause in the first place. --Feldmahler 19:28, 30 June 2009 (EDT)
Frankly, I'd suggest just asking the community, and if there are no serious objections, go ahead and switch anyway. The links in the page footer actually point to the text of version 1.3 rather than 1.2, therefore I would assume that if anyone had serious concerns about the (version number of) the license, they would have spoken up already. The spirit of the license is exactly the same anyway. --Leonard Vertighel 02:05, 1 July 2009 (EDT)
Seems to me the problem was caused by some broken markup in IMSLP:News‎. Apparently the code that tries to fix such stuff acts differently in MW1.15. We have some users who enjoy messing with XHTML/CSS without really understanding what they are doing.... Anyway, let me know if it works now. --Leonard Vertighel 17:26, 30 June 2009 (EDT)
Thanks! I will check in the next few days when I work on the update. --Feldmahler 19:28, 30 June 2009 (EDT)


FYI, MP3 sale is currently available also on Amazon UK, Germany, and France. You need to be resident in one of those countries to be able to buy MP3s (which I find somewhat infuriating, despite the fact that I could circumvent this restriction via my contacts in Germany, but I digress). Here is a link to the UK site, which also links to the corresponding German and French sites:

--Leonard Vertighel 03:04, 8 July 2009 (EDT)

Thanks for the note. Depending on what happens to the upgrade you may need to implement this feature instead, since I will have my hands full for a while. --Feldmahler 20:10, 8 July 2009 (EDT)


Just saw the notice, and I was wondering: are you actually using the script I sent you to return HTTP/503 during the downtime (to avoid polluting the search engine results)? You never replied to that... --Leonard Vertighel 10:15, 8 July 2009 (EDT)

Yes I am. During this upcoming downtime the web server will be offline entirely however, which shouldn't pollute search engines I hope.
Also, do you know why all the links on IMSLP are so... red? Its like this in both Konqueror (KHTML) and Arora (Webkit). It is a little scary since I cannot find the cause of this. --Feldmahler 20:10, 8 July 2009 (EDT)
Dunno, on my machine with Konqueror 4.2.4 the only links that appear red are the... "redlinks" (i.e. the links to non-existent pages). Did you try Firefox or some other browser? --Leonard Vertighel 02:27, 9 July 2009 (EDT)
It is not completely red; it is more like blue+red. The link color is noticeably different between external links (which are the normal blue) and internal ones. Happens in Firefox too, and also on my other laptop. The local copy of IMSLP on my computer is not affected. I just noticed this last night. --Feldmahler 07:35, 9 July 2009 (EDT)
Well, I did change the color of internal links (only the unvisited ones) recently to better match the other colors in the work templates etc. However, the new color is #003d70, in particular it has 0% red. If you see red, then either your browser or your screen is broken, or you have an anger management problem :P
Incidentally, the visited link color is purple, which actually is blue+red. However this color has been the same all the time, and it is also the same on Wikipedia.
If you think there is something wrong, you could upload a screenshot. --Leonard Vertighel 11:06, 9 July 2009 (EDT)
Ahh... well this explains it. You see, I'm red/green colorblind, and so will mistake a small amount of green for a small amount of red. I actually thought the visited link is blue, but purple explains the problem as I see purple = blue unless there is real blue right next to it for contrast. Everything is fine then :) (You see why I shouldn't be in the site design business?) --Feldmahler 11:49, 9 July 2009 (EDT)
Actually you should be in that business... red/green blindness being one of the more common, you can tell if the present colors are still sufficiently distinguishable from each other. I know that there are other types of colorblindness, but making the site "red/green safe" would certainly be a good start. So please give me a shout if you find anything hard to recognize or distinguish... --Leonard Vertighel 12:01, 9 July 2009 (EDT)


Some weird bug - the #makedate made "12. Juli 2009" so I just added a manual version, which fixed it. Weird. -- Snailey Talk to Me Email me 12:01, 8 July 2009 (EDT)

Probably has something to do with caching and language detection. Thanks for fixing it! The problem is most likely limited to the sitenotice. --Feldmahler 20:10, 8 July 2009 (EDT)

Language Selector

Was this a feature that you were planning to implement on Sunday? When it's over, I'll be interested to see the news article which should hopefully have all of the changes, so I won't have to root them out...;) I assume that one is going to be adding the new composer template.-- Snailey Talk to Me Email me 17:15, 10 July 2009 (EDT)


Hi, Getting lots of "500 - Internal Server Error" messages. Also, the copyright tagging does not work at all. All I get is a blank page after hitting the submit button. Thought you'd like to know. Carolus 16:19, 12 July 2009 (UTC)

The 500 errors are mainly because of server overload due to all of the caches being cleared after the upgrade (i.e. the server has to create everything from scratch when you request a page). This problem should hopefully be gone after about a day when the server has finished building up the cache again.
Also, apparently the MSN indexing bot has decided to attack the site with ~20 queries per second, and is ignoring my command for it to slow down in the robots.txt, which is contributing to the server overload. One can always count on Microsoft to be greedy, especially when they have a new toy. I'm trying to figure out a way to stop it for good.
Basically, when you get a 500 error, it means that the server is so overloaded that it is not able to handle your request. You can simply refresh the page.
Also, the copyright tagging issue should be fixed now. Do tell me if you bump into other problems. --Feldmahler 16:57, 12 July 2009 (UTC)

Thanks, the copyright tagging is fine now. Things are working better, too. I've noticed an unusual number of new users signing up today. I don't know if this is for real or if it could be a prelude to another attack by our "friend" InfoPanda. He's been nailed a couple of times after the big vandalism a few months back, so I always keep an eye out. Carolus 05:19, 13 July 2009 (UTC)

Well... the wiki actually never logs user account creation before, but apparently has started logging them (perhaps that is why it feels like many people are signing up). I think it is a very nice anti-vandalism function. InfoPanda will have one more thing to deal with when he comes back :) --Feldmahler 13:57, 13 July 2009 (UTC)
Maybe it's just me, but it seems that:
  • #iflang always displays English, regardless of user settings;
  • the site logo always links to the English Main Page, regardless of user settings;
  • IMSLP:Select_Language does not work for unregistered users.
--Leonard Vertighel 12:13, 13 July 2009 (UTC)
  1. This is a bug, I have fixed it in my offline copy, will upload at the end of this week.
  2. This is a change, though perhaps not a user-desirable one. It certainly is a programmer-desirable one since the old implementation was horribly convoluted and involved much patching to Mediawiki code itself. The current implementation is basically using only the LanguageSelector extension, which admittedly has functional drawbacks, but is much cleaner and simpler. I always prefer simple over functionality unless the functionality is essential ;) Since people can always just click on the link, I would rather leave things as is.
  3. Well, it does, except that you have to manually clear the cache (refresh) every page that you visited prior to using the selector (this includes the selector page itself). I can't think of a workaround. The reason registered users don't have this problem is because pages are not entirely cached client-side for them (server has to send page every request).
--Feldmahler 13:57, 13 July 2009 (UTC)

Just curious

What's up (sitenotice)? --Leonard Vertighel 18:36, 13 July 2009 (UTC)

Mediawiki 1.15 is using massively more CPU time than 1.11. Currently the server is way overloaded; load hovering around 12, with only 2 cores (with 1.11 the load was between 1 and 3). I am going to add aggressive caching and other optimizations on Saturday. I did a 12 hour programming marathon yesterday, which only fixed part of the problem.
I think it also has something to do with the fact that the MSN index bot is 1) sending 10-20 queries per second, and 2) requesting the RSS and Atom feed, "What Links Here" and etc. of every page (which is, I would think, a very CPU consuming process since it cannot be cached). And so I'm going to look into setting up a sitemap for Mediawiki. If it still doesn't behave, I may just ban the entire range of Microsoft IPs with the webserver. Microsoft's bots have always been extremely abusive while ignoring the robots.txt, even before the upgrade. Incidentally, they were most of the time banned before the upgrade (but the banning script is now apparently using way too much CPU, something I will fix on Saturday). I guess catching up to Google isn't that easy. --Feldmahler 18:50, 13 July 2009 (UTC)
How about starting by excluding all that stuff via robots.txt (as I suggested, like, five million years ago). You could start with something like this:
User-agent: *
Disallow: /index.php
Disallow: /wiki/Special:WhatLinksHere
Disallow: /wiki/Special:Search
Disallow: /wiki/Special:Random
I think this shouldn't break anything, and it might reduce the load significantly (as soon as the bot rereads the robots.txt, don't know how often it does). --Leonard Vertighel 19:00, 13 July 2009 (UTC)
Now that is a very good idea. Unfortunately I don't think I was around 5 million years ago ;) Was considering copying Wikipedia's robots.txt, but a simple one like yours is probably better for starters.
Still, I have to figure out what the other reasons are before Saturday... --Feldmahler 19:17, 13 July 2009 (UTC)

By the way, the robots.txt checker at claims about your current file: "You forgot to add a Disallow line in this block of code. You MUST insert at least one Disallow command. Please, remove all the reported errors and check again this robots.txt file." --Leonard Vertighel 19:49, 13 July 2009 (UTC)

New users

I noticed Carolus's comment, and either we are expanding much much faster, or some sort of vandalism is headed. If you can, you need to put the "rollback for this user" feature into play ASAP, because a multiple user attack could take a while to clean up. Perhaps this is something that could go on the list for Saturday's maintenance (as if you weren't busy enough....)?-- Snailey Talk to Me Email me 21:32, 13 July 2009 (UTC)

Did you also read Feldmahler's reply to Carolus' comment? "Don't panic"... --Leonard Vertighel 21:35, 13 July 2009 (UTC)
42.-- Snailey Talk to Me Email me

Category counter

The category counter function which I sent you, like, three billion years ago, seems to work also with MW1.15. It could be used to display the actual work count on the Main Page, and more interestingly, in conjunction with #ifeq it could be a nice possibility to host composer pages for composers for which no works have yet been uploaded, without cluttering the main Composer category. (The idea would be that empty composer pages would be by default categorized under Category:SomenameIhaventcomeupwithyet, and as soon as a work page is added to the composer category, the #ifeq makes the composer page switch automatically to Category:Composers.) Unless you have a more efficient solution... What do you think? Any chance this is going to be implemented within the current geological era? :P --Leonard Vertighel 12:07, 14 July 2009 (UTC)

Oh... I don't know... might take a few trips to Millways before that happens ;)
Jokes aside, a few issues:
  1. I'm currently focusing on making this thing actually run to any satisfactory speed. And so any other feature is going to have to wait.
  2. The query is not cached (at least in my memory of the function), so it is expensive.
  3. While the function may work, MW1.15 has its own category counter that is cached. An (iron) rule for IMSLP extensions is that they should never reimplement Mediawiki functionality. In fact, I spent most of the last month removing/replacing functionality in IMSLP MWE (MediaWiki Extensions) with its native equivalent. I'm sure a quick trip to CategoryPage.php will reveal how to tap into this source of information.
  4. Won't it be more of a problem if the page isn't in the Composer category? Users will think it doesn't exist, and try to create another one, which will either 1) frustrate them because the add composer page tells them it already exists when they can't see it, or 2) succeed because of spelling differences, which makes the entire point of empty categories moot.
  5. If you still really want to write this function, I'm going to leave this as an introductionary exercise when you take over the programming in a month or so. Though god knows there are enough things to fix (that are IMO more important) in the code besides this ;) (I can send you a list). I will also send you a style guide, and will comment on all the code you add at the beginning of your reign. Main lesson: simplify, simplify and then simplify some more. And duplicate code is evil. Keep away from it like the plague.
P.S. I've fixed the robots.txt and #iflang.
--Feldmahler 13:08, 14 July 2009 (UTC)
The general issue has been discussed multiple times on the forums: On the one hand, people want pages for unhosted composers. On the other hand, IMSLP is a library and not an encyclopedia with a few scores interspersed throughout. Therefore, I think we need some means to list only those pages from which one can actually download something -- unless we are going to reject the idea of unhosted composer pages in the first place. Personally I don't care all that much either way - after all, for mere info there is Wikipedia. --Leonard Vertighel 13:52, 14 July 2009 (UTC)
Well... it may be wise to somehow amalgamate the current system (see Stravinsky) with the composer FTE template (which is now being used), and any other functions used. I think that this problem is not easily solvable. For example, if you have a category with only composers with work pages and advertise that on the main page, then people will only use that category, and we are back where we started. On the other hand, making everyone use the all inclusive category will defeat the entire purpose.
I personally would purpose this: all empty composer pages with no work pages and the composer being public domain should be deleted, since most of the time people create composer pages to add files to it (and so generally this deletion won't be triggered). For composers prone to re-creation while being non-PD (like Stravinsky), we should put a note, or some sort of indication on the page (we can even, like Carolus suggests, simply remove the add-workpage link). This stuff can all be implemented automatically via the composer FTE template I believe. I would accept having a few empty composer category pages as the cost of preventing people from recreating Stravinsky a few hundred times... --Feldmahler 14:28, 14 July 2009 (UTC)
By the way, since I'm supposed to understand this thing sooner or later: Why is an uncached query a problem? I was under the (apparently wrong) impression that the page as a whole is cached anyway. --Leonard Vertighel 13:55, 14 July 2009 (UTC)
Mediawiki has many many layers of cache, for what I think is a good reason. My objection above is based on the fact that since Mediawiki goes to the trouble of caching it, it must be worth caching (since they know the architecture better than either you or me). Regarding caches themselves, there are multiple layers because there are many different ways of requesting a page, for example:
  • Anonymous user wiki page requests are cached via HTMLFileCache.php, which is the most thorough cache available. Currently only the English language is cached this way; I am going to change this on Saturday by patching HTMLFileCache.php (used to be multi-language, but I thought I could get away without; apparently not).
  • Logged in user wiki page requests must be generated using the parser cache of that page in question plus sidebar, etc.
  • All requests (anon and user) for non-standard pages (e.g. Categories with &from=, &until=, &intersect=) cannot be cached beyond the page text. Default Category view for anonymous users, however, is cached via the file cache.
  • All IMSLP FTE templates and FTE/SpecialPage translations are cached via Memcache. The autotagger also uses Memcache. Mediawiki itself does not, because it would be a big change and I have not tested it (plus, the objectcache table in MySQL is most likely memory-cached to a certain extent anyway).
  • Many Mediawiki objects are cached because creating them is expensive (in particular the Title object has two levels of caches).
  • Etc, etc. You will see everything when you see the code. In fact, you might want to familiarize yourself with the general layout of the Mediawiki code (e.g. what are the most important files, what do they do, etc).
Note that caching also follows the KISS principle. Use as few caches as possible, in the most cache-efficient places. However, with a project as large as Mediawiki, multi-layer caching is almost unavoidable. Without multi-layer caching, the program cannot efficiently cater to a wide array of possible requests. I've slowly come to realize that even one "clean hit" (i.e. parser has to do everything from scratch) is extremely expensive. Almost all hits should use some level of caching.
--Feldmahler 14:28, 14 July 2009 (UTC)

My two cents - for composers like Stravinsky who have some PD-US works and are extremely popular but not PD in Canada, we could eventually get their category just to be a link to the US-hosted one....although that might create some liability if people ignore the legal warnings. The rest of them (Poulenc, Messiaen) would have to be deleted.-- Snailey Talk to Me Email me 17:52, 14 July 2009 (UTC)

If Pml complains again that we do not generally host empty composer pages, I'll send him to you Feldmahler. :P By the way, maybe it depends on the time of the day, but right now the wiki seems much more responsive. --Leonard Vertighel 09:06, 15 July 2009 (UTC)
Thanks to your robots.txt suggestion the wiki has generally been much more responsive. Unfortunately the load is still very high, so we are not out of the woods yet. But at least there seems to be light at the other end ;) I've already solidified a plan of action. --Feldmahler 14:34, 15 July 2009 (UTC)


Why do some pages like The Peyote Sonata (St. George Tucker, Tui) contain the non-existing template WorknotPD1964? I can't seem to find it in the MediaWiki messages. --Leonard Vertighel 23:28, 15 July 2009 (UTC)

I believe it is injected into the FTE template by the template function. Some FTE templates have a corresponding PHP function which injects otherwise nonexistent variables into templates as values (they have the format {{{int:<name>}}}, 'int' meaning 'internal' and not 'integer'). Just look for that in the FTE template and you will see where it gets included. The value itself cannot be changed via the wiki, but how the FTE template uses the value can be changed via the FTE template page. --Feldmahler 16:02, 16 July 2009 (UTC)
Sounds confusing. I'll try to make sense of it. --Leonard Vertighel 16:20, 16 July 2009 (UTC)
I'm too stupid for this. The basic page template is MediaWiki:FTE:imslppage, right? Apart from the __NOEDITSECTION__ magic word, it starts off with the heading =={{{msg:musicfiles}}}==, which translates to ==Music Files==, right? Yet, the non-existent template appears above this heading on the page. So where should I be looking for it? --Leonard Vertighel 15:15, 17 July 2009 (UTC)
Ahhhh... you meant the work pages. Sorry, I somehow thought you meant the composer pages.
The answer to your question is that this is exactly one of the reasons I said "god knows there are enough things to fix" above. I've already left a comment about this in the code for you to read. Summarily, the auto workpage tagger is the culprit, and it really should be merged into the imslppage FTE template. The problem is that if it is merged, it can no longer process <!--noautotag--> tags. And so we basically need to 1) merge the autotagger into the composer and imslppage FTE functions (easy), and 2) run a bot over the entire wiki which will translate noautotag tags into a template variable (not hard, but potentially headache inducing and slow).
I think I will leave the exercise to you ;-) (Actually, I just don't have the time before September.) --Feldmahler 15:50, 17 July 2009 (UTC)

Cache question

How long until the cache expires for unregistered users? You put the message in the sitenotice over 60 hours ago, but it seems to me that if I'm logged out, most pages still appear without the notice. --Leonard Vertighel 08:45, 16 July 2009 (UTC)

HTML file cache expires in 3 days. I can shorten this length if it looks like the server can handle the load after the Saturday maintenance. --Feldmahler 16:02, 16 July 2009 (UTC)
Well, maybe it sums up with some other layers of cache. When I'm logged out, most pages still appear without the sitenotice, which was restored about 70 hours ago. On some pages I even get the old downtime announcement for July 12, which was removed over 96 hour ago. --Leonard Vertighel 16:20, 16 July 2009 (UTC)
Did you make some change to the caching mechanism? It seems that suddenly all the pages are updated. --Leonard Vertighel 15:19, 17 July 2009 (UTC)
I ended up finishing the programming early, and so IMSLP already has the updates planned for Saturday. A consequence of this is that the entire file cache was cleared out.
Another consequence is that I finally realized what was wrong with what you reported above. Apparently I forgot that I had myself added the file cache time limit to 1.11; the new install in 1.15 does not have a limit. Pages were cached indefinitely until the page is changed. Problem with that is 1) it breaks the site notice as you noticed, and 2) it breaks the autotagger, since the autotagger can change depending on composer page edits. I have modified the file cache to include a 3 day limit now.
Since this past maintenance (2 hours ago) is hopefully the last of this upgrade cycle, please do report any problems before I solidify everything and begin working on the next thing in my very long todo list of life (which happens to be another IMSLP-related matter). ;-) --Feldmahler 15:50, 17 July 2009 (UTC)

Do we really

need those community thingies right there in the already extremely long sidebar, and are they really more important than, say, the search box, which by now is far off the first screen (unless you happen to use a 30 inch monitor in portrait orientation), which in terms of user experience basically means that it has ceased to exist altogether? Also keep in mind that the more stuff on a page, the more likely it becomes that users will ignore most of it. --Leonard Vertighel 15:49, 16 July 2009 (UTC)

Not to mention the fact that having external links (four by now) in the middle of the main navigation bar is seriously confusing. --Leonard Vertighel 15:53, 16 July 2009 (UTC)

Oh, I just put them there because I discovered the twitter page and thought it interesting. My changes are by no means absolute; do feel free to modify it if you have a good reason (and I believe you do). My taste in site design is not to be recommended ;) --Feldmahler 16:02, 16 July 2009 (UTC)
It's not so much a matter of taste... I'd expect our users to need the search function more frequently than our facebook profile, so they shouldn't have to scroll to get there. Maybe I'll find a spot for those links in the About pages. --Leonard Vertighel 16:20, 16 July 2009 (UTC)
BTW is te PLMP search still needed? --Peter talk 10:40, 23 July 2009 (UTC)
I've been thinking about this. I greatly prefer people use the IMSLP # of course, so perhaps PMLP # search is not necessary after all (it doesn't follow the file if the file moves to another page for example). Its just there because the search page was easy to write, and the IMSLP # button is too short so I needed something besides it ;) I'll leave it up to Leonard whether he wants to keep it or remove it. --Feldmahler 12:04, 23 July 2009 (UTC)

Protection -!

Could you please make me "advuser" - I can't edit the featured scores. I'll do more "upcomings" here for now, and paste them later. But please!-- Snailey Talk to Me Email me 02:39, 20 July 2009 (UTC)

The alternative, of course, would be to change the protection, but I have the feeling that you're testing something (or, you could make me a bureaucrat...:/)-- Snailey Talk to Me Email me 02:44, 20 July 2009 (UTC)
Actually, this is one reason why we need more Bureaucrats - in case of testing ;)-- Snailey Talk to Me Email me 20:02, 20 July 2009 (UTC)

My guess is that all instances of "advuser" should be changed to "autoconfirmed". (I gather that "advuser" was the ad-hoc name for "autoconfirmed" users introduced with the extension for semi-protection, which is now a core function of MediaWiki.) Unfortunately, admins are unable to do so. --Leonard Vertighel 21:03, 20 July 2009 (UTC)

That's what I figured - it would be great if that could happen now, however ;)-- Snailey Talk to Me Email me 07:11, 21 July 2009 (UTC)
I've known this issue (and had a fix for it) since way before you notified me above. The problem was that I did not have internet access (it broke) for the past 4 days. I'm back and this has been fixed. Leonard's conjecture is correct. --Feldmahler 14:02, 21 July 2009 (UTC)
P.S. In case you are wondering what has been fixed, all admins ("sysop") now have "advuser" rights. We still need to manually move all "advuser"-protected pages to "autoconfirmed"-protected for it to work properly. --Feldmahler 14:05, 21 July 2009 (UTC)
*Gasp* It is actually possible to survive for FOUR DAYS without internet? Whoa. --Leonard Vertighel 16:37, 21 July 2009 (UTC)
Actually, I spoke too early. My ISP decided that what I really needed was another day without internet, so I only got back my internet for real a few hours ago. Lets hope this time it sticks. --Feldmahler 01:54, 23 July 2009 (UTC)

OK, thanks. I'll remove the clutter now.-- Snailey Talk to Me Email me 15:56, 21 July 2009 (UTC)

Minor stuff I noticed.

  1. The file tag does not change automatically to "removed" when a file is deleted.
  2. The "Find CR tags" link gives a different default list now (the 47 titles that are not clear in Canada). Also that list now appears as the first 25 only, instead of the default of 50 as before.

That's it so far. In light of the increasing number of audio and you tube links being put in for "Non-commercial recordings", I wonder if a file upload page should be set up for sound files. Lyle Neff has uploaded a number of his own recordings to some place where you have to pick your way through the ads to download the MP3 to your disk. If the files were hosted here - or even at another server where they could play upon connection, it would be a simple matter to include these via the "|Recording=" feature available in the file section. Even a lot of the YouTube recordings feature a still picture or a block of text - no actual video. If Lyle (and others) wanted to, it should be a simple matter to extract the sound file by itself and upload. Carolus 01:17, 22 July 2009 (UTC)

I believe that secundo is what I asked for. Before, also N! tags were in this link, which made it useless. But Feldmahler, I think it's better that you use the same link as on IMSLP:Special:IMSLPTagFinder/MainText so that only nq/nq/nq files are in the CR list, instead of nq/-/-. The latter includes files that are let on the server for one or two years until they enter PD - we don't want to see them as CR files.
I also don't like the length of 25 (it's already filled when two sets of parts are uploaded, which is not so interesting with the OP coming), but I suppose you did this is for performance issues? If there is no reason, please change back to 50.--Peter talk 10:37, 23 July 2009 (UTC)
How about nq/nq/-? I'm just afraid that someone might accidentally miss marking something nq and we will end up never finding it.
The length of 25 is indeed for performance reasons, but I will change it back to 50. The tag list was extraordinarily slow before, but I've rewritten the underlying code, and it should be of reasonable speed even with 50 entries. However, it will be noticeably slower than the current 25, but still tolerable I believe. --Feldmahler 12:04, 23 July 2009 (UTC)


Nice, but where is the maintext for old imslp add file? I can't find it, and a link is probably in order. Indeed, I might change the new one for instructions with pURLS (unless you think that's a bad idea, of course)-- Snailey Talk to Me Email me 01:32, 23 July 2009 (UTC)

All of the add file pages use the same text I believe... Go ahead and change the current one. You can simply note in the text that it only applies to the old special page. That way people looking at the new special page will know what is wrong if they want to use pURLs. --Feldmahler 01:54, 23 July 2009 (UTC)

OK, it works - Congratulations!! The parts we were lacking for Beethoven's Choral Fantasy have now been uploaded this way. It's considerably more cumbersome than Sibley uploads due to putting in the long directory string, which is fileprocess/OP Project/accepted/<Composer-Title folder>/<filename.pdf>. That's OK since the only way anyone can know the path is if they have access to the FTP server. It should go faster once they start pasting the path and filename in. Carolus 07:51, 23 July 2009 (UTC)

Yes, people should definitely copy and paste the string. Perhaps they can even move the files to a directory with a short name at the root of the FTP account. Unfortunately there is no good way to automate it unless all the files are in separate directories and sorted properly (maybe using numbers at the beginning of the filename?). If that can be done, I can set up a page like Sibley's pretty easily. Tell me if that sounds like a good idea. --Feldmahler 12:04, 23 July 2009 (UTC)

B0rked page(s)

Hi Ed, take a look at this page and tell me why it's all b0rked up:,_Op.67,_No.2_%28Faur%C3%A9,_Gabriel%29 Daphnis 02:44, 23 July 2009 (UTC)

I'm not Ed, but I'd say you need to fill in the Piece Style. --Leonard Vertighel 05:55, 23 July 2009 (UTC)

Ok, thanks. Daphnis 11:30, 23 July 2009 (UTC)


OK, I think that either an open letter/forum thread fully explaining everything about this in one place is in order. And you're really good at that. (Incidentally, $10 or so should be coming your way from Amazon ;)-- Snailey Talk to Me Email me 19:17, 25 July 2009 (UTC)

Well... this is actually Carolus' project, so any major explaining I will leave up to him.
And so just a few notes here. 10% of the retail price of the score will go to Project Petrucci LLC (legal owner of IMSLP). Otherwise Project Petrucci LLC is not directly involved in the publishing/distribution of the scores. The scans that make up the scores will be taken from IMSLP of course. It has all just started, so we do not know where it will go from here. Carolus told me yesterday however that there are orders placed already.
Thanks for the referral fees btw :) --Feldmahler 20:17, 25 July 2009 (UTC)
Question: When purchased on Amazon do you get 10% from both people?-- Snailey Talk to Me Email me 20:23, 25 July 2009 (UTC)
Amazon doesn't give us 10% (you need a gigantic amount of referrals to get that). But I believe the 10% Serenissima gives Project Petrucci LLC is on top of whatever Amazon gives us.
I took a look at the thread, and it seems like one person misunderstood and thought IMSLP was going the profit way. I think what he doesn't get is that PLP is not, in fact, owned by PP LLC, but by Serenissima who gives us royalties. Serenissima is a real music publisher, unlike PP LLC which is still on track to reorganize into a true nonprofit in either the US or Canada when the time comes. --Feldmahler 20:36, 25 July 2009 (UTC)

OK, I changed the wording to make it absolutely clear how it works. -- Snailey Talk to Me Email me 20:46, 25 July 2009 (UTC)

Scheduled Maintenance at 1:40 AM?

Well, good news: The 503 thingy works. What was that about, though?-- Snailey Talk to Me Email me 04:58, 26 July 2009 (UTC)

That's there every night at 1:40. Nightly SQL backups. --Feldmahler 01:32, 28 July 2009 (UTC)


I recently realized that you haven't posted any of your own compositions here. Why is that? Just curious.-- Snailey Talk to Me Email me 18:44, 27 July 2009 (UTC)

Well, two reasons (I've considered it before yes):
  1. I haven't cleaned up the scores to be publishing quality.
  2. I don't feel they are up to the standard to be included in a "library". However, I don't mind uploading them, so if lots of people have interest I'd have no problem uploading them. --Feldmahler 01:32, 28 July 2009 (UTC)

Fwd: kcleung

Hi Leonard, kcleung has passed the CR test 9.5/10. You can assign him CR status now. Carolus 22:29, 27 July 2009 (UTC)

Ok, will do --Feldmahler 01:32, 28 July 2009 (UTC)


What happened? They're all messed up.-- Snailey Talk to Me Email me 01:36, 28 July 2009 (UTC)

How are they messed up? Seems fine to me --Feldmahler 01:40, 28 July 2009 (UTC)
Well, the colours were broken...seems to have fixed itself.-- Snailey Talk to Me Email me 15:08, 28 July 2009 (UTC)

"Discuss this piece" links are broken

There are plus signs where underscores should be. By the way, why are those links external anyway? --Leonard Vertighel 13:13, 28 July 2009 (UTC)

I'm not entirely sure why the links are external, but I've fixed it. Probably a holdover from the very early days. (as in 3 years ago) --Feldmahler 13:36, 28 July 2009 (UTC)
3 years ago? I wasn't even born back then. At least I think... can't remember. Short attention span. --Leonard Vertighel 13:39, 28 July 2009 (UTC)
Maybe I wasn't either. As they say, memories are just a contraption to explain the difference between the current state of affairs and our state of mind ;) --Feldmahler 13:49, 28 July 2009 (UTC)