On 25 July 2012 03:33, Yury Katkov katkov.ju...@gmail.com wrote:
So here is my question: is it possible to figure out the properties before
the text is actually stored in the database?
I don't know exactly how SMW works, but it should be possible to parse
again the article text and collect the
Do you need the association between property and source text?
Probably I do. I want to know whether or not the user will change the
property befor the text is stored in the database.
I don't know exactly how SMW works, but it should be possible to parse
again the article text and collect the
Hey James,
I just merged in your changes, and they are looking great :)
One usability suggestion I have is adding a line of text at the top of the
other options box explaining what they are, in particular that you can
cover over their names to get their associated description (as this might
not
Hey,
Probably I do. I want to know whether or not the user will change the
property befor the text is stored in the database.
Sorry, that makes no sense to me. If you want to know the property value
changes, what you need is exactly the hooks providing diffs I mentioned.
Why would you need
Hey,
Semantic Watchlist operates with the data that has been already stored in
the database, right?
No, it uses the SMWStore::updateDataBefore hook, which gets fired in
SMWStore::updateData. So you can use this hook together with one that
allows modifying the user (assuming there is one that
Hi Yaron,
it just seems like too much work to makes users do
Well, their is not much wiggle room in making the Special:Ask layout
UI somewhat sane. On the one hand we want people immediately recognize
the content that is inherent in an option selected and on the other
hand by doing so puts the
I'm really not sure about that hover thing
Me neither but what else is there left, if this is not an option?
Another option would be to introduce a user preference where one can
opt-in/out of the text display but do we really want to do this?
[1]
Hi James,
Thanks for putting those two images together. I actually think that 2nd
layout, with the descriptions in a smaller font below the input, looks
totally fine - it would probably look nicer if the descriptions were under
both the parameter name and the input, but that's a minor point. It's
Hi Krabina ,
Why not use Tool tips as in SF
#info (not {{{info}}}) is a parser function that comes with SMW (not
SF) but it uses outdated JavaScript and is planned to be replaced [1]
someday. The method applied in Special:Ask is MW standard as far as
there is MW standard (using jquery.tipsy).
Hi Yaron,
I have spent more time on this now than I actually wanted to but with
change [1] you will have your standard behaviour of showing the text
beneath the input box (as default) but at the same time introduced a
user preference for a Special:Ask tooltip. For power user like me that
don't
Hi,
Okay, that works - making something an optional setting is always a
possibility when the group can't decide on something. :) Out of curiosity,
what do you think of Niklas's suggestion, of showing the description
instead of the label? That might actually work also - after all, that's how
the
For the formats we have nice internationalized names, we do not have such
names or labels for parameters (yet), only their canonical system names.
Using the descriptions seems like a bad idea as they are meant to describe
the parameter, not to identify it.
Sent from my Android phone.
Yes, that's a good point.
On Wed, Jul 25, 2012 at 1:34 PM, Jeroen De Dauw jeroended...@gmail.comwrote:
For the formats we have nice internationalized names, we do not have such
names or labels for parameters (yet), only their canonical system names.
Using the descriptions seems like a bad
13 matches
Mail list logo
