[Wikitech-l] An update on map internationalization

[Joe Matazzoni]

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 

_

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 
>  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  > 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,  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 

Re: [Wikitech-l] An update on map internationalization

[Moriel Schottlender]

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  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,  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 

Re: [Wikitech-l] MediaWiki 1.31 branch (and PHP versions)

[Brion Vibber]

Exciting times! Looking forward to our PHP 7 future, if not just yet. :D

-- brion

On Fri, Apr 20, 2018 at 4:54 PM, Chad  wrote:

> Hi,
>
> I meant to send this Tuesday but I forgot.
>
> MediaWiki 1.31 has been branched from master! You should now see a REL1_31
> branch where appropriate items should be backported to.
>
> Core was branched at 69257de17fc899c447c9f1229b6ed319bc05d316.
> All extensions & skins were branched from their respective masters at about
> the same time as core. I plan to cut rc.0 sometime next week.
>
> PHP versions
> The current plan of action is to leave master as compatible with 5.5 for
> now. This is because Wikimedia production isn't ready quite yet. This is
> being tracked at T172165[0]. We will be moving the REL1_31 branch to 7.0+
> as the required minimum version. Once production is ready, we'll
> forward-port this change to master. It should be a little inconvenient, but
> not too terribly bad (and notably, makes life less stressful for our SREs).
> In the meantime, please do NOT introduce changes to master that require
> 7.0+ for core, vendor, or WMF-deployed extensions & skins. Doing so will
> make me sad :(
>
> Otherwise, great job on 1.31.x everyone! I'm rather pleased with what I'm
> seeing so far. Check out the workboard[1] for ways you can contribute to
> getting it wrapped up (and as always, tag issues with that tag if they
> should absolutely block release).
>
> Have a fantastic weekend!
>
> -Chad
>
> [0] https://phabricator.wikimedia.org/T172165
> [1] https://phabricator.wikimedia.org/project/view/3011/
> ___
> 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

Re: [Wikitech-l] An update on map internationalization

[Strainu]

Hi Joe,

That's great news! I especially like the promise of replication within
minutes from OSM, it sounds wonderful. 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?

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?

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?

Thanks,
  Strainu

2018-04-21 2:00 GMT+03:00 Joe Matazzoni :
> 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 
> 
> [2] 
> 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 
> 
> _
>
> 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

Re: [Wikitech-l] Guideline on HTML classes?

[Derk-Jan Hartman]

There is no comprehensive list of classes, because we simply have too
many of them. And they differ per skin, extension and subpart of the
wiki. And then there is the content where wiki's do whatever they
want...

This specifically, is why for widgets etc we are moving too OOUI, so
that the classes are added automatically either by the PHP or the JS
(or both with infusion). See also
https://www.mediawiki.org/wiki/OOUI/Using_OOUI_in_MediaWiki

OOUI is generally the direction that core will go to, but things are
continuously in flux (the ooui transition is already going for several
years and still will take quite some time to complete). This is simply
a side effect of us having a LOT of UI that is all hand crafted and
now needs to be 'widgetfied', without breaking everything. jQuery UI
is deprecated within MediaWiki core (as in, if as an extension
developer you continue to rely on it you should at some point expect
to have to deliver and maintain jquery ui yourself, instead of being
able to rely on core providing it and it looking way different then
the rest of the wiki).

If you don't need all that, then I know that some people have been
working on a bootstrap version of the OOUI style (as opposed to the
widgets), but i'm not sure what stage that is in (or even where it
resides).

I'm not aware of an official deprecation policy for classes, but there
is one for both PHP and Javascript (which is why your browser console
will tell you that jquery ui is deprecated when you use it).

DJ

On Mon, Apr 23, 2018 at 10:47 PM, Stephan Gambke  wrote:
>
> On a tangent to T192752 ([1]), are there any general guidelines on which 
> classes are or should be used by core and extension devs on HTML elements for 
> styling?
> On mw.org I found scattered remarks about mw-ui-progressive, 
> mw-ui-constructive, and the like and I found the page on OOUI ([2]), which I 
> could probably reverse engineer. What I did not find is a comprehensive 
> description of HTML classes, that a skin developer might take as a starting 
> point to work on.
> Also, is [2] the way MW core will go and stay on for a while or is it "just" 
> a convenient option for developers?
> Last question, is there any deprecation policy in place similar to the one 
> for PHP ([3])?
>
> Cheers
> Stephan
>
> [1] https://phabricator.wikimedia.org/T192752
> [2] https://www.mediawiki.org/wiki/OOUI
> [3] https://www.mediawiki.org/wiki/Deprecation_policy
>
> ___
> 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] Guideline on HTML classes?

[Stephan Gambke]

On a tangent to T192752 ([1]), are there any general guidelines on which 
classes are or should be used by core and extension devs on HTML elements for 
styling?
On mw.org I found scattered remarks about mw-ui-progressive, 
mw-ui-constructive, and the like and I found the page on OOUI ([2]), which I 
could probably reverse engineer. What I did not find is a comprehensive 
description of HTML classes, that a skin developer might take as a starting 
point to work on.
Also, is [2] the way MW core will go and stay on for a while or is it "just" a 
convenient option for developers?
Last question, is there any deprecation policy in place similar to the one for 
PHP ([3])?

Cheers
Stephan

[1] https://phabricator.wikimedia.org/T192752
[2] https://www.mediawiki.org/wiki/OOUI
[3] https://www.mediawiki.org/wiki/Deprecation_policy

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l