Last modified: 2012-08-22 10:31:42 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.
(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.
See also Bug 32703 - Create {{SPACEUSER}} to improve detection of page owner in User spaces, also usable in interface messages.
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.
