Page MenuHomePhabricator

Review language handling in Kartographer & Kartotherian
Open, Needs TriagePublic

Description

Clarify existing requirements for maps localization (labels, script, ...) and investigate existing bug reports. Determine whether future work should be done to align software to requirements, or whether the requirements need adjustment.

Event Timeline

I'm looking into streamlining languages for the Parsoid support of Kartographer. My not-so-hidden goal is to get rid of "target language" for Parsoid, and to be able to pass either "this is page language", "this is user language" or "this is specific language X".

Here are the usages that I've found for localized strings in Kartographer:

  • coordinates for maplinks without labels
  • href for mapframe
  • href for maplink
  • mapframe imageUrl parameters
  • error handling

The language can be:

  • the page language
  • the user language (interface language)
  • the map territory local language ("local")
  • a specific language passed in the parameters of the map tag.

Here's the current situation, and what I'd propose to do for Parsoid (note: this does not aim at keeping the status quo (which comes with its own issues, see for instance T305926) ).

EntityNow (legacy)Parsoid (proposal)
Coordinates for maplinks without labelsTargetLanguagePage language
Href for mapframeResolvedLanguageParsoidResolvedLanguage
Href for maplinkResolvedLanguageParsoidResolvedLanguage
Mapframe imageUrl parametersResolvedLanguageParsoidResolvedLanguage
Error handlingTargetLanguageUser language

TargetLanguage in legacy is, in first approximation:

  • Whatever is passed in parserOptions if it exists, and otherwise
  • user language for messages that are marked as "interface language"
  • page language for the other messages. (It's PROBABLY more subtle than that, but let's assume this is enough for now.)

ResolvedLanguage is, in order of fallback:

  • Specified lang code (can be "local")
  • If KartographerUsePageLanguage is set -> targetLanguage
  • "local".

Suggestion for ParsoidResolvedLanguage, in order of fallback:

  • Specified lang code (can be "local")
  • If KartographerUsePageLanguage is set -> page language
  • Else "local"

An alternative, rather than using "page language" directly in many places, may be to either add a new option or to re-use $wgKartographerUsePageLanguage to fine-tune what is done on some wikis (commons in particular) to use the interface language language rather than the page language in some cases.

What am I missing / what needs to be fixed ?

One thing to take into account here is bcp47 languagecodes vs MW internal languagecodes. Im not 100% sure which is used where and if those are consistent accross all layers from html to backend. (Local specifically is definitely NOT bcp compliant i guess)

As far as I remember, if the language is "local", we're not exporting anything out of Kartographer anyway - it's just a shorthand to not add any language code when resolving the map. Thanks for pointing that out!

I'm looking into streamlining languages for the Parsoid support of Kartographer. My not-so-hidden goal is to get rid of "target language" for Parsoid, and to be able to pass either "this is page language", "this is user language" or "this is specific language X".

Please also note there are "page view language" and take language conversion into account (as described in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Kartographer/+/923286 and filed as T193815: Figure out how to handle language variants with maps .

Change 923286 had a related patch set uploaded (by Isabelle Hurbain-Palatin; author: Isabelle Hurbain-Palatin):

[mediawiki/extensions/Kartographer@master] Use page language rather than user language

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

Change 923286 merged by jenkins-bot:

[mediawiki/extensions/Kartographer@master] Use page language rather than user language

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