User talk:Feldmahler/archive14

Contents 1 New Version (IMSLP 0.7) 2 some quick thoughts on those tab thingies 3 file template 4 composer template 5 Message when not PD in US 6 The Second Coming of IMSLP 7 Problem???

New Version (IMSLP 0.7)

I really like the clean, elegant look - congratulations. I noticed a couple of things from a visual / end user's POV:

1. The second info block is indented from both the left and right sides. This creates text oddities when the Urtext message template is in place in the misc. comments field - even colliding with the field name itself. Would it help to remove the idents? Since this block is a contrasting color with the upper one, the indents strike me a superfluous, esepcially the one on the right.

2. The file description now serves as the hot link to the PDF file itself. This created some issues in some pages like the one I was working on for Godowsky's transcriptions. I'd originally put in direct links to the original version of the actual piece that Godowsky transcribed in addition to creating a link to the composer category in the subsection of the page. Because the name now serves as the file link, this is no longer possible. Would it be better (and more immediately obvious to the end user) if the common PDF icon (which one sees everywhere in the net these days) were positioned on the left side of the upper info-block to serve as the link to the file itself, which would free up the description field to function as it did before?

These are just style items more than anything, but they might make IMSLP that much easier to use. Carolus 00:39, 11 February 2008 (EST)

As to 2, why not use the "misc. notes" section? (unless I misunderstand what you want to do...) --Leonard Vertighel 10:47, 11 February 2008 (EST)

The left indent also does not seem visually peaceful to me, so I don't think we need it, but I don't think it's the cause of the Urtext template problem. The right darker box is meant for the thumbnail pictures. Also, Feldmahler, I don't find the template anymore so that we can make minor modifications to it. Could you give us links for editing the file, composer and work templates? I have another long list of requests for things I can't program, but I'd better keep them for a while... Wouldn't you need someone who can do minor programming work for you? In other words, what can we do? --Peter _talk 12:31, 11 February 2008 (EST)

Thanks for the feedback! I've removed the left indent (and hopefully it won't implode on IE... please check my change and see if it works Leonard :). Removing the right block (which like Peter says is for the thumbnail) should be possible too for entries without thumbnails, but requires coding, and so I'll put it on the todo list for the next IMSLP version (which will be out before IMSLP goes back online).

Carolus, for #1, it is not merely an indenting problem I believe (same problem exists even now that I've removed the left indent); it is probably a problem of the CSS. Maybe you can look into it Leonard? If changing the CSS is not possible, we can work around it in the Urtext template itself. For #2, the PDF icon is possible (and apparently that's what CPDL does), though my concern is that people might not understand what it means, and that you should click on it to download the file. It works on CPDL because they use many icons, but for IMSLP just putting an icon in the template may not be intuitive (though perhaps the icon + text works?). However, I know what you mean, and will think of ways around this. The easiest way is, like Leonard said, to put it in the Misc. Comments, but being able to use proper wiki-formatting (including links of course) in the description itself may be a good idea in the long run (and which makes all the fields in the template independent of any template-related extra formatting besides the absolutely necessary).

Peter, I basically copied the layout from here. However, the real code of the template is actually in the Mediawiki:Common.css file, as referenced to by the templates (all the work entry related entries are prefixed 'we_'). I put the real template itself in the code because that decreases the parsing time by order of magnitude (if we had the old template IMSLP's server would have died from overload a long time ago), but since most of the formatting-related code is now in the Common.css file, you can edit it right in the wiki. Though it may be a good idea to test any edits in all browsers you can find (and most important of all, IE). Web designing for IE with all its brokenness is bad enough, but we have to here design for both IE and every other browser at the same time without using any browser detection methods, which is pain squared as I'm sure Leonard can attest to ;) However, editing a CSS file is not a piece of cake; if you don't think you can do what you want, you can ask Leonard and maybe he can do it when he has some free time.

Also Peter, please do request any additional coding you want; that way I can organize my coding time so that I can finish everything in the most optimal fashion. As for what you can do insofar as IMSLP coding and design is concerned, Common.css would probably be the major one that anyone (well, the admins) can edit in the wiki. As for the actual IMSLP PHP code, it would require a considerable amount of time for even PHP programmers to get the hang of it (the extensions and modifications to Mediawiki code itself is quite extensive), and so I think it'd be best for me to handle the core functions. However, I've been thinking of letting other people code some modularized sections (ex. the LoC cataloging system that we planned), but that's after IMSLP comes back up. :) --Feldmahler 13:52, 11 February 2008 (EST)

