Help Wikitravel grow by contributing to an article! Learn how.

Wikitravel talk:Offline reader Expedition

From Wikitravel
Revision as of 11:26, 21 June 2007 by Guaka (Talk | contribs)

Jump to: navigation, search

Plucker

Did somebody contact the Plucker developers already? I don't have a PDA myself (yet..), so I won't delve into this. But I guess that there is room for some kind of cooperation between Wikitravel (or even Wikimedia) people and Plucker developers. Oh, and if I do have a PDA it will definitely run Linux, so then I have to think of tweaking Plucker, which only runs on PalmOS for the moment (fortunately it's free software :). Guaka 16:36, 3 Nov 2003 (PST)

Yeah, I posted to the plucker users mailing list, and got some off-list responses along the lines of "that sounds cool". -- Evan 19:14, 3 Nov 2003 (PST)

I don't see what's the goal of this expedition. Why can't I simply take wget (http://www.gnu.org/software/wget/wget.html) and make my offline copy? -- Hansm 05:10, 2003 Nov 4 (PST)

Cause it'd be very crude and take way too much space of your valuable PDA memory. Guaka 09:28, 8 Nov 2004 (EST)

Internet Tablets

This group should also consider the new class of devices dubbed internet tablets, like the Nokia N800.


Is the HTML generated by the Wikimedia software viewable on mobile devices? This probably isn't necessary for offline reading, but perhaps it's a place to start? --Dawnview 02:43, 2 Feb 2004 (EST)


The following bit was moved here from the Traveler's pub:

A way to edit offline

I've been thinking that it would be really nice to have a way to work on wikitravel articles offline. The advantages would include the possibilities of working on a laptop, while actually traveling and of giving the traveler a choice of the full range of text editors. I've noticed that there's been some discussion of this sort of thing on the Wikimedia meta site, but I think I would propose to do something a bit different (and hopefully simpler) than the stuff I've seen proposed there.

What I have in mind at least for now is something kind of like the cvs client command line software, but with a much simpler set of functions and behaviors. So if this command were called "wix" (a name pulled totally out of thin air) the user could type something like 'wix checkout pagename.wiki', or 'wix update pagename.wiki' or wix commit pagename.wiki'. While the pagename would pretty much obviously have to be the URL page name of the article. The commit function would either have to insist on an update first, or perhaps better, would be smart enough to do one automatically. The client would probably need some kind of conflict resolution behavior as well.

My idea is for the client to interface with the server just using the perfectly normal HTTP, just like all other user agents which communicate with Wikimedia so as to keep this as simple as possible and to avoid the range of possible bugs that can come from making drastic changes in server features. I suppose that if skins are fairly easy to make, then a stripped down skin for the client might be in order, thought I'm not sure that would be necessary so long as the form elements are named consistantly between the skins.

I've actually been doing something like this just using the "save as" feature of my browser, and editing the form action attribute of the page to give it a non-relative URL. Of course this requires diligence with updates, which have to be done manually. I would have to handle a conflict manually when doing this if one ever came up. So anyhow, I wouldn't mind automating this stuff just to keep from running diff once in a while.

Any thoughts? -- Mark 05:27, 30 Jan 2004 (EST)

This is definitely a desirable feature, since writing about travel tips is best done in the field, near the point of travel. When I was recently toting around SE Asia, I had an offline version of Wikipedia (Tomeraider format) so I could read up on countries, history, etc. There was definitely a desire to update facts, add content, fix typos, and the like. And since Wikitravel is so young and sparse, the chances of an edit conflict right now is very small, so checking in to the CVS is most likely to just succeed. So in short, yes, good idea. Now what next? Fuzheado 20:26, 30 Jan 2004 (EST)
My two main thoughts are: 1) Most of this should probably go on Wikitravel talk:Offline Reader Expedition, and 2) I think the "wix" client is a pretty good idea. I'd estimate about 16 hours of Perl programming (with LWP for the hairy part) to do the basics. --Evan 15:25, 1 Feb 2004 (EST)
OK. I'm going to probably get started on the stub for this tonight on the train. I'll post whatever I get done somewhere and make a note here for comments. I'll start with a monolithic script for now, and break it out into modules if it looks like that would be useful. -- Mark 14:29, 2 Feb 2004 (EST)
For those who are interested, there is now a stub for this thing at http://www.geekhive.net/~mark/wix.tgz. As you can see, I've got some way to go to a working prototype. Lot's of stuff is bound to change before then, so be warned! -- Mark 15:59, 7 Feb 2004 (EST)

