Last modified: 2012-08-22 10:31:42 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T29743, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 27743 - Handle GENDER more efficiently.
Handle GENDER more efficiently.
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Internationalization (Other open bugs)
1.18.x
All All
: Normal enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
: i18n
Depends on:
Blocks: gender
  Show dependency treegraph
 
Reported: 2011-02-26 16:33 UTC by Purodha Blissenbach
Modified: 2012-08-22 10:31 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Purodha Blissenbach 2011-02-26 16:33:55 UTC
Currently, user names are passed as parameters to message handling
routines and used there to detemine the users gender and return
language texts varying with the gender.

Sometimes, user names are also used to be included verbatim in messages.
Sometimes, rather links such as [[User:$2|$2]] are used instead.
Sometimes, series of links such as "Username (contribs, block, log, ...) "
are used and passed as parameters to messages.

This pactice has drawbacks:

A: Localizers often cannot immediately identify a parameter as being a plain name suitable for GENDER use, or a link or series of links which cannot be used.

B: When parameters for a message are evaluated, often a user object is already there, then only a name is passed to message handling which has to evaluate its own user object from the name in order to determine the gender. That's a waste.

C: Messages used outside the context of the wiki, where database lookups are not readily available (e.g. in JavaScripts) cannot support gender.

Suggestion:
When messages need gender, pass the evaluated gender to them, and alter gender handlincg accordingly. We need an additional parameter per independent occurrence of gender per message, which can be seen as a structural advantage, and the above drawbacks are avoided.
Comment 1 Krinkle 2011-04-04 12:19:40 UTC
(In reply to comment #0)
> C: Messages used outside the context of the wiki, where database lookups are
> not readily available (e.g. in JavaScripts) cannot support gender.

Just to be complete, this only applies to custom usernames. For the currently logged-in user JavaScript implementation of GENDER is possible. Ie. "You are {{GENDER:|male|female}}, click on the {{GENDER:|blue|pink}} button to continue." could be parsed client side.
Before 1.17 this required an API call to read preferences, overkill but possible.
Since 1.17 this can be done much simpler via mw.user.options.get('gender') etc.
Comment 2 Purodha Blissenbach 2011-11-30 17:26:34 UTC
See also Bug 32703 - Create {{SPACEUSER}} to improve detection of page owner in User spaces, also usable in interface messages.
Comment 3 Siebrand Mazeland 2012-08-22 10:31:42 UTC
GENDER is now available in JS. If there are messages that require JS support, separate bugs will need to be filed for it.

There will be no "more efficient way of handling GENDER". Closing as resolved.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links