Quick reply: IE - can't check right now. removing right block when unused - does it really look better? (no time to try right now) urtext template in file template - nests a div inside a p, which is illegal and causes the layout problem. Requires a change in the html code of the file template (and the associated css). icons - I agree that they may be confusing for the occasional users. If you want to use them at all costs, provide also a textual explanation alongside. But be careful about the signal/noise ratio, in other words: try to avoid visual clutter that carries no information. What may seem perfectly obvious for the experienced users, may nonetheless be totally confusing for the occasional users (presumably the majority of all users). See also KISS principle. In any case, I think the download link should be the biggest and most noticeable one of the entire file entry. testing css changes - use your user style sheet for testing, and run the code through the validator before applying it globally. Be sure to test in M$IE (at least 6+7; warning: may cause brain damage) as well as in at least one standards compliant browser (mozilla, opera,...). Coding - no more open sourcing? Hope to have more time when I'm back (see my user page). End of message. --Leonard Vertighel 16:59, 11 February 2008 (EST)

Now there's a lot of information to process ;) I'll just answer the last question. Open sourcing will definitely happen; the problem is will people be willing to work on the IMSLP code even after it is open sourced, and then whether the work on the code will be of sufficiently high quality (integration) to be admitted into the repository. This is less of a problem with modularized code, but the core IMSLP code is heavily integrated within itself (more like Mediawiki core code vs. special pages). There is also ~5400 lines of it (not including modifications to Mediawiki code) which build on existing Mediawiki code and core Mediawiki functions. So essentially, the programmer would be required to have a good knowledge of Mediawiki internals plus the IMSLP extensions, whereas with a modularized special page (ex. the LoC catalog) the programmer only needs to know the basic Mediawiki special page/parser extension API. --Feldmahler 21:01, 11 February 2008 (EST)

some quick thoughts on those tab thingies

pro:

• makes long pages potentially easier to navigate;
• ...?

contra:

• longer clickpath on short pages (the majority?) with no added benefit;
• two rows of tabs with no clear hierarchical relationship between them are potentially confusing (for those who are not familiar with the Mediawiki interface);
• integrates badly with Mediawiki (at least the version you linked in irc): the "edit" link (and possibly others) doesn't do what you expect (i.e. open the actual page for editing).

Just my proverbial 2¢... --Leonard Vertighel 04:20, 18 February 2008 (EST)

I concur with Leonard, and I see also some alternatives. The first suggestion would be facilitation of the use of the multifile template as discussed on irc. Secondly, I would propose to do a big layout update to improve overview and compactness. The situation as I see it is that the Leonard design is just beautiful, but is somewhat disturbed by the standard mediawiki layout (lines and spaces everywhere):

1. In particular, the standard headings are disturbing the fluency. Do we actually need them? Some headers are not used, others are duplicate (composer name), others could maybe be incorporated in the work / composer template. I think its fairly easy to redesign these headers as they are in the style sheet.
2. On long pages, one has to scroll to the end for the general information. How would the work template look on top?
3. Is it feasible to redesign the left pane and top bars?
4. Maybe a slightly smaller font, in general or just for some sections, would improve readability.
5. A table of contents, if present, disturbs sometimes the layout.
6. ...

