When using the API to find out if someone is emailable, the emailable property is set to empty string for true or undefined for false. Instead, it should be set to 'true' or 'false'.
True example:
http://en.wikipedia.org/w/api.php?&action=query&list=users&ususers=Kaldari&usprop=emailable&format=json
False example:
http://en.wikipedia.org/w/api.php?&action=query&list=users&ususers=Jorm&usprop=emailable&format=json
Version: unspecified
Severity: minor
XML versions for easier viewing...
True example:
http://en.wikipedia.org/w/api.php?&action=query&list=users&ususers=Kaldari&usprop=emailable
False example:
http://en.wikipedia.org/w/api.php?&action=query&list=users&ususers=Jorm&usprop=emailable
This is a slightly strange one. We tend to use (in xml) blah="" for defined, and nothing for undefined..
For gender, for example, we return 'male', 'female', or 'unknown'. Wouldn't it make more sense for emailable to be 'true' or 'false'? It would certainly make things more intuitive for API users, in my opinion.
It looks like we do the same thing for the 'readable' property of pages. I don't think that using empty strings to indicate truth is a good idea (especially since empty strings are interpreted as false in both PHP and Javascript). I understand why it was built this way, since all the properties are universally set up as XML attributes (when in some cases they might make more sense as attribute values or full nodes). Unfortunately, this leaves our users with rather unintuitive data that requires more verbose code.
If the resolution is WONTFIX, the return behavior of the property should at least be documented so that people know they have to test for whether or not the attribute is defined rather than testing for truth.
Bryan.TongMinh wrote:
This behavior is present on all boolean values.
Changing this would be a breaking change, for esthetic purposes only, so I recommend WONTFIX.
Indeed.
It's how HTML elements do stuff - disable="" means true, else it's false.
I think it's just a cause for documentation change, and WONTFIX...
Ryan, what sort of documentation are you suggesting? For all boolean types (probably makes sense).. Though, for properties, we don't store this level of granduality..
"Tags if the user can and wants to receive e-mail through [[Special:Emailuser]]"
Might be a manual process.
Per Bryan, changing emailable="true" or whatever would be a breaking change from the api... And the only time we try to make them is when security is involved...
Indeed.
It's how HTML elements do stuff - disable="" means true, else it's false.
I think it's just a cause for documentation change, and WONTFIX...
Ryan, what sort of documentation are you suggesting? For all boolean types (probably makes sense).. Though, for properties, we don't store this level of granduality..
"Tags if the user can and wants to receive e-mail through [[Special:Emailuser]]"
Might be a manual process.
Per Bryan, changing emailable="true" or whatever would be a breaking change from the api... And the only time we try to make them is when security is involved...
As Reedy and Bryan have said, this is just the way boolean attributes work in the API. This is a convention that I don't particularly like either, but it was introduced before my time and we've stuck with it ever since. Old properties aren't gonna be moved to a true/false format because that would be a breaking change (and we never make those for aesthetic reasons only, like Bryan said), and introducing new properties with a true/false format while keeping old properties with the present/absent format around would lead a weird, inconsistent state where no one remembers which property uses which format any more. So we're kinda stuck in the status quo.
That's fine. I've added a new section to the API:E-mail documentation on checking the emailable property:
http://www.mediawiki.org/wiki/API:E-mail#Checking_emailable_status
It includes some sample code, so hopefully that will help people figure it out without too much trouble.