User talk:Feldmahler

Free public domain sheet music from IMSLP / Petrucci Music Library

Jump to: navigation, search

Contents

Archive Pages for this Talk Page


Potential problem with robots.txt

Hi again, I just realised that by excluding /index.php, we may actually be preventing search engines from properly indexing the site: unless I'm overlooking something, it seems impossible to navigate large categories without using such URLs. (The strategy works for Wikipedia, where almost every page can be reached via wikilinks. On IMSLP on the other hand most pages are "orphaned" and can be accessed only via categories.) I don't have a solution right now. Thoughts? --Leonard Vertighel 19:50, 28 July 2009 (UTC)

I also realized this several days ago. But from the IMSLP lookingglass (which has lots of cool stuff, and which you will get access to soon ;) I see that the bots do crawl categories that are supposedly impossible to reach, so I wasn't too concerned. Wikipedia probably links to most IMSLP composer categories anyway. --Feldmahler 12:51, 29 July 2009 (UTC)
A little update: it seems that at least Google and MSN support the * wildcard in the disallow directive, so we could try to disallow only the /index.php URLs that contain an 'action', 'oldid', 'diff', or 'printable' parameter (others?). I'm actually surprised that those links do not have a 'nofollow' attribute.
I really would rather not break the Robots.txt standard. Many problem bots outside of the Big Three got tamed by it, and breaking compatibility might not be a good idea. And if I needed the Big Three to crawl all of the categories, it may be better to use the Allow directive instead of having to disallow every other possibility. If anything else, the Allow directive can be put under specific user agents and won't break other bots. --Feldmahler 12:51, 29 July 2009 (UTC)
Conversely, it's probably not so good that the alphabet links e.g. for the Composer category do have 'nofollow' (in terms of wiki markup they're external links). Any idea if there could be some trick to avoid this? I can't think of any right now. --Leonard Vertighel 07:50, 29 July 2009 (UTC)
Actually, for the latter there is $wgNoFollowDomainExceptions. --Leonard Vertighel 09:54, 29 July 2009 (UTC)
Well, I don't think this is a huge issue because all category pages have the "Next 200" link, which is presumably an internal link. The main problem is how to allow access to index.php for categories but nothing else. I think the correct resolution may be to use Sitemaps, provided that they override Robots.txt. Otherwise, I'd rather just count on Wikipedia and external sources linking in, or use an Allow directive for select bots that support it. I think I'll leave this up to you :) If you give me some Robots.txt code (using the Allow directive) before the weekend, I will include it in the maintenance on Saturday (no downtime btw). --Feldmahler 12:51, 29 July 2009 (UTC)
Sitemaps might indeed be the solution. Not sure if they override robots.txt, but then again maybe they don't need to. Everything that needs to be indexed is actually allowed, the problem is that crawlers may not be able to reach everything. Not sure how this affects page rank, which is still a problem for IMSLP. If the rank of individual pages depends on the link structure of the site (and not only on the sitemap if available), then the "next 200" links are probably not very good, because it puts the categories at the end of the alphabet very "far" from the Main Page (while the alphabet links put them all at about the same distance). I have to admit that this is mostly speculation however.
If we decide to disallow crawling of the full category listings anyway, then we might consider installing this CanonicalHref extension. It should help search engines identify links to redirects as pointing to the same page, and thus count them all towards the rank of that page. (It probably doesn't work properly with category listings, because the canonical URL will always be given as the initial page of the category listing.) I think Wikia still runs 1.14, but if you want I can test if the extension works with 1.15. --Leonard Vertighel 14:36, 29 July 2009 (UTC)
Scratch that, it seems to be a core function of 1.15. --Leonard Vertighel 14:45, 29 July 2009 (UTC)
The observation about the sitemap above is very good; I haven't thought about that. I might just decide to re-enable sitemaps on Saturday (sitemaps used to be enabled before the site shut down and the servers changed). --Feldmahler 19:32, 29 July 2009 (UTC)

New Template

I created Template:PopSection to try to stop people from creating redundant sectional work pages. I implemented it for Le Cygne (Saint-Saëns, Camille), as an example. Feel free to mess with it!-- Snailey Talk to Me Email me 20:03, 28 July 2009 (UTC)

Thanks for the note. --Feldmahler 12:51, 29 July 2009 (UTC)

One last message

And then I'll wait for someone else before the next one ;). I must take umbrage with the Song Cycle category - it's being used to include Opera like "5 Songs" which is not the same thing (Yes, Schwanengesang, I know). Is there any good solution?-- Snailey Talk to Me Email me 16:42, 29 July 2009 (UTC)

There is no good solution as long as we continue with this current horrendously broken categorization system. On the other hand, my programming time with IMSLP has almost run out, so this is a feature that will depend on Leonard. The main problem is not the programming; it is actually creating the consistant categorization system in the first place (for example, we probably should separate piece genre from piece structure). This will potentially be hard to do especially if we want to make it easy to use by normal non-musicologist contributors (for example, not everyone knows that Symphonies usually follow the Sonata form).
Unfortunately, this problem will only get worse as time drags on since there will be more pages to re-tag. On the other hand, designing an intuitive and comprehensive categorization system is also non-trivial, and we may be in more trouble if we make a major mistake in its structure. So we are caught between a rock and a hard place. I would, however, greatly encourage people to post ideas, or even entire categorization systems, as soon as possible, or else nothing will ever happen.
Barring a complete reworking of the categorization system, nothing can be fundamentally fixed. --Feldmahler 19:32, 29 July 2009 (UTC)
Why is the available Mediawiki categorization functionality not sufficient in order to implement a better categorization system? And what happened to the idea of using an existing library catalog system, was that discarded? I lost sight of that discussion at some point. --Leonard Vertighel 19:43, 29 July 2009 (UTC)
The single biggest problem with Mediawiki's category system is that they do not allow flexible searching. For example, if I want to find all the Baroque concertos that feature Flute or Oboe or Clarinet in them but is not written by Telemann (which is a fairly likely query, no offense to Telemann), Mediawiki falls flat on its face. Even with my category intersect hack, Mediawiki can only intersect two categories, nowhere near the 6 required (not to mention in an unconventional relationship).
Plainly speaking, Mediawiki categories are designed with searchability being the last thing on the list. The database design of it is such that the only efficient thing it can do is to find pages in a single category. Trying to make it do useful things between multiple categories is more painful than trying to pick up a tiny screw wearing a very thick glove. It is plainly not intended to be used as such, and, despite the fact that a bug report on Mediawiki not supporting category intersections has been filed several years ago (not by me I might add), no progress has been forthcoming. I don't blame them; it is going to be hell to make the current system efficient.
The one extension that may help us is Semantic Mediawiki. The problem with SM is that it is horrifically bloated feature-wise. SM was clearly written with the intention of being used in an encyclopedic wiki (which is why SM categories [or 'property' as they call it] creation is very cheap), and which, ironically I think, Wikipedia is not using. Using SM for a single highly customized categorization system is like using a hammer to swat a fly. It is hard to make extremely flexible for one specific task, and I have the feeling it is not going to be nearly fast enough. If you have time, you can try playing around with SM offline, but I'm not going to hold my breath for it to work.
However, if the new categorization system can be designed with some interesting approach, it can be very fast, simple and flexible. For example, putting all the categorizations in a MySQL TEXT field, and then running a regex fulltext match should be very fast (regex is frighteningly fast itself), and yet very flexible. The only drawback is that it will have to be a MyISAM table (InnoDB doesn't support fulltext searches), which means it is more liable to corruption (the same thing is used by the Mediawiki search function). But since this is a cached table anyway (ie. it can be regenerated if necessary), it probably doesn't matter.
But again, this is not the main problem. I can probably work out the programming with testing in a week. The main problem is figuring out a decent categorization system. I've seen the LoC music categorization system. It is extremely complicated, convoluted, confusing and conjested with needless subdivisions. It is something that only a trained librarian would be able to tackle without fear. I have a suspicion that many other systems are similar (not to mention not public domain like the LoC). I'd rather have either 1) a severely pruned version of the LoC, or 2) a categorization system designed from scratch just for IMSLP. I think Carolus had one he used before, but I haven't seen it yet... --Feldmahler 20:12, 29 July 2009 (UTC)

