User-facing URLs must be simplified

RESOLVED FIXED

Status

Mozilla Developer Network
Editing
P1
blocker
RESOLVED FIXED
6 years ago
4 months ago

People

(Reporter: teoli, Assigned: lorchard)

Tracking

Details

(Whiteboard: u=l10n c=wiki s=2012-06-05 p=3 t=2012-06-19)

(Reporter)

Description

6 years ago
It is important that whatever the UI language is, only one URL linked to the document.

If we don't do that we will have the following problems:
- users will have trouble to link to our content as what is seen will depend not of the viewer choice but of the linker choice (I will see the interface in polish if the link has been done by a polish guy)
- It will create numerous duplicate pages in search engines. (Which may even lead us to be flagged as "Duplicate content" web site and being unindexed)
- Link juice for SEO will be split into the different pages.

We need to have this as a user facing urls:

https://developer.mozilla.org/docs/en-US/<name_of_the_page> 

and not
https://developer.mozilla.org/fr/docs/en-US/<name_of_the_page>
https://developer.mozilla.org/en-US/docs/en-US/<name_of_the_page>
https://developer.mozilla.org/it/docs/en-US/<name_of_the_page>
https://developer.mozilla.org/es/docs/en-US/<name_of_the_page>
https://developer.mozilla.org/pt-BR/docs/en-US/<name_of_the_page>
...

The language of the chrome UI of the page must be selected using Accept-Language:, eventually overriden by a profile parameter (if logged).
(Reporter)

Comment 1

6 years ago
And of course we need to have 3xx Permanent redirect from the old pages to the new ones.
Could be complicated - all of our other sites use the "site language prefix" part of the url.

CC'ing James Socol who has done much of the SUMO locale prefix work that we're using.
So, from a broader perspective...

Nearly all Mozilla sites (and those that don't have a good reason) right now use the locale in the URL as a prefix.

whatever.mozilla.org/%LOCALE%/content

So we should really stick to that convention.

What we have here is an extremely unique requirement: no other Mozilla site (in fact very few other sites I know of at all) asks for "content" and "UI" in different languages. Kitsune, from which Kuma was forked, will occasionally show English document content with a localized URL (where the locale for the UI is dependent on the URL) when there _is_ no localized content. For SUMO, which is in a less competitive SEO space, that's fine.

In response to comment zero, I'll say:

1) It should be developer.m.o/%LOCALE%/docs/%PAGE%, not /docs/%LOCALE%/page, for consistency with all other Mozilla sites.
2) MDN is in a competitive SEO space, but in cases where we show English (or any other Locale's) content with a different UI language, something like <link rel="canonical"> should be able to help solve that.
3) I do not agree with the final comment "The language of the chrome UI of the page must be selected using Accept-Language:, eventually overriden by a profile parameter (if logged)."

W/r/t (3), the URL should be the winner. A URL should give you a single resource, linkable to anyone. Now, part of that may need to be contained in a query string.

I don't fully understand the use-case for splitting UI locale and content locale, but
1) the path shouldn't contain both, that's silly, bad for SEO, and silly,
2) the path should contain the locale of the intended content,
3) if the split is necessary, can we push part of that into a query string or cookie, instead of the URL?
I was leaning towards a query string halfway into reading your comment. So:

d.m.o/%LOCALE%/docs/%PAGE%?site_language=%LOCALE%
e.g.,
d.m.o/fr/docs/HTML/HTML5?site_language=en-US

That way d.m.o/fr/docs/HTML/HTML5 always means "The French article for HTML on MDN"
(Reporter)

Comment 5

6 years ago
> 3) I do not agree with the final comment "The language of the chrome UI of
> the page must be selected using Accept-Language:, eventually overriden by a
> profile parameter (if logged)."
That's the only correct way to do it. That's the goal of the Accept-Language.

