Magnus and Brion: [I've merged both of your comments into one email. The message is a bit long, but it keeps it all in one place. Note the M> and B> refer to Magnus and Brion respectively.] M> Cool! I like it! Hope to see the CDs at Wal-Mart soon ;-) B> A cool beginning, thanks! :) Thanks, I'm glad to see the idea receive such a positive response :) M> * On every page, there should be a link to the online article, and to M> the online edit. B> A link to that particular page on the live server would be a *very* good B> idea. The regular printable pages include this. I will add links to the current online article, online edit, and offline talk. The offline talk page will link to the online talk and online talk edit. I think that provides access to the online version of everything. B> User and talk pages are probably not necessary; if you're looking to B> discuss the page, you'll be doing it on the live site where you can edit B> it (and see the last 6 months' worth of edits which aren't on your B> CD-ROM). And, of course, they take up a large chunk of valuable CD real B> estate better devoted to future articles. I have debated whether to include the User and Talk pages myself. As space on the CD gets tight they'll probably be the first things to go. However, I noticed that articles sometimes provide a link to the corresponding Talk page. If the talk page was somehow relevant to the article (which it probably shouldn't be) I wanted to make sure people had access to it offline. As for the User pages, I thought it was a good way to give credit to the Wikipedia contributors. Also, many of the Wikipedia pages and Talk pages link to User pages where people have made comments. M> * Images should link to the image text, like wikipedia does, not to the M> image itself. One can save the image directly from the page. I'm not sure what happened there, I'll fix it so it behaves the same as Wikipedia. M> * A nice CSS will make it look less "plain", without compromising M> compatibility with older browsers. B> Could probably stand to be purtied up at least a little bit. I agree, I'll try using a different CSS to improve things. My intention is to keep a simple look and feel, but also to stay true to the Wikipedia style. M> * The CD could also have a recent Mozilla installer on it ;-) My assumption is that everyone has a HTML browser on their machine or can easily get one. Maybe I didn't get your joke? M> * There could be other index.html files with frames in them, where a M> small frame on top, bottom, or side, could carry useful links (Main M> Page, Copyrights, the "live" wikipedia, "live" search engine, etc.) and M> maybe the logo. Good idea. Thanks for the sample you emailed me personally. I'll create two interfaces, one frame based and the other with just the pages. M> * If you want statistics (date of last edit) at all, maybe add some more M> ("this was edited 123 times"). The number of edits could be useful to a person reading the article to determine how "mature" the article is. I'll look into how easy it would be to implement. M> * Should non-existent links be displayed as links? I think so, because M> people might feel tempted to write something ;-) I agree that links to non-existent articles would be a good way to encourage people to contribute, but it's at the expense of linking online which might not be available to them. I have tried to keep the number of links to online sources low so that offline users aren't frustrated by numerous broken (in their mind) links. Maybe using the stub marker (like an ! or *) after the topic would be best (I've seen this preference setting somewhere). Using an "external" CSS tag with a different color, as is done with the online version, would also help people distinguish. B> Some things to think about as far as the actual filenames: Some good observations about potential filename problems. I suppose I could use something other than the title, like the unique cur_id integer, but it wouldn't be as meaningful to people. Using eight characters (26 letters and 10 numbers) there are about 2.8 trillion possible filenames, so each article could be mapped to a unique 8 character filename. I think this would avoid all the length and conflict issues you've raised. Or maybe 64 characters would be better since some meaning could be kept in the name. I'll think about these issues and see what I can come up with. CD-ROM formats such as Rock Ridge Extension and Joliet support longer filenames (at least 64 characters), but the ISO 9660 standard only supports the 8+3 convention. I read that Joliet also supports Unicode characters for international support. Perhaps it would be enough to ensure the filenames conform to one of these CD-ROM standards and leave the rest up to the OS? The other thing to note about potential filename conflicts with my current setup is that the MD5 hash directory structure provides some safety. Even if two filenames conflicted (through removing invalid characters) with the 256 subdirectories their is only a 0.4% chance they'll be put in the same directory and actually conflict. It's not perfect, but it's not very likely to happen. B> Non-ascii chars appear to be left intact; will this work consistently B> across different filesystems which may be configured for different B> character encodings? I don't know much about different character encodings. I'll have to do some research on this unless anyone here knows the answer? M> There should also be a "real" offline search function. Shouldn't be too M> hard to hack some smallish programs for Windows, Linux, maybe Mac. B> A simple JavaScript-based title search could probably be rigged up out B> of that. I agree, there needs to be a "real" way to search the articles. My focus at the moment is to get the HTML and layout correct. The JavaScript-based search is a nice idea to provide some basic functionality. One of my goals is to try and keep everything OS and browser independent. This may not be possible for extra features like a search function, but I think it should be the goal. It's also one of my goals to try and ensure it works on the most basic setup that libraries, schools and third-world countries might have. M> We might also think of adding special "view" functions to the software M> (like the "printable version"), to aid projects like this, and maybe M> Larry's wikipedia sifter. By software I assume you mean the Wikipedia code base. Doesn't the current Skin object provide something like this already? If you want to view things differently you just need to implement a new skin. B> That will need to be fixed, of course! :) It's on my todo list :) Once the English version is working, I'll try some of the other language Wikipedias. I'm looking forward to learning more about different character sets and internationalization. B> > - redirects replaced with direct link to article B> B> Nice. I was really fun to implement because I got to use recursion to follow the redirects to the final page :) Hopefully, Wikipedia never has any infinite redirection loops. Thank you both Brion and Magnus for your comments. Anyone else with some thoughts or ideas? I'll post my next revision when it's ready. Best Regards, Steve Rawlinson

On Sun, 17 Nov 2002, Giskart wrote: As you suggest, I expect the primary use for the static HTML will be for a CDROM that people without (or expensive) Internet access could use. I think that schools and libraries might also greatly benefit from it. There are some other good reasons for doing this. Plain HTML format means that anyone can easily put Wikipedia on their server or LAN for read-only use. They won't need to install PHP, MySQL, configure the software, import the database, etc. Another possibility: if the updates to the static HTML were frequent enough, other's could mirror the site which would reduce the load on Wikipedia. Editing and new articles would still need to be done on the main Wikipedia site, but read-only access could be distributed. Finally, having lots of HTML copies of Wikipedia around also servers as a backup. If for some unfortunate reason the Wikipedia server was ever destroyed or taken offline, the articles (in HTML format) wouldn't be lost. It's also just neat to have your own copy of Wikipedia on CD :) I agree, the more people working on Wikipedia the better, but I think having some type of network connection is absolutely necessary for contributing to Wikipedia. An interesting idea, but I think if they have email then they are also very likely to have a web access and could submit changes in the "normal" way online. I know of people who currently work this way because their Internet connection is expensive. They only connect long enough to get the most recent changes and upload any updates. Best Regards, Steve Rawlinson

Steve Rawlinson heeft geschreven: [cut] I think there are people who have email but no www. And to connect only for downloading and submit en disconnect again. Connecting is the most expencieve thing to do. It depens of your telecom operator of cource, but i now from the past when I used a modem and not ADSL that making the conncetion is very expencive.

Axel, thanks for the comments. Now that I think about it some more, you're right. The back button is redundant and the Javascript has the potential to cause problems (or not work if Javascript has been disabled). I'll remove it. An excellent idea. My original reason for the link was to give people a way to find the online Wikipedia. A link to [[Wikipedia]] will accomplish this and provide more information about the project as you suggest. Also, Magnus and Brion suggested adding a links to the current online version of the article and a link to the online edit page, which should also help people find the online version. Thanks, Steve