466079 - TikiWiki page handling based on URL for localized pages?

Status: RESOLVED INVALID

(support.mozilla.org :: Localization, task)

Description

[Paul Craciunoiu [:paulc]]

I've been toying around with how localization works and would like to discuss a possible reworking of the back-end.

Here's a situation in which I find the behavior non-intuitive. Steps:

1. You are currently in <locale1>, that is, your article url is
/<locale1>/Article title in locale 1
Example: http://support.mozilla.com/en-US/kb/Installing+Firefox

There are at least two ways to view this article in a different locale:

2a. Use the drop-down at the bottom to change to <locale2> and get redirected to
/<locale2>/Article title in locale 2
http://support.mozilla.com/ro/kb/Instalare+Firefox
(good)
OR
2b. Change the locale in the URL:
/<locale2>/Article title in locale 1
http://support.mozilla.com/ro/kb/Installing+Firefox
(not so good)

Furthermore, by adding the parameter "bl=n" in the URL on (2b), you can again see the article in the original language. I find this very confusing, so I was thinking if we could discuss a simple and intuitive way to handle localization through URLs and/or cookies.

One consequence of the way localization is currently handled is that we may not have multiple pages with the same name, each for a different locale.

Suggestions:
1. Make pages be identified by locale + title, and perform URL redirects on old links.
In the example above, <locale2>/Article title in locale 1 would redirect to
(a) <locale2>/Article title in locale 2
if article exists translated for locale 2 (so that users can change the locale in the URL and be redirected to the article for that locale)
OR
(b) <locale1>/Article title in locale 1
if article exists but not translated for locale 2
OR
(c) page not found
if article with given title does not exist for any of locale 1 or locale 2

2. The present handling of locales allows for viewing an article in a language, while the menu and other parts of the site are in a different language, by adding a "bl=n" in the URL.
For example, the link:
http://support.mozilla.com/ro/kb/Installing+Firefox?bl=n
Can show the article in English, even though the locale is clearly set in Romanian. Moreover, the drop down language box "Other languages" always has the same language as the article. So, the above link, although under /ro/ locale, shows "English" selected in the drop down.

We should redirect users in confusing situations such as above, and keep the entire site in a single language at all times. Hence, after zero or more redirects, all valid links will be of the form:
<locale1>/Article title in locale 1

Also, get rid of the parameter "bl", unless there is a different reason for keeping it, of which I am not aware.

Comment 1

[David Tenser [:djst]]

I like this idea. Nelson, can you advice on the last question about other usages of the bl parameter, given the proposal on how this bug would change the standard behavior?

Also, is this something that has been thought of within the TikiWiki community or is this behavior currently isolated to the SUMO way of handling URLs?

Comment 2

[Paul Craciunoiu [:paulc]]

This is related to l10n, however I'm not sure all of it is as practical as I suggested at first. I'd stick to a single one, this:

(l=locale, t=article title in locale)
You are in <l1> viewing article t1. Changing <l1> to <l2> in URL redirects from 
/<l2>/t1 to /<l2>/t2
If t2 does not exist, remain on <l2>/t1 but display notification about translating (already implemented)

How does that sound?

Comment 3

[David Tenser [:djst]]

It sounds good to me. I'd still like to hear from Nelson to make sure there aren't any problems with this.

Comment 4

[Chris Ilias [:cilias]]

This would also fix bug 428795 [Different article feedback on an article accessed from different URLs].

We also need to make sure that the inproduct links in the htaccess file still work. For instance, German users are currently pointed to http://support.mozilla.com/de/kb/Firefox+Help not http://support.mozilla.com/de/kb/Firefox+Hilfe .

Comment 5

[Paul Craciunoiu [:paulc]]

(In reply to comment #4)
> We also need to make sure that the inproduct links in the htaccess file still
> work. For instance, German users are currently pointed to
> http://support.mozilla.com/de/kb/Firefox+Help not
> http://support.mozilla.com/de/kb/Firefox+Hilfe .
A good approach to this is to redirect automatically to the corresponding URL.

Comment 6

[James Socol [:jsocol, :james]]

Bugs in tikiwiki, going away.