Closed Bug 388841 Opened 17 years ago Closed 17 years ago

Clean up sumo URIs

Categories

(support.mozilla.org :: General, defect)

Product:
support.mozilla.org
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: cilias, Unassigned)

References

(
URL
)

Details

(Whiteboard: tiki_triage simpleURLs) 

We should take the "tiki-index.php?page=" out of Sumo URIs.
Instead of <http://support-stage.mozilla.org/tiki-index.php?page=Contributor%20Home%20Page>, it should be <http://support-stage.mozilla.org/Contributor%20Home%20Page>.

In mozilla.support.planning, Marc had posted a link to the tikiwiki.org htaccess, which cleans up the URIs.
<http://tikiwiki.cvs.sourceforge.net/tikiwiki/tiki/_htaccess?view=markup>
It should be underscore, not %20, no?
Unfortunately, the underscores are not displayed as spaces in the article title.
Right, but I mean do it like how MediaWiki does it. You name the article with spaces, which get converted to underscores for the URL.

Article name: Gray bar below status bar
Article URL: http://kb.mozillazine.org/Gray_bar_below_status_bar
That's a great idea. :-)
I guess, from the latest changes, the plus sign is being used for spaces.
<http://support-stage.mozilla.org/tiki-index.php?page=Contributor+Home+Page>
Blocks: 395788
Just to recap, from the 27/09/07 meeting, we want the end result be:
http://support.mozilla.com/kb/article+name

Correct?
And the lack of locale in the URI is intentional.
The best I can do for now is:

http://support.mozilla.com/kb-article+name

To insert a slash changes the directory, which breaks some things. It perhaps shouldn't be like that, but it will take time to hunt this down.
I assume we need to have this decided for tomorrow, correct?
CCing djst
(In reply to comment #6)
> Just to recap, from the 27/09/07 meeting, we want the end result be:
> http://support.mozilla.com/kb/article+name
> 
> Correct?
> And the lack of locale in the URI is intentional.
> 

That's what we want. And the lack of local means en-US. 

What we really want for l10n is:
1. http://support.mozilla.com/kb/ArticleName
2. http://support.mozilla.com/kb/en-US/ArticleName
3. http://support.mozilla.com/kb/sv-SE/ArticleName

1 and 2 above should result in the same page. 3 would serve the Swedish version of ArticleName, if it existed. Otherwise, it would fall back to en-US, unless the user has specified another fallback order.

Keeping the article name the same in all locales is a requirement for in-product help integration. 
(In reply to comment #7)
> The best I can do for now is:
> 
> http://support.mozilla.com/kb-article+name
> 
> To insert a slash changes the directory, which breaks some things. It perhaps
> shouldn't be like that, but it will take time to hunt this down.
> 

Wordpress can do redirects using slashes, doesn't have to mean a different directory.

If it has to be kb-articlename, why do we need kb- in the first place?
As soon as this is setup (when the latest htaccess I just uploaded to SVN works properly on the servers), we can do just articlename.

i.e. "support.mozilla.com/articlename"

As for support of the full pattern for i10n, I will treat that as a bug but that will not be fixed immediately. I'd say about a month's time.
Depends on: 397942
/ArticleName is not a good because I don't want to get into the business of having to apply a regexp to all incoming URLs that could be too greedy.

For example, if you have article names with xx-xx or xxx-xx or xx in them you'd confuse them with locales.

In the meeting last week I explicitly stated that not using an identifier like /kb or /pages or /whatever before ArticleName makes managing URLs a lot harder.  That's just speaking from experience.

Why is it so much more work to use /kb ?  Not clear on that.  Could you elaborate?
(In reply to comment #12)
> In the meeting last week I explicitly stated that not using an identifier like
> /kb or /pages or /whatever before ArticleName makes managing URLs a lot harder.
>  That's just speaking from experience.

I missed that part, sorry.

So the goal here is 
1. https://support.mozilla.com/en-US/kb/ArticleName
2. https://support.mozilla.com/sv-SE/kb/ArticleName
3. https://support.mozilla.com/kb/ArticleName

The question is, what can we achieve today, and when can we achieve the goal?
Can we enforce the use of the same article name (URL) for all locales? Like if you want to do a Swedish translation of a page, can we lock the article url? We don't want to end up with e.g.

https://support.mozilla.com/en-US/kb/ArticleName
https://support.mozilla.com/sv-SE/kb/ArtikelNamn

That would make the in-product help string parsing a total mess.

Actually if the goal is simply to facilitate in-product help, this can be achieved even without enforcing the same article name.

TikiWiki already has a best language feature that sends you to the closest available translation based on the http accept-language header value. With a slight improvement, this can be made to accept the best language from the query string in addition to the accept-language header. Using this method,

https://support.mozilla.com/en-US/kb/ArticleName
https://support.mozilla.com/en-US/kb/ArtikelNamn
will both point to the English ArticleName.

and 
https://support.mozilla.com/sv-SE/kb/ArtikelNamn
https://support.mozilla.com/sv-SE/kb/ArticleName 
will both point to the Swedish ArticleName.

It's not difficult to do and will not take as long as I said before.

(In reply to comment #16)
> Actually if the goal is simply to facilitate in-product help, this can be
> achieved even without enforcing the same article name.
> 

I'd say the goal is also to keep things consistent. With your proposal, we would eventually run into naming collisions, right?

Maybe enforcing is a bit too much, but I would definitely want to encourage localizers to use the same article id unless there are strong reasons not to. But I guess as long as TikiWiki can serve the correct page regardless, the issue is not as critical for in-product help as I thought.
I think we want the formatting in comment 9 rather than the formatting in comment 13. "kb" should come before the locale. Right?
(In reply to comment #18)
> I think we want the formatting in comment 9 rather than the formatting in
> comment 13. "kb" should come before the locale. Right?
> 

Actually that depends on what we want to do with forums and live chat. I'm not sure if that has been discussed, but even having the chat start page translated would justify putting the locale before "kb", e.g:

support.mozilla.com/en-US/forum
support.mozilla.com/sv-SE/chat

Of course, for the localized Live Chat launch page you would make it clear that you need to ask your question in English, but that's another topic. 
Also, we want the SUMO start page to be localized, so yeah, I really think the locale string should come before kb/chat/forum. Even if we will only use forums, that URL scheme makes more sense. Then the start page would be http://support.mozilla.com/sv-SE/ for the Swedish start page.
(In reply to comment #20)
> Even if we will only use forums

I meant to say "Even if we will only use en-US forums". Sorry about the bugspam.
This looks fixed, to me. Anyone disagree?
We still have the l10n issues, but that's bug 398625.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Verified FIXED with bug 398625 fir 110n issues (Also RESO FIXED)
Status: RESOLVED → VERIFIED
Whiteboard: tiki_triage simpleURLs
You need to log in before you can comment on or make changes to this bug.