Page MenuHomePhabricator

Name spaces and Local wiki
Closed, DuplicatePublic

Description

Author: shijualex

Description:
I am from Malayalam wiki (http://ml.wikipedia.org/).

Currently in local wikis we have the option to set the prefered langauage to English . Once we do this all the messages will be in the language that we selected.

Like the same way is there is any way to set the preferred name space language to English. That is when we select the preferred langauage as English all the name spaces should be in English.

Recently we have converted the name spaces in malayalam wiki to malayalam. But this is creating lot of problem with non articles. (Eg:Templates, Category and so on).

The main problem is that the url that we copy from the browser is percentage encoded. Because of this we cannot use percentage encoded url(or the url that has local language in address) in our communication. Example : send the percentage encoded url through email, gtalk and so on.

It will be good if there is an option to set the prefered name space langauage also to english. I think this will be a problem for all nonlatin langauage wikis.


Version: unspecified
Severity: enhancement
URL: http://ml.wikipedia.org

Details

Reference
bz10624

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:54 PM
bzimport set Reference to bz10624.
bzimport added a subscriber: Unknown Object (MLST).

ayg wrote:

Note that the percent-encoded URLs appear to only be an issue in Firefox (see https://bugzilla.mozilla.org/show_bug.cgi?id=105909 et al.). The bug was marked FIXED as of 2007-07-07, some days ago, apparently for mozilla1.9alpha6. I suppose this means it should be in Firefox 3, since that's supposed to use Gecko 1.9 final, estimated to be released four months from now in November. If you're seeing this in a non-Firefox browser, which one? Otherwise, are you sure this is needed, as opposed to just suggesting that your Firefox users use Opera or something for the next four months?

sadik.khalid wrote:

I have submitted a bug to solve this issue http://bugzilla.wikimedia.org/show_bug.cgi?id=10342

brion added a comment.Jul 18 2007, 5:59 PM

Percent encoding exists *so that* the URL can be reliably transmitted.

shijualex wrote:

My bug was not for changing the Name space of a wiki. It is related to an issue
that we face in loacal wikies while sending a URL that contain either local
language or percentage encoded characters.

Both these will create problem while we send this url through email or chat.
Once the user receive the url it is obselute and it will not just work.

For articles in main space we can use the english redirect pages and use that
url for communication. But for non article pages this is not possible due to
number of reasons. We cannot create redirect pages for each and every non
articles (Usualy the number of non articles are very huge).

Another issue is, since all the name spaces are localised, by default the
browsers will show the url in local language or the entire url will be
percentage encoded. (Keep in mind most number of endusers are using Internet
explorer and not Firefox or Opera).

Because of this, we couldnot send across the non-articles urls.

There is an option in wiki to set the prefered langauge to English. But
currently in Wikimedia software even if we select the preferred language as
English the non article name spaces will still appear in the local langauge.

Is there is any way to upadate the wikimedia software so that when the user
select his preferred language as English the name spaces will also be displayed
in English.

brion added a comment.Jul 18 2007, 6:25 PM

The percent-encoded URLs can be copied and sent just fine.

Isn't the English namespace (as default) are canonical except NS_PROJECT?

for example in the URL, we type "User:XXX", isn't it will redirect to
"ഉപയോക്താവ്:XXX"?

shijualex wrote:

(In reply to comment #7)

Isn't the English namespace (as default) are canonical except NS_PROJECT?
for example in the URL, we type "User:XXX", isn't it will redirect to
"ഉപയോക്താവ്:XXX"?

The redirection will happen. But our problem is not that. I will provide an example from malayalam wikipedia. There is a template with name "IndiaFreedomLeaders" in malayalam wikipedia.

  1. If you copy the url of that template from internet explorer it will be:

http://ml.wikipedia.org/wiki/%E0%B4%AB%E0%B4%B2%E0%B4%95%E0%B4%82:IndiaFreedomLeaders

  1. If we copy the url from firefox or opera it will be.

http://ml.wikipedia.org/wiki/ഫലകം:IndiaFreedomLeaders.

Now try to send these links to a gmail ID, and then forward to a Yahoo ID. See what is the result. This exactly the problem we are facing.

Also just try to send across the local language url for another manin article "http://ml.wikipedia.org/wiki/മുസ്തഫാ_കമാല്‍‍_അത്താതുര്‍ക്ക്" through gtalk. See whether the enduser can click on the link that is sent.

A solution for this is changing the user preferance so that user can see see the url as "http://ml.wikipedia.org/wiki/Template:IndiaFreedomLeaders" in the address bar of the browser. That is not happening now.

I am just requesting for this updation. That is, even though the default name space is in local language the user should able to set his prefered namespace language to English so that he can view the entire url in English in the address bar.

ayg wrote:

*** Bug 10589 has been marked as a duplicate of this bug. ***

ayg wrote:

(In reply to comment #5)

My bug was not for changing the Name space of a wiki. It is related to an issue
that we face in loacal wikies while sending a URL that contain either local
language or percentage encoded characters.
...
There is an option in wiki to set the prefered langauge to English. But
currently in Wikimedia software even if we select the preferred language as
English the non article name spaces will still appear in the local langauge.
Is there is any way to upadate the wikimedia software so that when the user
select his preferred language as English the name spaces will also be displayed
in English.

Then this is a duplicate of bug 10342.

*** This bug has been marked as a duplicate of bug 10342 ***