I've mentioned this elsewhere, but the cvs like client for Mediawiki now exists. I've uploaded it to CPAN where it is available as WWW::Mediawiki::Client. -- Mark 06:05, 27 Apr 2004 (EDT)


It looks great. I kan download with wix, use parsewiki to convert to latex for printouts, and html for PDA (Yopy with dillo) and edit the wiki files on my PDA.

  • Would it be possible to add a -r (recursive) option to wix. I want to put a whole country on my pda. And I want images, that belong to wikis I download
  • The Quick bar is HTML, not wiki. When parsewiki sees HTML it converts <, and > to & lt; , & gt; to make it HTML and \ensuremath{<}, \ensuremath{>} to make latex
  • 8 bit charaters come out wrong in html because they are UTF-8 but not marked as such. Is that a wix or a parsewiki problem?

elgaard Aug 15, 2004

Hi Elgaard!

I'm glad you find the mediawiki client software useful. I guess it's time for me to do a bit more work on it. I'm going to need some clarification from you others before I can continue though.

  • Recursiveness Adding recursion sounds like a useful feature, especially for downloads. I think it's probably better for Wikitravel's bandwidth to avoid having recursive or bulk uploads. I'd like to know what other wikitravelers think about recursive downloads, especially Evan since he has to deal with bandwidth issues.
  • Quick Bar I guess the Quick bar is that thing on the country pages right? I've never messed with one of those. Are you saying that you would like WWW::Mediawiki::Client to somehow process that html into wiki?
  • UTF-8 Hmm, I don't actually know. Something in the back of my head says that there's a way to signal that a textfile should be considered as a UNICODE file by giving it a magic number or something, but I don't have specifics. Help with the research on that would be great, though I could probably figure it out eventually. As for parsewiki, I dunno, maybe there's a way to tell it that it's dealing with UNICODE.
update I've downloaded and tried parsewiki. I think I can solve your problem with a patch that adds an encoding flag for use on the command line, and which then includes an http-equiv header for character set. That should take care of it, assuming your browser pays attention to http-equiv stuff. -- Mark 05:09, 16 Aug 2004 (EDT)

Also, I'm considering changing the name of the script to mwc, as the name wix is already taken by a project on sourceforge. Are there any objections? Does anybody know if that name is taken? Does anybody have a better idea? Maybe something faster to type? -- Mark 05:00, 16 Aug 2004 (EDT)

Encoding Patch for parsewiki

Here's a patch which adds an encoding switch to parsewiki. You can apply this patch to the original parswiki script using:

 patch -p0 -i parswiki.patch parsewiki

Once you have a patched version of parsewiki you should be able to do this:

 parsewiki --encoding=UTF-8 Copenhagen.wiki > Copenhagen.html

The resulting html file works with my browser, hopefully it will work with yours too.

For what it's worth I tried to upload this but ran into the same problem with uploads that Elgaard was having.


--- /usr/bin/parsewiki	2003-07-03 01:20:29.000000000 +0200
+++ parsewiki	2004-08-16 11:23:52.000000000 +0200
@@ -40,6 +40,9 @@
     -T, --title=TITLE    Title.
     -t, --template=FILE  File with a template to use instead of thestandard.
     -c, --copyright      Display copyright and copying permission statement.
+    -e, --encoding=ENC   Sets the character set or encoding of the
+                         document output for html and xhtml. (default
+                         ISO-8859-1)
     -h, --help           Show this usage summary.
 
 FILE is a simple text file with wiki formating syntax. The result will be
@@ -63,7 +66,7 @@
 	    $Titles $Authors $Orgs $Addresses $Dates $Versions $Abstracts
 	    $Figures @Title @Author @Org @Address @Date @Version @Abstract
 	    @Figure @Language @BabelLang @Tag %SaveUrl %OpenTag %CloseTag
-	    %OpenItem %CloseItem %Meta %LangCode $Revision $LF);
+	    %OpenItem %CloseItem %Meta %LangCode $Revision $LF $Encoding);
 
 # Configuration variables and Default options
 %SaveUrl = ();
@@ -74,6 +77,7 @@
 %CloseItem = qw(ol </li> ul </li> dl </dd>);
 $Format = 'html';
 $Revision = q($Revision: 1.29 $);
+$Encoding = 'ISO-8859-1';
 
 my $file = &GetOpts(); # Process command line options
 
