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

Wikitravel:Feature requests

From Wikitravel
Revision as of 10:55, 19 June 2006 by Zenogantner (Talk | contribs)

Jump to: navigation, search


This is the page to put feature ideas or feature requests for the MediaWiki software.

See also:

Note: IWBNI is an abbreviation of "it would be nice if...".

Ability to add Google Earth [.kmz] files

It would be cool to be able to upload and refer to Google Earth .kmz files. Imagine being able to fly users from an orbital view down to earth level to see a location. -- gcleveland

And with placemarks can be converted to a number of formats and uploaded to most GPS receivers. The best would be if users can specify their preferences (Google Earth, Mapsource etc) and if the system accepts all 'gpsbabel' formats as input.
I think the best would be to standardize on kml because it's text. If we can embed the kml in the documents, then MediaWiki can track the history and differences. -- Nic 12:59, 9 Aug 2005 (EDT)


Moved from travellers' pub by Evan

Man, has anyone else seen htmlArea? It's really nifty -- a WYSIWYG HTML editor built into the browser. The new (3.0) version works with Mozilla and IE... I dunno about Konqueror, Opera, or anything else. But it'd be pretty neato to have WYSIWYG editing built into Wikitravel... --Evan 00:37, 20 Jan 2004 (EST)

Yeah, it's pretty neat. We were considering using it for our Bricolage installation at WHO this summer but switched to a Java solution since htmlArea was slightly broken on some of the browsers. It should be easier to make it work with Wiki markup though since it's soooo much simpler than HTML. -- Mark 01:25, 20 Jan 2004 (EST)
I think right now the plan is to incorporate Wikiwyg/ into MediaWiki; see . --Evan 16:00, 17 June 2006 (EDT)

Page renames, all pages discussable

Please add page renames to history of a page. Please also make non-editable pages discussable (for example, the Special Pages menu).

Language variations

(Forked by Notty 01:34, Feb 9, 2004 (EST) so that this portion of the original comment just shows the portion appropriate to Feature requests. The other portion can be found in Wikitravel talk:Phrasebook Expedition)

"Because the same language can be used in multiple countries (for example, Spanish or Arabic), phrasebooks in Wikitravel will be separate articles from country, city or regional articles. Those articles can link to the appropriate phrasebook for local languages, and may also include small micro-phrasebooks for local deviations. For example, the article for Quebec would link to the French phrasebook, but might also include some variations for Quebecois French. "

In Wikitravel talk:Phrasebook Expedition, I discuss my opposition to micro-phrasebooks. It would be much better to use the computer's ability to filter content to achieve an improved printout.

It could be handled with an extension to Wiki code. A possible example for the Spanish phrasebook (with nonsense words):

; blahblah : <<Mexico|blehbleh>> <<Argentina|aoaoao>> <<Chile,Peru|bababa>> <<!|cecece>>

Default display would be:

Mexico: blehbleh
Argentina: aoaoao
Chile, Peru: bababa
elsewhere: cecece

There would also be a link on the page for each country covered by the vocabulary. So, if you clicked the Venezuela link you would see:

outside Mexico, Argentina, Chile, Peru: cecece

If you clicked on the Argentina link you would see:

Argentina: aoaoao

If you find the localization markings unwieldly, you could just mark them with a warning symbol so people with printouts know they have to go back to the phrasebook if they spontaneously decide to go to another country.:

 ! aoaoao

Of course, any word or phase with no regional markings would show normally:


I don't know whether this would be easy to program. It would, however, be flexible and printer friendly, and a lot easier to use than splitting the vocabulary between a phrasebook and an article.

This concept could even extend to the destination pages. For instance, someone only interested in budget accomodations could hide moderate and expensive ones, saving paper.

Notty 02:19, Feb 6, 2004 (EST)

