Last modified: 2013-11-12 09:03:20 UTC
https://gerrit.wikimedia.org/r/86172 This dirty, dirty hack brought to you by the fact that the JS messages API only accepts a user object (which means, it only accepts the current user) or "male" or "female" as its arguments to GENDER. I should really be able to pass in the username of _any_ user on the site, like I can on the PHP side. Fun fact: This will introduce an asynchronous leg to the message parser on the client side. Potential solution: Have an *optional* argument to the message parser that will be an update callback. Once the API returns the data we need to parse the message, we cache it and callback with the final message contents. Before then we pass back "unspecified" messages. They'll be updated within seconds. The problem with this is that it becomes the responsibility of the user to run the update - they're no longer just dealing with strings.
Santhosh, as you initially implemented GENDER support in JavaScript, any thoughts?
Mark already explained it very well. The message parser(basically jqueryMsg) did not want to have responsibility of a server call and return asynchronously or do a callback execution once the server is responded. The easiest solution at that time was giving the responsibility of figuring out the gender to the user of message parser. For eg, An extension can do the async call to get user object based on user id and in the success callback, render the message using mw.msg. Just like https://gerrit.wikimedia.org/r/86172 Ideally mw.msg should not be bothered about collecting the data using apis, but only about parsing. Better ideas are welcome.
