API requests supports the URL parameter variant. For instance, compare
https://sr.wikipedia.org/w/api.php?action=parse&format=jsonfm&formatversion=2&page=HTTP&variant=sr-ec and
https://sr.wikipedia.org/w/api.php?action=parse&format=jsonfm&formatversion=2&page=HTTP&variant=sr-el
But it generates the warning:
"warnings": "Unrecognized parameter: 'variant'"
So remove the warning and support the parameter officially.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T309166 Review language handling in Kartographer & Kartotherian | |||
| Open | Feature | None | T193815 Figure out how to handle language variants with maps | ||
| Resolved | None | T246314 Map cannot be displayed when Simplified Chinese characters are present | |||
| Open | None | T41272 Bugs in "Live preview" feature (tracking) | |||
| Resolved | Fomafix | T294052 Support variants of page content languages in live preview | |||
| Resolved | BUG REPORT | Daimona | T284625 Live preview should respect user's language variant setting | ||
| Resolved | Fomafix | T117529 TextExtracts API supports URL parameter variant but generates warning and generates no warning for the parameter exvariant | |||
| Resolved | Samwilson | T117549 Do not generate warning on parameter `variant` for API requests |
Change 250686 had a related patch set uploaded (by Gerrit Patch Uploader):
ApiParse: Support parameter variant
Quick cross-reference: the variant parameter is only documented here in phab: T44356#439479 and T34906#381101
The patch in gerrit seems to be stuck based on resolution of caching issues. Note that caching is apparently currently broken in some cases if you use this API parameter as a logged-in user, so beware.
Resolving T44240: LanguageConverter should not inspect global state to determine the variant would make it easier to progress on this task, since then the API can have more direct control over the variant used (or at least better knowledge of how the variant is going to be determined).
This task has been assigned to the same task owner for more than two years. Resetting task assignee due to inactivity, to decrease task cookie-licking and to get a slightly more realistic overview of plans. Please feel free to assign this task to yourself again if you still realistically work or plan to work on this task - it would be welcome!
For tips how to manage individual work in Phabricator (noisy notifications, lists of task, etc.), see https://phabricator.wikimedia.org/T228575#6237124 for available options.
(For the records, two emails were sent to assignee addresses before resetting assignees. See T228575 for more info and for potential feedback. Thanks!)
Change 732908 had a related patch set uploaded (by Samwilson; author: Samwilson):
[mediawiki/core@master] Downgrade HTTP caching when language variant is in use
FTR, according to my results detailed in T294848 (in particular, see section "One final word"), it should be possible to officially add support for this parameter without fixing the caching bug first.
Tagging PET as code stewards for the API component. The question is: would you be fine with officially supporting the "variant" parameter in ApiMain? The caching bug mentioned above wouldn't be affected, so my question is more like "do we want such a feature, or should there be a better way to achieve the same goal?".
Change 736618 had a related patch set uploaded (by Samwilson; author: Samwilson):
[mediawiki/core@master] Expose existing 'variant' API parameter
If it's decided that it's the right approach, here's a patch for adding the variant param: r736618
Change 732908 abandoned by Samwilson:
[mediawiki/core@master] Downgrade HTTP caching when language variant is in use
Reason:
Notes from the Platform Engineering meeting yesterday:
Sam: Do not generate warning on parameter variant for API requests (T117549): https://gerrit.wikimedia.org/r/c/mediawiki/core/+/736618
- Should it be supported for ALL modules?
- Uselang is available everyhwere (for error messages), so variant should be as well
- Several modules parse content.
- Variant uses global state internally
- No technical reason to not support it for all modules, parity with uselang
So we're good to proceed with the above patch.
Change 736618 merged by jenkins-bot:
[mediawiki/core@master] Expose existing 'variant' API parameter
Change 250686 abandoned by Fomafix:
[mediawiki/core@master] ApiMain: Support parameter variant
Reason:
Superseded by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/736618 (Ib7347f7c6fbffd4c0cbb378a14a0166da6b3d39c) with the same solution as in PS5.
1.38.0-wmf.12 is now deployed.
https://sr.wikipedia.org/w/api.php?action=parse&format=jsonfm&formatversion=2&page=HTTP&variant=sr-ec and
https://sr.wikipedia.org/w/api.php?action=parse&format=jsonfm&formatversion=2&page=HTTP&variant=sr-el generates no warning anymore.