Remove parentheses in result formats list, ul, ol and instead use sep= parameter
Closed, DeclinedPublic


When using result formats list, ul, or ol the additional query parameters are forcibly surrounded by parentheses, as documented here:

Parentheses may be desirable in some circumstances, but certainly not all circumstances. For example, the query result output:

1957 (blue convertible soft-top Chevy)

Would be more readable as:

1957 blue convertible soft-top Chevy

Parentheses should be optional, and perhaps controllable just like the separator/delimiter when using the sep= parameter.

Version: unspecified
Severity: normal


bzimport set Reference to bz32863.
bzimport added a subscriber: Unknown Object (MLST).
Badon created this task.Dec 7 2011, 11:06 PM

You can do this with the template param.

Badon added a comment.Dec 8 2011, 12:27 AM

Reopened. I know this can be done with a template, but that would simply be undoing work that didn't necessarily need to be done in the first place. In fact, I suggest doing it the other way around, where arbitrary extra characters are added using templates, instead of by default.

Since we already have the sep= parameter, I don't think there's any need whatsoever for extra characters, since they can easily be added already even without a template. If there's still some reason parentheses are a useful default (I can't think of one), then it should be optional. If you can't think of a reason why they should be there by default, then I also suggest that they not be there at all, so users can just use the sep= parameter instead.

What do you think?

As far as I'm concerned, this is wontfix. You can already do it w/o introducing new stuff. Adding new params for every possible display change is not something I want to see happen.

Badon added a comment.Dec 8 2011, 3:25 AM

I agree about not adding new params, that's why my suggestion is to remove the parentheses entirely, and just rely on the existing sep= parameter, so the affected result formats will function cleanly without needing to strip them down in a custom template.

Simply also apply the sep= parameter to the first portion my example:

1957 blue convertible soft-top Chevy

If sep=, then you would get:


If sep=,  then you would get:

1957, blue, convertible, soft-top, Chevy

If sep=  (entity number for a space) then you would get:

1957 blue convertible soft-top Chevy

Since the last example above is identical to the current behavior, except without added parentheses, that is my suggested default.

The parentheses in the current implementation don't represent anything, and don't perform any function other than presentation, I think they should be removed, and the result formats list, ul, and ol should be slightly modified to use the sep= parameter on all results, including the first one, where it does not currently work.

Badon added a comment.Dec 8 2011, 11:34 PM

As a compelling example why this is important, imaging querying for pages or properties that already have parentheses in them, like is common on Wikipedia:

If that page were a property, it would appear something like this with the way things currently work:


I hope that is clearer why this is a problem. I changed this bug report from "enhancement" to "normal", since after giving it further thought with the above example, it is a fairly important issue warranting removal of the parentheses.

Making an option out of them is a possible enhancement, but I don't think it's needed. The sep= parameter should probably just be reconfigured to work on all returned data elements, with further customization done in templates, if needed.

Badon added a comment.Jan 7 2012, 3:17 AM

It appears this bug is getting worse with MORE parentheses added to SMW 1.7. This newly breaks images queries that are intended to be processed further to format the images:

A query like this:

{{#ask: [[Category:Images]]



Should produce results like this (as in SMW 1.6):

image1.jpg,image2.jpg,image3.jpg, etc

Which can then be easily processed with #arraymap or the Arrays extension (and pretty much anything else) to format these images any way required. But, that is the behavior in SMW 1.6. SMW 1.7 returns LOTS of parentheses:

image1.jpg (image1.jpg),image2.jpg (image2.jpg),image3.jpg (image3.jpg), etc

Demo (login Demo/test):

Of course, code that works with images needs to be rewritten to strip all that unneeded text. I was using the list format because the array format did not (and still does not) work correctly:

Badon added a comment.Jan 7 2012, 3:48 AM

All the workarounds I can come up with for this will damage file names that have parentheses in them, since ( and ) are valid and common file name characters. So, simply hunting for them and stripping them won't work.

Badon added a comment.Jan 9 2012, 1:02 AM

It looks like there was an undocumented change in the output format of query results. I can probably still work around this problem in a slightly different way. I'm doing more testing.

I'm open to seeing the sep parameter change the format of the output if it doesn't already do something in this case.

However I DO NOT want to see the default behavior change. This behavior is already in place, wikis are already using it and expecting it, and working around it if they don't want it. There isn't a good enough reason here to force wikis that do in fact want the formatting the way it is to suddenly have to modify several queries they already have on their wiki just to re-introduce behavior that was already working perfectly fine on their wiki.

Badon added a comment.Jan 9 2012, 2:21 AM

Too late, there are already breaking changes. Here's a description of one of them I have found:

It appears the outline format may also be broken, but that was reported to me by someone else, I haven't tested it myself yet.

I consider SMW to still be immature, so I kind of expect breaking changes from time to time, even though they can be frustrating, especially when they're sprung on us by surprise with no warning or documentation. In addition to warnings and documentation, I'd also like to see suggested changes to bring everything up to the current version. It may even be possible to script those changes, to make the upgrades painless. In the situation I discovered (linked above), I think it would be straightforward to find those kinds of affected queries, and automatically convert them to 1.7 queries.

As SMW gradually becomes more mature, there will be an increasing need to either maintain backwards compatibility, plan for obsolescence, and provide upgrade paths that can do the mass changes necessary to keep things compatible with the current version.

Aklapper closed this task as "Declined".Mar 3 2015, 5:51 PM
Aklapper added a subscriber: Aklapper.

The Semantic MediaWiki developers requested in to move their task tracking to and to close remaining tasks in Wikimedia Phabricator. If you still face the problem reported in this task in a supported version of SMW, please feel free to transfer your report to . We are sorry for the inconvenience.

Add Comment