Your time running out...is this because of first MERLOT and then Harvard? I'm sorry if it is (then again, don't blame you).

Yes, I'm mostly gone after MERLOT. Even though Harvard is just across the River, I still have to move everything which is a pain (and hence why I'm gone after MERLOT). But you won't miss me, because Leonard will take over the programming with my supervision. He will need time to adjust (IMSLP's code is quite big even without MediaWiki), but I will check everything he does so there shouldn't be major problems. --Feldmahler 23:50, 29 July 2009 (UTC)

I think that the users should help decide - I say help, because it should ultimately be up to someone like Carolus. I think that this is probably one of the most significant fixes that needs ot be made to IMSLP (of which work is not almost complete - i.e. gen. info. boxes, etc.). So no matter how hard, it is very worthwhile.

Also, perhaps allowing admins to make new categories as necessary (obviously not regular users) might ease the pain, once it's in place.-- Snailey Talk to Me Email me 20:57, 29 July 2009 (UTC)

I think one thing that people forget is that I'm more than happy to have IMSLP contributors decide about a particular aspect of IMSLP. I will voice my opinions, and when I think something is way out of line I will not hesitate to say so and stop it. In all other cases, I am more like another regular contributor than people think.
With that aside, I think that creating new categories is a really, really bad idea, which is partly why I never did so even after dozens of people asked me to. First, contributors are basically wasting time creating and maintaining something that is already broken, and that will ultimately be scrapped regardless. This is especially the case since if I grant one exception, dozens of people will ask for all kinds of exceptions and category extensions. I'd rather people spend the time thinking about the new categorization system instead. Second, the category system is tied to the code. Without code changes new categories will be semi-broken. Code changes to extend a knowingly broken functionality is a generally bad idea, especially since energy is supposed to go into writing new and un-broken code.
Regarding community decision, let me say one more thing. I think it is a bad idea to have a loosely structured discussion to create a new categorization system. Everyone has their own idea of what a good categorization system is, and if we don't have some leadership in the discussion, nothing will ever happen. This is part of the reason why I sometimes called the shots even when things are not entirely clear: in many cases doing something is better than talking a lot and then doing nothing. And so, in essence, the new categorization system design is an IMSLP project, like all others. There needs to be a project leader (not me), and only then will stuff really happen.
Don't get me wrong; I do not oppose casual discussion of this. However, at some point there needs to be a project leader to drive things to actual fruition. I don't know who is interested in taking this up (it's a huge project)... perhaps we should have a forum thread about this. --Feldmahler 23:50, 29 July 2009 (UTC)
Before making any changes we really need to know what people want from the 'genre' categories. Do users want to be able to find all works that could be classed as "Symphonies", or "Motets", or "Suites"? Or is the instumentation they're more interested in, so bringing up lists of pieces for wind octet, for trombone and orchestra, for piano 4 hands, etc. would be more useful? It couldn't hurt to ask on the Forum... — P.davydov 21:37, 29 July 2009 (UTC)
I say: do so. I did say <quote> (yes I know this tag is forums only): think that the users should help decide - I say help, because it should ultimately be up to someone like Carolus</quote>-- Snailey Talk to Me Email me 21:39, 29 July 2009 (UTC)
Yes, do ask on the forum. (And see above.) --Feldmahler 23:50, 29 July 2009 (UTC)
OK, here goes — P.davydov 07:38, 30 July 2009 (UTC)

Oh well. I guess that kind of failed

Not to jump on you or anything, but you ruined my streak on recent changes ;) What is this new experiment?-- Snailey Talk to Me Email me 02:30, 30 July 2009 (UTC)

