RFC: Per-language URLs for multilingual wiki pages
Open, NormalPublic

Description

(Rewritten 2016-11-26)

Synopsis:

For multilingual wikis such as Wikidata, but also Commons and perhaps mediawiki.org and meta.wikimedia.org, it would be useful if anonymous visitors could browse the wiki using their preferred user language. We currently do not allow this, since serving pages localized for different languages from the same URL would poison the web cases. There is at the moment no way to bookmark or link to a specific language version of a page, and search engines will only index one language version.

Simply disabling the web caches for such wikis, or at least bypass such caches if a selang or uslang cookie is set, might be feasible if anonymous traffic on the relevant wiki is low enough. Another option would be to vary (split) the cache based on a language cookie. However, both options still do not allow linking to a specific language version, or indexing by search engines.

Proposed solution:

  • encode the user's preferred language in the URL path, and use it to set the value of the uselang URL parameter via some kind of rewrite magic. A similar approach is already used for wikis that support language variants.
  • $wgArticlePath needs to be automatically adjusted based on uselang, so that all generated links point to pages under the current per-language url path. (We may run into trouoble witht the message cache here)
  • the (old) language neutral path should be rewritten to some special page which redirects to the user's preferred version of the page, similar to how Special:InMyLanguage works. The user's preferred language could be determined by ULS via a hook.
  • Logged in users would also be using the per-language paths for consistency, but would bypass the web caches as before. When viewing a page in a path that disagrees with the user language from their preferences, some kind of notification bar should be shown, with easy access to the language rendering in the user's normal (as per preferences) language.

Note: variants apply to the pages content language, while this RFC is concerned with the user language. How user language and content language relate, in particular for localizable page content and variants, is not in scope of this RFC. This should rather be discussed in the context of T114640: RFC: make Parser::getTargetLanguage aware of multilingual wikis.

Discussion points:

  • Is the proposed solution viable and useful?
  • Can we use varnish's xkey feature to purge all language versions of a page at once? If not, what needs to be done, what alternatives do we have?
  • If we do this, what should the path scheme look like? /wiki-fr/Foo or just /fr/Foo or something else? Should the path pattern be the same as for variants, or should it be different, so both can be used at once?
  • Can we first try this without the automatic rewrite of the classic /wiki/ path? On which wiki shall we try this first?
  • How do we make a wiki-link to a specific language version of a page? Do we need a {{#link:Foo}} function?

See also:

Related Objects

There are a very large number of changes, so older changes are hidden. Show Older Changes
coren added a comment.Feb 5 2016, 5:42 PM

I've created a variation on common's link trickery with JS for wikimania2017wiki (see related T122994) and it works pretty well; so having the links constructed in that way properly would help a great deal.

While this proposal seems okay, what is wrong with /xx prefix like TranslateExtension currently uses? Having /wiki/Foo 302 to /wiki/Foo/xx would work just as well, it seems to me.

Purodha added a subscriber: Purodha.EditedFeb 5 2016, 5:51 PM

We have an extension that already offers some or much of the required functionality: https://mediawiki.org/wiki/Extension:Polyglot Maybe, it should be integrated into core. Maybe not so, as not to swamp small monolingual wiki installations with even more unwanted multilingual stuff that freshly installed wikis want to get rid of ;-) such as hundreds of unnecessary i18n files eating disk space.

For multilingual wikis, the user language is part of the request path: e.g. we would use /wiki-de/ instead of /wiki/ .

Why not use /wiki/.../be-tarask as it is already established practice in many wikis and fields, and that users are used to?

When viewing a page ...

The complicated user bar with or without warning is imho nonsense, when the user himself decided on a language. One then likely wanted it so :-) Rather have a list to choose from all available languages for a page and show it unconditionally. Only, if a link lead to a page which does not exist in the currently selected language, there could be either a warning replacing the page contents with an option to choose another language, or a warning and a page shown in a fallback language of some kind. See also T50496 for the latter.

Should translated names for namespaces and special pages be supported on the language specific pathes? (would be nice, but tricky)

Yes, on the long run and as an independent task. Tricky, indeed. Needs refactoring of various things. Would finally solve, or rather mainly obsolete, T43969.

Provide a way to explicitly link to a specific language rendering from wikitext,

That should be easily possible by appending /zxx to the target page name. Also, the language selector can be set via a template.

...what is wrong with /xx prefix like TranslateExtension currently uses?

fwiw, that is a suffix ...

Having /wiki/Foo 302 to /wiki/Foo/xx would work just as well, it seems to me.

Yes it does.

i'd love if "wiki" would redirect to the original version as long as a user is able to understand the language according to her preferences. e.g. in my preference i can list "en, fr, de, cn". original version is the one created first, or marked as such.

Strainu added a subscriber: Strainu.Feb 5 2016, 8:45 PM

Totally agree with @Purodha and @coren , the use of the /xx suffix is preferable, not only because other wikis use it, but also because it's easier to link to random languages from non-Lua templates without using string parsing templates.

daniel added a comment.Feb 5 2016, 9:10 PM

@Nemo_bis, you wrote

It's not currently clear what purpose this new URL format would serve, so
it's hard to judge whether the proposal is sufficient or overkill for the
goal. The title is misleading, in that "Per-language URLs for pages of
multilingual wikis" already exist in practice (see below). This is, in fact,
the main characteristic of multilingual wikis in MediaWiki as opposed to
other wikis or CMSs: to change language, you nearly always have to change
URL.

This is about multilingual pages, where there is only one source, but what you see depends on your language. This is the case for example for wikidata, and for (some) file descriptions on commons.

Having separate pages for each language already works, of course. But the wiki won't automatically show you the one you understand.

Personally I think this proposal would be more useful if rephrased as "do
whatever is needed to fix https://phabricator.wikimedia.org/T58464".

page content depending on the user's interface language (for instance
wikidata.org and commons.wikimedia.org, or other wikis using the Translate
extension). All language versions (renderings) of a page are served from
the same URL