(End of forked comment. Evan's response below is pre-fork and is not to be evaluated by the fork above. Notty 01:34, Feb 9, 2004 (EST) )

This is an interesting idea, but I'm not sure if it would apply for phrasebooks. If there's a small number of variations, they can be handled within the phrasebook or in a micro-phrasebook for the region or city. Quebecois French is like this; just a few variations on International French. I think American English and Brazilian Portuguese would also be handled. If there's a large number of variations, then we could have separate phrasebooks. --Evan 13:01, 6 Feb 2004 (EST)
I am responding post-fork to your response to my pre-forked comment. You may well be right that my features request is overkill for phrasebooks. While my Spoken Spanish dictionary lists many regional variations, it is possible that the ones which would be listed in a phrase book would be few enough as to not make a programming change worthwhile. Notty 01:34, Feb 9, 2004 (EST)

Translating pages

Moved from Wikitravel:travellers' pub by Evan

here's something that's been bugging me: I see that already lots of cities have a English page and a Romanian page, and even though I can't understand a word of Romanian, it's obvious that they are totally different. What does that Romanian page say ? Would it be possible to tweak the wiki software so someone viewing, say, the English version of [Paris] also sees the Romanian version in English ? (Either running it through Google or or some other translation software). Naturally, when I hit the Edit button, I would only be able to edit the English version, not the Romanian (or the on-the-fly-translated English version of the Romanian page). -- DavidCary
(I busted this out to a separate section). The way I've always thought of it, someone who understands both languages should try to keep the pages in sync. Some kind of automated translation tool would make that easier, though, I agree. --Evan 12:44, 26 Jan 2004 (EST)

Pageable RC

Is it possible for the "Recent Changes" page to have a "Next 50" etc. button, similar to the one on the "User Contributions" page? This would make it much easier to scroll through the changes (plus get to changes more than 500 old). DanielC 18:06, 12 May 2005 (EDT)


Imagine encoding Wikitravel URLs with this... That'd be a rather nifty way to spread wikitravel information. -- Nils 09:21, 11 May 2004 (EDT)

Page Information Functions

Although one can see the number of views, date of last edit and number of bytes in a page from various Special Pages there does not appear to be a function that allows the statistics associated with a specific page to be shown on another page. Also no function tells me how many times a page has been edited or how many bytes a page has changed since the last edit. Thus I know a page may be popular but I do not know if it is being changed a lot.

For example:

{{VIEWS:$Page}} = Number of times a page has been viewed.
{{EDITS:$Page}} = Number of times a page has been edited.
{{BYTES:$Page}} = Number of Bytes in the page.
{{EDITDATE:$Page}} = Date (and time) of latest edit.
{{CREATEDATE:$Page}} = Date (and time) of first edit.

-- Huttite 07:23, 28 Apr 2004 (EDT)

Article text formatting

I'm coping below text from my orginal question in Talk:Polish phrasebook, as I believe problem is universal, and here more people will see my question

Is there any smart (and accepted) way to put more text on a page? For example to have 'Pronunciation guide' displayed in two columns?

Scrolling several pages to find something is rather annoying. I believe that if somebody prints phrasebook, can be also a bit unhappy because of number of pages used (and carrying them and searching among them). -- JanSlupski 12:48, 15 Apr 2004 (EDT)

Right now, there's not an easy way to do this. We want to keep all the phrasebook information in a single article, so you just print out the page and go. It'd probably be better for printing a phrasebook on A4 or letter-sized paper to do 2-up printing. It's an interesting concept; I don't know exactly what to suggest. --Evan 13:13, 15 Apr 2004 (EDT)

Truncating links when shown

Would it be possible to jig up some Perl to display [[Foo/Bar]] links as just Bar automatically? There's rarely if ever reason for readers to see the first part, and it would make interlinking city articles oh so much easier; it's a real pain to write things like [[Singapore/North & East|North & East]] all the time. Jpatokal 03:06, 27 Jul 2004 (EDT)

Links on Printable version Pages

Is it possible to make it so that when you follow an internal link (on wikitravel) on the printable version page you get a printable version page?

The reason I would like this is that I would like to use isilo to download pages to my palm and view them there. It is generally better to use the printable version as the formatting is better for isilo to deal with. I would like to be able to set isilo to follow links and get 2 deep version (so I can get all the cities in an area). -- Webgeer 18:32, Sep 15, 2004 (EDT)

For those who may want to use isilo as well, I figured out a workaround for this in isilo. You can set a cookie with the value of printable=yes and then all the pages will be printable versions of the page. Not all similar programs have this feature so I still think it would be nice to fix on the wikitravel side. -- Webgeer 19:06, Sep 15, 2004 (EDT)

Change to XHTML?

I looked at the HTML source of the wiki-pages, and I must say that it is rather ugly ;) Mixed quoting styles (sometimes ', sometimes ", something none of these), mixed upper-/lower-case tags and no indention. I would like to help convert to a clean XHTML 1.0 Strict source, if you could give me any hints. Also I would start to work on a new CSS skin. Thoughts? Mo 15:18, 1 Oct 2004 (BST)

I believe the Monobook skin outputs XHTML Transitional. Isn't that close enough? --Evan 17:18, 8 Oct 2004 (EDT)

Suggestion: article template button on Edit screen

Having just started to contribute to WikiTravel over the past few months, I've got a suggestion for the site, and am guessing this is the place to make it. When adding / starting lots of pages, I find it's a real hassle to have to dig around WikiTravel for the appropriate article template to copy and paste from. Given the project is still in its relative infancy with lots of pages being started, this happens a lot. If I've got two minutes of credit left at a slow Internet cafe, I'd be much more inclined to quickly add the hostel I've just stayed at to the Sleep section of a blank city / town if I didn't have to dig around the site to find the article template, then copy and paste it first.

How about having a button at the top of the text box on the edit screen (next to the formatting buttons), that automatically inserts a skeleton big city / small city / region template whenever clicked? A bit of JavaScript should do the trick. Cheers. -- Allyak 12:19, Oct 1, 2004 (EDT)

Agreed, this would be very useful. An even more radical option would be have the template already as the default content when you create a new page, perhaps (if we want to get fancy) so that the user can select which template to apply. Jpatokal 01:04, 2 Oct 2004 (EDT)
As a very simple but effective solution to this problem until a button is made, we could simply add the following text to the Edit this Page copy. It'd reduce the number of clicks needed to get from the edit screen of a blank page to the article templates from 3 to 1:
If you're getting started on a blank page, copy paste one of these useful templates for countries, geographic regions, huge cities, big cities, small cities or city districts.
This should be easier to add, no? Allyak 12:45, Oct 6, 2004 (EDT)
I notice we currently have a link that opens up a help file in a new window-- could we also have the template pages open in a new window for reference? That way you wouldnt loose any info already added to the edit page. Majnoona 12:39, 22 Nov 2005 (EST)

Preview Summary Line

So I just put a phma in the summary of a page change instead of phma. It'd be nice if Show preview could also preview the summary to at least give me a chance of avoiding a non-fixable error like that. -Colin 18:46, 8 Oct 2004 (EDT)

Selective Blanket Extlink Ban

It would be nice if admins had the ability to ban all external links on selected pages. Then if consensus is reached to turn this bit on for a given page, then no external links of any sort would be permitted from the selected page. As an obvious example, we could turn this bit on for the main page, and then spammers would no longer be capable of putting extlinks into the main page. And since we rarely need extlinks on the main page, this could work out. We might want to enable the same thing on the continent pages. But even if the feature were limited to the main page, that'd be very helpful. -- Colin 03:22, 3 Dec 2004 (EST)

Good idea! Jpatokal 23:15, 5 Dec 2004 (EST)

More special pages features

Is there anyway to list pages that are not in the main namespace by using a special URL variable like ... &namespace=namespace& ... in the special pages URLs? If not present can it be implemented?

Also at the risk of going overboard with special page features, I am thinking it would be useful to have a couple more special pages.

  • Only Child pages - Could list all (main namespace) pages that only have one (main namespace) parent page linking to them.
  • Solo Parent pages - Could list all (main namespace) pages that link to only one other (main namespace) page.

These two features would reveal potential orphan pages and dead-end before they occur. Essentially, I believe that if a page does not link to or from 2 or more pages then the content of the page can be included in the other linked page with no loss of utility. Limiting it to the main namespace is necessary to exclude the noise generated by talk pages and project pages. This would also identify pages that have {{stub}} and {{disamb}}iguation messages on them but not other links. -- Huttite 22:49, 23 Jan 2005 (EST)

An Edit Button for the first (non) section

The edit buttons for the sections are very useful. Would it be possible to have an additional one for the text before the first section, because at present if you want to edit that bit you have to edit the entire article. DanielC 18:02, 12 May 2005 (EDT)

I notice that if you edit the page then there is still an edit button at the top of the page - which seems a bit redundant if you are already editing the whole page. Perhaps if you were editing a section and wanted to edit section 0 (the section before the first one) then this button shows edit section 0 instead. That way two cliks of the edit button gets you the introduction section. I always edit section 1 then change the section number to 0 in the URI and call the page again to edit these introductory sections.
Alternatively on sectioned pages, edit means edit section 0 if you have your user preferences set to show edit by section. Would mean anonymous users would have to click edit twice to edit a whole page. Logged on users could turn off edit by section in their preferences. -- Huttite 02:08, 25 Dec 2005 (EST)

Search for article name

This is probably a low-priority, high pain-in-the-butt, but I thought I'd throw it out here while I was thinking about it... How about a left-nav tool that let you search for an article name for use as a link? For example, I'm a sucky speller with a bad memory and if I want to like to, say, that page that welcomes wikipedians, I usually end up trying Welcome wikipedians and [[Welcome Wikipedians] and Wikipedian welcome before I open a new tab and search to get the right link Wikitravel:Welcome, Wikipedians. Of course opening a new tab isn't a biggy, but it would be a neato short-cut to have an inline search widget... Majnoona 12:43, 22 Nov 2005 (EST)

Selective spelling checker

The spelling checker checks all words for spelling errors. However, Wikitravel Manual of style talks about using highlighting, italics and bolding to emphasose words, including foreign words. If the spelling checker was selective and ignored highlighted words, or even words in links to article or external links or only checked plain text, deliberate mispellings could be excluded at will. -- Huttite 02:15, 25 Dec 2005 (EST)

Prohibit identical new pages

Recently a number of anonymous users posted identical edits to new pages within a space of a few minutes. All the text posted was exactly the same, down to the number of bytes being posted. The text posted on all these pages was spam. It is highly unlikely that two or more wiki pages should need to be identical.

In an effort to limit spam, how about a prohibition on creating a second new page that is identical to the immediately previously (or the last x hours worth? of) created new page(s), unless it is a redirect to an existing page. This would defeat multiple user attacks as well as single user attacks. It would mean the attacking user(s) was/(were) locked out for as long as they persisted attacking with the same text but allow them to edit if they changed. Would defeat simple robots.

This could be extended to prohibit identical portions of text on consecutive new pages, that is the total text is not identical, but a significant proportion is. Or prohibiting the same user from making identical consecutive edits to multiple pages. Or perhaps even just prohibiting posting identical external links on consecutive edits would do the job.

Or is this the Patrolled edit feature? -- Huttite 02:41, 25 Dec 2005 (EST)

Spell check just one page

Is there a way to check just one page for spell errors?

If so please explain it in the FAQ or help files. If not, underlining the errors in the preview would be perfect, but just a list of errors would also be great. The current spellchecker gives a list of common mistakes and the pages in which they occur. It's quite useless if you want to check your freshly entered page for mistakes.

I think it'll save the admins a lot of work. --Ronald 16:48, 5 Jan 2006 (EST)

Spam-filterable pages

[...] Additionally, is there any way to create a "special" page that would show what articles currently would trigger the spam filter? I've had problems editing Las Vegas because the spam filter triggers while I'm editing based on information that was previously in the page. If this second feature is a lot of work then it's not important, but the first would be hugely valuable. -- Ryan 16:22, 8 March 2006 (EST)

New years wishes

Swept in from the Pub:

Happy newyear everyone. It is a good time to consider new ideas and directions. My wishes for WT are:

  • License: It will not be easy but we have to move on to a CC2.X licence. There is just too much good material out there that we cannot use for version-technical reasons. For example Commons have been very helpful in adding a copyleft multiple license that include CC-1.0, but there is still a lot of good pictures that are CC2.x. Projects like Open Street Map could be very useful, especially outside north America, but are CC-2.0. Open Street Map, SVG-maps, geo-tagged destinations and attractions could become a great combination.
  • Promotion: An official T-shirt. An official one-page flyer explaining Wikitravel that we could give to fellow travellers, leave in hostels, etc.
  • More focus on off-line versions. The isIn template should make this easyer.

-- elgaard 00:07, 2 Jan 2006 (EST)

RSS feeds for the Watchlist

Just like the one on the recent changes page. Would that be possible/feasible? I'd love to follow up my wathclist from my Firefox Bookmarks Toolbar. Ricardo (Rmx) 15:46, 25 April 2006 (EDT)

Mailto: formatting

If you have a mailto like [] the text of the link is presented in the web browser as Instead it should be formatted as since Actual Users don't really care about URL encodings and it's unnecessary and ugly obfuscation.

It Would Be Nice if [] were treated as equivalent to [] since email addresses really can't be confused with URLs and it would be easier for the nontechnical contributor to type. -- Colin 16:40, 27 April 2006 (EDT)

These are both good ideas. Some other url formats use "@" (to put the username in, like for an FTP site), but their usefulness on wikis in general and Wikitravel in particular are, say, 4-5 orders of magnitude less than email addresses. I agree that this is preferable. --Evan 16:50, 27 April 2006 (EDT)
You should parse it as an email-address only if it first fails to parse as a URL. Email addresses which are valid URLs ( can just be prefixed with mailto ([1]) to clarify what the contributor means. -- Colin 17:58, 27 April 2006 (EDT)

Moving images to Wikitravel Shared?

Apologies if this has been covered before or is obvious, but: Is there a straightforward way for me to move images (the rights to which I control) from to Wikitravel Shared, so that they can be used conveniently by the other Wikitravels? Or is it necessary to manually re-upload them? I can see justifications for the latter (probably cuts down on concerns about abuse), but being a lazy cuss :-), something easier would be nice. -- Bill-on-the-Hill 22:01, 2 May 2006 (EDT)

Wouldn't it? I don't think there's a way to do that now, but it would be nice -- especially for big images. --Evan 00:03, 3 May 2006 (EDT)

Single sign-on for all WT sites

I want to make it so that if you have an account on any Wikitravel wiki you can log in with that account on any other Wikitravel wiki. This is especially useful for Shared:, but for people doing lots of interwiki work it's nice too.

My preferred technology for doing this is OpenID, since it's an open protocol that would eventually let Wikitravellers log into Wikimedia, Wikia, or even other non-Wiki sites with their Wikitravel logins. OpenID uses your URL as an identity, so that I'd log into Wikitravel fr: as "". I think we could use inter-wiki syntax to shorten this to "en:User:Evan" or even "en:Evan", and allow logins from wikipedians as "wikipedia:de:Benutzer:Example" or even "wikipedia:de:Example". --Evan 15:59, 17 June 2006 (EDT)

Forward-port spellchecker from MediaWiki 1.4.x to 1.6.x

The spellchecker tool from MediaWiki 1.4.x was really useful; it was dropped because it wasn't practical for million-page sites like Wikipedia en:, but it's really nice for 10K-page sites like Wikitravel en:. So, it'd be nice to forward-port it as an extension. --Evan 15:59, 17 June 2006 (EDT)

Pop-up editing for listings tags

For listings, it would be nice to have a form-based editing interface, preferably pop-up and AJAX-y. --Evan 16:05, 17 June 2006 (EDT)

listings converter bot

It would be nice to auto-convert listings in current MoS style to the new listings tags. --Evan 16:05, 17 June 2006 (EDT)

Upload categories to Shared

There's a whole geographical hierarchy I cribbed from UN/LOCODE; I'm going to get it uploaded as a seed set of categories on Shared. --Evan 16:20, 17 June 2006 (EDT)

Merge features of our custom BannedContent extension (e.g., a local whitelist) to more widely-used SpamBlacklist

The SpamBlacklist is used on a lot of other MediaWiki sites. It works a lot like our BannedContent system, except a) it only checks the contents of external links and b) it doesn't have an automated whitelist. I'd like to merge our whitelist feature into the SpamBlacklist and then switch to that system. --Evan 16:20, 17 June 2006 (EDT)