Oops, never mind. Found the forum. But you did ruin my streak...combo breaker...-- Snailey Talk to Me Email me 02:32, 30 July 2009 (UTC)
Hahaha! :) Let's hope other aspects of /b/ don't get in here... (No, I don't go there anymore; too insane.)
Btw, perhaps the PermissionGranted template should be limited to cases where there is external documented granting of permissions (in which case perhaps we can have a link somewhere)? Otherwise it just duplicates functionality in both the autotagger (the !--noautotag business) and the copyright reviewer (N!/N!/N!). I think Tui is fine as she granted permission externally (my memory may serve me wrong).
The other way is just to tie the PermissionGranted template to the file or page FTE template. There is an obscure way to do this I think... {{~ifeq&:crtag<>(some HTML code of the N!/N!/N! tag...)<>{{PermissionGranted}}~}} might work, though there is probably a much less painful way of doing it.
Anyway, just don't try to tag everything marked N!/N!/N! as PermissionGranted, as that would be duplicate I believe. :) Just an observation.--Feldmahler 02:43, 30 July 2009 (UTC)
OK, thanks. I've just been working on that as a side project (the Tui scores), and that was the template I made (i.e. the publisher and the PermGranted template.-- Snailey Talk to Me Email me 16:58, 30 July 2009 (UTC)

Paypal (forgetting about one of my previous posts)

Is the button going to be added again? What happened?-- Snailey Talk to Me Email me 01:43, 31 July 2009 (UTC)

Fixed, see IMSLP:Changelog (Leonard and I will be using that page to publish code changes from now on). --Feldmahler 14:38, 4 August 2009 (UTC)

Admin

In response to Snailey's message on my talk page, the answer is 'yes'. I'm more than happy to help out where I can, and thanks for considering me sufficiently worthy :-) — P.davydov 16:37, 3 August 2009 (UTC)