This would of course take a lot of work :( :( Peter _talk 12:59, 18 February 2008 (EST)

I've set up a page to address this, let's continue over there... --Leonard Vertighel 14:20, 18 February 2008 (EST)

file template

By the way, there have been some changes to the file template that I don't quite understand:

• I had proposed to use "scanned by" rather than "scanner", in an attempt to prevent people putting "Epson" rather than the name/nick - what was wrong with that? ("uploaded by" was then just for consistency)

This is an oversight on my part (didn't remember the previous discussion)... though I think one reason I changed to "scanner" was to match "uploader", because the uploader field is rather long, and having "uploaded by" would break many of them into two lines (unless the uploader name is very short). Though you do have a good point (and which has happened several times in the past).

• why do we need the redundant "Type: Scan, Scanner: ..." - if somebody scanned it, then what else could it be except a scan?

Well, there are actually three types that would have a "Scanner": normal scan, manuscript scan, and original composition, hence the explicit type definition. If there is a way to incorporate the three into the description ("Scanner") that would be nice, and so we can get rid of the "Type" part.

Now I'm slightly confused: for an original composition (what's the exact definition, by the way? Previously unpublished?), how do you distinguish between scanned and typeset scores?

The answer is that this is a very hacked-together system lol. The original intent was to distinguish between scans (i.e. officially published typesets) and typesets (i.e. non-published typesets), but other stuff got piled on top of it and now we have four categories (scan, manuscript scan, typeset, original composition). The definition of original composition is rather uncertain... it should mean compositions of composers still alive, but perhaps we should remove this category altogether. The reason the category originally existed is because they don't fit nicely into either scan or typeset (or more to the point, the definition is pretty much pointless for them because usually it is the composer him/herself submitting it to IMSLP), but I suppose we can make do without a separate category. The other problem of course is to distinguish between manuscript scan and normal scan.

The last one is easy: replace "Type: Scan, Scanner: ..." with "Scanned by ..." and "Type: Manuscript, Scanner: ..." with "Manuscript scanned by ...". Shorter, more fluid, same information content.

Ok, I will make the necessary adjustments. I'll for now classify original composition as typesets.

• rating now is just a number with no explanation - not good imho, requires people to find and read some explanation to understand what is being rated (the music? the download speed? the performance difficulty? the haircut of the composer?)

--Leonard Vertighel 03:21, 19 February 2008 (EST)

Well, I was mostly trying to cram the various things into one line... if you could suggest a way to do it and also be more explicit about the rating then I would certainly be implementing it :) The reason I didn't use the version in the drafts exactly is because it is broken into two lines (the "uploaded by" line is also broken into two for the second one). Perhaps we need to use smaller fonts? --Feldmahler 11:19, 19 February 2008 (EST)

Weird... on my computer, with Firefox, it starts breaking only if I resize the window to less than 900px (at default font size)... how wide is your browser window? --Leonard Vertighel 12:03, 19 February 2008 (EST)

I'm using Konq, maximized with 1024x768 screen size. I think it may be because of difference in font sizes, plus the fact that the entry is fixed-width. Speaking of width, perhaps we should stop designing for 800x600 and instead aim for 1024x768 (and thus increase the width of the entry)? --Feldmahler 12:27, 19 February 2008 (EST)

I see, Konqueror has indeed overall a huge default font. Problem is, if we make it smaller, it gets too small for both Firefox and Opera (dunno about IE...). The entry is max-width rather than fixed-width (except for silly IE6, which goes full-width). We can thus easily increase the width, on narrow screens it will just be full-width. --Leonard Vertighel 12:52, 19 February 2008 (EST)

That would be a very good idea. I believe Peter also requested something similar, to prevent lines from unnecessarily breaking. Plus, everything seems to be widescreen these days anyway ;) --Feldmahler 15:53, 19 February 2008 (EST)

composer template

Alternate names:

• "Alternate Names: None given" -> cognitive noise -> please remove ;)

Removed both non-existant intersections and alternate names. :) --Feldmahler 18:09, 22 February 2008 (EST)

• A better place (when they are given) might be under "Miscellaneous information"; maybe not perfect either, but IMHO it makes more sense than among the navigation links.

Hmm... Is it possible to put it directly below the name itself (in smaller font obviously)? The "Misc. Information" section is for customized messages (it just takes a chunk of whatever you feed it and spits it out in that section without processing).

I guess that could work.

Edit help:

• Please not in every single template. We're trying to make them as compact as possible, to make it easier to get an overwiev of long work pages, among other things. If anything, then one link per page.
• One possibility could be to put it next to the edit link at the top of the page. Maybe remove the "discussion" link instead, since it's not used in the same way as on Wikipedia (And maybe we should rethink the site navigation as a whole, since it's currently more complex than Wikipedia's, which is a far bigger and more heterogeneous project than IMSLP.)

Would a centralized help be better? We can use the "help" link in the sidebar, or even a special "help" section with a few sub-sections in the sidebar.

