Page MenuHomePhabricator

Fix gender in user namespaces for Portuguese wikis
Open, NormalPublic

Description

I'm forking this request from T33459: Gender in user namespaces for Portuguese Wikipedia, to avoid confusion.

Currently, if we setup a new wiki using MW 1.18 and set $wgLanguageCode = "pt", and then create an user account "Female", and its user and user talk pages, we will have all the following links pointing to its user and user talk pages:

  • [[User:Female]] / [[User talk:Female]]
  • [[Utilizador:Female]] / [[Utilizador Discussão:Female]]
  • [[Utilizadora:Female]] / [[Utilizadora Discussão:Female]]
  • [[Usuário:Female]] / [[Usuário Discussão:Female]]

and the title text of all links will be the same "Utilizadora:Female" / "Utilizadora Discussão:Female". This is the expected behavior.

But there are more links which, for consistency, should be working by default on any MediaWiki installation (even outside Wikimedia world), and currently doesn't:

  • [[Usuária:Female]] / [[Usuária Discussão:Female]]

At the moment, both links point to pages on NS_MAIN, instead of the corresponding NS_USER and NS_USER_TALK pages.

Besides, the current default text of NS_USER and NS_USER_TALK namespaces for users having "undisclosed" gender is "Utilizador" and "Utilizador Discussão", respectively, but this corresponds to the "Male" form. When we don't know what is the gender of someone (very common in the case of new users), we prefer to use "Utilizador(a)" (or "Usuário(a)" if we are from Brazil). So, the default namespace names should also be changed so that

  • If $wgLanguageCode = "pt", MediaWiki shows by default:
    • NS_USER = "Utilizador(a)"
    • NS_USER_TALK = "Utilizador(a) Discussão"
  • If $wgLanguageCode = "pt-br", MediaWiki shows by default:
    • NS_USER = "Usuário(a)"
    • NS_USER_TALK = "Usuário(a) Discussão"

These changes are valid for every wiki (except ptwiki, which uses $wgLanguageCode = "pt" but prefer to have the pt-BR version of the names by default, i.e. the "Usuári..." instead of "Utilizador...").

Details

Reference
bz31986

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 21 2014, 11:57 PM
bzimport set Reference to bz31986.
He7d3r created this task.Oct 27 2011, 12:31 PM

Created attachment 9291
Links to NS_USER and NS_USER_TALK

Attached:

Reedy added a comment.Nov 14 2011, 3:00 PM

You realise putting them in images makes it harder, right? ;)

Proposed fix

I think the attached patch fixes it (I also added some more aliases that were missing). I'm assuming $namespaceNames['NS_USER'] is the used namespace when there's no specific gender.
I'm not keen of using foo(a) forms, though. Would prefer to see some more support from users that it is indeed the right thing to do in Portuguese (not in being valid language, but what would be used normally).

Attached:

(In reply to comment #3)

I'm not keen of using foo(a) forms, though. Would prefer to see some more
support from users that it is indeed the right thing to do in Portuguese (not
in being valid language, but what would be used normally).

It is fairly normal in Portuguese to use the foo(a) form. It is also common, though, to use the male form to refer to both genders when it's undisclosed or when we're referring to a group of mixed genders.

The former is probably more semantically correct, so this in a way is a choice between "de jure" (theoretical) correctness, versus "de facto" (practical) correctness.

In the end, it's not a big deal, since most people won't be especially bothered either way, as both methods are common.

Upon revisiting the issue, I don't think the patch to fix this should include duplicating namespace names from MessagesPt_br.php into MessagesPt.php, or vice-versa, as the patch does[1].

I believe this bug actually describes two issues, that should be separate:

  1. the neutral user namespace in Portuguese should (arguably) be changed to "Utilizador(a)"
  1. the messages from a fallback message should work as aliases for the main language, even if they are defined (the same way the canonical English forms work).

Probably this bug should be restricted to issue 1), with the second issue spawned into a different bug.


[1] in any case, should that approach be used, the "Usuário(a)" and "Usuário(a) Discussão" forms are missing in MessagesPt.php's $namespaceAliases.

Patch in https://gerrit.wikimedia.org/r/#/c/29761/ .

I was reluctant to change the default namespace names - there should be a wider consensus for that, and AFAIK it will also require more technical maintenance to working wikis. Just making all possible links work seems enough to me, but I'm open to suggestions.

In gerrit 29761 all the names with -o(a) are over-engineering. Please remove those.

Adding this because Amir asked me to ask it here.

How so? They are the "neutral" form, which should be the ones shown by default.

(In reply to comment #8)

How so? They are the "neutral" form, which should be the ones shown by default.

In that case, please make it so in the patch, because its not. They're aliases now.

(In reply to comment #9)

(In reply to comment #8)

How so? They are the "neutral" form, which should be the ones shown by default.

In that case, please make it so in the patch, because its not. They're
aliases
now.

Heldir, still planning to work on this?

Change 29761 abandoned by Siebrand:
(bug 31986) Add user namespace aliases for all genders and varieties

Reason:
I'm abandoning this given the open issues that haven't been addressed in the past year. Can be restored if wanted.

https://gerrit.wikimedia.org/r/29761

Amire80 removed Amire80 as the assignee of this task.Jan 24 2015, 2:39 PM
He7d3r updated the task description. (Show Details)Jun 27 2015, 9:40 PM
He7d3r set Security to None.
MarcoAurelio added a subscriber: MarcoAurelio.

Patch was abandoned. Nothing to review afaics.

Amire80 moved this task from Untriaged to Gender on the I18n board.Feb 4 2018, 10:38 AM

Is this still an issue after the introduction of $namespaceGenderAliases?

Regards.

He7d3r added a comment.EditedSep 27 2018, 7:35 PM

I can't install MW to test this again, but if I remember correctly this bug was created after that feature was implemented. So, I assume it still happens.