I also received a message, OK with me. --Leonard Vertighel 19:12, 3 August 2009 (UTC)
Done. Welcome to the team :) --Feldmahler 14:38, 4 August 2009 (UTC)
And the userboxes are added!-- Snailey Talk to Me Email me 14:39, 4 August 2009 (UTC)

Internal error #1

Transcriptions - Mozart: Andantino from Piano Concerto No.9 (K.271), BV B 84 (Busoni, Ferruccio) under Recordings - what is it? --Leonard Vertighel 08:39, 4 August 2009 (UTC)

This is just a transient error. It means that the server was not able to connect to Amazon.com. --Feldmahler 14:38, 4 August 2009 (UTC)

CC?

--Leonard Vertighel 06:14, 5 August 2009 (UTC)

I have decided against mass licensing change for the time being after doing some more research about the differences between GFDL and CC. The differences are, to put it mildly, huge, and I don't feel confident at the moment that we should fix what is not broken (at least yet), especially if the fix is huge.
The GFDL 1.3 mass re-licensing clause is essentially custom-tailored for Wikipedia, and will be very hard to use on other public wikis that do not follow the Wikipedia timeline without breaking something legally (August 1st is not the only deadline). I may be paranoid, but I would rather that the license of the text be clear and unified under a suboptimal license (GFDL) instead of what could potentially happen after a switch to CC. Which would be that some text might potentially still be single-licensed under GFDL 1.2, while others (the new stuff) are under CC, and still others are undefined. While I'm not sure anyone cares, technically speaking it is a legal headache, and a legal headache of any size is not something IMSLP really needs...
Plus, the August 1st deadline has already passed anyway. We might as well take our time to do more research instead of haphazardly trying to change the license. --Feldmahler 15:47, 5 August 2009 (UTC)
Considering that there was zero opposition on the forums, I remain of the opinion: you have been exposed to more legalese mumbo-jumbo than is good for your health. Actually, I even doubt if any of the contributors to this wiki have ever read and understood the GFDL at all.
Anyway, you're the boss... --Leonard Vertighel 17:35, 5 August 2009 (UTC)
Well, I agree with you and also doubt that anyone has read the GFDL (well, except for poor me). But I'm a little concerned about future problems. In any case, let's fix other things first. I just realized that I broke something in the code for a rare configuration... probably should fix that first. --Feldmahler 22:39, 5 August 2009 (UTC)

Autotagger - necessary?

Do we really need the autotagger for Non-PD works? We always end up either deleting it or putting noautotag on, which seems to me to be a ridiculous waste. Is there any particular reason why it's use is continued on works that are not PD anywhere?-- Snailey Talk to Me Email me 21:08, 5 August 2009 (UTC)

I should rephrase: for modern works that have been released (it gives the red box that looks rather ugly).-- Snailey Talk to Me Email me 21:08, 5 August 2009 (UTC)
This is a good point. However, I no longer have time to fix something like this. In fact, Leonard and I have been talking about disregarding noautotag altogether, so perhaps Leonard can fix this when he moves the autotagger into the FTE template. --Feldmahler 22:39, 5 August 2009 (UTC)

Great, thanks for the response. Sorry.-- Snailey Talk to Me Email me 22:46, 5 August 2009 (UTC)

OK, so I moved my requests to Leonard. He claims that he doesn't have access to any of the code, and therefore can't do much. This is going to put us in a bit of a bind if we have noone who is able to program. Therefore...something needs to happen. Thanks.-- Snailey Talk to Me Email me 13:25, 7 August 2009 (UTC)

How to Search a User page ?

It appears that the IMSLP General Search doesn't find "Jamaican" , although this is a key word in a title on my user page. The page is http://imslp.org/wiki/User:Clark_Kimberling/Historical_Notes_1 . Although the page has had 12000+ visits, the bulk of them must be coming from outside IMSLP. A few external emailers have mentioned they have trouble finding the page unless they have the address written or else get it from one of the print publications in which the address appears.