@@ -681,6 +685,7 @@
 <head>
 <!-- Created by parsewiki $Revision -->
 <title>$title</title>
+<meta http-equiv="Content-Type" content="text/html; charset=$Encoding">
 </head>
 <body>
 $frontmatter
@@ -714,13 +719,14 @@
     unless ($Template)
     {
 	$Template = <<'        EndXHTML';
-<?xml version="1.0" encoding="ISO-8859-1" ?>
+<?xml version="1.0" encoding="$Encoding" ?>
 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
                "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
 <html$lang>
 <head>
 <!-- Created by parsewiki $Revision -->
 <title>$title</title>
+<meta http-equiv="Content-Type" content="text/xhtml; charset=$Encoding">
 </head>
 <body>
 $frontmatter
@@ -1007,6 +1013,8 @@
 	if (/^-t$/) { &ReadTemplate(shift(@ARGV)); next }
 	if (/^-t(.*)$/) { &ReadTemplate($1); next }
 	if (/^--template\=(.*)$/) { &ReadTemplate($1); next }
+	if (/^-e(.*)$/) { $Encoding = $1; next }
+	if (/^--encoding\=(.*)$/) { $Encoding = $1; next }
 	if (/^(-c|--copyright)/) { &Copying; next }
 	if (/^(-h|--help)/) { &Usage }
     }

  • Recursiveness: Yes downloads are fine. I do not think downloading a country would be too bad, considering it is a cvs-like sync. You could limit it to countries and below, ie. no downloading of all WikiTravel.

Probably recursive uploads would be fine too, if only what users have actually edit are uploaded. Because it will typically be copied to and from PDA's with simpe filesystems you would need to use a checksum or file size comparison (rsync style). Maybe you would also need to handle CR/LF conversions.

  • Quick Bar If you try to edit a quick box, you will see HTML-codes, mostly tables. According to WikiMedia these tags are allowed, so I guess it is a parsewiki problem. The parsewiki manual says: This is a preliminary beta release, and probably filled with bugs. Among the future development plans are the implementation of tables, bibliographies and figures captions. But this was in 2002.
  • Parsewiki patch Good. Did you submit it upstream to parsewiki?

elgaard 08:40, 2004 Aug 16 (EDT)


DICT

I've written wik2dict, a Python thingy that converts the MediaWiki database dumps available from Wikimedia into the DICT format. It's text-only, read-only, and gzipped. Debian has some dict packages. And it's probably quite easy to use the dict stuff on a GNU/Linuxy PDA. But this hasn't been tested with Wikitravel yet.

So... I'd like to see a Wikitravel database dump available for download! Guaka 09:28, 8 Nov 2004 (EST)

Dump available ?