Centralized help sounds good. (The current one is a mess however, and I'm tempted to delete most of it and start from scratch.) Please no more subsections in the sidebar: as I was saying, we already have five sections where Wikipedia manages with two; that's too much already. Just think of how many people are unable to program a VCR. It's not a complicated task per se, but most people will unknowingly refuse to figure out anything that looks complex. Navigation should be as few links as possible, and each one should have an immediately obvious meaning. Clearly this is not easy to achieve, and I'm certainly no master at this. But we should at least try... --Leonard Vertighel 04:04, 23 February 2008 (EST)

It goes without saying that there is no hurry as long as we're offline, just don't forget ;) --Leonard Vertighel 17:57, 22 February 2008 (EST)

Well its easy enough to put in the code... in fact I'm doing this right now so I don't forget (the ones we agreed on that is). --Feldmahler 18:09, 22 February 2008 (EST)

Message when not PD in US

Hi Feldmahler, I just came across something: I tried to open a score V / NotPDUS / V when I was not logged in yet, but there came an error message. I tested it with a file V / V / NotPDinEU -> this was working, though not PD in EU. Why this selective blocking if a file is not PD in US? Is it only temporarily? Hmm, I hope so...
By the way, does the new IMSLP version contain a category mover to rename a composer? Several names are wrongly written. Regards and Happy Easter Holidays :), Hobbypianist 04:27, 21 March 2008 (EDT)

The Second Coming of IMSLP

Thank you for the advance notice about estimated time of arrival! (Don't worry, my lips are sealed.) I'll try to upload as much as I can before then, and when IMSLP comes back up I'll probably go to ground for a little while and let everybody else play so that the whole thing doesn't crash.

Your perseverance and hard work throughout this whole affair has been legendary. If the Queen gives out awards to Canucks for service to the music community (like she does when it's Australia Day here), you should get one.

(off to work now...born to scan, forced to work!!)

Aldona 17:47, 16 April 2008 (EDT)

Thank you for the praise! I think many other IMSLP contributors (with yourself being at the top of the list) deserve as much praise, if not more :)

Also, an update on the situation. I just had a talk with Carolus, and he corrected me that it is more likely IMSLP will be up in ~5-6 weeks. Apparently the name check is taking a long time (still ~3 weeks to go according to the lawyer). But after that it should be a breeze. In the meanwhile I get a chance to get some of the features squeezed in before IMSLP officially goes online :) --Feldmahler 00:16, 17 April 2008 (EDT)

And we get some more time to contribute some more files.

Just passed 16,000 files and growing...and I can't even post a celebratory thread on the forum. Damn.

I'll try to confine myself to stuff that's definitely, unmistakeably PD without any doubts, so as not to overwork the copyright checking team. Aldona 08:24, 1 May 2008 (EDT)

Thank you again for your tireless work on IMSLP! Even though we can't celebrate on the forums right now, we can simply roll it into one huge celebration once IMSLP comes back online ;) --Feldmahler 01:14, 2 May 2008 (EDT)

Problem???

First I was unable to access IMSLP at all for 24 hours (from about this time yesterday, until now). Both from my home computer, and from the computer at work.

Now it's back and I am trying to add a work. I get a peculiar truncated version of the "add work" page; only a space for the work title, the composer name automatically filled in, and a box for "miscellaneous comments." That's all.

Has there been some kind of bug or glitch in the system?

Aldona 17:46, 16 June 2008 (EDT)

Hi Aldona! Sorry for the problems you were (and are) experiencing. I was upgrading IMSLP over the weekend, and hence the downtime... I should have notified people earlier, but I had everything ready and thought that I'd just do it, since the time left is not that much (and leave more time for general testing). The shortened Add Work page is actually not an error, but a result of the split of IMSLP into IMSLP and IMDBP (http://imdbp.org , just go to the Recent Changes and click "Show bot edits"), which means that all information on a page resides on IMDBP, but which IMSLP "embeds" into the work page. The edit link for the info section will ultimately point to the corresponding IMDBP page (I have not yet set everything up correctly). After adding an IMSLP work page you will also see an error for the info section (because there is no corresponding IMDBP page), but functionality is not impaired, and that error will turn into a link to the corresponding IMDBP page-creator once I actually get more of this stuff linked (the pages are there, just not linked properly).

Hope this helps, and sorry for the inconvenience! I really should have sent out a message in advance. But this is a rather necessary (and huge) upgrade prior to the restart of IMSLP because there is a third project in planning, and IMDBP is necessary for everything to happen. Many of the prior niceties may be broken, but as this week progresses I aim to get IMSLP back to (better than) the original working state. Please do tell me if there are any broken parts or bugs that you think I have overlooked (the only known one currently for the IMSLP side is the bad edit link)...