In total, there are 12 such pages of historical notes covering some 1500 melodies, with thousands of terms and titles that don't seem to be found by IMSLP's search.

Can something be done to make the IMSLP General Search find these terms and titles?

Thanks. Clark Kimberling 19:33, 8 August 2009 (UTC)

You can set the general search to search for user pages in your preferences.-- Snailey Talk to Me Email me 15:14, 10 August 2009 (UTC)

Language links

Hi Feldmahler, you wouldn't happen to know why several interwiki-style language links fail to work? See for example the Main Page language links in the sidebar: all the Asian languages have been commented out because the links don't work. I just tried to add Japanese and it fails as well. Any clues? --Leonard Vertighel 12:52, 14 August 2009 (UTC)

A code dive may be necessary. Especially pertinent is the IMSLP config (I think there may be some hard-coded stuff about languages there). I have a vague memory that interwiki links only work for two-letter country codes, so if you have dialects like zh-cn or zh-tw it may break. If that's not the problem, then I can't really think of a reason unless I code dive. (You can try it too! More exciting than a trip to Hawaii! ;)
But let me first fix other broken stuff (Amazon has started requesting authentication for search requests, which is why all Amazon searches are broken starting yesterday).
Just for reference, if you have time, the most urgent parts of IMSLP to work on are:
  1. The internationalization system. The code-side of things are fine, but the documentation is non-existant, which I think confuses translators. This is especially because the translation process is not intuitive in any way. We need to start doing good documentation of translation features.
  2. Documentation in general. This includes mostly the Fast Template Extension (FTE), which has lots of wonderful stuff that nobody knows about. (Well, ok, not that much, but I don't think many people know how to use them in the first place.)
  3. A new categorization system. But that's only after someone actually creates a decent classification system in the first place. --Feldmahler 14:19, 16 August 2009 (UTC)
New thing to work on: # lists don't work anymore! ;) (The problem was the line break in between each one. You should know better Feldmahler! ;)-- Snailey Talk to Me Email me 20:41, 18 August 2009 (UTC)
Hahaha, thanks. I was just too lazy to edit the page again. --Feldmahler 14:07, 22 August 2009 (UTC)

Genres

Answering your plea on the forum, I've just set up this page with suggestions for new genre categories. It will probably get shot down in flames, but at least it should get the ball rolling! — P.davydov 19:20, 16 August 2009 (UTC)

Very nice! If you want to take up this project as a project leader, please do so. I fully expect people to come up with good ideas, but there will be someone needed to resolve disputes, and to actually tie everything together and come up with a coherent system. That would be the task of the leader.
Also, I think the idea currently is that work genre (sonata, etc) should be separate from work instrumentation. Whether or not the separation can be possibly clean is another matter of course, but I think the general tendency is in that direction.
I also vaguely remember that Carolus had a classification system he created for something else, and which has this genre/instrumentation separation, so perhaps it may be a good idea to ask him if he would be willing to share this. That way, we have some concrete system to start working on. --Feldmahler 18:11, 17 August 2009 (UTC)

Thanks for the encouragement. As you may have seen, a few people have been asking if it's technically possible to have more than one genre category per work, i.e. one for the instrumentation, and another for the work 'type' (e.g. 'Nocturne'). Can you advise whether it's technically possible to add a second genre category to a) the existing works, and b) all new works?

Yes, this is possible.

The instrumentation genre would be relatively straightforward to map from the existing genres, but classifying by 'type' would require manual inspection of all 14,000+ scores to determine an appropriate label (and to be honest I'm not convinced that every work can be labelled in this way). Do you have any thoughts on the subject? — P.davydov 07:00, 18 August 2009 (UTC)

My suggestion is that while it is great to be able to automatically map the current classification to the new one, I do not want that to influence the design of the new classification. I've already prepared for the prospect of having to reclassify everything, and I do not want legacy issues to interfere with creating a more usable classification.
My advice is that the classification system should focus on making it easy to find what users are looking for, while at the same time balancing the demand on contributors (i.e. make it easy for contributors too). For example, the reason I didn't want to move the LoC system to IMSLP is because it is grossly complicated to use for contributors. On the other hand, the current system is semi-useless for users, so I do expect some level of increase in complexity. It is all about the complexity/usability ratio :)
However, the new classification system should not be a compromise due to legacy issues. We are still at the point when we can afford to break all legacy bonds, so we better use the chance before IMSLP grows to 100,000 works ;) Also, remember that while 16,000 work pages may seem like a lot, I also plan on having IMSLP stick around for a while. We managed to copyright review all 15,000 old files in about a year, and that is only with the copyright team. If we make changing work page genres easy for anyone to do, it probably would be pretty easy to reclassify everything.
What might happen is that some old classifications are automatically remapped to new ones, while others are reclassified manually. --Feldmahler 14:55, 18 August 2009 (UTC)

