Proposal from me and @Mooeypoo: add a setting like $wgKartographerDefaultLang, which defaults to null (meaning page language) but can optionally be set to 'local'.

We can do the default resolution in JavaScript to make it more responsive, but static maps would remain stale.

I also just realized: we've had code propagating the lang attribute in production for a few weeks. That means we already have static maps in the parser cache whose URLs contain e.g. ?lang=fr. These will magically become i18ned after the i18n deployment unless they are reparsed (a reparse would change it to ?lang=local).

Wouldn't all current static maps be lang=fr on fr wikis both before and after the change? No one is using lang=local yet

In T192955#4155839, @Pnorman wrote:

Wouldn't all current static maps be lang=fr on fr wikis both before and after the change? No one is using lang=local yet

Sorry, I forgot to provide a missing piece of context: @SBisson told me about a plan where he wants to make lang=local the default, so that we can simulate the old behavior with the new tiles, and get rid of the old tiles.

In T192955#4155420, @Catrope wrote:

Proposal from me and @Mooeypoo: add a setting like $wgKartographerDefaultLang, which defaults to null (meaning page language) but can optionally be set to 'local'.

I'm actually going back and forth between 1) a string variable that can take 'local' but also 'en' or 'fr' and a special value (null, or 'pageLanguage') that means page content language; and 2) a more restrictive boolean flag (i.e. $wgKartographerMapsInContentLanguage) that would default to false (translated into lang=local) and could be enabled to mean page content language. The ability to specify any string like 'en' or 'fr' can be seen as a feature or an open door to mistakes and weird configuration we would rather not have.

We can do the default resolution in JavaScript to make it more responsive, but static maps would remain stale.

That the bigger issue. Regardless of the variable used for rollout (custom source or custom lang), all pages with maps on wikis with static maps will be stale until edited. There must be a way around that. Has no one ever wished to deploy a parser update and have it fix all pages using feature X? Is it completely unreasonable to loop on all pages with Category:Page_with_maps and ?action=purge ?

Change 429471 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/Kartographer@master] Determine default language dynamically, and add config flag

https://gerrit.wikimedia.org/r/429471

Change 429471 merged by jenkins-bot:
[mediawiki/extensions/Kartographer@master] Determine default language dynamically, and add config flag

https://gerrit.wikimedia.org/r/429471

Change 429985 had a related patch set uploaded (by Catrope; owner: Catrope):
[operations/mediawiki-config@master] Set $wgKartographerUsePageLanguage to false everywhere

https://gerrit.wikimedia.org/r/429985

Change 429985 merged by jenkins-bot:
[operations/mediawiki-config@master] Set $wgKartographerUsePageLanguage to false everywhere

https://gerrit.wikimedia.org/r/429985

Mentioned in SAL (#wikimedia-operations) [2018-04-30T23:36:33Z] <catrope@tin> Synchronized wmf-config/InitialiseSettings.php: Set $wgKartographerUsePageLanguage to false everywhere (T192955) (duration: 00m 59s)

Change 433931 had a related patch set uploaded (by Thiemo Kreuz (WMDE); owner: Thiemo Kreuz (WMDE)):
[mediawiki/extensions/Kartographer@master] Fix missing …LangCode property declarations in TagHandler

https://gerrit.wikimedia.org/r/433931

Change 433931 merged by jenkins-bot:
[mediawiki/extensions/Kartographer@master] Fix missing …LangCode property declarations in TagHandler

https://gerrit.wikimedia.org/r/433931