Again, sorry! --Feldmahler 21:27, 16 June 2008 (EDT)

Thank you and keep up the good work - I'll go easy on the uploads and just concentrate on scanning things for a few days until things settle down.

(reflex action - whenever the site goes down without warning I get flashbacks to Oct 20-21 and think the worst - e.g. that IMSLP is under attack again by hackers, music publishers, aliens or other malevolent forces ;-))

Aldona 21:47, 16 June 2008 (EDT)

One thing I just noticed: The field "Scanner" appears to with the label "Unknown." The default for that field is the term Unknown (in italics), so that most of these I've seen read: Unknown: Unknown. Also, the link just beneath the "General Info" section goes only to the main page instead of to a place where the General Info can be edited. (You probably already know about that one, though.) - Carolus 22:38, 16 June 2008 (EDT)

Hi Feldmahler. I'm also noticing lots of weird happenings here, for example the intrusion of the Greek and English U.S. copyright warnings on some pages that apply (see Roussel's page). I also can't seem to edit the General Information on a piece even after clicking the "Click this link..." link. I also don't think I'm getting email notifications like I should (although nothing has changed on my end), but I'm not sure this is related. Daphnis 08:48, 20 June 2008 (EDT)

The multiple-language copyright warnings is because I disabled the old IFLANG function in favor of the new IFLANG parser function which is much cleaner (ex. {{#iflang:en=a|es=b|el=c}}), but some of those pages have not migrated yet. I will make sure that the migration of IFLANG is complete before launch.

The edit link should bring you to the IMDBP information page, and editing any information on that page will automatically update the IMSLP page. If you are having problems with this process, please do tell me.

E-mail notification for wishlist items are temporarily disabled because of load concerns (like Wikipedia). If load is fine after IMSLP comes back up, I will probably re-enable e-mail notification...

Thanks for the reports! If you feel something is out of place or buggy, do report it to me. :-) --Feldmahler 10:58, 20 June 2008 (EDT)

I still haven't changed the templates because I thought the table inside the function didn't work yet. If you want me to change them, just give me a signal! Btw my mail is still delayed, I know. --Peter _talk 14:34, 20 June 2008 (EDT)

Thanks for standing by :) I already added a function that will allow it to work, but apparently that function is currently broken (I have yet to debug that part). However, I wanted to ask whether it is possible to use #iflang inside the table, and not outside it? I did a quick check of one of the problem templates, and it seems very possible to just put the #iflang inside the table... don't know if that holds for the others though. --Feldmahler 12:05, 21 June 2008 (EDT)

Of course! I should think more outside the box. It works for not too complex templates (e.g. all important copyright notification templates that need a priority on translating), but not if there are new rows inside the iflang because of the "|" (e.g. Template:Beethoven String Quartets). Other pages like Browse by composer time period should imo better be translated on a different page instead of using the iflang, because the page code just gets too complex. The choice of using iflang or not should be made based on the risk of loosing an important page modification in the translations. On the other hand, while Jujimufu did an excellent job on translating every title in the publisher pages, adding iflang code for every language in every line would make it impossible to have a coherent view on the page structure. A solution would be substituting the table contents from one common source page, but this again makes everything very complex. We'll see - one translation is manageable for now.--Peter _talk 16:50, 21 June 2008 (EDT)

I have programmed an extension to the template function (for *all* templates, actually) that solves the problem of the pipe ('|') symbol. Unfortunately, for whatever reason the extension is not working properly yet, but I will make it work properly :) For longer pages, it might be a good idea to have completely separate page instead of #iflang as you say (I think this is the norm already, at least for some pages).

Regardless, there will probably be details that need to be ironed out (ex. what the limit of when to use #iflang and when to use a separate page is, how to distinguish outdated translations, etc), but most translations should be functioning correctly after I fix the bug with the new template input format (I'll announce the technical details after I fix it).

Also, 10000+ works, and a new name :) More info in the news entry I'm going to write now. --Feldmahler 17:30, 21 June 2008 (EDT)

hehehe...those flute sonatas by the Sons of Bach have pushed us over the 10,000 work mark. I didn't see that until you pointed it out.

