Page MenuHomePhabricator

$1 not expanded in namespace aliases in the API
Closed, ResolvedPublic

Description

On ast.wikipedia.org "$1 discusión" is a namespacealias for the "project talk" namespace. I don't speak that language but "$1" is wrong.


Version: unspecified
Severity: major
URL: http://ast.wikipedia.org/w/api.php?action=query&meta=siteinfo&siprop=namespacealiases|namespaces

Details

Reference
bz17267

Event Timeline

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

There seems to be quite a many cases where $1 (with or without grammar) is used in aliases.

egrep ">\s*NS_PROJECT" languages/messages/*.php | grep '$1' | wc -l
30

Enabled conversion in r46648, but the API still reports unconverted values, reassigning to API for resolution.

(In reply to comment #1)

There seems to be quite a many cases where $1 (with or without grammar) is used
in aliases.

egrep ">\s*NS_PROJECT" languages/messages/*.php | grep '$1' | wc -l
30

Enabled conversion in r46648, but the API still reports unconverted values,
reassigning to API for resolution.

Assigning back and changing summary. The API reports the correct values, it's the i18n/l10n code that's not expanding $1 in namespace aliases here. The API reports "$1 discusión" as an alias for "Uiquipedia alderique" (the Project_talk namespace). This is fully correct, as http://ast.wikipedia.org/wiki/$1_discusión:Foo redirects to http://ast.wikipedia.org/wiki/Uiquipedia_alderique:Foo , whereas http://ast.wikipedia.org/wiki/Uiquipedia_discusi%C3%B3n:Foo is a page in the main namespace (the páxina tab is highlighted rather than the alderique tab).

Like I said in my previous commit: Enabled conversion in r46648

(In reply to comment #3)

Like I said in my previous commit: Enabled conversion in r46648

Right, overlooked that. Local testing confirms that r46648 fixed the bug I mentioned but doesn't fix it in the API.

(In reply to comment #4)

(In reply to comment #3)

Like I said in my previous commit: Enabled conversion in r46648

Right, overlooked that. Local testing confirms that r46648 fixed the bug I
mentioned but doesn't fix it in the API.

Fixed in r46656 by expanding on your fix a little bit.