User:JMatazzoni (WMF)/drafts

During the first half of 2018, the WMF Collaboration team will make improvements to Kartographer and associated map functions. The team’s engagement with maps was prompted in part by the overwhelming support the maps community gave the 2017 Community Wishlist proposal Kartographer Improvements, though the work won’t be restricted to items named there. The project is scheduled to conclude at the end of June 2018.

Goals
The immediate goals of the Map Improvements project are: Goals that relate to extending maps to a wider audience—such as bringing mapframe functionality to English Wikipedia (as requested by RfC) and making sure that mapframe works properly on wikis that use Flagged Revisions (T151665)—are also under serious consideration.
 * To ensure that Kartographer and the associated maps technology stack are stable and can be easily maintained as maps gain a wider audience.
 * To accomplish the two “main wishes” named in the Community Wishlist proposal, along with as many of the other wishes as are possible in the time provided. The main wishes are T112948, “All map location names should be shown in the user's language” (an extremely challenging but crucial job), and T180907, “Add zoom level 19.”

Background and approach
Maps are a valuable form of visual data that can improve reader understanding of many topics in our encyclopedias and other free-knowledge projects. Yet currently, only 14 Wikipedias, of almost 300, have the mapframe function that puts an actual map—as opposed to just a link to a map—on article pages. Meanwhile, basic improvements are necessary to bring the Kartographer technology and user experience up to software-development and general wiki best practices—and to make the system easier to maintain. On the user-experience front, for example, Kartographer currently displays maps only in the language of the territory mapped, rather than in the language of the wiki where the map exists, let alone in the preferred language of the map reader.

