Strain writes: Regarding resources, not many free tile servers that I'm aware of can provide this multilanguage capability. Have you considered the possibility that some 3rd party might want a "free ride" and use Wikimedia's tile servers, creating an increase in usage? Are there usage caps or other similar methods in place to prevent abuse?
It’s an interesting question. The maps terms of use [1] state that use by third parties is allowed. But they request that third parties "please respect our limited services and resources” and warn that: We reserve the right to discontinue or change our service, block or limit certain users or applications, or take other measures in cases at our sole discretion at any time without notice. So it seems like this is an issue we’ll just have to keep an eye on. Thanks for bringing it up. Joe [1]https://wikimediafoundation.org/wiki/Maps_Terms_of_Use <https://wikimediafoundation.org/wiki/Maps_Terms_of_Use> _____________________ Joe Matazzoni Product Manager, Collaboration Wikimedia Foundation, San Francisco mobile 202.744.7910 jmatazz...@wikimedia.org "Imagine a world in which every single human being can freely share in the sum of all knowledge." > On Apr 23, 2018, at 4:16 PM, Moriel Schottlender > <mschottlen...@wikimedia.org> wrote: > > Hi Strainu, > > Let me pitch in, at least from the technical point of view to some of your > questions: > > On Mon, Apr 23, 2018 at 2:39 PM, Strainu <strain...@gmail.com > <mailto:strain...@gmail.com>> wrote: > >> That's great news! I especially like the promise of replication within >> minutes from OSM, it sounds wonderful. > > > Just to clarify -- the change will not mean that all updates will be a > matter of minutes. We are making the update from OSM to our systems more > frequent, but the **best case** would be a minute. > If you update a label just before we update, it will take minutes to > update, but overall we are shortening the update length from every 48 hours > to every 24 hours. > That's the meaning of Joe's comment about how the updates will now take > anywhere between minutes to 24 hours. > It's still making it half as long! :) > > >> I see the feature is to be >> deployed to mapframe-using wikis first. Do you have a timeline for >> maplink-only wikis? If a wiki decides to enable mapframe after the >> deployment, will it have to ask explicitly for this feature to be >> enabled or will it be done automatically? >> > > For the most part, <maplink> should also support these, as it calls the > same server, but there might be slight differences in available features > (like language override) for now. > The main challenges to the displays and interaction that we're now busily > fixing are more pronounced in mapframe displays, but the maplink system > should follow the same stack, so it should also be updated when the system > comes up, without having to do anything special. > > If a wiki enables mapframe, the feature will be available by default. > > >> Regarding resources, not many free tile servers that I'm aware of can >> provide this multilanguage capability. Have you considered the >> possibility that some 3rd party might want a "free ride" and use >> Wikimedia's tile servers, creating an increase in usage? Are there >> usage caps or other similar methods in place to prevent abuse? >> > > This is more a policy question, I am not sure I can answer it, so I'll > leave it to others. > > >> Also, regarding fallback languages, could you clarify what "languages >> that use the same alphabet" mean? For instance, Romanian does not have >> a fallback language; will the labels be displayed in English before, >> say, Chinese? >> > > The fallback issue is actually pretty complex, and we've been trying to > come up with the best case to display language in maps the best way > possible; we've gone a bit back and forth with the algorithm as we examine > the results, and it's likely that the consideration itself will continue to > be slightly adjusted as we go. > I will make sure that we document the technical behavior in a proper task > on Phabricator, though. > > That said, to answer your question directly, we are, for the moment, > getting rid of the "same script" behavior. > As we examined maps, it actually makes no sense to display label names in a > random language that just happens to share the same script. > > There are actually several issues we're concerned with, I am trying to > summarize briefly: > - It's really incorrect to assume that a speaker of language A can speak or > read or make sense of names of a place in language B, even if it uses the > same script. Place names aren't always the same in different languages. > - It makes it much more unclear that labels in the requested language are > missing > - Some cases can be politically and culturally sensitive > - We don't control the information in OSM, and some of it is missing a > language tag (only tagged is the local language without specifying what > language that actually is). The more aggressive we are in trying to add > more fallbacks, the more we risk ignoring local names that are actually > useful. > > So, to continue your example, it depends what area of the map you look at: > - If you look for Romanian labels in China, it will show anything in > Romanian, then it will look for anything that is latinized (suffix -Latin) > in case there are transliterated labels, and then it will fall back to > local language. You will likely see some labels in Romanian, some > transliterated, and some in Chinese. > - If you look for Romanian labels in Romania, you will likely get all of > them (it will either get the direct language, or 'fall back' to local, > which is Romanian) > etc. > > It's important to note that in general, creating fallbacks for languages is > a complex, and sometimes culturally sensitive issue, and that the fact we > fetch the data from OSM means we don't have complete control over the way > people added that data in. > No matter what programmatic strategy we choose, there will be "holes" in > the available data that will either need to be fixed in OSM by translating > more labels, or by categorizing labels by their language better. Or, of > course, by setting up more direct fallbacks for smaller languages. > > Thankfully, as you can probably see from the original email, Joe is being > super thoughtful about any and all of those fallback considerations as we > examine more and more maps, and we're really hoping to get as close as we > can to the best experience possible, given the data and the scope of having > maps for all over the world, displayed in so many languages. > > Hope that helped! > > Moriel > > > >> >> Thanks, >> Strainu >> >> 2018-04-21 2:00 GMT+03:00 Joe Matazzoni <jmatazz...@wikimedia.org>: >>> This is to let you know that Collaboration Team is planning to release >> map internationalization next week for testing on testwiki [1]. When it’s >> ready, we’ll post a note to confirm. >>> >>> Meanwhile, you might like to check out the detailed post I added last >> night to the Map Improvements 2018 project board: Special Update on Map >> Internationalization[2]. It includes a lot of information on the feature's >> status, how the it will work, how we imagine it might be useful, what the >> known limitations are, etc. I’m looking forward to getting your input on >> this challenging but important feature (the best place to leave your ideas >> and questions is on the project talk page [3]). >>> >>> Yours, >>> Joe >>> >>> [1] https://phabricator.wikimedia.org/T112948 <https://phabricator. >> wikimedia.org/T112948> >>> [2] https://www.mediawiki.org/wiki/Map_improvements_2018# >> April_18,_2018,_Special_Update_on_Map_Internationalization < >> https://www.mediawiki.org/wiki/Map_improvements_2018# >> April_18,_2018,_Special_Update_on_Map_Internationalization> >>> [3] https://www.mediawiki.org/wiki/Talk:Map_improvements_2018 < >> https://www.mediawiki.org/wiki/Talk:Map_improvements_2018> >>> _____________________ >>> >>> Joe Matazzoni >>> Product Manager, Collaboration >>> Wikimedia Foundation, San Francisco >>> >>> "Imagine a world in which every single human being can freely share in >> the sum of all knowledge." >>> >>> >>> >>> >>> _______________________________________________ >>> Wikitech-l mailing list >>> Wikitech-l@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >> >> _______________________________________________ >> Wikitech-l mailing list >> Wikitech-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >> > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org <mailto:Wikitech-l@lists.wikimedia.org> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > <https://lists.wikimedia.org/mailman/listinfo/wikitech-l> _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