Add "purge" to tabs, for admins

If there's been a caching problem, people have to edit the page and save it with no changes to purge the cached version. IWBNI there were a tab to purge the cache. --Evan

Graph of edits, new articles by month

IWBNI we had a graph of how many articles and edits are created each month. --Evan 16:20, 17 June 2006 (EDT)

Add Special:Map using Mapstraction; link for {{geo}}-tagged pages and for single listings

We're building up a lot of lat-long information with geocoding; IWBNI we could show these geographical points on an automated mapping system. I'm not thrilled about favoring one or another map server, so I like the Mapstraction library, which works with the three major map servers and will hopefully work with more in the future.

The idea is to put a link for each city that's geocoded, and for listings that are geocoded, to go a map to show that point. Further enhancements would show the city or district and all listings within it.

The big question is how this would interrelate with the Wikitravel:Mapmaking Expedition. My feeling is that a tourist map is significantly different from a precise street map, and that we would still need to create the former. It's possible that at some point in the future we could find some embeddable SVG-generating map server (see ArcWeb SVG Map Viewer for an example) that we could push Wikitravel listings into automatically, and then get SVG out. We could then create tourist maps with a lot less trouble.

That's a ways down the road, though. --Evan 16:28, 17 June 2006 (EDT)

Add GeoRSS for Special:Recentchanges