Understood, thanks. I think the instrumentation classification is the way to go, not because it's the most straightfoward to convert, but because it seems the most logical and the most likely way for people to want to search (and the forum discussions seemed to support that conclusion). But if you have reservations about this, or have something quite different in mind, then it's important to make that clear from the outset. It's difficult to imagine switching to a new system without the approval of IMSLP's 'founding father'  :-) — P.davydov 19:41, 18 August 2009 (UTC)

I'm fine with what the community comes up, especially since you are the leader of this project. Unless there is something grossly wrong, I do not like to dictate what project leaders should do :-) I will, of course, voice my own opinions as another member of the IMSLP community, but I will not force anything unless something goes very wrong. Take my opinions like opinions of any other IMSLP member.
You will also need to make some hard decisions as project leader if the community is unsure of something, which will probably happen at some point in this project. I'm fine with whatever you decide. I will just need to check the final result to make sure it works with everything else, that's all. --Feldmahler 14:07, 22 August 2009 (UTC)

Thanks. It's looking like we will need two kinds of 'genres' (or whatever they end up being called) — one based on the instrumentation (as already proposed), and the other more being descriptive (like 'Oratorio' or 'Sonata'). The first will be mandatory (probably through a drop-down list, replacing the current genres), the second will be optional, since it won't necessarily apply to all works. Is it possible at this stage to make provision for two categories, or do you need the details to be finalised first? It might help with testing to have the second field available in advance, if that won't cause a lot of work for you or Leonard? — P.davydov 18:02, 1 September 2009 (UTC)

Forums

They're down. What's up? See Yagan's talk, too.-- Snailey Talk to Me Email me 03:39, 21 August 2009 (UTC)

Some weirdness on the part of the forum's SQL server. I e-mailed the server admin and it is fixed as you can see :-)
Also, I received your e-mail about promoting KGill to an administrator. I'm happy to do that, provided KGill himself accepts (you can ask him if you haven't already). --Feldmahler 14:07, 22 August 2009 (UTC)

Admin

Hi Feldmahler,
After some consideration, I have decided to accept the offer. I hope to help out as much as I can! Thank you :-) KGill talk email 15:07, 29 August 2009 (UTC)

Done. --Leonard Vertighel 16:03, 29 August 2009 (UTC)

MediaWiki:Composerperiod-url/ja

doesn't work. MediaWiki:Composerperiod-url however does (tested by changing it to something else). Would you know why, or does this also require digging into the code? --Leonard Vertighel 16:33, 30 August 2009 (UTC)

And now we're talking about the language implementation, you should also once take a look at this old bug in which new languages are not displayed in the left pane. They also will not be able to autoswitch to the browser's language setting. These are commented out in OtherLangs:Main Page. Uncommenting them will produce a red linked text in the body of the page.--Peter talk 00:30, 31 August 2009 (UTC)
Actually that was discussed a few sections earlier on this very page. --Leonard Vertighel 04:45, 31 August 2009 (UTC)
Doesn't the reason of problem of MediaWiki:Composerperiod-url come from $wgForceUIMsgAsContentMsg on LocalSettings.php of mediawiki?--Supertchan 12:15, 1 September 2009 (UTC)
Supertchan is completely correct. This is a configuration problem with $wgForceUIMsgAsContentMsg in the code and not on the wiki. I believe the culprit is in IMSLPConfig.php --Feldmahler 13:36, 1 September 2009 (UTC)

Sitenotice

Hi Feldmahler, I know I keep bugging you rather than actually doing something, but... the sitenotice suddenly started showing up in Japanese rather than English for me (both logged in and logged out). Any clues what's going on? --Leonard Vertighel 08:51, 4 September 2009 (UTC)

