Snaterlicious added a subscriber: Snaterlicious.
Snaterlicious added a comment.
First off: Renaming in the UI has already happened. The reason behind that
change was that, in the layout, the sub-component of a `Fingerprint` (label,
description, aliases in one language) needs to be encapsulated
Snaterlicious created this task.
Snaterlicious added a subscriber: Snaterlicious.
Snaterlicious added a project: MediaWiki-extensions-WikibaseRepository.
Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTION
Previously (version deployed on wikidata.org), it was not possible
Snaterlicious added a comment.
Would be awesome to document the reasoning behind the agreements. So, instead
of flexible entity types, there will be special properties? As that is a very
fundamental decision, it should be evaluated properly as to other use cases
(spontaneously, https
Snaterlicious added a comment.
Works as expected by now, except for the siteselector selecting the first site
when pressing ESC. Solved in https://gerrit.wikimedia.org/r/#/c/185976/.
TASK DETAIL
https://phabricator.wikimedia.org/T40360
REPLY HANDLER ACTIONS
Reply to comment or attach
Snaterlicious added a comment.
Unable to reproduce. Works for me on https://www.wikidata.org/wiki/Q16503 in
Chrome, FF, IE. The gadget does not require a dependency on
`jquery.wikibase.entityview`, just like the AuthorityControl gadget is not
supposed to require that dependency. Either some
Snaterlicious added a comment.
https://gerrit.wikimedia.org/r/#/c/185979/
TASK DETAIL
https://phabricator.wikimedia.org/T87195
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
username.
EMAIL PREFERENCES
https
Snaterlicious added a comment.
https://gerrit.wikimedia.org/r/#/c/185411/
TASK DETAIL
https://phabricator.wikimedia.org/T86895
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
username.
EMAIL PREFERENCES
https
Snaterlicious added a comment.
Just an idea: That could be a chance to fill the skin template native h1
class=firstHeading tag with meaningful information.
TASK DETAIL
https://phabricator.wikimedia.org/T85633
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim
Snaterlicious closed this task as Resolved.
Snaterlicious claimed this task.
Snaterlicious added a comment.
Yes, done with https://github.com/wmde/WikibaseSerializationJavaScript/pull/6.
TASK DETAIL
https://phabricator.wikimedia.org/T78273
REPLY HANDLER ACTIONS
Reply to comment or attach
Snaterlicious reassigned this task from Snaterlicious to Wikidata-bugs.
TASK DETAIL
https://phabricator.wikimedia.org/T78273
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
username.
EMAIL PREFERENCES
https://phabricator.wikimedia.org
Snaterlicious reassigned this task from Snaterlicious to Wikidata-bugs.
Snaterlicious set Security to none.
TASK DETAIL
https://phabricator.wikimedia.org/T75310
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
username.
EMAIL PREFERENCES
Snaterlicious added a comment.
Unable to reproduce (trying with uselang=nl on wikidata.org on that property
name). Would be very surprised if that actually was a bug in the entityselector
widget as there is no mechanism to change the order of the suggestions in any
way.
It might rather point
Snaterlicious added a comment.
The move toolbar was removed as of https://phabricator.wikimedia.org/T58050
and is supposed to be re-implemented on top of
https://phabricator.wikimedia.org/T74297. Of course, I would like to have
move functionality back, but, in my opinion, there is no point
Snaterlicious added a comment.
I had that in mind and, yes, there should be some concept covering all those
cases. Regarding multilingual value: In my opinion, I could very well imagine
that working just the same, as the label acts (and, basically, is), in fact, a
multilingual value
Snaterlicious added a subscriber: Snaterlicious.
Snaterlicious added a comment.
Would be nice to get that ticket back on track as, by now, there is complete
code documentation in place for the JS components / JS part of the components
DataModel, API, Serialization, DataTypes, DataValues
Snaterlicious added a comment.
The JavaScript code documentation of ValueView was updated extensively some
time ago (by now) and is part of ValueView = 0.9.0. The remaining part is
generating and deploying the actual documentation. Not sure whether that should
be part of this ticket
Snaterlicious added a comment.
The code documentation is in place. Maybe the task of generating and deploying
the documentation should be tracked on
https://phabricator.wikimedia.org/T42657. (see also
https://phabricator.wikimedia.org/T75987)
TASK DETAIL
https://phabricator.wikimedia.org
Snaterlicious added a comment.
While that is a reasonable suggestion, adding any code to that feature is quite
demotivating as it appears to be senseless effort...
https://gerrit.wikimedia.org/r/#/c/184907/
I sincerely hope there is a way to replace that embarrassing mechanism. Can't
we just
Snaterlicious added a subscriber: Snaterlicious.
Snaterlicious added a comment.
Just noticed that bug. ValueView documentation has been updated via
https://phabricator.wikimedia.org/T75987.
As to the documentation (see `jquery.valueview.valueview.js`), there is no
generic `change` event
Snaterlicious added a comment.
Adding the language name in superscript was proposed already and we even had
some mock-up way back. It would tie in with what we do with the calendar names
as those are, in a way, some kind of language as well. It would be nice to be
able to use the language name
Snaterlicious added a comment.
What is the rest of the header design? Change is submitted already:
https://gerrit.wikimedia.org/r/#/c/184629/
TASK DETAIL
https://phabricator.wikimedia.org/T84913
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe
Snaterlicious added a comment.
Just wondering about the message content. As having a hint in non-JS is
probably not that useful anyway, still, there would be at least two messages.
One for logged-in users and one for users not logged in. To avoid being bashed
for improper messages and since
Snaterlicious added a comment.
https://gerrit.wikimedia.org/r/#/c/183456/
TASK DETAIL
https://phabricator.wikimedia.org/T76849
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
username.
EMAIL PREFERENCES
https
Snaterlicious added a comment.
OK, follow-up question: As the whole procedure of using Babel is kind of not
how it should be, should that mechanism be implemented as a gadget on Wikidata,
or should effort be put into implementing a dedicated Special page (that should
be removed rather sooner
Snaterlicious added a comment.
I my opinion, specifically developing for Wikidata would be opening Pandora's
box. We already have rather awkward Wikidata-specifics in the the code
(Calendar types reference Wikidata items, for example) and, from my point of
view, dealing with gadgets is already
Snaterlicious added a comment.
Just some thoughts on that:
In my opinion, the full name should be defined by a property as well. Using
the label would add an an assumption on top of the concept of label whose
original purpose is nothing more than to identify an entity. Additionally
Snaterlicious closed this task as Resolved.
Snaterlicious added a subscriber: Snaterlicious.
TASK DETAIL
https://phabricator.wikimedia.org/T75749
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
username.
EMAIL PREFERENCES
https
Snaterlicious closed this task as Resolved.
Snaterlicious added a subscriber: Snaterlicious.
TASK DETAIL
https://phabricator.wikimedia.org/T75749
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
username.
EMAIL PREFERENCES
https
Snaterlicious closed blocking task T75655: Rename existing fingerprint* widgets
as Resolved.
TASK DETAIL
https://phabricator.wikimedia.org/T75654
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
username.
EMAIL PREFERENCES
https
Snaterlicious closed this task as Resolved.
Snaterlicious claimed this task.
TASK DETAIL
https://phabricator.wikimedia.org/T75655
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
username.
EMAIL PREFERENCES
https
Snaterlicious added a subscriber: Snaterlicious.
Snaterlicious added a comment.
I suppose it was not possible in the past (probably before implementing the JS
data model), but it would be better practice to retrieve the `Reference`
objects from the Statement object, instead of gathering it from
Snaterlicious added a comment.
After some tossing and turning, I opt for not implementing a dedicated skin as
long as there are no specific requirements. A dedicated skin (although it would
just be an adaption of an existing skin without applying any complex patterns)
increases complexity
Snaterlicious added a subscriber: Snaterlicious.
Snaterlicious added a comment.
https://gerrit.wikimedia.org/r/#/c/180150/
TASK DETAIL
https://phabricator.wikimedia.org/T76673
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
username
Snaterlicious added a comment.
`SnakSerializer` submits the parameters in the order `type`, `value`, `error`
while the `UnUnserializableValue` constructor assumes `value`, `type`, `error`.
Started cleaning up in https://github.com/wmde/DataValuesJavascript/pull/58.
The other issue is, of course
Snaterlicious added a comment.
The pros and cons were discussed in older comments already... I am reluctant to
retrigger the discussion.
It boils down to the question is whether there should be a selector or a
suggester. (While it makes sense for a selector to use hard
auto-completion
Snaterlicious added a comment.
Using CSS flexbox, the mock-up could just be adapted as is. However, due to
the lack of compatibility, this options is disregarded. (Sensible) options from
a technical perspective:
- Leave the badges left to the page name: When toggling edit mode, the page
name
Snaterlicious added a comment.
As to the mock-up, the plan is to have the badges at the end of a line / after
the page name input box in order to be able to prevent jitters when toggling
edit mode. This, of course, if effective only if the space for the remove
button is reflected by white
Snaterlicious added a comment.
Widgets that aggregate other widgets should encapsulate their aggregated
widgets' events using `event.stopPropagation()`. If parent components/widgets
are to receive notification, these parent components should rely only on the
events of their direct children
Snaterlicious added a comment.
This ticket needs some more specification. I am not sure about what the
expected outcome should be as I do not see the need for the ticket to be
blocked by the high-level documentation.
The diagram embedded on https://github.com/wmde/WikibaseDataModelJavaScript
101 - 139 of 139 matches
Mail list logo
