Page MenuHomePhabricator

Enable $wgExtraGenderNamespaces on plwiki *BEFORE* MW1.18 deployment
Closed, ResolvedPublic

Description

Author: danny.leinad

Description:
Per bug10064, bug17160 and bug27398, please enable $wgExtraGenderNamespaces on plwiki with the following configuration:

$wgExtraGenderNamespaces = array(
NS_USER => array( 'male' => 'Wikipedysta', 'female' => 'Wikipedystyka' ),
NS_USER_TALK => array( 'male' => 'Dyskusja_wikipedysty', 'female' => 'Dyskusja_wikipedystki' ),
);

You have to make live this configuration before MediaWiki 1.18 deployment, because changes from bug27385 without the above configuration will cause problem with namespaces on Polish Wikipedia - users with specified in Preferences "male" gender will still have namespace "Wikipedysta:", but users with specified "female" gender will get namespace "Użytkowniczka:".


Version: unspecified
Severity: enhancement

Details

Reference
bz30938

Event Timeline

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

danny.leinad wrote:

I made a mistake in one of names, so once again:

$wgExtraGenderNamespaces = array(
NS_USER => array( 'male' => 'Wikipedysta', 'female' => 'Wikipedystka' ),
NS_USER_TALK => array( 'male' => 'Dyskusja_wikipedysty', 'female' =>
'Dyskusja_wikipedystki' ),
);

(In reply to comment #0)

You have to make live this configuration before MediaWiki 1.18 deployment,
because changes from bug27385 without the above configuration will cause
problem with namespaces on Polish Wikipedia - users with specified in
Preferences "male" gender will still have namespace "Wikipedysta:", but users
with specified "female" gender will get namespace "Użytkowniczka:".

If that's the case, it needs fixing for any and all wikis that have got it setup

Ar, De, Es, He, Pl, Pt and Pt_br...

danny.leinad wrote:

(In reply to comment #2)

If that's the case, it needs fixing for any and all wikis that have got it
setup

Ar, De, Es, He, Pl, Pt and Pt_br...

Yep, you are right. The problem occurs only there where is configured using $wgExtraNamespaces local user namespaces like "Wikipedian".

All projects should be informed about this case. If they don't request for similar configuration with specified female form, you will have to set in $wgExtraGenderNamespaces for female form the same name as in male form in $wgExtraNamespaces.

PS. For other Polish projects I will open bugs in the next week, because it's not so clear like in Polish Wikipedia with "Wikipedian", for example Wikisource community have to discuss whether "Wikiskryba" is a gender neutral word.

Ok, test2 get's done later today, and the first wiki with differences is hewiki on Wednesday

For the rest of them that are set, we've got about 2 weeks till this happens.

I'll confirm with Niklas, but if we need to at least set the gender neutral version (as a basis if we don't receive the actual names) for each wiki with the gendering, we might aswell add that in now, as it won't affect 1.17, but will then start workign for 1.18 as the deployments roll out

With r97461 we can at least keep the status quo without hassle. The downside is that some languages won't get gendered namespaces even if core has them (but most languages don't even have them in core yet).

danny.leinad wrote:

I checked r97461, looks on reasonable solution :)

And yes, imho there is no problem to add now $wgExtraGenderNamespaces configuration (if already some project requested, like pl.wiki) and it will start workign for 1.18.

PS. On http://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php also cswiki and cswikinews have configured in $wgNamespaceAliases female user namespaces, so you could consider to set it as $wgExtraGenderNamespaces.

'wgExtraGenderNamespaces' => array(

'default' => array(),
'plwiki' => array( NS_USER => array( 'male' => 'Wikipedysta', 'female' => 'Wikipedystyka' ), NS_USER_TALK => array( 'male' => 'Dyskusja_wikipedysty', 'female' => 'Dyskusja_wikipedystki' ) ),

)

cswiki/cswikinews should be logged as a separate bug probably. Also, be explicit of what wants to go where...