It would be a nifty hack to add GeoRSS output to the Special:Recentchanges RSS feed. Imagine browsing recent changes on a big world map... --Evan 16:29, 17 June 2006 (EDT)

Create a merged Recentchanges feed for all or some language versions

IWBNI you could read recentchanges from multiple language versions at the same time. --Evan 16:30, 17 June 2006 (EDT)

Wikitravel as WFS source for mapping servers, Google Earth

We're generating a lot of rich information for travellers, and it may be useful for some people to browse it in a map-oriented interface rather than a text-oriented one. IWBNI we could generate a or feed for people to view in mapping services or Google Earth. --Evan 16:32, 17 June 2006 (EDT)

Stock description metatags for travel guides

For articles that describe a place (that is, ones that now have "X travel guide" as the HTML title), it'd be nice to have a stock description metatag for the HTML, rather than using the first paragraph of the guide. --Evan 16:36, 17 June 2006 (EDT)

Option to browse long articles with one page per section

For guide and star articles, it would be nice for some users to browse the articles one section per page, rather than as one long page. Any such feature would have to allow people to read and/or print the entire article as a single page, though. See Wikitravel talk:Article templates#The best Wikitravel articles are too damn long. --Evan 16:48, 17 June 2006 (EDT)

Interwiki linking between Wikitravel and World66