I am not entirely sure what the problem is. The biggest likelihood would be that somehow the Sitenotice is cached without language distinction, resulting in the wrong language being selected. The Mediawiki Sitenotice is not the best integrated feature in Mediawiki, and bugs related to it seem to be many. I would try perhaps using #iflang: instead of the natural message translation system, just to eliminate the possibility of other reasons for the bug. Failing that, it might be a good idea to temporarily bar translations of the Sitenotice, as the fix will very likely be hard to find and messy. --Feldmahler 00:40, 5 September 2009 (UTC)
Actually using #iflang is exactly what Perlnerd did anyway... at this moment I see the message in English. Don't know if it was just a hickup or if it will happen again. --Leonard Vertighel 06:41, 5 September 2009 (UTC)

FTP

It's down - why?-- Snailey Talk to Me Email me 21:59, 5 September 2009 (UTC)

Performance

Still experiencing some slowness issues - especially with downloading scores (or viewing PDFs in browser window). Otherwise things seem much closer to normal. Carolus 05:12, 7 September 2009 (UTC)

This is actually part of the server move. There will be some slowness the first few days because of one little oversight on my part committed a long time ago, and which means that the new server will have to needlessly re-upload all the files to the mirror servers, in the process having to take all download requests itself.
Summarily: the server's bandwidth will be saturated for the first few days (especially at night), and hence the slowness. Unlike before, the slowness is not caused by server overload. After all the files have been re-uploaded (in 2-3 days I'd estimate), the server should be lightning fast. Considering the readings I get of the server load right now, I think upgrading was a very good decision. There should be no slowdowns even during the busiest time of day (~noon EST), or the busiest months (Oct/Nov).
Tell me if any part of the server doesn't work as it should. If everything works, we should be set for at least another two years without needing to move again. --Feldmahler 16:05, 7 September 2009 (UTC)

Well, in two years we might need to add another digit to the imslp numbers...;)-- Snailey Talk to Me Email me 16:18, 7 September 2009 (UTC)

Redirect at imslp

Regarding redirects from http://www.imslp.org/wiki/ to http://imslp.org/wiki/: you may be interested in the points raised at Wikipedia:Village pump (technical)#Template IMSLP broken and the other links mentioned there. -- Michael Bednarek 15:10, 14 September 2009 (UTC)

I will look into this this upcoming weekend. Unfortunately I have no time before then. I also cannot promise a complete solution (or any) because Lighttpd's redirect mechanism is screwy, and there is a possibility that a fix is, in fact, impossible without patching Lighttpd itself, something basically impossible for me to do due to logistics. Good thing we only need it for redirecting www. We've had this headache a while ago, and apparently it is happening again (or perhaps it had always been happening).
I also see that there is action on the Interwiki maps at WP, though uncertain as to the date of inclusion. Please tell me if WP resolves this problem before IMSLP does. There really should be no reference to www.imslp.org at all anywhere on the net. --Feldmahler 00:28, 15 September 2009 (UTC)
The shortcut scores: has now been fixed at Wikimedia. The templates IMSLP and IMSLP2 were fixed before that by avoiding the shortcut, and I think they should be left as they are now. I have no idea about the additional point TheDJ made about not redirecting spaces in URLs properly — probably not important enough to worry about. -- Michael Bednarek 09:09, 15 September 2009 (UTC)

Propositum pro Libellorum Musicae Bibliotheca internationali

Just noticed this and thought you might like it. Now we need someone to make us a Main Page in Latin. ;) --Leonard Vertighel 21:32, 15 September 2009 (UTC)

*looks at Leonard* Well... aren't you from Rome... ? ;) --Feldmahler 11:43, 16 September 2009 (UTC)
Actually, no. Besides, I'm not that old... --Leonard Vertighel 11:46, 16 September 2009 (UTC)

Genres update

Hi Feldmahler. Thanks for your message, and just to update you on the current situation:

  1. The list of instrumentation categories is more or less finalised, with probably a few tweaks needed here and there
  2. It's proven much more difficult to reach agreement on the more descriptive categories, and the chances of achieving a consensus on this don't seem good. Everyone has their own idea of what constitutes a cantata, motet, oratorio, serenade, etc., which doesn't necessarily agree with anyone else's  :-) In most cases the standard music dictionaries are unhelpfully woolly and contradictory in their definitions
  3. Without agreement on the descriptive categories, we could still go ahead with the instrumentation categories (I'm using the word 'categories' here because one regular poster objects strenuously to the term "genres")
  4. As soon as the new categories/genres are introduced we should expect cries of protest from people who didn't read the discussion because they didn't think it applied to them, but who are vehemently opposed to whatever new system comes in :-) I'll try to mitigate this with further postings on the forum
  5. We shouldn't expect more than four or five volunteers to convert the existing pages, and the process will take several months
  6. It might be helpful to set a 'deadline' for introducing the new categories, which should concentrate minds somewhat. I don't think it would be appropriate for me to do that (because it might seem like I'm trying to stifle debate on some of my own ideas), but maybe you'd like to suggest a date? — P.davydov 18:00, 16 September 2009 (UTC)
