Dealing with variant URLs is a complicated issue. The rules for variants are different depending on which API or content you are dealing with. Many clients have implemented logic to deal with this, and this code basically has to be rewritten on every client, usually with a different set of bugs.
Most of this could be solved by returning all the URLs needed by clients so they never have to figure out how to mangle the titles.
This ticket has two major components:
1. Return an exhaustive dictionary of URLs and titles for all variants of the page
2. Ensure the primary titles and URLs in the summary response are actually correct and take into account the idiosyncrasies of manipulating variant URLs for each API
The structure will be something like the top level dictionaries, but scoped to each variant:
```
variants: {
zh: {
titles: {
"title": "File:Collage_of_Nine_Dogs.jpg", // Use this when constructing a URL
"normalized_title": "Collage of Nine Dogs.jpg", // Use this for plain text
"display_title": "<strong>Collage of Nine Dogs.jpg</strong>", // Use this for WebViews
"namespace_title": "File", // Use this when you want to include the namespace in the rich or plain text title
},
content_urls: {
page: "…",
revisions: "..."
editor: "…",
talk_page: "...",
},
api_urls: {
summary: "...", //The URL to this response
mobile_sections: "...", //return for now, but will be deprecated
read_html: "...", //new PCS endpoint
content_html: "...", //new PCS end point
metadata: "…", //new PCS end point
references: "…", //new PCS end point
gallery: "…", //new PCS end point
revisions: "...",
edit_html: "..." //Parsoid HTML url
talk_page_html: "...", //Parsoid HTML url for the talk page
},
zh-cn: {
titles: {
"…"
},
content_urls: {
"…"
},
api_urls: {
"…"
}
},
```
See the parent tickets for the proposed content of each of the dictionaries.
Some open questions:
1. The implementing engineers will need to research this a bit further to see if this is a good structure
2. Do we need other information like marking the "canonical" variant?