Since Wikitravel and World66 are starting to work together as partners, IWBNI we had a way to make an interwiki link between a Wikitravel article and its corresponding World66 article. This would make it easier to copy data from W66 to Wikitravel either manually or (later) automatically. The link would appear in the left nav area, like OpenDirectory or Wikipedia links.

See Wikitravel:Cooperating with World66 for more details. --Evan 16:48, 17 June 2006 (EDT)

Yeah, this would be really nice. You are the admin, Evan, so I think you should make it work. Shouldn't be oo difficult ;-). --zeno 06:51, 19 June 2006 (EDT)

Single sign-on between Wikitravel and World66

IWBNI Wikitravel users could sign onto World66 with their Wikitravel user IDs, and vice versa. This would probably work with OpenID, like the SSO between Wikitravel language versions. --Evan 16:49, 17 June 2006 (EDT)

Editing stats in Subtitle

It's not always clear to readers that Wikitravel articles are the product of a lot of hard work by Wikitravel contributors. It would be cool to see the editing stats for an article appear right under the title of the page, like:

Created by 12 users in 150 edits since 24 February 2006

--Evan 17:52, 17 June 2006 (EDT)

Editing stats on User page

It might be kind of cool to show how much work someone's done on Wikitravel on their user page. Something like:

10,450 edits to 3478 articles since 5 March 2004

--Evan 17:52, 17 June 2006 (EDT)



Destination Docents

In other languages

other sites