I've just discovered what a wonderful gold-mine my "Commercially Available Resource" music CD-roms are turning out to be - especially as I have some without the commercial logo. The only headache-inducing bit is precisely identifying and cataloging the works. (any idea how many works Quantz wrote that are simply titled "Flute Concerto in G"??) Aldona 18:36, 21 June 2008 (EDT)

Feldmahler, I sent you an email using the mail this user link on this page, because I don't know what address you are using at the moment.--Peter _talk 03:52, 22 June 2008 (EDT)

Can you resend it to my feldmahler {at} imslp.org address? It seems like my account still has the old imslp@imslp.org one... Thanks! --Feldmahler 21:33, 22 June 2008 (EDT)

Hi, It appears the Piano Concerto Navigator in the Mozart Piano Concerto pages does not parse with the new version of the software. I've not checked any of the other similar navigation aids (Bach Cantatas, etc. ) but it might be worth looking at a few. Carolus 02:14, 24 June 2008 (EDT)

One of the things that makes the template system choke (which I have not realized before) are raw tables ({| |}) in the page. The template essentially treats all '|' signs in the tables as argument delimiters, which wrecks havoc with the table. Good thing is, raw tables are usually not necessary in templates, and when they are necessary (as in the navigation aids), they are usually better served by template inclusion (like the Beethoven Sonatas).

However, I will be trying to fix this problem myself, so you can wait for the fix if you don't want to edit those pages and replace the navigation aid with a template. That said, in the long run it may be a good idea insofar as maintenance is concerned to have them all using one template... --Feldmahler 11:54, 24 June 2008 (EDT)

Feldmahler, something screwy keeps happening when I add files. First, when adding a new composition and file for Vincent d'Indy, it fills out his name without the apostrophe, so I had to move it manually. Then, when adding a file to an existing page for Enescu, it screws up that work page and is unviewable from the composer's page now. Can you see what's going on here? I've got a ton of stuff to upload before the reopening and can't be bothering you for each oddity :) Daphnis 21:39, 26 June 2008 (EDT)

I've fixed the d'Indy bug, but are you still experiencing the Enescu one? I cannot seem to find any example of the problem. The Romanian Rhapsodies are properly under the Enescu category, just categorized under 'R' and not '2'. --Feldmahler 17:45, 27 June 2008 (EDT)

I just made some cosmetic and language changes to the CUSP disclaimer so they are in line with those recommended by the IP attorney. Also, there's some weirdness with a couple of work pages I ran across in the past few days. Here are links to them: 1. Toccata, 2. Concerto for Recorder, Oboe, Violin and Piano

Carolus 19:15, 27 June 2008 (EDT)

Thanks, but I think Carolus must have gotten to it before you did, or the system somehow corrected itself and it was only a temporary bug. In any case, it seems to be ok now. Speaking of the CUSP, would you expound on this filtration system and if the CUSP message will only be displayed for users about to download a non-PD work in their country, or will it effectively block downloading? Oh, and when will you re-activate email alerts? Daphnis 22:07, 27 June 2008 (EDT)

Thanks for the links Carolus. There is a somewhat sizable list (a dozen or so) of pages that for whatever reason failed to convert. Many was due to an ampersand (&) in the page name, but apparently a few was not. I had been wanting to fix this for quite a while (to be precise, ever since the bot converted all the pages), but am still swamped with stuff I need to get done before reopening Sunday (Saturday afternoon probably impossible, unfortunately). This dozen or so unconverted pages will probably have to wait until after IMSLP goes back up...

Daphnis, do report any further occurrences of this. The disclaimer will at first apply every time a file is downloaded, but I will have a system in place so that you only need to click on it once in a month or so. The disclaimer is not by any means a filtration system; it is merely a warning that IMSLP is not liable for any damages. It will in no case block downloading.

E-mail alerts will be reactivated after IMSLP goes back up. Currently I am trying to shorten the list of things that absolutely must be done prior to IMSLP's relaunch, and since e-mail alerts are not absolutely essential (I assume), I'll leave them until after the resurrection... I really need to keep a list of those things :)

Also, reopening is scheduled for Sunday (June 29th) and not Tuesday the 1st. I will, however, be taking the site offline for what is probably a substantial while later today (Saturday). --Feldmahler 23:44, 27 June 2008 (EDT)