Last modified: 2007-08-19 15:52:38 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 7502 - label not shown in left colum of table
label not shown in left colum of table
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
Semantic MediaWiki (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Markus Krötzsch
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-05 21:52 UTC by Steve Sanbeg
Modified: 2007-08-19 15:52 UTC (History)
1 user (show)

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


Attachments

Description Steve Sanbeg 2006-10-05 21:52:22 UTC
I'm new to this, so I'm not sure if I'm missing something; but in the table of
results, the leftmost colum has no heading.  Even if a specify heading for all
columns, the left one is ignored; i.e.

<ask>[[has_capital::|Country]][[has capital::*|Capital]]</ask>

The Country text is just dropped, and no heading is produced; that specifiction
seems to only tell it to show capitals for articles that have capitals, rather
than just empty results from the first few articles.
Comment 1 Steve Sanbeg 2006-10-05 22:01:38 UTC
OK, I found the mainlabel parameter, which is missing from most of the examples.
 I still think using the normal anchor text syntax (maybe concatenating them
together) is more inuitive, but since it can be done, I'll lower the priority.

Comment 2 Markus Krötzsch 2006-10-30 16:14:41 UTC
The above example is no proper query. If it works, this is our fault. But it
should not and it might break any time. Proper syntax is

[[has capital::*|Capital]] (print "has capital" relations in a column "capital")
[[has capital::+]] (show all things with at least one "has capital" relation)
[[has capital::Paris]] (show all things with a "has capital" relation to "Paris")

Only statements with "*" are about printing another column, and so only there
can a label for said coolumn be chosen. Since no statement corresponds to the
first (main) column, you cannot set its label in this way.

What do you mean with "normal anchor text syntax"?
Comment 3 Steve Sanbeg 2006-10-30 20:45:42 UTC
Oh, that's odd.  I wouldn't have guessed that something else was needed after
the ::, since it seems to be sufficient, and + is a valid article name.  

But what I was referring to is that it's not intuitive how to get the heading
for the left column.  If I specify text after the | on both columns, it parses
them OK, since it resolves the links, and generates the data.  But on the right
column, the specified text is used as a heading, while on the left is silently
discarded.

It seems like the more intuitive way would be to concatenate the text for all of
the left column specifiers, so that way it would work no matter where it was
put.  Paring it and ignoring it just seems bad.

Granted, at some level it makes sense that since the left column is handled
differently, its text would also be handled differently.  But from a user
perspective, as long as we can parse the text from the first statement, it would
be more intuitive to use that, instead of having to figure out another syntax to
specify it.
Comment 4 Markus Krötzsch 2006-11-15 14:57:06 UTC
"+" used to be illegal in article names until very recently. This has changed,
but we cannot change the syntax of <ask> so easily (it is used in existing
wikis). We will need to introduce some escaping mechanism for handling such
articles (I think there are no spare symbols for our purpose).

I get your point considering the (un)intuitiveness of the current approach. I am
not sure whether concatenating is the best solution, but it could be done and
seems also more intuitive to me. Should we then also concatenate the text given
via the "mainlabel" parameter of <ask>?
Comment 5 Steve Sanbeg 2006-11-15 23:16:10 UTC
(In reply to comment #4)
> "+" used to be illegal in article names until very recently. This has changed,
> but we cannot change the syntax of <ask> so easily (it is used in existing
> wikis). We will need to introduce some escaping mechanism for handling such
> articles (I think there are no spare symbols for our purpose).
> 

Maybe some kind of quoting, like [[has operator:[[+]]]], which is only slightly
odd; not much more than a linked image caption, though/

> I get your point considering the (un)intuitiveness of the current approach. I am
> not sure whether concatenating is the best solution, but it could be done and
> seems also more intuitive to me. Should we then also concatenate the text given
> via the "mainlabel" parameter of <ask>?

That seems reasonable, if for nothing else then backwards compatability.  I
think most of the time, people would specify the label in only one place, but
it's hard to guess which place that would be, so concatenating them shold work.
 It's likely that when someone does specify more than one, it is by mistake;
then, concatenating should make it obvious what their mistake was, so it will be
clear how they can fix it.
Comment 6 Markus Krötzsch 2007-08-19 15:52:38 UTC
The new (SVN) version now allows to specify the mainlabel parameter via pipe syntax in all conditions of the query (the parts with * are no conditions and behave as before), just as you suggested. If many labels are given, the result is created as a concatenation of all parts, in the hope that this helps users to clean up the mess.

For properties that link to pages (the former relations), escaping is possible via an extra ":". So <ask>[[has operator:::+]]</ask> should work. There is no such escaping for other datatypes yet (but this would be another feature request).

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


Navigation
Links