[Moved from Travellers' pub by Hypatia 17:49, 18 Dec 2004 (EST)]

Old stuff:

Hi,
Where are database dumps avaliable ? This is specially important as SQL queries are disabled. With a dump, SQL queries can done at home on my own computer. Yann 09:05, 26 Jun 2004 (EDT)
I've created wik2dict and like to have Wikitravel in the dict format now :) It would be nice if the dump uses the same format as the Wikipedia SQL dump. Otherwise I need to hack some more. Guaka 13:56, 2 Aug 2004 (EDT)

Yes, old question, but no answer. So I'd like to pose the question again: Would it be possible to make SQL dumps available somewhere? That way I can hack wik2dict so that I have Wikitravel as a dict on my laptop. Guaka 12:37, 19 Oct 2004 (EDT)

See also Wikitravel:Offline Reader Expedition Guaka 06:28, 11 Nov 2004 (EST)
It should be pretty easy to write a script to dump the whole thing once the next version of WWW::Mediawiki::Client is out. -- Mark 09:12, 2 May 2005 (EDT)
Huh? It should be pretty easy to have the dumps available. Wikimedia has them available since ages. Even the Star Trek wiki has downloadable database dumps. Why not Wikitravel? Guaka 00:04, 4 May 2005 (EDT)
True, but I can't help you there. If you want to use the tool that is available it's there. If you prefer to wait fore the db dumps you can do that too. -- Mark 01:09, 4 May 2005 (EDT)
Oh, sorry, I thought that Perl thingy was needed to create the dumps. I don't really speak Perl, but it might be an alternative if there's no response coming from people who do have access to the MySQL database. Guaka 15:37, 6 May 2005 (EDT)
Sorry it's taking so long to get the database dumps on-line (2 years?). There's not a big demand, and there's other higher priorities (like keeping the site running). The big problem I have is that I want to make sure we comply with the Wikitravel copyleft-- notably, editor attribution. Wikimedia-style data dumps don't do that. I think a MediaWiki XML-file dump should be sufficient, but I think probably the best thing is a big pre-rendered HTML tarball with accompanying RDF files. --Evan 17:17, 6 May 2005 (EDT)
Is there a dump available somewhere? I would be interested in linking to pages from my site (http://www.unearthedoutdoors.net/ ). I don't have experience editing wikis, so I hope I'm doing it correctly here... -- Seth 7 April 2006

Book format?

Is there any thought on doing a book format? Has anyone used/checked out http://www.lulu.com[1]? Appearantly you can upload your book in electronic format, and they handle billing etc. for you. You don't pay them exactly, you decide on a cut for them of each sale, then they print the book on demand and ship it. Is this the right place to ask about this? Thanks, Michael Moore


You want to sell Wikitravel ? - rofl

See User:Elgaard --Elgaard

iSilo

What about iSilo format? It's pretty popular among PalmOS users, at least in Russia. -- DenisYurkin 16:32, 25 Sep 2005 (EDT)

Offline version

Swept in from the Wikitravel:Travellers' pub:

Is there a friendly way to get an offline version of either all or a part of Wikitravel?

Specificly: I'm in Europe for 3 months with intermitant internet access, and a Eurail pass. I'd absolutely _love_ to be able to browse the Europe pages for whatever country I happen to find myself in at the moment. If there were an easy way to do this for offline viewing I could do it without paying EU $7.00/hour (for an internet cafe) to do so.

More in general: I think that if it were possible to download a tarballed HTML version of Wikitravel (or maybe a contenent or country at a time), travelers could put it on their Palm pilots or laptops and have an excelent guide book to take with them.

See the Wikitravel:Offline Reader Expedition. Right now, we don't have an HTML dump, but it's a priority. I usually just print out the guides I need for where I'm going. --Evan 15:31, 20 May 2005 (EDT)
Last time I did that was last month. When I arrived downtown Toronto, I realized Toronto had been split into districts and I only had only printed out the city page. In July I'll make my way from Rome to Naples, I might go to most destinations south of Rome. It is just to much to do by hand. It should not be to difficult to write a script that follows Regions, Cities, District, and Other Destinations links using mvs, but parsewiki is not quite right.
I would love a cron job that updates a PDF for each country.
If I brought a laptop, I would prefer a dump of Wikitravel, so I could run it locally. --elgaard 18:27, 20 May 2005 (EDT)
I'd probably print where I was going if only I knew. :-) On our trip last week which was intended for Barcelona, we ended up in Millan, Genoa, and some small Italian towns. Untill we got to the Zurich train station and found that the Barcelona train was booked, we didn't know we were headed to Italy.
It's quite fun to have the flexibility to change destinations on the spur of the moment, but it makes being informed (tourist-wise) about where you end up fairly dificult.
-- Michael

Wikipedia for iPod

Did anyone happen to see this? [2] It is Wikipedia for the iPod. This would be good for Wikitravel. Will it work? -- Tom Holland (xltel) 13:43, 28 February 2006 (EST)

Putting wikitravel on ipods - lonelyipod.com

Moved from Wikitravel:Travellers' pub

I spent a lot of time in India, where I saw everyone lugging around their heavy travel guides and an ipod, and wondered why nobody had combined the two. Well, I've produced a rough and (hopefully) ready web page that will do just that. I'm looking for feedback and suggestions, but if you just want to use it to make your travels easier, lighter, and cheaper, great! lonelyipod.com is the site. bcnstony 4:13, 25 April 2006 (EDT)

That's an excellent idea! Although I don't own an iPod, I think it would be great to have it working for the other language versions too (couldn't get a zip file for any of the pt: articles). Ricardo (Rmx) 05:59, 25 April 2006 (EDT)
Multi-lingual doesn't work yet because I'm going through XML, and the Special:Export link changes depending on the language. Once I move to SQL this will be solved. bcnstony 13:13, 25 April 2006 (EDT)
Yeah, that's a very good idea. I think the name is probably going to get you in trouble, though. I'd really like to get that kind of thing working on wikitravel.org (see Wikitravel:Offline Reader Expedition). --Evan 09:15, 25 April 2006 (EDT)
Which part of the name? The lonely or the ipod? I don't think apple will care, since if this works people will only want to buy more ipods, and 'Lonely' could be just as easily from Sgt. Pepper's Lonely Hearts Club Band (in which case the other Apple company would sue me!). bcnstony 13:13, 25 April 2006 (EDT)
The "I think this is good for them" argument doesn't really hold up well in trademark disputes. The courts give the owner of the trademark the right to decide when/where/how it gets used, and actually tends to punish them if they're too lenient. The closest thing to a neutral standard is the "confusion in the marketplace" test, which says that if people might mistake this for an Apple-sanctioned service (or a Lonely Planet service), you lose. I'm not saying you would, but I'm not saying you wouldn't either. - Todd VerBeek 14:36, 25 April 2006 (EDT)

What I'm currently struggling with is how to get the data easily. I can get the info from XML in the /en/Special:Export/city, but that link changes by language (i.e. Spanish is /es/Especial:Export/city). Is it possible to get read access to the database? Or a dump of the database? I read this wasn't available yet, but wanted to see what people thought. bcnstony 13:28, 25 April 2006 (EDT)

Will users be able to read the generated file on other MP3 players such as Creative Zen too? Or is it an iPod-only thing? By the way, Todd seems right about the trademark and the "confusion in the marketplace" argument - maybe you could use lonelypod.com instead - it think still provides a pretty good "mental link" to both LP and iPods and would save yourself from any trouble. Ricardo (Rmx) 15:01, 25 April 2006 (EDT)
I think you guys have a valid point, so I'll look into changing that, though I'll get to it after I put some more work into the code.
As for other players, since iPod's are the dominant device I'm focusing on them right now, but eventually I'd like to see this on anything and everything possible. Most of the hard stuff is going to be handling the dynamic linking within documents. Changing the tags so they are read on other players, such as Zen, or Palms, or phones, or whatever, will (I hope) be fairly straightforward. Eventually I'd like to see that right in the options - the user will choose 3 options
  • What Top level page (i.e. Barcelona, NYC, Kenya, etc.)
  • How deep to follow links (just that page, 1 deep, 2 deep, etc.)
  • What format (iPod, Zen, Palm, Windows CE, Motorolla Phone, etc.)
bcnstony 16:02, 25 April 2006 (EDT)
If you do give it a different name, I'd suggest dropping the "lonely" altogether, because that really does make it sound like it's using Lonely Planet content. That bothers me as a Wikitravel partisan almost as much as it would the LP folks. :) Maybe Podtravel, TravelPlayer, GuidePlayer? - Todd VerBeek 17:43, 25 April 2006 (EDT)

People have suggested I change the name, and for legal and other reasons (see above!) I am changing it. I like the suggestions so far, if anyone has other suggestions, feel free to add them here. My favorite, PodTravel, is sadly already taken.

Also, the site now handles long articles by breaking them up into smaller pieces. This is both easier to read and circumvents iPod's 4000 character limit per file.bcnstony 18:28, 25 April 2006 (EDT)

How about wikipod? Especially if you could generalise it so it handled Wikipedia or others? Pashley 21:02, 1 May 2006 (EDT)

I've been thinking about something like this, but instead a more general application to export wiki to other formats like TeX (and on to PDF), openoffice and msword. This would make it really easy to make a paper travelguide. So far I haven't been really looking into it, but including a export to iPod seems like and interresting feature. Ronald 09:48, 5 May 2006 (EDT)


"although there are plenty of us who don't have the luxury of owning a portable computer or PDA"

What a load of technophobic nonsense. Travelling itself is a luxury. Second hand PDAs cost as little as $50. Who can afford to travel can afford a PDA.

The economic issue isn't important; I've simply changed it to state that some people can't or don't want to use PDAs and laptops for their travel guide for whatever reason. --Evan 11:17, 6 July 2006 (EDT)

Wikitravel on PDA

Swept in from the Pub:

I'm new to this project, so forgive me if I'm posting in the wrong section. Anyway, I feel the real wikitravel revolution would come from PDA compability. A simple program installed in your PDA both for reading wikitravel and adding new information. I would use wikitravel a million times more and contribute ten times more than now if I could read and contribute through a handheld computer and just "sync" (downloading all new information and uploading all contributions) when coming across a WiFi hotspot or a internet connected computer with a USB-port. Has this been discussed? Is there such an application already? Why isn't it top priority? -- Fridday 20:35, 29 June 2006 (EDT)

There's an independent project that's been started to format Wikitravel articles for downloading to iPods. For most full-featured PDAs (e.g. PalmOS, WinCE) it's mostly a matter of downloading web pages and reading them offline, which isn't terribly difficult to do. Offline updates are much trickier, because you don't know whether someone's edited the article online since you downloaded it. As for priorities, developing the content itself – and letting that drive the development of offline readers (and updaters) – seems to be closer to the top of most people's lists. —The preceding unsigned comment was added by TVerBeek (talkcontribs)
There's also a project that's part of Wikitravel called Wikitravel:Offline Reader Expedition. PDA and mobile phone versions of Wikitravel are one of the project's targeted platforms (see Wikitravel:goals and non-goals), but we don't have any standardized output for PDAs. There are a couple of reasons. First, mobile phone and PDA providers have in the past had widely disparate content standards for text and hypertext, and those phones and PDAs that do support standards like WAP and XHTML-Basic do so inconsistently. Second, there aren't already good apps for editing hypertext on a PDA or mobile phone, nor for syncing with a remote server. Third, the platforms are very split -- Java, Symbian, Windows Mobile and PalmOS all have significant distribution -- so making an editor ourselves would only get part of the market, or be spread across 4-5 platforms with lots of bugs and errors.
Lastly, it seems like a really important thing to people who have mobile phones with big screens and PDAs. For the other 99.999% of the world, it's better to have a Web page that looks good printed out, or a printed book. --Evan 11:12, 30 June 2006 (EDT)
Great, thanks for your answers! I don't own a PDA myself, but would most probably buy one right away if there was an offline wikitravel application. The expedition mentioned seems to be right on target. But do you really think it is that diffcult to work out a system for offline updates? It would be easy to start with an integrated notepad in the reader, with the notes linked to a specific article. The traveller could just copy and paste after reading the latest versions. And doesn't the system already check if there has ben a simultanious update while you were writing your contribution online? Couldn't that be used for offline updates? -- Fridday 15:31, 30 June 2006 (EDT)
The software on the web site tries to keep track of whether more than on person has a page open for editing at the same time, which works pretty well over the course of a few minutes, but there could be a delay of days between when you download a page to your PDA and when you upload the edited version, and there could be dozens of edits in the meantime if it's a popular destination. That's a bit much for a simple wiki database to keep track of. Your thought of manually copying and pasting new/updated info is more practical. - Todd VerBeek 16:06, 30 June 2006 (EDT)
I'm sorry, but I believe you are plain wrong. This is the error you get if someone has changed the page while you were editing:
Someone else has changed this page since you started editing it. The upper text area contains the page text as it currently exists. Your changes are shown in the lower text area. You will have to merge your changes into the existing text. Only the text in the upper text area will be saved when you press "Save page".
I don't think the wikiscript "keep track" of people having the page open for editing. It just checks if the version you try to edit is the last one.
It seems to me an offline editor could work something like this: You have made four offline updates. When online you manually click "sync". The program tries to add the first edit to the database. If the page has not been changed while offline, itwill just move on with the next update, if it has been changed you will be presented with above message and you copy and paste and then push a button for the program to move on with the other updates. I really don't see why everybody seems to think that an offline editor is such a problem. -- Fridday 18:50, 1 July 2006 (EDT)
Yes this would work. I did a proof of concept last year when travelling in Italy. I wrote wiki-code for many destinations on my Yopy PDA. Every few days I wrote to text to a CFlah card which i moved to a USB-adaptor, that I could plug in computers at hotels and internet-cafes so I could put it on Wikitravel. Conflicts were not a significant problem. A Sleep or Eat section for a small italian city is not edited that often. Many conflicts could even be resolved automatically. --elgaard 21:10, 13 July 2006 (EDT)
That sounds great! Proof! An easy to use application doing this is what I'm hoping for. Is there anybodu out there with the skills and motivation to make such a program? -- Fridday 17:32, 15 July 2006 (EDT)
I have done this sort of thing before I would like to do it for a free project the question really is I dont want to scrape the data can i get at it like wikipedia data download after all its copyleft and publishers would like to put data in if they knew they could get it out again

Let's move this one to Shared

I think this expedition concerns all language versions and should be moved to Wikitravel Shared. By doing so, we could benefit from contributions from users from all other Wikitravel language versions. The fact that the expedition has been handled in English so far is not an issue as English is Shared's official "working language". Ricardo (Rmx) 21:15, 5 November 2006 (EST)

Variants

Actions

Destination Docents

In other languages