That's not the person who makes the link who decide it, but the one who access it.
(In reply to Jean-Yves Perrier [:teoli] from comment #5)
> > 3) I do not agree with the final comment "The language of the chrome UI of
> > the page must be selected using Accept-Language:, eventually overriden by a
> > profile parameter (if logged)."
> That's the only correct way to do it. That's the goal of the Accept-Language.

That is not how Mozilla sites do it. This decision has its reasons and we should stick to it for those reasons and consistency with all other Mozilla web properties.

> That's not the person who makes the link who decide it, but the one who
> access it.

One URL should be one resource, not different resources for different people. MDN is not enough of an "app" for that. I think we'd agree that the resource here is the page content, not the site UI.
Why can't the user simply have a preference that lets them pick their UI language? Default to showing the same UI language as the page if they haven't set a preference. This seems the most reasonable solution to me, and is what I would prefer. Then you don't need to do weird stuff with the URL, query strings, etc. We need user preferences anyway.
(Reporter)

Comment 8

6 years ago
(In reply to James Socol [:jsocol, :james] from comment #6)
>  This decision has its reasons 
Sorry James, I find this answer rude and not acceptable. I'm not stupid: I can understand reasons.

I think we are loosing time here. We should revert the ability to have a chrome of the page in the different language than the content. It is not perfect, but it is better than what we have know which is a no-go for Kuma.

We can leave with the same language for chrome and content for Kuma launch, even if it is annoying when we want to edit a Chinese page because of vandalism.

We can discuss reintroduction separation of language for UI and chrome in Q3 or Q4.
(In reply to Jean-Yves Perrier [:teoli] from comment #8)
> (In reply to James Socol [:jsocol, :james] from comment #6)
> >  This decision has its reasons 
> Sorry James, I find this answer rude and not acceptable. I'm not stupid: I
> can understand reasons.

I apologize. It was not my intent to be rude, but to avoid enumerating what you already knew.
(Reporter)

Comment 10

6 years ago
Thanks James, even I knew that it wasn't your intention, but it got me heated anyway. I will look at this bug again tomorrow, once I will have really cooled down :-) New day, new eyes, new ideas, new opinions.
<3 DevEngage + Webdev FTW!
Also, just for some more input to the topic: http://restpatterns.org/Articles/Designing_URIs
I'm neck-deep in this right now for bug 728417. I'm restoring lots of the translation features we inherited from kitsune/SUMO. I agree we should show the same single language for both site UI and doc content. I propose we go with the Accept-Language and URI segments as kitsune/SUMO:

/%LOCALE%/docs/%SLUG% E.g.,

/fr/docs/AJAX
/en-US/docs/AJAX
/es/docs/HTML/HTML5

The kitsune/SUMO locale-detection code first uses Accept-Language header AND allows that language selection to be overridden via direct url. E.g.,

GET /docs/AJAX
Accept-Language: fr, en;q=0.8

HTTP/1.1 301 MOVED PERMANENTLY
Location: /fr/docs/AJAX
Vary: Accept-Language

GET /en-US/docs/AJAX
Accept-Language: fr, en;q=0.8

HTTP/1.1 200 OK

Later we can decide if/when we need the ability to show site UI and content in separate languages.

Sound good?
Component: Deki Infrastructure → Docs Platform
QA Contact: infrastructure → docs-platform
Whiteboard: u=l10n c=wiki s=2012-06-05 p=
(Reporter)

Comment 14

6 years ago
Luke, that's ok for me, but: all internal links in Kuma must be of the form /%LOCALE%/docs/%SLUG% . We should never have /docs/%slug% in it (or locale-detection override user choice and it renders the Web site unusable)
Sounds good to me.
Links to /docs/%slug% go thru this locale-detection logic:

https://github.com/groovecoder/kuma/blob/page-translation-features-bug-728417/apps/sumo/urlresolvers.py#L94-123

i.e., ?lang or the most appropriate and relevant Accept-Language is used, if we support the language. Lastly, we default to en-US.

So, the only way the user *chooses* their language is by the ?lang parameter (using the language drop-down in the header or footer of the site) or by Accept-Language header value.

We have a "Language" drop-down in the user profile, but we don't use it to determine language (yet).
Sorry, all that is to say links to docs/%slug% seem good to me - i.e., link to a doc and let the site determine the best language based on that logic.

Comment 18

6 years ago
You seem to assume that content in all languages is equal. That's not the case.

In my strong opinion, the canonical URL of a page should include the language, and the wiki-internal links should link directly to the canonical URL.
(Reporter)

Comment 19

6 years ago
What is this attribute lang? We never spoke about that.

We need to have the locale of the page in the URL. We want people to link to a specific locale of the page and when I'm navigating I want to be sure to stay on the same locale, except if I explicitly choose another locale. That's what is done now and must not be changed.

If the page I'm navigating to doesn't exist in the locale I'm requesting, we want to have an "Article not found" page (that is a 404 page) with the ability to create it.

URL without locale in them must redirect to a page with a locale in the URL, the way the locale is chosen in that case is either Accept-language either the lang parameter.

URL with locale in them must ignore the lang parameter for the content language.

Internal links in the wiki must always link to URL with locale.
:teoli - sounds perfect, with on caveat:

django middleware uses the ?lang= parameter to *switch* languages. E.g., if you go to /fr/HTML/HTML5?lang=en-US it redirects to /en-US/HTML/HTML5

We don't want to change that - we use it all over the rest of MDN and other Mozilla websites. It's how users "explicitly choose another locale" - it's an explicit signal to the middleware that the user is intentionally changing language, so we can do things like set a language preference cookie.

In reality, there are never links to ?lang= url's. It's only used internally by the language selector menu in the footer of the site.
(Reporter)

Comment 21

6 years ago
(In reply to Luke Crouch [:groovecoder] from comment #20)

> django middleware uses the ?lang= parameter to *switch* languages. E.g., if
> you go to /fr/HTML/HTML5?lang=en-US it redirects to /en-US/HTML/HTML5

I have no problem with that :-) That's ok.

Updated

6 years ago
Blocks: 756882
(Assignee)

Comment 22

6 years ago
Time to do this is pre-July, if ever.
Blocks: 756263

Updated

6 years ago
Priority: -- → P1
Whiteboard: u=l10n c=wiki s=2012-06-05 p= → u=l10n c=wiki s=2012-06-05 p=3
(Assignee)

Updated

6 years ago
Assignee: nobody → lorchard
(Assignee)

Updated

6 years ago
Blocks: 760595

Comment 23

6 years ago
Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/b861a64763a13fa03e19da424669f314d3ea0048
fix bug 754534: Simplify wiki URLs

* Rework locale_and_slug_from_path to support redirects where
  legacy-MindTouch or modern-Kuma locales appear as first path segment,
  but otherwise use request-detected or default locale

* Widespread test tweaks to account for URL change

* Uncomment URL route to enable mindtouch_to_kuma_redirect - no need to
  leave it commented out, since Apache won't send traffic to it until
  configs/htaccess is changed to exclude MindTouch anyway

* Sample config/htaccess files both with and without MindTouch enabled

* Tweak to mindtouch_to_kuma_redirect and mindtouch_namespace_redirect
  to account for new URL structure

* Tweak to devmo_url() helper to rewrite old /en links to point to new
  Kuma URLs with current detected locale

* Template tweak to include document locale and path in documents list

* Unicode fixes and refactorings for document Last-Modified cache keys

https://github.com/mozilla/kuma/commit/2ef4564618c1e18b9e1312e30f6a06b75a950e99
Merge pull request #242 from lmorchard/simplify-wiki-urls-754534

bug 754534: Simplify wiki URLs

Updated

6 years ago
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whiteboard: u=l10n c=wiki s=2012-06-05 p=3 → u=l10n c=wiki s=2012-06-05 p=3 t=2012-06-19
Version: Kuma → unspecified
Component: Docs Platform → Editing
Product: Mozilla Developer Network → Mozilla Developer Network

Updated

4 months ago
See Also: → bug 962148
You need to log in before you can comment on or make changes to this bug.