While advanced interactive and annotation features for maps can be useful, especially on WikiVoyage, it’s the judgement of our engineering and design teams that supporting such features—and making them technically stable and usable by a broad audience—would require significant investment in technical staffing extending over many years to come. The Map Improvements 2018 project will, therefore, not emphasize these types of features, prioritizing instead fixes to the system that make it easier to maintain, especially at scale, while improving the user experience for the broader and more basic use case one might call “locator” maps—maps which show the position of events or entities, along with basic geographic features. (Just to be clear, advanced features that exist now will continue; they just won't be the focus of our upgrades.)

The decision not to build out interactive and advanced annotation features at this time may disappoint some who voted for the Kartographer Improvements Wishlist proposal. To put that decision in perspective, however, it might be worth noting that the investment represented by the Map Improvements 2018 project, which will absorb the full energies of the Collaboration team over five-plus months, is already much larger than the scope usually allowed for Wishlist tasks.

Current Activity
The team and has assembled a list of tasks that align with the goals described above and is working through them. We can’t promise that we’ll get to all of the tasks on this list, but we’ll give it our best effort. (For an up-to-date view of the tasks that are in progress, go to the Collaboration team Phabricator board “This Quarter” and sort for the tag “Collaboration-Feature-Rollouts (Collaboration-Maps).”.”)

As of mid-April, we’ve made great progress on rationalizing the overall Kartotherian code. This has enabled us to complete some of the desired user features, including these Community Wishlist items:


 * T180907: Add zoom level 19 (one of two “main wishes” from the Wishlist proposal)
 * T140209: Don't show "hand" mouse icon on unclickable objects
 * T141750: and/or : clickable marker area too big 

Internationalization
We’re also making excellent progress on the other Wishlist “main wish,” T112948: All map location names should be in the user's language. If all goes according to plan, we’ll release this by the end of April, 2018. This fix will enable maps to display labels in the language of the wiki the map is on, instead of in the language of the territory mapped, as now.

It’s important to know that our mapping service gets most of its map data—including map label data—from the open-source mapping project OpenStreetMap. What and how much multilingual data is available from OpenStreetMap varies widely from map to map and language to language. Which means that on release of the new feature, our maps will have the capability to display local languages, but individual maps won’t necessarily have the data you want. (If labels in the desired map language aren’t available, the system will fall back in an intelligent way:  first to the languages configured as fallbacks in MediaWiki for the desired language, then to English, and finally to the language of the territory mapped.) https://translatewiki.net/wiki/Translatewiki.net_languages#Fallback_language_.28MediaWiki.29

Users who find that labels in their desired language aren't available for a particular map can add those labels in OpenStreetMap. We’re looking into this process and will provide information on the process in a future update.

Feedback
We want to hear from anyone with an interest in maps. If you have thoughts about any of the tasks on our board, please leave them in the task discussions; or use the Maps Improvements 2018 talk page for comments and questions about the project in general.

If there’s a Phabricator task you’re interested in—and if you feel the task is consistent with the Map Improvement 2018 goals described above—then give it this Phabricator tag: “Collaboration-Feature-Rollouts (Collaboration-Maps).”  That will bring it to the team’s attention, and we’ll consider whether it can be prioritized for action as part of this project.

Special Update on Map Internationalization, April 18, 2018
One of the “main wishes” from the winning 2017 Community Wishlist proposal  Kartographer Improvements was that maps should be able to display data in the user’s language instead of only in the language of the territory mapped, as currently (T112948). We’re on schedule to  see the first real results for this challenging goal soon, so it seems like a good time to check in with map users on the project. We want to hear from you about how well this new feature will work for you and what we can do (with the resources we have) to make it work better.

PROJECT STATUS AND PLANS
We’d thought to release mapframe with internationalization to wikis that have mapframe by the end of April. But as we’re increasingly able to see the feature in action—and to see how complex the font, language and user experience issues involved can be—we’ve decided to release internationalization first  to testwiki, to give us time to clean up the issues users will likely discover.The testwiki release is now scheduled for the week of April 23-27. The date for a full production release will depend on the type of feedback we get from testers.

HOW THE FEATURE WORKS
Currently, mapframe maps display labels in the language of the territory mapped. The first image at right shows how the existing software displays a map of Asia. As you can see, a wide variety of different languages and alphabets display simultaneously. The second image shows how that same map will display on an English-language wikis after internationalization.


 * Where do the map labels come from? Our mapping service gets its map data from the open-source mapping project OpenStreetMap. Those labels are created by OpenStreetMap volunteer users. Which means that what labels are available for which languages varies from location to location and language to language, depending on what the volunteers have entered (more about this under Known Limitations, below.).




 * How are multilingual labels displayed? Once internationalization is implemented, each wiki will try to display map labels in the language of that wiki. For each label, if the desired language isn’t available, the system falls back gracefully:  first to the languages configured as fallbacks in MediaWiki for that language, then to languages that use the same alphabet, then to English, and finally to the language of the territory mapped.
 * What can you do if labels are missing? If a particular label isn’t available in the language you need, you can add the label in OpenStreetMap. See the screenshot, which shows the fairly simple interface for the process: you find the map feature you want to label, log in, enter Edit mode, select the feature, select your language from a menu, add the label, and upload it.



KNOWN LIMITATIONS

 * Availability of multilingual labeling varies. As noted above, the amount of label data available from OSM varies from location to location and language to language. In general, country, state, province and prominent city and town names are present in many languages, while smaller villages and other features may not be.  The table at left shows the relative quantity of translated label data for the 25 most commonly translated languages in OpenStreetMap. You might also like to  examine the map of Paris as it will appear on a Russian-language wiki.
 * Changes in OpenStreetMap take time to propagate. It's not hard to add labels in the language of your choice to OpenStreetMap, as described above. Once uploaded, your new label data will convey from OSM to our map system. But such additions don’t show up on the wiki immediately; servers have to talk to each other, new map images have to be generated, etc.  Right now, the lag can be from 1 to 48 hours. We’re working on some changes that will cut that range down to anywhere from minutes (if the stars align) to 24 hours. That speedup should be completed in May.
 * Only some types of objects are labeled. To make Wikimedia maps readable and uncluttered, our map styles are configured to show only a subset of the available data on OpenStreetMap, with a focus on features that are useful for what we’re calling “locator” maps: place names, streets, transit features, parks, and some geographic features, like lakes. Among the many things you won’t see labels for are restaurants, stores, houses of worship, archeological sites, tourist attractions…. If our map styles don’t show a category of object, like restaurants, then entering a restaurant name in  OpenStreetMap in your language won’t change the map on your wiki.

USE CASES FOR THIS FEATURE
Locate a city in a foreign country, or foreign country in the world (basic locator maps)

For an article about Antwerp, an English Wikipedia editor wants to show the city’s location within Belgium.


 * Process for a mapframe map: the user enters the city coordinates, the zoom level, and data for a marker position into mapframe code in a page or template.




 * Results: a map displays that is similar in level of detail to what exists on many typical Wikipedia city entries today (e.g., Antwerp).


 * Advantages of using mapframe: The mapframe  map shows a similar level of detail on the page as does the static map style in use today. But it can be zoomed in and out to show more detail or more context, and popped up for a larger view.  The process of adding the map is also liable to be more streamlined.
 * Disadvantages of using mapframe: Depending on the size of the town and the desired language, a label in that language may not be available (though it can be entered at OpenStreetMap.org). In general, users creating a static graphic may have more control over what is or isn’t shown and the precise framing of the map.

GIVE US YOUR FEEDBACK ON THIS FEATURE
So, what do you think? What might you do with this new capability? What other use cases can you see for dynamic, internationalized maps? Do you think you will enter new label data in OpenStreetMap to create more detailed maps in your language? Does the process of creating mapframe maps seem easier than what you do now or harder? What might make this new internationalization capability more attractive? Please post your comments on the project talk page: we’re listening.

April 11, 2018
In the coming days, some version of the following note will go out to most Wikipedia communities proposing to release mapframe on all but nine Wikipedias that currently lack the feature.

Time to bring embedded maps (‘mapframe’) to most Wikipedias

Mapframe is a feature that enables users to easily display interactive maps right on wiki pages. Currently, most Wikipedias don’t have mapframe. But fifteen Wikipedias, along with literally all the other wiki projects, are using mapframe today to display maps on hundreds of thousands of pages.

A little background: over the last few months, the Foundation’s Collaboration team has been working to improve the stability and user experience of the maps service. In addition, a question about long-term support for the maps service was recently settled, and a small team has been assigned for routine maintenance. Given these developments, bringing the benefits of mapframe to Wikipedias that lack the feature seems both safe and supportable. (Nine Wikipedias that use a stricter version of Flagged Revisions will not get mapframe in this release.)

Maps are a valuable form of visual data that can improve readers’ understanding across a wide range of topics. If you know of any reasons why mapframe shouldn’t be implemented on your Wikipedia, let us know on the project talk page. Unless we hear from you, we plan to release mapframe to most Wikipedias in May, 2018. So, if you foresee an issue, let us hear from you. Otherwise, happy mapping!

March 29, 2018
We consulted with English Wikipedia on Village Pump as to whether community members are still in favor of the proposal put forward in an October RfC requesting that mapframe be turned on. Broad support remains for the idea, so we are moving forward with a plan to release mapframe on English Wikipedia soon after we launch the internationalization feature (T112948) described above. Expect a release by the end of April, 2018.