The last is a good point. However, I'll refrain from decreeing on this issue because I do not believe I'm in a good position to judge how much more time people need.
Instead, I will give you full control over everything that falls under the classification system project. Of course I will ask you to use this control in a fair way, to balance various interests that may arise, but since you are the leader of the project, you would be in the best position to make tough decisions.
The reason I chose you was also because I trust your musical judgment, so I do expect and am prepared for a certain amount of your personal preference in the end product. Obviously, I'd like that element to be as minimal as possible, but I am sure there will be situations where you will have to call the shots, and I do accept that.
Don't worry if there are disagreements. If need be, I will step in if there is some major problem (problem as in people being nasty and etc). If anyone doubts your authority to make a certain decision, let them post a message here on my talk page, and I'll address it.
Also, I'd rather have the entire system completed before you post it here. Perhaps you can post the system on the forum in its complete form prior to giving it to me so that people can give last-minute suggestions. Do not worry about post-release criticism, as I am aware of this and there will be no problem. --Feldmahler 20:44, 16 September 2009 (UTC)

Default messages

"DO NOT EDIT THE "DEFAULT" MESSAGE PAGE WITH NO /<language_code>. Editing it will result in noticeable performance impact (unless deleted afterwards)." (source)

This is what I had in mind when I said "I remember you saying that due to performance reasons, there should be no English versions of the messages."

I take it that the info on the Translation page is outdated and needs to be revised? --Leonard Vertighel 18:14, 1 November 2009 (UTC)

I think I was referring to the message pages for #imslpcomposer, #imslpwork, etc. That page was created Oct. 1st of 2007. IMSLP has changed immensely since then, and everything on that page should be taken with a grain of salt, and doubted unless proved. For starters, FTE templates didn't exist back then, and I have some doubt that the current IMSLPGetTranslations() function existed back then either (and in any event was without caching, hence the performance problem, which is almost nonexistant currently because of the cache). The amount of code changes between pre-UE and post-UE is astonishingly huge (in fact, more than half of the code was rewritten). --Feldmahler 14:47, 3 November 2009 (UTC)
I see... things are somewhat chaotic on the wiki, it's not always clear which infos are up-to-date and which aren't. --Leonard Vertighel 16:45, 3 November 2009 (UTC)
Always presume that the documentation on the wiki is out of date. I say this because I have really not updated the documentation after essentially rewriting the code. Many of the wiki-side features will remain constant because of backwards compatibility, but never assume the documentation is valid for the code itself; in fact, in most cases the documentation is probably not valid. This is why I had emphasized the need for code documentation before, and why I created the programmer portal (which I hope will develop into a much more extensive set of pages, if not a project in itself).
Also, I've been thinking about the JS infobox you wanted to implement. A word of advice: It may be a good idea to make form element creation (in this case the text boxes with the JS infobox) into a separate function. I say this because, as you may have already realized, the AddWork page has a different code structure for form creation than the AddComposer and AddFile pages. This is a remnant of ancient history, and it really should not exist (that and the recent additions list, as I noted in the code).
The AddWork page code structure is correct (using loops instead of ad verbatim HTML code), and it is probably a good idea to take this opportunity to correct the problem with the other two pages (a problem which extends to some other special pages, though not as prominent because the other special pages are generally short). I will leave the discretion to you whether to split out the actual form element (i.e. individual textbox + infobox) creation code into a separate function (I would not split out more than that due to idiosyncrasies between special pages), or to have customized HTML for each special page. But I would strongly advise against continuing the ad verbatim quoting of HTML code; it is extraordinarily ugly especially if you are going to add JS to it.
P.S. Feel free to move this discussion to the programmer portal. In fact, it probably should be there anyway. --Feldmahler 04:22, 4 November 2009 (UTC)

Forums

Just a heads up that the forums have been down (SQL ERROR "Too many connections") for the past 12 hours or so. --Leonard Vertighel 07:01, 7 November 2009 (UTC)

Thanks for the note. --Feldmahler 15:19, 7 November 2009 (UTC)
Retrieved from "http://imslp.org/wiki/User_talk:Feldmahler"
Personal tools
Donate via Paypal
in association with