Wikivoyage/Wishlist
Where to? A roadmap for Wikivoyage and a rough technical wishlist for the future. Note that some of the following ideas aren't totally backed by the community, and that some of them are very very interdependent, especially for listings, dynamic maps and Wikidata. A coherent plan is essential (but alas not present) to combine these initiatives with one another and could do with a high-level discussion. The sections are not in order of priority. Also see Wikivoyage/Summit for monthly reports, and Bugzilla for other bugs.
High priority items edit
Dynamic maps edit
Currently implemented on Wikivoyage e.V servers, using Mapquest Open tiles as the default. Some example maps for voy:de:Hornburg [1] and voy:en:Tokyo/Roppongi [2].
@RolandUnger: is in charge of the server, @Mey2008: is the lead developer.
Security certificate for map server edit
- Required in order to avoid mixed content iframes, some preliminary discussion - moving to somewhere else
- Technically easy to solve by shifting hosting to WMF labs (only need a secure landing site), but advantageous to keep it where it is?
- Create a request for SSL cert in the issue tracker of the WMF Operations team by simply sending an email to ops-requests (at) wikimedia.org.
OpenStreetMap production tile server edit
- High priority, bugzilla:33980
Tracked in Phabricator:
Bug 33980
- Access to an agreed Wikivoyage map style suited to travel purposes - high contrast, good for printing (TileMill)
- Access to multilingual maps - English names on English Wikivoyage, German names on German Wikivoyage etc etc
- Access to HTTPS tileserver
Special:Nearby edit
- Incorporate listings into the Geodata extension - with a listings parser? Probably the most robust implementation for dynamic maps. Either output all listings on a page or output all listings within a certain radius of your location or give both options. External maps can then call this information instead of parsing the wikitext itself. Should the numbers of a listing be hard-coded in an extension as well - now it is either manually inputted or uses a CSS counter to be automatically numbered.
- Possible API query and output
<geosearch>
<gs pageid="31086" ns="0" title="San Francisco/Fisherman's Wharf" lat="37.8083" lon="-122.416" dist="2771.6" primary="" />
<listing type="see" name="Pier 39" address="the Embarcadero at Beach St"
directions="located on the eastern fringe of Fisherman's Wharf" phone="+1 415 705-5500"
e-mail="groupsales@pier39.com" price="Free" lat="37.80863" long="-122.40947" dist=""
content="A 45-acre pier-complex featuring 100 specialty stores, 12 full service restaurants, theater, cruises,
live entertainment, and more" />
<listing type="see" name="Ripley's Believe It Or Not! Museum" address="the Embarcadero at Beach St"
directions="" url="http://www.ripleysf.com" phone="+1 415 771-6188"
e-mail="" price="$19.99 (ages 13 and older), $9.99 children (ages 5-12)" lat="37.80863" long="-122.40947" dist=""
content="Set over 2 floors it has over 10,000 square feet of galleries, exhibits, illusions, and interactive displays." />
</geosearch>
Generated user maps edit
- Add an "I've been here!" button to the top of articles, and link to a map that adds POIs to an OSM map to show all the locations for which a user has clicked that button.
Export to GPX feature edit
- An extension like Export to Book (pdf), but exports listings with coordinates to a GPX/KML file that can be loaded onto GPS devices
Listings/vCards edit
One major problem with listings/vCards is that all languages do not have a shared idea of what a listing should contain, resulting in quite a few deviations. These Points of Interest (PoI) listings have at minimum a name, address, website, telephone number and opening hours, but other parameters like Wikipedia, Facebook and Twitter links are more contested.
Move listings/vCards to Wikidata edit
- Needs the entire community to agree to this and hammer out details
- Discussion about standardisation - German vCards have a very wide range of listing types, while the others have about six to seven.
- Discussion on en:voy, primary argument against Wikidata is that it shifts a lot of information off Wikivoyage, which may make it harder to edit, primary argument for Wikidata is that it centralises listings and the structured data is a very good fit for a database
- Any data on Wikidata has to be CC-0 compared to CC-BY-SA, so listing descriptions would have to be factual in nature if included. Should there be a way to retrieve listings from the Wikivoyage API before any migration to Wikidata?
- Possibly a separate database on Wikidata for Wikivoyage vCards
Listings review edit
- Allow users to rate listings, which personalises user experience as people like to offer their opinions but not necessarily write a thorough guide. However this also dilutes volunteer focus (reviews need to be moderated, better left to for-profit competitive sites?)
- Some very long discussions about whether reviews are wanted : voy:en:Wikivoyage talk:Roadmap#Why_are_we_better_than_the_rest.3F and voy:de:Wikivoyage:Lounge#Aktuelles_aus_der_Presse
- A more thought-out discussion about the pros and cons of reviews
- Possible implementation in separate namespaces or store them together with Wikidata/proper database
Interface edit
Customised printing using book tools edit
- New mw:PDF rendering system to work on Parsoid, include CSS?
- For example, adjusting color, controlled printing of external links, print parameter for full-page map/images (print=fullpage).
- Improved tables of contents and addition of indices (the latter of which could use legacy WTP template voy:en:Template:Index)
- Improve print handling of voy:en:Template:Infobox, voy:en:Template:Quickbar, and voy:en:Template:Pagebanner
User interface edit
- Make edit section links look nicer - currently looks like [edit][add listing] for en:voy, [modifier][ajouter un élément de listing] for fr:voy, maybe use icons instead?
- Clickable section anchors, make it easier to directly link to sections and listings, bugzilla:16691
Editing interface edit
- Yay or nay for Visual Editor? Would require a specialised listings plugin bugzilla:46225, otherwise a page made out of listing templates would be hard to edit. Template-wise, less problems are expected compared to Wikipedia as there is a smaller range of templates. However, for en:voy especially, country articles are often 100kb and above, which will make for very slow loading.
- Mobile listing editor, similar to voy:en:Wikivoyage:Listing_editor.
Miscellany edit
Patrol multiple diffs edit
- Ability to mark several sequential diffs by a user as patrolled. This heavily relieves patrolling duty, especially for users who make a lot of edits like Added listing and Updated listing in a row. (high priority), bugzilla:43977
Fix breadcrumbs edit
- Enable (i.e., customize) support for multiple parents in breadcrumb navigation. E.g., it should be possible to assign Russia two parents: Asia and Europe, then allowing destinations further down in the hierarchy to pick one of those parents for its breadcrumb trail. So Vladivostok would use Asia/Russia, while Saint Petersburg would use Europe/Russia.
- Fix breadcrumbs to return to WT functionality (no disambiguators, no parroting the current page in the breadcrumbs)
Enhance inter-project links edit
- Link to other sister projects using mw:extension:RelatedSites or Wikidata. it.voy currently uses the Lua module voy:it:Modulo:Interprogetto to simulate such an effect.
Enhance Google PageRank edit
- en:voy ranks very poorly on search engines, partially due to large similarity to Wikitravel. High priority, covered in bugzilla:52688
- Possibly change credits footer to text-only, bugzilla:53942
Related grants edit
- m:Grants:IEG/ShareMap
- m:Grants:IEG/Wikimaps Atlas
- m:Grants:IEG/Elaborate_Wikisource_strategic_vision -- possible funding for high-level discussion of goals? cross-Wikivoyage
See also edit
Grants and coding programs