Translate uses different URLs, with the standard language-code subpage
format.
https://www.mediawiki.org/wiki/Help:Extension:Translate/Page_translation_administration

This is not about translation. It's about showing the *same* information (e.g. the license of an image) in the user's language.

Commons uses AnonymousI18n.js and the uselang URL parameter, by making
content language rely on interface language.

That's more along the lines I was thinking of. It would be nice if we could actually serve content in the user's desired language in the first place, though.

So you suggest to force the content language based on the interface language?
I hope not; that's something Commons (and the old Meta-Wiki
LanguageSelect/LangSwitch) do out of necessity, not because it's a good
thing.

Not "force", but "default", yes. It works perfectly fine for wikidata. What problems do you see?

warnign bar is shown at the top

This is the AnonymousI18n.js approach. FWIW, we have developed better ways in
the meanwhile (except that WMF ops don't support them).

Can you describe them a bit?

zhwiki already has something like this, where the URL selects a variant for
LanguageConverter. (cf https://phabricator.wikimedia.org/T114640#1800068)
Could you describe how this is different (or the same)?

That's about variants, not languages.

Indeed. So why not make it work for languages too? The mechanism is the same.

daniel added a comment.Feb 5 2016, 9:12 PM

While this proposal seems okay, what is wrong with /xx prefix like TranslateExtension currently uses? Having /wiki/Foo 302 to /wiki/Foo/xx would work just as well, it seems to me.

That works well enough for translations. I wrote an Extension:Polyglot to do just that, 9 years ago.

But this proposal isn't about translations. It's about showing the *same* content in different languages. Like the structured information on file description pages.

daniel added a comment.Feb 5 2016, 9:13 PM

My take-away from the comments so far is that I need to clarify that this is not about manually translated text. It's about displaying structured data in the user's preferred language. For translations, I also prefer suffixes.

daniel added a comment.Feb 5 2016, 9:23 PM

...and I suppose I should talk about namespace in the proposal. Will update.

daniel renamed this task from RFC: Per-language URLs for pages of multilingual wikis to RFC: Per-language URLs for multilingual wiki pages.Feb 5 2016, 9:38 PM
daniel updated the task description. (Show Details)

Ok, I hope it's clearer now.

My take-away from the comments so far is that I need to clarify that this is not about manually translated text. It's about displaying structured data in the user's preferred language. For translations, I also prefer suffixes.

It should be about both IMHO (e.g. s/nice/compulsory in the last challenge). It doesn't make sense for the linkers to know whether the namespace you want to link to has structured data or is manually translated - the link to Qxxxxx and File:Yyyy.jpg should have the same structure.

I do understand now that using that suffix might create a confusion, but the new system should be aware of the old one.

Ok, I hope it's clearer now.

Indeed, thank you!

I think we need very clear rules about how we structure our URLs. If we already have en.wikipedia.org, Page/en, and /zh-tw/ (variants?), it's time to figure out and explicitly define our long-term URL scheme. This process would include clearly defining which language codes are used, where they'll appear in the resource locator string, and what the expected behavior is when they're requested in specific ways (anonymous HTTP GET, authenticated HTTP POST, etc.).

In other words, we need a spec.

(I intentionally include en.wikipedia.org as that is really a choice we make. We could move everything to www or no-www wikipedia.org.)

Purodha added a comment.EditedFeb 6 2016, 8:03 AM

I see a point in the various technically independent things that can have languages:

  • Interface messages (including page layout)
    • including messages from fallback languages which are not currently correctly identified as belonging to another language
  • Page data,
    • per wiki language,
    • per page language (true multilingual, or translated, or machine-translated)
    • words or snippets that authors enter in another language or script but the page language or script (e.g. quotes, names, or foreign words in language comparisons , etc.),
      • having correct language and directionality markup,
      • not marked up as such,
  • Imported data from various sources,
    • Commons descriptions,
    • WikiData structured data,
  • Interlanguage links.

Do we really want to select all these languages individually and separately, or do we rather want to have mainly one selection only?

Note that users wanting to look something up in a language or script that they can not, or hardly, read may have problems when the interface changes.

The finer the granularity, we need, the more complex an URI structure we get.

Nemo_bis added a comment.EditedFeb 7 2016, 9:36 AM

Having separate pages for each language already works, of course. But the wiki won't automatically show you the one you understand.

Why do you think so? We can redirect to the other URL.

This is not about translation. It's about showing the *same* information (e.g. the license of an image) in the user's language.

I don't understand this distinction. This seems the definition of translation to me.

Ok, I hope it's clearer now.

No, it's not any clearer. Examples of multilingual wiki pages are:

  • translatable pages on most multilingual wikis, which already have per-language URLs (Page, Page/en, Page/de etc.);
  • file descriptions on Commons and other autotranslate-like pages, which already have per-language URLs (Page?uselang=de, Page?uselang=it etc.).

It's about displaying structured data in the user's preferred language.

So this RFC is just about finding a replacement for the current usage of Q123456?uselang=de and similar? It would be useful to state so in the summary, as that's much easier to understand and address.

We could start by making the *de facto* uselang standard explicitly supported by MediaWiki's linking functions, and then maybe think of a different URL format if there is ever a need.

daniel added a comment.Feb 7 2016, 1:12 PM

This is not about translation. It's about showing the *same* information (e.g. the license of an image) in the user's language.

I don't understand this distinction. This seems the definition of translation to me.

The difference is that you can view a wikidata item in different languages, without having to define the item in different languages. The content of the page is not translated, it's language-neutral (except for the label and description, which are multilingual).

Ok, I hope it's clearer now.

No, it's not any clearer. Examples of multilingual wiki pages are:

  • translatable pages on most multilingual wikis, which already have per-language URLs (Page, Page/en, Page/de etc.);
  • file descriptions on Commons and other autotranslate-like pages, which already have per-language URLs (Page?uselang=de, Page?uselang=it etc.).

Indeed, this RFC is about the second use case. uselang=it etc causes the web cache (varnish) to be bypassed, and it's not persistent - when you click a link, you are back to the standard language. I would like to change that. The preferred way to change that is to put the language into the path instead of a parameter, and make the Linker aware of uselang, so it becomes "sticky".

So this RFC is just about finding a replacement for the current usage of Q123456?uselang=de and similar? It would be useful to state so in the summary, as that's much easier to understand and address.

What I propose is technically very similar to what the uselang and variant URL parameters do. And we may well keep using these internally. There are a few more aspects to it, like making the Linker aware of this, coupling the parser target language to the user language (for some pages/namespaces), and allowing such multi-lingual pages to make proper use of web caches, so hacks like AnonymousI18n.js are no longer needed.

We could start by making the *de facto* uselang standard explicitly supported by MediaWiki's linking functions, and then maybe think of a different URL format if there is ever a need.

That is exactly what this RFC is about, yes.

daniel updated the task description. (Show Details)Feb 7 2016, 1:15 PM

The preferred way to change that is to put the language into the path instead of a parameter, and make the Linker aware of uselang, so it becomes "sticky".

Do we not have setlang= already which is sticky?

Do we not have setlang= already which is sticky?

It is in ULS and (soft) deprecated.

daniel added a comment.EditedFeb 8 2016, 11:30 AM

@Purodha setlang works OK for logged in users, but it still means we serve different content for the same URL. Which is Not Nice (tm), and screws with web caches. For anons, setlang sets a cookie, which would either be ignored by the web caches, causing random language versions to be cached and served, or it would cause the cache to be bypassed, causing performance issues. That's why it's soft-deprecated, and not enabled for anons. I wrote this RFC in order to fix that.

I agree by the way that we should avoid having a confusing set of language settings for various aspects of our content. I propose having two, basically: the "current" language (uselang), and the "preferred" language (from user preferences). Anons only have a "current" language. This language would be applied to the UI, and to the content of multilingual pages. We may also use it to pick translations, though I'm not sure about the UI for that.

zhwiki already has something like this, where the URL selects a variant for LanguageConverter. (cf https://phabricator.wikimedia.org/T114640#1800068) Could you describe how this is different (or the same)?

That's about variants, not languages.

Yes, but variants and languages share the distinction that @daniel made here:

My take-away from the comments so far is that I need to clarify that this is not about manually translated text. It's about displaying structured data in the user's preferred language. For translations, I also prefer suffixes.

Rather than add "yet another" way to specify a language in the URL, I'd prefer if we try to reuse the mechanisms we already have. When the user selects a language+variant in which to view a page, it seems natural that the UX text would also change to that same language+variant. They are specified in the same way: base language code, hyphen, variant string.

For the record (and belatedly):
This was discussed at the 2016 MediaWiki Developer Summit.

My recollection was that there was more extensive discussion than that which is captured in the above notes.

@cscott As far as I remember, the discussion was mostly about T114640: RFC: make Parser::getTargetLanguage aware of multilingual wikis. There isn't much in the notes that relates to per-language URLs.

This was discussed at E140: RFC Meeting: Per-language URLs for multilingual wiki pages (2016-02-10, #wikimedia-office) . The transcript for that discussion is at E140#1400. Action items:

  • ACTION: DanielK_WMDE to list proposed URL schemes with pros/cons (TimStarling, 22:57:32)
  • ACTION: confer with ops re vcl_hash (TimStarling, 23:01:52)

Recapping some discussion in E168: RFC Meeting: Support language variants in the REST API (2016-04-27, #wikimedia-office), there's the question of whether the "target language" and "user interface language" need to be distinct and/or specified separately. In T114640: RFC: make Parser::getTargetLanguage aware of multilingual wikis we let {{int}} expand to label localized in the UX language, independent of the targetted language variant (which is set via the initial path prefix or user preference).

My strawman example is a user on zhwiki who has a target variant set to zh-hant but has the UX language (image metadata labels, {{int}} output, page UI) set to, say, de. Is this something we ought to account for? If you specify de alone, is language converter just turned off? (The result is an incomprehensible mix of character sets and variant terms.) Or do we fall back to some default (politics alert) and acknowledge this is nonideal but it's a corner case and unusual in practice?

RobLa-WMF mentioned this in Unknown Object (Event).May 11 2016, 12:09 AM
RobLa-WMF triaged this task as Normal priority.May 11 2016, 8:23 PM

Per E170

Scott_WUaS updated the task description. (Show Details)May 25 2016, 9:42 PM
Restricted Application added a subscriber: Cosine02. · View Herald TranscriptNov 16 2016, 10:29 PM
daniel updated the task description. (Show Details)Nov 26 2016, 9:37 PM
daniel updated the task description. (Show Details)Nov 26 2016, 9:49 PM
daniel updated the task description. (Show Details)

In the meanwhile I have been trying to resurrect the discussion on the status of the web cache issue at T149419: Interface language selection for unregistered users on Wikimedia projects.

I don't think I will be able to attend the meeting at midnight – I have asked for rotating times in the past. Maybe I'll have time to add some thoughts here before the meeting.

Nikerabbit updated the task description. (Show Details)Nov 27 2016, 9:48 AM

Thank you for the pointer, @Nikerabbit!

As to rotating the meeting times - yes, we should discuss that again. Maybe it's worth it's own RFC! The main issue is that any other time is extremely inconvenient either for me or for Tim.

daniel updated the task description. (Show Details)Nov 28 2016, 7:40 PM
daniel added subscribers: Jonas, thiemowmde.

Some thoughts:

There are many websites which do not have per-language URLs and that seems fine. There is always a trade-off: whether making it harder to share an URL with explicit interface language or to share an URL without an explicit interface language. To me the case of not having explicit interface language in the URL feels as the more common use case, but I don't have data to back this up. But it can be compared to the permanent links where oldid is present, but not there by default. I would argue that interface language should also be optional, put possible to add when wanted (which is right now possible with uselang).

Sure, if there is no sane way to do either manual or automatic interface language selection (see T149419), then having explicit interface language in the URL can be an acceptable trade-off, but it would not be optimal for user experience in my opinion. It is not clear from the proposal whether this URL scheme would only be used internally (say, rewriting non explicit language URL based on a cookie in the frontend), or also externally. Considering that other MediaWiki installation would need this kind of URL scheme, it would be better if Wikimedia did not deviate from this practice externally.

And if we still want to use per-language URLs, I would require very good justification for not using the existing uselang parameter.

In relation to Translate, I would be happy for solution to redirecting readers to content in the correct language (interface language) that would not depend on using Special:MyLanguage which breaks link tables.

I do recommend using ULS's logic to determine default language if possible, there is no reason to build new, likely diverging, solutions.

There are many websites which do not have per-language URLs and that seems fine. There is always a trade-off: whether making it harder to share an URL with explicit interface language or to share an URL without an explicit interface language.

I think you are right if we are really talking about the UI language. And in MediaWiki we technically are talking about the UI language, not the content language.

But the main use case, Wikidata, generates content in the UI language. So uselang=fr will not just cause your navigation to be in French, it will cause the entire page to be in French. It seems quite useful to e.g. have Google index these different versions separately, and to be able to bookmark them, and link to them.

I am not proposing to do this for all wikis. I'm proposing to do it for Wikidata, Commons, and perhaps a handful others.

To me the case of not having explicit interface language in the URL feels as the more common use case, but I don't have data to back this up. But it can be compared to the permanent links where oldid is present, but not there by default. I would argue that interface language should also be optional, put possible to add when wanted (which is right now possible with uselang).

The uselang argument currently breaks web caches, and it's arguably ugly. Basically, my proposal is a prettified, "sticky" uselang. "Sticky" because links would be generated so that they would again point to the same language version.

It would still be possible to link to a language neutral path. My thinking is that the neutral path should trigger an HTML redirect based on the user language (or a good guess), but it could also serve content directly (though it would have to bypass web caches then). Or always use user language = content language for anons, as we do now.

Sure, if there is no sane way to do either manual or automatic interface language selection (see T149419), then having explicit interface language in the URL can be an acceptable trade-off, but it would not be optimal for user experience in my opinion.

To me it seems to be exactly the other way around. Having separate URLs serves the user better - the different renderings of the page get indexed separately by google, you ban bookmark a specific language, and you can link others to a specific language. Some guessing heuristic should be used as a fallback.

It is not clear from the proposal whether this URL scheme would only be used internally (say, rewriting non explicit language URL based on a cookie in the frontend), or also externally.

[...]

And if we still want to use per-language URLs, I would require very good justification for not using the existing uselang parameter.

The URL path containing encoding the desired language will be used *only* externally. The idea is to use uselang internally. The language encoded in the path will be rewritten to uselang before it hits MediaWiki code.

In relation to Translate, I would be happy for solution to redirecting readers to content in the correct language (interface language) that would not depend on using Special:MyLanguage which breaks link tables.

Yes, but I would like to keep that discussion separate. The relationship between user language and content language (and variant) is quite complex, and differs across use cases. My proposal should already work out of the box with the way file description pages are localized on commons.

I do recommend using ULS's logic to determine default language if possible, there is no reason to build new, likely diverging, solutions.

Yes, absolutely. There is no intention to build another language selector or guessing heuristics.

daniel updated the task description. (Show Details)Nov 29 2016, 5:33 PM
daniel updated the task description. (Show Details)Nov 29 2016, 5:37 PM
daniel updated the task description. (Show Details)Nov 29 2016, 6:01 PM
daniel updated the task description. (Show Details)

To me it seems to be exactly the other way around. Having separate URLs serves the user better - the different renderings of the page get indexed separately by google, you ban bookmark a specific language, and you can link others to a specific language.

Most of the times, when someone shares a uselang URL with me (e.g. those which many Wikimedia wikis generate to link Commons files), the URL is wrong. People don't quite pay attention to the meaning of the URLs they share.

Most of the times, when someone shares a uselang URL with me (e.g. those which many Wikimedia wikis generate to link Commons files), the URL is wrong. People don't quite pay attention to the meaning of the URLs they share.

What do you mean by "wrong"? You mean you get a language-specific URL (for some reandom language), while you would prefer a language-neutral one?

My idea to resolve this is to show a navigation bar when the current uselang disagrees with your preferences. So going from the "wrong" to "your" language would be a single click. This was part of the original RFC, but I decided to cut it out, to keep the scope narrow.

Anyway, would that address your problem with the "wrong" URL being shared?

daniel added a comment.Dec 1 2016, 4:12 PM

IRC meeting on #wikimedia-office at 22:00 UTC on 2016-11-30

Full log: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-11-30-22.00.log.html

Minutes: RFC: Per-language URLs for multilingual wiki pages (TimStarling, 22:01:20)

  • LINK: https://phabricator.wikimedia.org/T114662 (DanielK_WMDE, 22:01:54)
  • LINK: https://phabricator.wikimedia.org/E384 (DanielK_WMDE, 22:02:03)
  • LINK: https://commons.wikimedia.org/wiki/MediaWiki:AnonymousI18N.js (legoktm, 22:07:30)
  • YairRand notes that we may need /w-en/ etc too, for action=edit at least (DanielK_WMDE, 22:08:11)
  • LINK: https://phabricator.wikimedia.org/T149419 (DanielK_WMDE, 22:09:19)
  • <DanielK_WMDE> subbu: re default path for a default language: i think that when we first try this, the default path should stay as it is now. eventually, the default path can trigger a redirect to the apprpriate language path <subbu> wfm. (DanielK_WMDE, 22:13:33)
  • we can use subdomains instead of pathes, but it's probably harder to get right (DanielK_WMDE, 22:14:13)
  • competing RFC T149419 proposes to split the cache on a cookie, instead of the url. (DanielK_WMDE, 22:14:42)
  • LINK: https://github.com/varnish/varnish-modules/blob/master/docs/vmod_xkey.rst (DanielK_WMDE, 22:17:29)
  • vernish xkey could be used to purge all language versions (renderings) of a page in one go (DanielK_WMDE, 22:19:28)
  • perhaps could have experimental option to use xkey for regular page purges, and enable it on a small wiki (DanielK_WMDE, 22:21:46)
  • LINK: https://wikitech.wikimedia.org/wiki/XKey has some docs (legoktm, 22:25:07)
  • LINK: https://wikitech.wikimedia.org/wiki/XKey (DanielK_WMDE, 22:25:37)
  • "We currently do not support setting the same XKey on very large numbers of objects. In practice something on the order of 1-100 objects attached to a given XKey is reasonable." (DanielK_WMDE, 22:26:40)
  • <TimStarling> action item to corner bblack and make him say that? (DanielK_WMDE, 22:27:02)
  • <TimStarling> the patch would be to CdnCacheUpdate (DanielK_WMDE, 22:34:32)
  • ask ops about impact of cache fragementation (x20?) (DanielK_WMDE, 22:35:42)
  • <TimStarling> think we can go ahead with [xkey support in CdnCacheUpdate] without ops approval (DanielK_WMDE, 22:38:20)
  • <TimStarling> basically use the language-neutral URL as the xkey (DanielK_WMDE, 22:40:37)
  • gwicke would prefer subdomains instead of pathes to select the language (DanielK_WMDE, 22:45:01)
  • <TimStarling> can use the actual uselang parameter for /w/index.php (DanielK_WMDE, 22:48:00)
  • Gabriel would like to see some details on how language selection would affect API responses (both PHP and REST) (gwicke_freenode, 22:55:25)
  • <TimStarling> [use PathRouter, which is hookable; the hook is WebRequestPathInfoRouter] (DanielK_WMDE, 22:55:44)
  • LINK: https://phabricator.wikimedia.org/T146965 (DanielK_WMDE, 23:02:18)

My idea to resolve this is to show a navigation bar when the current uselang disagrees with your preferences. So going from the "wrong" to "your" language would be a single click.

I don't quite care about that, I already know how to switch. The point is that users share URLs without having any idea of their meaning.

daniel moved this task from Inbox to Push on the User-Daniel board.Jan 5 2017, 7:02 PM
daniel moved this task from Push to Project on the User-Daniel board.
Nemo_bis updated the task description. (Show Details)Mar 30 2017, 7:48 AM