From CSS Discuss

Jump to: navigation, search

Initial Cleanup basically done. There was so little to do that Jack T. and I were able to cover it in about a day. If anyone finds a page whose content is botched, let us know.

There is one thing that User:Pabramow noticed, which is that some 'pre' elements have excessively long lines. The ideal fix would be to add 'pre {white-space: pre-wrap;}' in the site's CSS, but support for 'pre-wrap' is poor at best. So if you come across a 'pre' with long lines of text, edit the page to insert hard returns in the source to "wrap" the lines. It's kludgey but it works.

There's no way to detect those programmatically, so far as I know. It'll have to be on an "as-found" basis.

20 March 2010 What would be the desired number of characters per line for these 'pre' elements to be wrapped at? User:BFunk

Botched Links

There is one area where the migration script fell down, and that's with internal links. A good example of the two patterns I've seen are here:

The first example is the "Two Column" links. Both should have been Two Column Float" links. I'm assuming the original Taviwiki text was "TwoColumnFloat" and only the first two words got linked.

There seems to be a two-word assumption built into the link conversion, because later on that same page you can see that "Align Left And Right" got split into two links, "Align Left" and "And Right". The actual page is and doubtless the original Taviwiki text was "AlignLeftAndRight".

So what I'd like now is for us to scout around the site to see if there are other link conversion failure patterns besides what I noted above, and also to see which failed links show up the most. I'm talking to Incutio about the possibility of automated correction but to do that we'll need some idea of what we're up against. So if y'all could do some field work and report what you find here, that would be awesome. Just edit this section to add your notes at the end.

19 March 2010: the Incutio folks figured out what in the script botched all the links and is working to fix up the errors, so this isn't something we need to do either.

Are We Done?

It really seems like everything's either been done or is being done! If anyone comes across anything, do note it on this page so we can investigate further, but it may well be that the migration is basically done on our end. Which means we all had to do a lot less work than was originally envisioned. Woohoo! And thank you, one and all, for your willingness to help. Even if you didn't get a chance to pitch in, that you stepped up and offered tangible support to the wiki and the css-d community really means a lot to me.

In an offlist, Eric said something about maybe adding a comments section here so that we could all compare notes, I'll start it off. Except for a couple of pages that are total losses (and one page I found that was corrupt but recoverable), the biggest issue I'm seeing is corrupt links to other Wiki pages. Wiki uses single or double square brackets (double for internal links) and what I'm seeing the most of? Pages with three-or-more words in the page name that have the square brackets arranged improperly - so it's largely a proofreading exercise and trying to guess the correct page name. So if there is a Site Map document, it would be very helpful for determining original page names and which (if any) linked text strings are false positives. Also discussed elsewhere, a pointer to the docs for this Wiki software. Here's hoping for that, sometime soon. --InkWorks

I just found out (like fifteen minutes before starting this reply) that the Incutio people have figured out what went wrong with link conversion and have generated a list of pages that suffer the corrupted internal-link problem, and are working through them all fixing the errors. So we're looking good there!

I edited the Help:Editing page (the one you get when you click "Editing help" in the page-editing view) to point to some official WikiMedia documents. Are there other places where we need to link in docs?

There are site-mappish pages available from Special:SpecialPages, although maybe nothing exactly like what you were thinking. At some point the orphan and dead-end lists will likely be useful in content cleanup, but until the internal-link problem is cleaned up I don't want to start that process. Once it's done we'll known which pages really are orphans and dead ends.

Which pages are total losses, and which one was recoverable? —Emeyer

Personal tools