[Wikidata-bugs] [Maniphest] T314360: cleanup of ontology definition file

2022-09-28 Thread abian 
abian added a comment.


  Copying here for the near or distant future:
  
  From OOPS! (OntOlogy Pitfall Scanner!)
  --
  
  `P40` (critical): Namespace hijacking. It refers to reusing or referring to 
terms from another namespace that are not defined in such namespace. This is an 
undesirable situation as no information can be retrieved when looking up those 
undefined terms. See TripleChecker 
<http://graphite.ecs.soton.ac.uk/checker/?uri=https://wikiba.se/ontology-1.0.owl>.
  
  - http://creativecommons.org/ns#licence
- It should be 'licen**s**e'
  
  `P11` (important): Missing domain or range in properties. Object and/or 
datatype properties without domain or range (or none of them) are included in 
the ontology.
  
  - http://wikiba.se/ontology#qualifierValue
  - http://wikiba.se/ontology#referenceValueNormalized
  - http://wikiba.se/ontology#claim
  - http://wikiba.se/ontology#qualifier
  - http://wikiba.se/ontology#qualifierValueNormalized
  - http://wikiba.se/ontology#statementValueNormalized
  - http://wikiba.se/ontology#statementValue
  - http://wikiba.se/ontology#badge
  - http://wikiba.se/ontology#statementProperty
  - http://wikiba.se/ontology#referenceValue
  - http://wikiba.se/ontology#directClaim
  - http://wikiba.se/ontology#novalue
  - http://wikiba.se/ontology#reference
  - http://wikiba.se/ontology#wikiGroup
  
  `P04` (minor): Creating unconnected ontology elements. Ontology elements 
(classes, object properties and datatype properties) are created isolated, with 
no relation to the rest of the ontology. Solving this pitfall may lead to new 
results for other pitfalls and suggestions.
  
  - http://wikiba.se/ontology#Value
  - http://wikiba.se/ontology#BestRank
  - http://wikiba.se/ontology#Reference
  - http://wikiba.se/ontology#Entity
  - http://wikiba.se/ontology#PropertyType
  - http://wikiba.se/ontology#GeoAutoPrecision
  - http://wikiba.se/ontology#Dump
  
  File: F35538142: ontology-1.0.owl 
<https://phabricator.wikimedia.org/F35538142>

TASK DETAIL
  https://phabricator.wikimedia.org/T314360

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: HasanAkgun_WMDE, abian
Cc: abian, Lucas_Werkmeister_WMDE, Michael, danshick-wmde, Lydia_Pintscher, 
Jainitbafna, Jersione, Hellket777, LisafBia6531, Astuthiodit_1, 786, Biggs657, 
karapayneWMDE, Invadibot, Gaurav24072002, Abhinay76, GFontenelle_WMF, 
Annysah01, Rohitgeddam, maantietaja, FRomeo_WMF, Juan90264, Alter-paule, 
Beast1978, CBogen, ItamarWMDE, Un1tY, Nintendofan885, Akuckartz, Soda, 
Chaytanya, JorisDarlingtonQuarshie, Hook696, wiki-helenatxu, Kent7301, 
joker88john, Dinadineke, DannyS712, CucyNoiD, Klein, Nandana, JKSTNK, Tks4Fish, 
Gaboe420, Mh-3110, Giuliamocci, tabish.shaikh91, Cpaulf30, Lahi, Gq86, Af420, 
E1presidente, Ramsey-WMF, Cparle, SandraF_WMF, Bsandipan, GoranSMilovanovic, 
Jayprakash12345, JakeTheDeveloper, Mahir256, QZanden, Tramullas, Acer, merbst, 
LawExplorer, Samuele2002, Salgo60, Lewizho99, Maathavan, Silverfish, _jensen, 
rosalieper, xSavitar, Neuronton, Scott_WUaS, mb, MuhammadShuaib, Susannaanas, 
Tmalhotra, Fuzheado, SimmeD, Jane023, Wikidata-bugs, Base, matthiasmullie, 
aude, Daniel_Mietchen, Ebe123, Ricordisamoa, Wesalius, Raymond, TheDJ, 
Steinsplitter, Mbch331
___
Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org
To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org

[Wikidata-bugs] [Maniphest] T314360: cleanup of ontology definition file

2022-09-26 Thread abian 
abian added a comment.


  You may want to check https://oops.linkeddata.es. It won't tell you about all 
the possible issues, but it will give you an idea of some (so-called) common 
pitfalls that still need to be resolved. By doing so you may also be solving 
T210337 <https://phabricator.wikimedia.org/T210337>. 0:-)
  
  You can visualize the result at 
http://vowl.visualdataweb.org/webvowl-old/webvowl-old.html#iri=http://wikiba.se/ontology-1.0.owl.

TASK DETAIL
  https://phabricator.wikimedia.org/T314360

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: HasanAkgun_WMDE, abian
Cc: abian, Lucas_Werkmeister_WMDE, Michael, danshick-wmde, Lydia_Pintscher, 
Jainitbafna, Jersione, Hellket777, LisafBia6531, Astuthiodit_1, 786, Biggs657, 
karapayneWMDE, Invadibot, Gaurav24072002, Abhinay76, GFontenelle_WMF, 
Annysah01, Rohitgeddam, maantietaja, FRomeo_WMF, Juan90264, Alter-paule, 
Beast1978, CBogen, ItamarWMDE, Un1tY, Nintendofan885, Akuckartz, Soda, 
Chaytanya, JorisDarlingtonQuarshie, Hook696, wiki-helenatxu, Kent7301, 
joker88john, Dinadineke, DannyS712, CucyNoiD, Klein, Nandana, JKSTNK, Tks4Fish, 
Gaboe420, Mh-3110, Giuliamocci, tabish.shaikh91, Cpaulf30, Lahi, Gq86, Af420, 
E1presidente, Ramsey-WMF, Cparle, SandraF_WMF, Bsandipan, GoranSMilovanovic, 
Jayprakash12345, JakeTheDeveloper, Mahir256, QZanden, Tramullas, Acer, merbst, 
LawExplorer, Samuele2002, Salgo60, Lewizho99, Maathavan, Silverfish, _jensen, 
rosalieper, xSavitar, Neuronton, Scott_WUaS, mb, MuhammadShuaib, Susannaanas, 
Tmalhotra, Fuzheado, SimmeD, Jane023, Wikidata-bugs, Base, matthiasmullie, 
aude, Daniel_Mietchen, Ebe123, Ricordisamoa, Wesalius, Raymond, TheDJ, 
Steinsplitter, Mbch331
___
Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org
To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org

[Wikidata-bugs] [Maniphest] T314083: Special:NewLexemeAlpha's example can be confusing

2022-07-28 Thread abian 
abian updated the task description.

TASK DETAIL
  https://phabricator.wikimedia.org/T314083

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, 
Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, Mahir256, QZanden, 
LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org
To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org

[Wikidata-bugs] [Maniphest] T314083: Special:NewLexemeAlpha's example can be confusing

2022-07-28 Thread abian 
abian created this task.
abian added projects: Wikidata Lexicographical data, Special:NewLexeme revival, 
Wikidata.

TASK DESCRIPTION
  In Special:NewLexemeAlpha's example, I find it confusing that the language 
code (en) and the language (English) are on different lines. 'cat' (L7) is a 
quite complete Lexeme about a nice entity, but also a very short word that 
looks like a language code, which doesn't help solve the confusion.
  
  F35353359: example-newlexemealpha.png 
<https://phabricator.wikimedia.org/F35353359>
  
  Something similar happens when applying uselang=fr (or other language codes):
  
  F35353598: ama.png <https://phabricator.wikimedia.org/F35353598>
  
  **Suggestions**: swap the "Language" and "Lexical category" lines; rethink 
the layout; use a Lexeme on a word widely recognized as such but with more 
characters

TASK DETAIL
  https://phabricator.wikimedia.org/T314083

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, 
Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, Mahir256, QZanden, 
LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org
To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org

[Wikidata-bugs] [Maniphest] T274687: Links is not localizable in Wikidata sidebar

2022-07-26 Thread abian 
abian added a comment.


  More or less the same: T273370 <https://phabricator.wikimedia.org/T273370> 
(with subtasks T273368 <https://phabricator.wikimedia.org/T273368> and T273369 
<https://phabricator.wikimedia.org/T273369>)

TASK DETAIL
  https://phabricator.wikimedia.org/T274687

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, Amire80, Lydia_Pintscher, matej_suchanek, YFdyh000, Aklapper, 
Astuthiodit_1, Prufkick, karapayneWMDE, Invadibot, Universal_Omega, 
maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, 
QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Srdjan, MuhammadShuaib, 
LNDDYL, Psychoslave, Wikidata-bugs, aude, Gryllida, Shizhao, Arrbee, Mbch331, 
Jay8g
___
Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org
To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org

[Wikidata-bugs] [Maniphest] T297528: incorrect SPARQL queries when several quantity-based conditions are defined

2021-12-10 Thread abian 
abian added a project: Wikidata.

TASK DETAIL
  https://phabricator.wikimedia.org/T297528

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Aklapper, abian, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, 
GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, 
Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org
To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org

[Wikidata-bugs] [Maniphest] T236295: integrate exceptions as part of Wikibase datamodel of the entity concerned

2021-06-19 Thread abian 
abian added a comment.


  For me, constraints should constrain (unless they have the level of 
suggestion defined), and exceptions should be exceptional. Those cases where 
the number of exceptions ends up skyrocketing are cases where either the 
constraints were conceived trying to generalize too small, specific and biased 
a set of cases, or there's a broader underlying problem of knowledge 
representation that is difficult to address and users choose to add exceptions 
to ignore it. The first reason for this task ("Currently the way to store 
exceptions is not scalable") is an effect of these problems, and I think we 
should solve them instead of thinking of a way to add even more exceptions. The 
Property that motivates this task (`P225`) is also mentioned at 
Wikidata:2020_report_on_Property_constraints#Exceptions 
<https://www.wikidata.org/wiki/Wikidata:2020_report_on_Property_constraints#Exceptions>
 in the context of some of the problems caused by exceptions; see also T244045 
<https://phabricator.wikimedia.org/T244045>.
  
  Property constraints are part of the intensional 
<https://en.wikipedia.org/wiki/Extensional_and_intensional_definitions> 
definition of each Property, and their usefulness lies in the fact that we can 
check their consistency with an enumerative definition, of which all uses of 
the Property are automatically part. A finite list of current exceptions 
override this automatic enumerative definition, but it does so alongside, or 
with reference to, the intensional definition, which applies to a generally 
infinite number of possible present and future entities. Ideally, the 
intensional definition should never refer to the enumeration or vice versa, and 
in the case of Wikidata it's worse because these references are not controlled: 
as exceptions are implemented now, I can delete a constrained statement and 
still have the Item listed as an exception; and, as proposed to be implemented 
in this task, I could delete a constraint and still have exceptions to it.
  
  For when there are many exceptions I would suggest either using the 
suggestion level or using mechanisms other than standard Property constraints; 
luckily, today there are many ways to check compliance with complex rules that 
don't involve the Property constraint system.

TASK DETAIL
  https://phabricator.wikimedia.org/T236295

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, ChristianKl, Esc3300, Lucas_Werkmeister_WMDE, Aklapper, Bugreporter, 
Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, 
QZanden, LawExplorer, _jensen, rosalieper, Agabi10, Scott_WUaS, Wikidata-bugs, 
aude, Mbch331
___
Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org
To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org

[Wikidata-bugs] [Maniphest] T195178: Label in language constraint type

2021-06-02 Thread abian 
abian added a comment.


  šŸ˜‚

TASK DETAIL
  https://phabricator.wikimedia.org/T195178

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Esc3300, abian, Lydia_Pintscher, Aklapper, Multichill, Invadibot, 
maantietaja, Akuckartz, Nandana, Lahi, Gq86, Lucas_Werkmeister_WMDE, 
GoranSMilovanovic, QZanden, merbst, LawExplorer, _jensen, rosalieper, Agabi10, 
Scott_WUaS, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org
To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org

[Wikidata-bugs] [Maniphest] T195178: Label in language constraint type

2021-05-30 Thread abian 
abian added a comment.


  In T195178#7123731 <https://phabricator.wikimedia.org/T195178#7123731>, 
@Multichill wrote:
  
  > Not sure about what your intentions are with these questions. I'll just 
assume good faith
  
  Hey. Of course there's no bad intention; I don't know why I should have bad 
intentions towards you, you've never harmed me or my family (because you 
haven't... have you? šŸ˜…).
  
  In T195178#7122976 <https://phabricator.wikimedia.org/T195178#7122976>, 
@abian wrote:
  
  > My devil's advocate questions:
  >
  > - I assume that the main purpose of all constraint types is to inform 
editors of mistakes or suggestions that would otherwise not be obvious. I also 
assume that all Items should have both labels and descriptions in virtually all 
supported languages. Why should users be told that the lack of a label in one 
language is a mistake and shouldn't be told the same about a label in another 
language that is more relevant (e.g. more demanded by Wikipedia) or more 
familiar to the user?
  > - Would it be expected that users who didn't previously fill in labels 
would switch to filling them in as a result of these violations? Or would these 
violations be ignored and contribute to all constraint types being ignored more?
  > - Might labels that were not suggested by these constraints be more 
neglected?
  
  I usually leave these kinds of questions on Phabricator to try to assess in 
advance possible problems I can think of that might (or might not) arise after 
the possible implementation. The questions aren't ironic, I really don't know 
the answers but I do think they're relevant. There are a couple of dozen 
constraint types considered or proposed for implementation, so the first 
question would serve to justify why this constraint type would be particularly 
helpful; the second question is related to the problem of habituation to 
warnings <https://dl.acm.org/doi/10.1145/3025453.3025896>, which is already 
occurring on Wikidata and we know both indirect figures 
<https://www.wikidata.org/wiki/Wikidata:2020_report_on_Property_constraints#Knowledge,_perception_and_ease_of_use>
 and individual users who routinely ignore these warnings, but this problem 
will evolve and new warnings could make it worse or better; and the third would 
be another question to think about whether the overall balance of obeying the 
warnings would be positive for Wikidata (re)users or not. Of course I don't 
have these answers nor a special interest that this constraint type isn't 
implemented... until you harm me or my family, in which case I won't hesitate 
to add a dislike token to this very task.

TASK DETAIL
  https://phabricator.wikimedia.org/T195178

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Esc3300, abian, Lydia_Pintscher, Aklapper, Multichill, Invadibot, 
maantietaja, Akuckartz, Nandana, Lahi, Gq86, Lucas_Werkmeister_WMDE, 
GoranSMilovanovic, QZanden, merbst, LawExplorer, _jensen, rosalieper, Agabi10, 
Scott_WUaS, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org
To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org

[Wikidata-bugs] [Maniphest] T195178: Label in language constraint type

2021-05-29 Thread abian 
abian added a comment.


  My devil's advocate questions:
  
  - I assume that the main purpose of all constraint types is to inform editors 
of mistakes or suggestions that would otherwise not be obvious. I also assume 
that all Items should have both labels and descriptions in virtually all 
supported languages. Why should users be told that the lack of a label in one 
language is a mistake and shouldn't be told the same about a label in another 
language that is more relevant (e.g. more demanded by Wikipedia) or more 
familiar to the user?
  - Would it be expected that users who didn't previously fill in labels would 
switch to filling them in as a result of these violations? Or would these 
violations be ignored and contribute to all constraint types being ignored more?
  - Might labels that were not suggested by these constraints be more neglected?

TASK DETAIL
  https://phabricator.wikimedia.org/T195178

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, Lydia_Pintscher, Aklapper, Multichill, Invadibot, maantietaja, 
Akuckartz, Nandana, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, 
QZanden, merbst, LawExplorer, _jensen, rosalieper, Agabi10, Scott_WUaS, 
Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org
To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org

[Wikidata-bugs] [Maniphest] T264535: duplicated lines in all Wikidata entities with statements in LD formats

2021-05-13 Thread abian 
abian assigned this task to hoo.
abian closed this task as "Resolved".
abian added a comment.


  You fixed it. \o/

TASK DETAIL
  https://phabricator.wikimedia.org/T264535

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: hoo, abian
Cc: Lucas_Werkmeister_WMDE, Lydia_Pintscher, Aklapper, abian, Invadibot, 
maantietaja, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, 
LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org
To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org

[Wikidata-bugs] [Maniphest] T264535: duplicated lines in all Wikidata entities with statements in LD formats

2021-04-30 Thread abian 
abian added a comment.


  In T264535#7048342 <https://phabricator.wikimedia.org/T264535#7048342>, 
@Lucas_Werkmeister_WMDE wrote:
  
  > Is this problematic for any particular reason? As far as I understand, itā€™s 
generally acceptable to repeat triples in RDF (they just have no effect).
  >
  > (We can still fix this, of course, Iā€™m just curious if itā€™s more important 
for some reason Iā€™m not aware of.)
  
  I don't know, I guess not, apart from the extra bytes stored, transmitted, 
processed, etc. Perhaps certain applications also display this information (or 
the result of processing it) twice. (?)

TASK DETAIL
  https://phabricator.wikimedia.org/T264535

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Lucas_Werkmeister_WMDE, Lydia_Pintscher, Aklapper, abian, Invadibot, 
Lalamarie69, maantietaja, Alter-paule, Beast1978, Un1tY, Akuckartz, Hook696, 
Kent7301, joker88john, CucyNoiD, Nandana, Gaboe420, Giuliamocci, Cpaulf30, 
Lahi, Gq86, Af420, Bsandipan, GoranSMilovanovic, QZanden, LawExplorer, 
Lewizho99, Maathavan, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, 
Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T264535: duplicated lines in all Wikidata entities with statements in LD formats

2021-04-29 Thread abian 
abian added a subscriber: Lydia_Pintscher.
abian added a comment.


  @Lydia_Pintscher, do you know to which project/team this task would belong?

TASK DETAIL
  https://phabricator.wikimedia.org/T264535

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Lydia_Pintscher, Aklapper, abian, Invadibot, maantietaja, Akuckartz, 
Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, 
rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T280191: Prevent simultaneous executions of the same query with the Query Builder

2021-04-14 Thread abian 
abian created this task.
abian added projects: Wikidata Query Builder, Wikidata.
Restricted Application added a subscriber: Aklapper.

TASK DESCRIPTION
  **Problem:** Whereas https://query.wikidata.org/ disables the execution 
button while a query is running, https://query-builder-test.toolforge.org/ 
allows the user to launch any number of executions of the same query with no 
waiting time between launches (until the server ends up returning a low-level 
error for exceeding the allowed rate of requests). This practice cannot help 
users to satisfy their demands more quickly or better; in fact, it delays the 
time at which users will see the results, apart from causing a waste of 
resources.
  
  F34394966: Run query.png <https://phabricator.wikimedia.org/F34394966>
  
  **Acceptance criteria:**
  
  - It is not possible to launch a new execution until the current one has 
finished.
  - Alternatively, it is not possible to launch a new execution of the same 
query within a number of seconds from the start of the current execution.

TASK DETAIL
  https://phabricator.wikimedia.org/T280191

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Aklapper, abian, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, 
GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, 
Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T280158: Date input should indicate the system interpretation of valid 4-digit dates

2021-04-14 Thread abian 
abian added a comment.


  Yeah, we could make the UI explicitly state "CE" for all those dates of the 
Common Era with one- or two-digit years, in line with 
https://en.wikipedia.org/wiki/WP:BCEā€¦
  
  > One- and two-digit years may look more natural with an era marker (born in 
2 AD or born January 15, 22 CE, not born in 2 nor January 15, 22).
  
  This might solve a number of potential confusions.

TASK DETAIL
  https://phabricator.wikimedia.org/T280158

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, Aklapper, Sarai-WMDE, Invadibot, maantietaja, Akuckartz, Nandana, 
Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, 
Scott_WUaS, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T272697: (MS 6) Query for date values

2021-04-13 Thread abian 
abian added a comment.


  According to the UI, you can retrieve people born before (or after), for 
example, 31 January (birthday), but what you get has nothing to do with that. I 
believe there are quite a few other problematic use cases (which is 
understandable, this is a challenging task!).
  
  F34374151: 31-1.png <https://phabricator.wikimedia.org/F34374151>
  
  https://w-beta.wmflabs.org/Ho
  
  https://w.wiki/3BVR

TASK DETAIL
  https://phabricator.wikimedia.org/T272697

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: amy_rc, abian
Cc: Michael, Sarai-WMDE, abian, Charlie_WMDE, Lydia_Pintscher, amy_rc, 
Aklapper, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, 
GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, 
Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T279044: Publishing Mastodon addresses is very hard

2021-04-06 Thread abian 
abian closed this task as "Resolved".
abian claimed this task.
abian added a comment.


  It should be fixed with this 
<https://www.wikidata.org/wiki/Special:AbuseFilter/history/42/diff/prev/1347>. 
Please feel free to reopen this task if you continue to have problems. Thanks!

TASK DETAIL
  https://phabricator.wikimedia.org/T279044

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, Lydia_Pintscher, Lucas_Werkmeister_WMDE, selfisekai, Aklapper, 
Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, 
QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, 
Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T276876: Create condition for properties to declare inverse relationship properties that will be automatically assigned to the inverse item

2021-03-09 Thread abian 
abian added a comment.


  Note that this could be done with inverse constraints (Q21510855 
<https://www.wikidata.org/wiki/Q21510855>) using the "mandatory" severity 
level. See the help page about this constraint type 
<https://www.wikidata.org/wiki/Help:Property_constraints_portal/Inverse> and an 
explanation on severity levels 
<https://www.wikidata.org/wiki/Wikidata:2020_report_on_Property_constraints#Severity_levels>.

TASK DETAIL
  https://phabricator.wikimedia.org/T276876

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, Aklapper, MavropaliasG, maantietaja, Akuckartz, darthmon_wmde, 
Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, 
rosalieper, Scott_WUaS, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T273113: Wikidata pages don't seem to show up on Google and Bing Search results

2021-03-07 Thread abian 
abian added a comment.


  See also T200846#4487680 <https://phabricator.wikimedia.org/T200846#4487680>.

TASK DETAIL
  https://phabricator.wikimedia.org/T273113

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, dr0ptp4kt, Mmarx, Pigsonthewing, Lydia_Pintscher, DanBri, 
DVrandecic, Aklapper, maantietaja, Akuckartz, Nandana, Lahi, Gq86, 
GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, 
Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T272697: (MS 6) Query for date values

2021-03-02 Thread abian 
abian added a comment.


  In T272697#6875288 <https://phabricator.wikimedia.org/T272697#6875288>, 
@Sarai-WMDE wrote:
  
  > Hey, @abian. Those are very valid and concerns, and we really appreciate 
you sharing them! We are aware that unfortunately some current issues will also 
be reproduced by the new application (e.g. querying for a specific date like 
01-01-2021 will result in false positives, since 2021 with precision year will 
also be retrieved). In the context of the Query Builder, users will only be 
able to enter specific dates, and precision will be interpreted based on their 
input (we are yet to define how some values ā€“ e.g. years only ā€“ would be 
translated into SPARQL. This might be the key to alleviate some of the inherent 
issues with dates?). This data type is definitely a tricky one, and we wouldn't 
like to proceed being unaware of big problems. Since you seem to really have a 
deep understanding of the issue and its consequences, it'd be great if you'd be 
up for a chat?
  
  Of course we can chat. :-) I'll send you an email.

TASK DETAIL
  https://phabricator.wikimedia.org/T272697

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Sarai-WMDE, abian, Charlie_WMDE, Lydia_Pintscher, amy_rc, Aklapper, 
Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, 
_jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T272697: (MS 6) Query for date values

2021-03-02 Thread abian 
abian added a comment.


  Hey over here. I'm writing to warn you that, unfortunately, this can be 
extremely problematic. Since Wikibase stores all dates with day precision, 
regardless of their actual precision (which is stored separately), and the 
irrelevant part of the value can be arbitrary, it's very easy to generate 
misinformation with these features, as has been quietly happening for years and 
continues to happen to many agents and to at least three Property constraint 
types (see T168379 <https://phabricator.wikimedia.org/T168379>, one of the most 
important causes of false positives in the very system that is intended to 
ensure data quality; and see https://reasonator.toolforge.org/?q=Q100410179 
mentioning the year 1476, totally arbitrary value that Wikibase stores 
internally and shamelessly communicates to all software agents but does not 
display in its web interface). Including these features in the Query Builder 
aimed at the general public without first resolving this problem could have 
very undesirable consequences. I should have opened a Phabricator task 
describing this general problem and all its consequences, but I have never 
found the time or known where to start because of its magnitude and the 
questions it opens up.

TASK DETAIL
  https://phabricator.wikimedia.org/T272697

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, Charlie_WMDE, Lydia_Pintscher, amy_rc, Aklapper, Akuckartz, Nandana, 
Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, 
Scott_WUaS, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T273368: Include MediaWiki:Randomlexeme in the Wikibase Lexeme extension

2021-01-30 Thread abian 
abian added a parent task: T273370: Make the Wikibase Lexeme extension show a 
section on lexicographical data in the sidebar.

TASK DETAIL
  https://phabricator.wikimedia.org/T273368

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, Mahir256, 
QZanden, LawExplorer, _jensen, rosalieper, Bodhisattwa, Scott_WUaS, 
Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T273369: Include MediaWiki:Lexicographical-data in the Wikibase Lexeme extension

2021-01-30 Thread abian 
abian added a parent task: T273370: Make the Wikibase Lexeme extension show a 
section on lexicographical data in the sidebar.

TASK DETAIL
  https://phabricator.wikimedia.org/T273369

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, Mahir256, 
QZanden, LawExplorer, _jensen, rosalieper, Bodhisattwa, Scott_WUaS, 
Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T273370: Make the Wikibase Lexeme extension show a section on lexicographical data in the sidebar

2021-01-30 Thread abian 
abian added subtasks: T273368: Include MediaWiki:Randomlexeme in the Wikibase 
Lexeme extension, T273369: Include MediaWiki:Lexicographical-data in the 
Wikibase Lexeme extension.

TASK DETAIL
  https://phabricator.wikimedia.org/T273370

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, Mahir256, 
QZanden, LawExplorer, _jensen, rosalieper, Bodhisattwa, Scott_WUaS, 
Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T273370: Make the Wikibase Lexeme extension show a section on lexicographical data in the sidebar

2021-01-30 Thread abian 
abian created this task.
abian added projects: Wikidata, Wikidata Lexicographical data.

TASK DESCRIPTION
  We have a locally defined section on lexicographical data in Wikidata's 
sidebar <https://www.wikidata.org/wiki/MediaWiki:Sidebar>. Including it by 
default in the Wikibase Lexeme extension would allow it to be displayed in 
other installations. Regardless of this, the migration of interface messages 
would make it easier to include their translations (see T273368 
<https://phabricator.wikimedia.org/T273368> and T273369 
<https://phabricator.wikimedia.org/T273369>).
  
  **Screenshots/mockups:**
  
  | F34076378: lexdata-en.png <https://phabricator.wikimedia.org/F34076378> | 
F34076381: lexdata-qqx.png <https://phabricator.wikimedia.org/F34076381> |
  |
  
  **Open questions:**
  
  - Should this section be migrated to the extension completely, or only 
partially, leaving some links not included by default?

TASK DETAIL
  https://phabricator.wikimedia.org/T273370

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, Mahir256, 
QZanden, LawExplorer, _jensen, rosalieper, Bodhisattwa, Scott_WUaS, 
Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T273369: Include MediaWiki:Lexicographical-data in the Wikibase Lexeme extension

2021-01-30 Thread abian 
abian created this task.
abian added projects: Wikidata, Wikidata Lexicographical data.

TASK DESCRIPTION
  **Problem:** We have **MediaWiki:Lexicographical-data 
<https://www.wikidata.org/wiki/MediaWiki:Lexicographical-data>** locally 
defined on Wikidata. This makes it difficult to translate the message, as each 
translation must be manually included on a subpage by an administrator, and 
forces external installations to do the same locally.
  
  **Screenshots/mockups:**
  
  | F34076378: lexdata-en.png <https://phabricator.wikimedia.org/F34076378> | 
F34076381: lexdata-qqx.png <https://phabricator.wikimedia.org/F34076381> |
  |
  
  **Acceptance criteria:**
  
  - The Wikibase Lexeme extension introduces the interface message 
MediaWiki:Lexicographical-data by default.
  - The default content of MediaWiki:Lexicographical-data in English is 
`Lexicographical data`.
  
  **Open questions:**
  
  - A name other than MediaWiki:Lexicographical-data could be defined for this 
message if appropriate.

TASK DETAIL
  https://phabricator.wikimedia.org/T273369

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, Mahir256, 
QZanden, LawExplorer, _jensen, rosalieper, Bodhisattwa, Scott_WUaS, 
Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T273368: Include MediaWiki:Randomlexeme in the Wikibase Lexeme extension

2021-01-30 Thread abian 
abian created this task.
abian added projects: Wikidata, Wikidata Lexicographical data.

TASK DESCRIPTION
  **Problem:** We have **MediaWiki:Randomlexeme 
<https://www.wikidata.org/wiki/MediaWiki:Randomlexeme>** locally defined on 
Wikidata. This makes it difficult to translate the message, as each translation 
must be manually included on a subpage by an administrator, and forces external 
installations to do the same locally.
  
  **Screenshots/mockups:**
  
  | F34076378: lexdata-en.png <https://phabricator.wikimedia.org/F34076378> | 
F34076381: lexdata-qqx.png <https://phabricator.wikimedia.org/F34076381> |
  |
  
  **Acceptance criteria:**
  
  - The Wikibase Lexeme extension introduces the interface message 
MediaWiki:Randomlexeme by default.
  - The default content of MediaWiki:Randomlexeme in English is `Random Lexeme`.
  
  **Open questions:**
  
  - The name of this message is based on that of MediaWiki:Randompage, but a 
different one could be defined.

TASK DETAIL
  https://phabricator.wikimedia.org/T273368

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, Mahir256, 
QZanden, LawExplorer, _jensen, rosalieper, Bodhisattwa, Scott_WUaS, 
Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T271079: Add "same language" constraint for lexicographical data properties

2021-01-04 Thread abian 
abian added a comment.


  Good idea. :D And also a similar constraint type for the lexical category?

TASK DETAIL
  https://phabricator.wikimedia.org/T271079

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, Nikki, Akuckartz, Nandana, Lahi, Gq86, Lucas_Werkmeister_WMDE, 
GoranSMilovanovic, Mahir256, QZanden, LawExplorer, _jensen, rosalieper, 
Agabi10, Bodhisattwa, Scott_WUaS, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T213803: [Tracking] Request for new constraint types

2021-01-04 Thread abian 
abian added a subtask: T271079: Add "same language" constraint for 
lexicographical data properties.

TASK DETAIL
  https://phabricator.wikimedia.org/T213803

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Aklapper, Lucas_Werkmeister_WMDE, Lydia_Pintscher, Lea_Lacroix_WMDE, 
Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, 
_jensen, rosalieper, Agabi10, Scott_WUaS, abian, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T271079: Add "same language" constraint for lexicographical data properties

2021-01-04 Thread abian 
abian added a parent task: T213803: [Tracking] Request for new constraint types.

TASK DETAIL
  https://phabricator.wikimedia.org/T271079

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Nikki, Akuckartz, Nandana, Lahi, Gq86, Lucas_Werkmeister_WMDE, 
GoranSMilovanovic, Mahir256, QZanden, LawExplorer, _jensen, rosalieper, 
Agabi10, Bodhisattwa, Scott_WUaS, abian, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T269724: Allow restricting constraints to certain entity types

2020-12-26 Thread abian 
abian added a comment.


  In T269724#6711904 <https://phabricator.wikimedia.org/T269724#6711904>, 
@Nikki wrote:
  
  > I can't take the credit for the task description, that's Lydia's work. :)
  
  What a shame, what a disappointmentā€¦
  
  > I don't think it would be a good idea to split this property. It serves 
exactly the same purpose in both places - to link to a file containing the 
pronunciation of a word - and multiple almost identical properties makes it 
harder for people to use the right one in the right place. It already took me a 
long time to stop accidentally using the "audio" property instead of 
"pronunciation audio".
  >
  > The property constraints themselves don't seem that complex to me. The main 
problem I have is that the way we model/describe them is quite abstract and 
technical and I can never remember exactly which properties/values I need to 
use. Most people should never need to touch property constraints though.
  
  Actually, only 27% of those active Wikidata users who decided to answer the 
survey on Property constraints (and who knew what Property constraints were) 
said that the system was "relatively easy" to use. Even considering only these 
users, by "complexity" I also mean the number of decisions the system requires 
us to consider.
  
  If the constraint system consisted only of adding or not adding a constraint 
per Property without qualifiers (only one constraint type available), there 
would only be one dichotomous decision to make for each Property, users would 
be aware of the two possible options and could spend time considering both to 
make the best decision. The number of decisions would be the number of 
Properties (~8260). This isn't a small number to begin with but can be 
addressed by all of us.
  
  If we had 25 constraint types without values or qualifiers (that is, the 
decision remains simply whether or not to add the constraint), there would be 
8260*25=206500 decisions to be made. Here efforts are concentrated on a 
minority of Properties and the constraint types that are remembered, so the 
error of omission is introduced, it's not known whether certain constraints are 
missing because they aren't applicable or because they haven't yet been 
considered, some of the cases considered when there was only one constraint 
type are no longer considered and each constraint type receives several (up to 
~25) times less attention on average. From this supersimplified scenario 
onwards, each qualifier that is possible to include and each value that needs 
to be specified causes a new combinatorial explosion in the number of decisions 
("complexity"), increases the number of omissions and forces high-impact 
decisions to receive less attention, as the features that are recalled or well 
specified and the features that have the greatest impact in each case don't 
necessarily coincide.
  
  To cover a single case or a small set of them, the number of possibilities 
this qualifier would introduce, which could be specified for any constraint 
type, would be disproportionate, including inconsistencies such as specifying a 
set of entity types that violate those of the //allowed entity types// 
constraint, even specifying the entity types for an //allowed entity types// 
constraint. Perhaps to solve the problem you indicate with the different 
Properties ("pronunciation audio for this Item" or "pronunciation audio for 
this Form", for example) we only need //allowed entity types// constraints to 
be taken into account in the web interface (Properties that are not applicable 
to an entity type shouldn't be suggested for that entity type). Also according 
to 
https://www.wikidata.org/wiki/Wikidata:2020_report_on_Property_constraints#allowed_entity_types:
  
  > This constraint type is the third with the highest proportion of mandatory 
constraints (48%), only after the Commons link and Property scope constraint 
types. Consistently, it has no constraints with the suggestion level and no 
exceptions. Widely applicable constraint types without exceptions, with a high 
proportion of mandatory constraints and with a clear and controlled set of 
parameters should be considered good candidates for becoming default Wikibase 
features.
  
  To reduce complexity for users (number of decisions they have to make), it 
would also be nice to address T244050 
<https://phabricator.wikimedia.org/T244050> and remove from our sight those 
constraint types that don't make sense considering the Property type.
  
  All this talk is just my opinion, but I wanted to explain what I meant by 
"complexity", because I recognize that it was very ambiguous. Don't stop 
implementing something just because it doesn't look promising to me if the 
arguments don't convince youā€¦

TASK DETAIL
  https://phabricator.wikime

[Wikidata-bugs] [Maniphest] T269724: Allow restricting constraints to certain entity types

2020-12-11 Thread abian 
abian added a comment.


  I understand the motivation (thanks to the fact that Nikki's tasks are much 
more interesting and better described than mine), :-)  but I believe we should 
strive to contain the complexity of the constraint system and, if possible, 
reduce the current complexity, which is quite high. The need that the example 
represents might not be recurrent and, for that case, I think we could have two 
Properties, one for Items and one for Forms, to better adjust the constraints 
(not only the one we're commenting on) and statements of each of them to their 
cases of use. I wouldn't find it a big problem if there were some similar 
statements on two different Properties, as they aren't expected to change 
frequently and they'll be used in different namespaces (so both shouldn't 
appear together or be read by the same software agents that might know about 
one Property but not about the other). Please don't hate me for this (hate me 
for something elseā€¦).

TASK DETAIL
  https://phabricator.wikimedia.org/T269724

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, Lydia_Pintscher, Lucas_Werkmeister_WMDE, Nikki, Aklapper, Akuckartz, 
Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, 
rosalieper, Agabi10, Scott_WUaS, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T229100: Links for feedback on protected Wikidata entities

2020-10-15 Thread abian 
abian added a comment.


  It would be great to have this available considering T254280 
<https://phabricator.wikimedia.org/T254280> and 
https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Administrator/MsynABot;
 if there are some setbacks or this is proving more difficult than it seemed, 
we can comment on it, change the acceptance criteria, ask on Wikidata for ideasā€¦

TASK DETAIL
  https://phabricator.wikimedia.org/T229100

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Charlie_WMDE, Bugreporter, Sjoerddebruin, Multichill, Lydia_Pintscher, 
MisterSynergy, abian, Aklapper, Akuckartz, darthmon_wmde, Nandana, Lahi, Gq86, 
GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, 
Jonas, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T254280: Semi-protecting all properties

2020-10-15 Thread abian 
abian added a comment.


  In T254280#6545624 <https://phabricator.wikimedia.org/T254280#6545624>, 
@Lydia_Pintscher wrote:
  
  > Is the page info just out of date? Does it get overwritten by 
namespace-wide protection and just doesn't reflect that?
  
  Luckily or unfortunately this happens on all wikis (also Wikipedia 
<https://es.wikipedia.org/w/index.php?title=M%C3%B3dulo:NF&action=info&uselang=en#Page_protection>)
 and all protected/semi-protected namespaces (also the MediaWiki namespace 
<https://www.wikidata.org/w/index.php?title=MediaWiki:Sp-contributions-footer&action=info#Page_protection>).
 The (dis?)information page only seems to take into account the individual 
protection status of the page.

TASK DETAIL
  https://phabricator.wikimedia.org/T254280

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Lucas_Werkmeister_WMDE, abian
Cc: ItamarWMDE, Bugreporter, Lucas_Werkmeister_WMDE, WMDE-leszek, abian, 
alanajjar, Ymblanter, Rehman, Fuzheado, Lydia_Pintscher, Jasper, Bencemac, 
Addshore, Aklapper, Mike_Peel, Akuckartz, Iflorez, darthmon_wmde, alaa_wmde, 
Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, 
rosalieper, Scott_WUaS, Jonas, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T226885: Set up an open-source bot in Toolforge to regularly semi-protect the most used Wikidata Items

2020-10-11 Thread abian 
abian added a comment.


  See 
https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Bot/MsynABot.

TASK DETAIL
  https://phabricator.wikimedia.org/T226885

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, Aklapper, Nintendofan885, Akuckartz, darthmon_wmde, Nandana, 
skpuneethumar, Zylc, 1978Gage2001, Lahi, Gq86, GoranSMilovanovic, DSquirrelGM, 
Jayprakash12345, Chicocvenancio, QZanden, Tbscho, LawExplorer, JJMC89, _jensen, 
rosalieper, Scott_WUaS, Wikidata-bugs, Jitrixis, aude, Gryllida, scfc, Mbch331, 
Krenair
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T226885: Set up an open-source bot in Toolforge to regularly semi-protect the most used Wikidata Items

2020-10-11 Thread abian 
abian updated the task description.

TASK DETAIL
  https://phabricator.wikimedia.org/T226885

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, Aklapper, Nintendofan885, Akuckartz, darthmon_wmde, Nandana, 
skpuneethumar, Zylc, 1978Gage2001, Lahi, Gq86, GoranSMilovanovic, DSquirrelGM, 
Jayprakash12345, Chicocvenancio, QZanden, Tbscho, LawExplorer, JJMC89, _jensen, 
rosalieper, Scott_WUaS, Wikidata-bugs, Jitrixis, aude, Gryllida, scfc, Mbch331, 
Krenair
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T229100: Links for feedback on protected Wikidata entities

2020-10-10 Thread abian 
abian added a parent task: T234976: feedback flows of Wikidata and the Wikibase 
ecosystem.

TASK DETAIL
  https://phabricator.wikimedia.org/T229100

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Charlie_WMDE, Bugreporter, Sjoerddebruin, Multichill, Lydia_Pintscher, 
MisterSynergy, abian, Aklapper, Akuckartz, darthmon_wmde, Nandana, Lahi, Gq86, 
GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, 
Jonas, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T234976: feedback flows of Wikidata and the Wikibase ecosystem

2020-10-10 Thread abian 
abian added a subtask: T229100: Links for feedback on protected Wikidata 
entities.

TASK DETAIL
  https://phabricator.wikimedia.org/T234976

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Hjfocs, Lydia_Pintscher, abian, Aklapper, Akuckartz, darthmon_wmde, 
Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, 
rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T234976: feedback flows of Wikidata and the Wikibase ecosystem

2020-10-10 Thread abian 
abian updated the task description.

TASK DETAIL
  https://phabricator.wikimedia.org/T234976

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Hjfocs, Lydia_Pintscher, abian, Aklapper, Akuckartz, darthmon_wmde, 
Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, 
rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T254280: Semi-protecting all properties

2020-10-09 Thread abian 
abian added a comment.


  In my case, do I have to do anything with the patch? I always add reviewers 
arbitrarily, more or less according to the suggestions of the interface; should 
I add more/other reviewers, or change anything else?

TASK DETAIL
  https://phabricator.wikimedia.org/T254280

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: ItamarWMDE, Bugreporter, Lucas_Werkmeister_WMDE, WMDE-leszek, abian, 
alanajjar, Ymblanter, Rehman, Fuzheado, Lydia_Pintscher, Jasper, Bencemac, 
Addshore, Aklapper, Mike_Peel, Alter-paule, Beast1978, Un1tY, Akuckartz, 
Hook696, Iflorez, darthmon_wmde, Kent7301, alaa_wmde, joker88john, CucyNoiD, 
Nandana, Gaboe420, Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, 
GoranSMilovanovic, QZanden, LawExplorer, Lewizho99, Maathavan, _jensen, 
rosalieper, Scott_WUaS, Jonas, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T258354: remove noratelimit from bot group for Wikidata

2020-10-08 Thread abian 
abian added a comment.


  In T258354#6528169 <https://phabricator.wikimedia.org/T258354#6528169>, 
@Urbanecm wrote:
  
  > Ignore rate limits? No rate limit? Fast editors? Fast users? I don't think 
we should go for superbot, because there are use cases for noratelimit too, 
such as creating accounts at outreach events.
  
  According to what I've just checked, in the history of Wikidata the 
`accountcreator` flag has been granted four times, and on none of those 
occasions has it been used for anything, the users didn't create any account 
with it. If we anticipate that such a need may arise in the future, we could 
introduce the event coordinator 
<https://en.wikipedia.org/wiki/Wikipedia:Event_coordinator> group, although for 
now such a need doesn't seem to exist.
  
  I would prefer it to be understood that belonging to this group is an 
undesirable exception, and I wouldn't like users who don't belong to it (almost 
everyone) to be considered handicapped or punished because they're categorised 
as "slow" or "limited", as opposed to "fast" users; in fact, all users can 
continue to edit at a high rate. Other names as mediocre as "superbot" come to 
mind, from more serious to more irreverent: structural user/account, greedy 
user/account, exhausting/draining user/account, speed(ing) offender, 
freeloader, racehorse (racing goat <https://en.wikipedia.org/wiki/Goat_racing>? 
šŸ¤Ø)ā€¦

TASK DETAIL
  https://phabricator.wikimedia.org/T258354

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, MarcoAurelio, Urbanecm, ItamarWMDE, Lucas_Werkmeister_WMDE, 
Hazard-SJ, pywikibot-bugs-list, Multichill, Rschen7754, Pasleim, 
matej_suchanek, tfmorris, Ladsgroup, Mike_Peel, Mohammed_Sadat_WMDE, 
Dipsacus_fullonum, Bugreporter, MisterSynergy, Lea_Lacroix_WMDE, Aklapper, 
Lydia_Pintscher, JohnsonLee01, SHEKH, Dijkstra, Alter-paule, Beast1978, Un1tY, 
Khutuck, Akuckartz, Zkhalido, Hook696, Iflorez, darthmon_wmde, Kent7301, 
alaa_wmde, joker88john, Viztor, CucyNoiD, Nandana, Wenyi, Gaboe420, 
Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, GoranSMilovanovic, 
QZanden, Tbscho, MayS, LawExplorer, Lewizho99, Mdupont, JJMC89, Maathavan, 
Dvorapa, _jensen, rosalieper, Altostratus, Avicennasis, Scott_WUaS, Jonas, 
mys_721tx, Wikidata-bugs, aude, jayvdb, Ricordisamoa, Masti, Alchimista, 
Mbch331, Rxy
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T254280: Semi-protecting all properties

2020-10-07 Thread abian 
abian added a comment.


  If it's about testing what it's like to have the Property namespace with the 
permissions of the actual Wikidata, we could also set the autoconfirmed status 
on Test Wikidata to, for example, zero days and one edit, or zero edits.

TASK DETAIL
  https://phabricator.wikimedia.org/T254280

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Lucas_Werkmeister_WMDE, WMDE-leszek, abian, alanajjar, Ymblanter, Rehman, 
Fuzheado, Lydia_Pintscher, Jasper, Bencemac, Addshore, Aklapper, Mike_Peel, 
Alter-paule, Beast1978, Un1tY, Akuckartz, Hook696, Iflorez, darthmon_wmde, 
Kent7301, alaa_wmde, joker88john, CucyNoiD, Nandana, Gaboe420, Giuliamocci, 
Cpaulf30, Lahi, Gq86, Af420, Bsandipan, GoranSMilovanovic, QZanden, 
LawExplorer, Lewizho99, Maathavan, _jensen, rosalieper, Scott_WUaS, Jonas, 
Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T127213: [Bug] Merging doesn't always create a redirect

2020-10-07 Thread abian 
abian added a comment.


  This is still happening frequently and has consequences on the project.
  
  Some cases that I have recently found by chance:
  
  - On 6 October 2020 Wowo2008 partially merged Q1622041 
<https://www.wikidata.org/w/index.php?title=Q1622041&type=revision&diff=1287412614&oldid=1286925802>
 into Q7157841 
<https://www.wikidata.org/w/index.php?title=Q7157841&type=revision&diff=1287412615&oldid=1225524796>.
 Apparently, the user didn't notice.
  - On 18 September 2020 Siam2019 partially merged Q9761807 
<https://www.wikidata.org/w/index.php?title=Q9761807&type=revision&diff=1278863041&oldid=835470022>
 into Q7006090 
<https://www.wikidata.org/w/index.php?title=Q7006090&type=revision&diff=1278863043&oldid=1276246862>.
 Apparently, the user didn't notice.
  - On 2 September 2020 Š”Š¾Š»Š±Š¾ŠÆщŠµŃ€ partially merged Q9891392 
<https://www.wikidata.org/w/index.php?title=Q9891392&type=revision&diff=1270066914&oldid=836107673>
 into Q9909061 
<https://www.wikidata.org/w/index.php?title=Q9909061&type=revision&diff=1270067322&oldid=1015920764>
 (including a link to merge.js 
<https://www.wikidata.org/wiki/MediaWiki:Gadget-Merge.js>). Apparently, the 
user didn't notice.
  - On 19 August 2020 Philemonbaucis partially merged Q8619302 
<https://www.wikidata.org/w/index.php?title=Q8619302&type=revision&diff=1260910896&oldid=829258552>
 into Q30788505 
<https://www.wikidata.org/w/index.php?title=Q30788505&type=revision&diff=1260910897&oldid=1110052441>.
 Apparently, the user didn't notice.
  - On 9 July 2020 Gotogo partially merged Q4783136 
<https://www.wikidata.org/w/index.php?title=Q4783136&type=revision&diff=1227968274&oldid=1003830436>
 into Q22426445 
<https://www.wikidata.org/w/index.php?title=Q22426445&type=revision&diff=1227968276&oldid=980362207>.
 Apparently, the user didn't notice.

TASK DETAIL
  https://phabricator.wikimedia.org/T127213

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: daniel, Sjoerddebruin, abian, XXN, PokestarFan, MisterSynergy, Mahir256, 
Liuxinyu970226, Addshore, Pasleim, Lydia_Pintscher, Esc3300, Magnus, 
matej_suchanek, hoo, Mbch331, Aklapper, Nikki, StudiesWorld, Akuckartz, 
darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, 
_jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T260737: Improve the editing reason labels and descriptions to be more precise

2020-10-06 Thread abian 
abian added a comment.


  In T260737#6520630 <https://phabricator.wikimedia.org/T260737#6520630>, 
@danshick-wmde wrote:
  
  > Howdy, I'm the technical writer in question.
  
  Hi, technical writer Dan! :-)
  
  > In light of this observation and the foregoing discussion, I propose the 
following wording:
  >
  >> Please select the type of edit you are making:
  >> I am supplying updated information (archive previous value)
  >> I am correcting an incorrect value (delete previous value)
  
  The motivation for this task is that users are clear about and make the right 
choices in the following two cases:
  
  1. //I'm completing or making more precise the original value, which I 
already considered correct but less detailed// (e.g. museum ā†’ history museum; 
cancer ā†’ prostate cancer; Berlin ā†’ Friedrichshain).
  2. //I know the original value is not applicable today but I cannot determine 
if it was correct at some point in the past or not// (e.g. there was a 
population figure without references and I want to provide the one I just found 
on the council's website, which is different).
  
  Case 2 seems to be solved with your new wording, which no longer states that 
the previous value was necessarily correct at some point: "I am supplying 
updated information (archive previous value)".
  
  On the contrary, case 1 wouldn't be solved yet, as it's still claimed that 
the previous value was incorrect ("I am correcting an incorrect value") when 
it's not considered so ("completing or making more precise the original value, 
which I already considered correct"). I'm sure that the clarifications in 
brackets will be positive for experienced users ("archive previous value", 
"delete previous value"), but unfortunately I don't think they help users who 
don't know Wikidata's policies, i.e. when to delete/archive, to solve case 1.

TASK DETAIL
  https://phabricator.wikimedia.org/T260737

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: danshick-wmde, Lea_Lacroix_WMDE, Charlie_WMDE, abian, Aklapper, Akuckartz, 
darthmon_wmde, Michael, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, 
LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, 
Lydia_Pintscher, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T264626: Enable ORES in Wikidata's Lexeme namespace

2020-10-05 Thread abian 
abian created this task.
abian added projects: Wikidata, ORES, Wikidata Lexicographical data.
Restricted Application added a project: Machine Learning Platform.

TASK DESCRIPTION
  This task is just a reminder that ORES is not currently configured in 
Wikidata's Lexeme namespace, for when those who can estimate its feasibility 
and its cost (computational, memory, working time, etc.) find it worthwhile to 
start the process.

TASK DETAIL
  https://phabricator.wikimedia.org/T264626

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, calbon, lmata, Akuckartz, darthmon_wmde, Nandana, Lahi, Gq86, 
Xinbenlv, Vacio, GoranSMilovanovic, Fz-29, Mahir256, QZanden, LawExplorer, 
_jensen, rosalieper, Mkdw, Scott_WUaS, notconfusing, Wikidata-bugs, aude, 
Alchimista, Mbch331, Rxy
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T264542: With monolingual text, the language pop-up covers the value field

2020-10-04 Thread abian 
abian created this task.
abian added a project: Wikidata.
Restricted Application added a subscriber: Aklapper.

TASK DESCRIPTION
  **Problem:** On the web page of a Wikibase Item with a Property of the 
monolingual text data type, the pop-up for defining the language does not go 
down as the value field grows, so it covers the new text lines.
  
  **Screencast (current behaviour):**
  
  F32373316: immovable-language(1).gif 
<https://phabricator.wikimedia.org/F32373316>

TASK DETAIL
  https://phabricator.wikimedia.org/T264542

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Aklapper, abian, Akuckartz, darthmon_wmde, Nandana, Lahi, Gq86, 
GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, 
Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T264537: MusicalNotation data type is missing from Wikibase's ontology-1.0.owl

2020-10-04 Thread abian 
abian created this task.
abian added projects: Wikidata, MediaWiki-extensions-Score.
Restricted Application added a subscriber: Aklapper.

TASK DESCRIPTION
  **Problem:** The data type MusicalNotation (see 
Special:ListDatatypes#musical-notation 
<https://www.wikidata.org/wiki/Special:ListDatatypes#musical-notation>) is not 
defined in the ontology-1.0.owl <http://wikiba.se/ontology-1.0.owl> file.
  
  **Acceptance criteria:**
  
  - `http://wikiba.se/ontology#MusicalNotation` is defined in Wikibase's 
ontology file.

TASK DETAIL
  https://phabricator.wikimedia.org/T264537

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Aklapper, abian, Akuckartz, darthmon_wmde, Nandana, Lahi, Gq86, 
GoranSMilovanovic, Mahir256, QZanden, LawExplorer, Samuele2002, _jensen, 
rosalieper, Scott_WUaS, mb, Wikidata-bugs, aude, Ebe123, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T264535: duplicated lines in all Wikidata entities with statements in LD formats

2020-10-04 Thread abian 
abian created this task.
abian added a project: Wikidata.
Restricted Application added a subscriber: Aklapper.

TASK DESCRIPTION
  **Problem:** The lineā€¦
  
http://wikiba.se/ontology#Property"/>
  
  ā€¦ is duplicated in all the blocks `rdf:Description` that describe statements 
of Items, Properties, Lexemes, Forms and Senses in RDF (*.rdf). Analogous lines 
are also duplicated in, at least, Notation3 (*.n3), Turtle (*.ttl), N-Triples 
(*.nt) and JSON-LD (*.jsonld).
  
  **Examples:**
  
  - Item Q42 <https://www.wikidata.org/wiki/Special:EntityData/Q42.rdf> in RDF, 
first duplication out of 241 (the line appears 482 times):
  
http://www.wikidata.org/entity/P31";>
http://wikiba.se/ontology#Property"/>
http://wikiba.se/ontology#Property"/>
http://wikiba.se/ontology#WikibaseItem"/>
[ā€¦]

  
  
  
  - Property P101 <https://www.wikidata.org/wiki/Special:EntityData/P101.n3> in 
Notation3:
  
wd:P101 a wikibase:Property,
wikibase:Property ;
  
  
  
  - Lexeme L2 <https://www.wikidata.org/wiki/Special:EntityData/L2.ttl> in 
Turtle:
  
wd:P5831 a wikibase:Property,
wikibase:Property ;
  
  
  
  - Form L2-F1 <https://www.wikidata.org/wiki/Special:EntityData/L2-F1.nt> in 
N-Triples:
  
<http://www.wikidata.org/entity/P898> 
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type> 
<http://wikiba.se/ontology#Property> .
<http://www.wikidata.org/entity/P898> 
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type> 
<http://wikiba.se/ontology#Property> .
  
  
  
  - Sense L2-S1 <https://www.wikidata.org/wiki/Special:EntityData/L2-S1.jsonld> 
in JSON-LD:
  
"@type": [
"wikibase:Property",
"wikibase:Property"
],
  
  **Acceptance criteria:**
  
  - The content `http://wikiba.se/ontology#Property"/>` 
in RDF, or its analogous in other formats, is no longer unnecessarily 
duplicated.

TASK DETAIL
  https://phabricator.wikimedia.org/T264535

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Aklapper, abian, Akuckartz, darthmon_wmde, Nandana, Lahi, Gq86, 
GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, 
Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T264499: Incomplete merging of Items

2020-10-03 Thread abian 
abian created this task.
abian added a project: Wikidata.
Restricted Application added a subscriber: Aklapper.

TASK DESCRIPTION
  **Problem:** Sometimes, when a user tries to merge two Items, the two 
corresponding edits, one on the source Item and one on the target Item, are 
saved with some of the changes, but not all of them. The conflicting labels, 
descriptions or aliases are left behind, and the corresponding redirect is not 
created. Often the responsible users don't notice the problem, so they leave 
the Items in that state. At the moment we don't know when the problem occurs, 
but we do know that merge.js 
<https://www.wikidata.org/wiki/MediaWiki:Gadget-Merge.js> was used at least in 
one case.
  
  **Examples:**
  
  - On 9 July 2020 Gotogo partially merged Q4783136 
<https://www.wikidata.org/w/index.php?title=Q4783136&type=revision&diff=1227968274&oldid=1003830436>
 into Q22426445 
<https://www.wikidata.org/w/index.php?title=Q22426445&type=revision&diff=1227968276&oldid=980362207>.
 Apparently, the user didn't notice.
  - On 19 August 2020 Philemonbaucis partially merged Q8619302 
<https://www.wikidata.org/w/index.php?title=Q8619302&type=revision&diff=1260910896&oldid=829258552>
 into Q30788505 
<https://www.wikidata.org/w/index.php?title=Q30788505&type=revision&diff=1260910897&oldid=1110052441>.
 Apparently, the user didn't notice.
  - On 2 September 2020 Š”Š¾Š»Š±Š¾ŠÆщŠµŃ€ partially merged Q9891392 
<https://www.wikidata.org/w/index.php?title=Q9891392&type=revision&diff=1270066914&oldid=836107673>
 into Q9909061 
<https://www.wikidata.org/w/index.php?title=Q9909061&type=revision&diff=1270067322&oldid=1015920764>
 (including a link to merge.js 
<https://www.wikidata.org/wiki/MediaWiki:Gadget-Merge.js>). Apparently, the 
user didn't notice.
  - On 18 September 2020 Siam2019 partially merged Q9761807 
<https://www.wikidata.org/w/index.php?title=Q9761807&type=revision&diff=1278863041&oldid=835470022>
 into Q7006090 
<https://www.wikidata.org/w/index.php?title=Q7006090&type=revision&diff=1278863043&oldid=1276246862>.
 Apparently, the user didn't notice.

TASK DETAIL
  https://phabricator.wikimedia.org/T264499

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Aklapper, abian, Akuckartz, darthmon_wmde, Nandana, Lahi, Gq86, 
GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, 
Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T254280: Potentially semi-protecting all properties: best approach?

2020-10-02 Thread abian 
abian added a comment.


  According to the resolution of Wikidata:Requests for comment/General semi 
protection for all property pages 
<https://www.wikidata.org/?diff=1285653229&oldid=1284596132> today:
  
  > The grace period proposal has been opposed. Thus, all property pages must 
be semi-protected.--[[User:Ymblanter|Ymblanter]] ([[User talk:Ymblanter|{{int:Talkpagelinktext}}]]) 20:51, 2 October 2020 
(UTC)
  
  So the solution is `$wgNamespaceProtection`.

TASK DETAIL
  https://phabricator.wikimedia.org/T254280

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, alanajjar, Ymblanter, Rehman, Fuzheado, Lydia_Pintscher, Jasper, 
Bencemac, Addshore, Aklapper, Mike_Peel, Akuckartz, darthmon_wmde, Nandana, 
Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, 
Scott_WUaS, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T260728: suggestions to improve Wikidata Bridge dialog when direct editing is not supported

2020-10-02 Thread abian 
abian added a comment.


  Thank you, Charlie! I've updated the description.

TASK DETAIL
  https://phabricator.wikimedia.org/T260728

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Lea_Lacroix_WMDE, Vriullop, Charlie_WMDE, Aklapper, abian, Akuckartz, 
darthmon_wmde, Michael, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, 
LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, 
Lydia_Pintscher, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T260728: suggestions to improve Wikidata Bridge dialog when direct editing is not supported

2020-10-02 Thread abian 
abian renamed this task from "too wordy Wikidata Bridge dialog when direct 
editing is not supported" to "suggestions to improve Wikidata Bridge dialog 
when direct editing is not supported".
abian updated the task description.

TASK DETAIL
  https://phabricator.wikimedia.org/T260728

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Lea_Lacroix_WMDE, Vriullop, Charlie_WMDE, Aklapper, abian, Akuckartz, 
darthmon_wmde, Michael, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, 
LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, 
Lydia_Pintscher, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T260728: suggestions to improve Wikidata Bridge dialog when direct editing is not supported

2020-10-02 Thread abian 
abian added a subtask: T261103: Bridge interface translations: datatype names 
in italic and untranslated.

TASK DETAIL
  https://phabricator.wikimedia.org/T260728

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Lea_Lacroix_WMDE, Vriullop, Charlie_WMDE, Aklapper, abian, Akuckartz, 
darthmon_wmde, Michael, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, 
LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, 
Lydia_Pintscher, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T261103: Bridge interface translations: datatype names in italic and untranslated

2020-10-02 Thread abian 
abian added a parent task: T260728: suggestions to improve Wikidata Bridge 
dialog when direct editing is not supported.

TASK DETAIL
  https://phabricator.wikimedia.org/T261103

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Charlie_WMDE, Lucas_Werkmeister_WMDE, Vriullop, Incabell, Lydia_Pintscher, 
Lea_Lacroix_WMDE, Aklapper, Akuckartz, darthmon_wmde, Michael, Nandana, Lahi, 
Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, 
abian, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T258354: create new rate-limited bot group for Wikidata

2020-10-01 Thread abian 
abian added a comment.


  I like this solution. The only right provided by the flag of account creator 
is `noratelimit`, and right now no user account has this flag, so we can freely 
change the group/flag name with MediaWiki:Group-accountcreator 
<https://www.wikidata.org/wiki/MediaWiki:Group-accountcreator> and 
MediaWiki:Group-accountcreator-member 
<https://www.wikidata.org/wiki/MediaWiki:Group-accountcreator-member> to fit 
its future purpose on Wikidata.
  
  What should this group/flag be called? //Superbot//? Something more creative? 
Ideally, the name shouldn't suggest that it's redundant with the bot 
group/flag, but additional.

TASK DETAIL
  https://phabricator.wikimedia.org/T258354

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, MarcoAurelio, Urbanecm, ItamarWMDE, Lucas_Werkmeister_WMDE, 
Hazard-SJ, pywikibot-bugs-list, Multichill, Rschen7754, Pasleim, 
matej_suchanek, tfmorris, Ladsgroup, Mike_Peel, Mohammed_Sadat_WMDE, 
Dipsacus_fullonum, Bugreporter, MisterSynergy, Lea_Lacroix_WMDE, Aklapper, 
Lydia_Pintscher, JohnsonLee01, SHEKH, Dijkstra, Alter-paule, Beast1978, Un1tY, 
Khutuck, Akuckartz, Zkhalido, Hook696, Iflorez, darthmon_wmde, Kent7301, 
alaa_wmde, joker88john, Viztor, CucyNoiD, Nandana, Wenyi, Gaboe420, 
Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, GoranSMilovanovic, 
QZanden, Tbscho, MayS, LawExplorer, Lewizho99, Mdupont, JJMC89, Maathavan, 
Dvorapa, _jensen, rosalieper, Altostratus, Avicennasis, Scott_WUaS, Jonas, 
mys_721tx, Wikidata-bugs, aude, jayvdb, Ricordisamoa, Masti, Alchimista, 
Mbch331, Rxy
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T195226: Precision issues with diff-within-range constraint in Wikidata

2020-09-30 Thread abian 
abian removed a parent task: T168379: Deal with precision in ā€œrangeā€, 
ā€œdifference within rangeā€ and "contemporary" constraints.

TASK DETAIL
  https://phabricator.wikimedia.org/T195226

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Aklapper, Lucas_Werkmeister_WMDE, abian, Akuckartz, darthmon_wmde, Nandana, 
Lahi, Gq86, GoranSMilovanovic, QZanden, merbst, LawExplorer, _jensen, 
rosalieper, Agabi10, Scott_WUaS, Jonas, Wikidata-bugs, aude, Lydia_Pintscher, 
Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T168379: Deal with precision in ā€œrangeā€, ā€œdifference within rangeā€ and "contemporary" constraints

2020-09-30 Thread abian 
abian removed a subtask: T195226: Precision issues with diff-within-range 
constraint in Wikidata.

TASK DETAIL
  https://phabricator.wikimedia.org/T168379

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Epidosis, abian, Tacsipacsi, doctaxon, Lydia_Pintscher, Aklapper, 
Ivan_A_Krestinin, Lucas_Werkmeister_WMDE, Akuckartz, darthmon_wmde, Nandana, 
Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, 
Agabi10, Scott_WUaS, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T226883: Semi-protection of very used Wikidata Items

2020-09-30 Thread abian 
abian closed subtask T226882: Generate regularly the list of unprotected and 
very used Wikidata Items as "Declined".

TASK DETAIL
  https://phabricator.wikimedia.org/T226883

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: MisterSynergy, abian, Aklapper, Akuckartz, darthmon_wmde, Nandana, Lahi, 
Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, 
Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T226882: Generate regularly the list of unprotected and very used Wikidata Items

2020-09-30 Thread abian 
abian closed this task as "Declined".
abian added a comment.


  We have a regularly generated list in CSV format that will meet this 
objective. :D

TASK DETAIL
  https://phabricator.wikimedia.org/T226882

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Aklapper, abian, Akuckartz, darthmon_wmde, Nandana, Lahi, Gq86, 
GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, 
Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T263867: Wikibase's ontology-1.0.owl has the label "referenceValue" repeated

2020-09-30 Thread abian 
abian closed this task as "Resolved".

TASK DETAIL
  https://phabricator.wikimedia.org/T263867

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Lydia_Pintscher, danshick-wmde, abian, Aklapper, Alter-paule, Beast1978, 
Un1tY, Akuckartz, Hook696, darthmon_wmde, Kent7301, joker88john, CucyNoiD, 
Nandana, Gaboe420, Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, 
GoranSMilovanovic, QZanden, LawExplorer, Lewizho99, Maathavan, _jensen, 
rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T263867: Wikibase's ontology-1.0.owl has the label "referenceValue" repeated

2020-09-28 Thread abian 
abian added a comment.


  I know three ontology (OWL) files, all independently edited (which is not 
good):
  
  1. https://wikiba.se/ontology-1.0.owl
  2. 
https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/WikibaseLexeme/+/refs/heads/master/docs/ontology.owl
  3. 
https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Wikibase/+/refs/heads/master/docs/ontology.owl
  
  [1] manually combines [2] and [3].
  [2] imports [1] via `http://wikiba.se/ontology#"; 
/>` (line 22 
<https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/WikibaseLexeme/+/refs/heads/master/docs/ontology.owl#22>).
  
  The important file is [1], and I really don't know the applications of [2] 
and [3], but they make maintenance tedious.

TASK DETAIL
  https://phabricator.wikimedia.org/T263867

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Lydia_Pintscher, danshick-wmde, abian, Aklapper, Alter-paule, Beast1978, 
Un1tY, Akuckartz, Hook696, darthmon_wmde, Kent7301, joker88john, CucyNoiD, 
Nandana, Gaboe420, Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, 
GoranSMilovanovic, QZanden, LawExplorer, Lewizho99, Maathavan, _jensen, 
rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T263867: Wikibase's ontology-1.0.owl has the label "referenceValue" repeated

2020-09-25 Thread abian 
abian added a comment.


  Pull request for wikiba.se: https://github.com/wmde/wikiba.se/pull/14.

TASK DETAIL
  https://phabricator.wikimedia.org/T263867

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, Aklapper, Alter-paule, Beast1978, Un1tY, Akuckartz, Hook696, 
darthmon_wmde, Kent7301, joker88john, CucyNoiD, Nandana, Gaboe420, Giuliamocci, 
Cpaulf30, Lahi, Gq86, Af420, Bsandipan, GoranSMilovanovic, QZanden, 
LawExplorer, Lewizho99, Maathavan, _jensen, rosalieper, Scott_WUaS, 
Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T263867: Wikibase's ontology-1.0.owl has the label "referenceValue" repeated

2020-09-25 Thread abian 
abian created this task.
abian added a project: Wikidata.
Restricted Application added a subscriber: Aklapper.

TASK DESCRIPTION
  Lines 310-311 of https://wikiba.se/ontology-1.0.owl are:
  

referenceValue
  
  The label "referenceValue" is already defined on line 305 and, for 
consistency, this should be "referenceValueNormalized":
  

referenceValueNormalized

TASK DETAIL
  https://phabricator.wikimedia.org/T263867

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, Aklapper, Akuckartz, darthmon_wmde, Nandana, Lahi, Gq86, 
GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, 
Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T263435: `content was: ""` (empty string) when deleting Lexemes

2020-09-21 Thread abian 
abian created this task.
abian added projects: Wikidata Lexicographical data, Wikidata.

TASK DESCRIPTION
  **Problem:** When deleting a Lexeme, it is indicated that the content was an 
empty string (`""`). This prevents users from identifying what the Lexeme was 
about before it was deleted.
  
  **Acceptance criteria:**
  
  - `content was: "" [ā€¦]`

TASK DETAIL
  https://phabricator.wikimedia.org/T263435

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, Akuckartz, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, 
Mahir256, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, 
aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T263360: Newcomers do not understand the difference between Item and Lexeme when creating an entity

2020-09-20 Thread abian 
abian updated the task description.

TASK DETAIL
  https://phabricator.wikimedia.org/T263360

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Lydia_Pintscher, abian, Akuckartz, darthmon_wmde, Nandana, Lahi, Gq86, 
GoranSMilovanovic, Mahir256, QZanden, LawExplorer, _jensen, rosalieper, 
Scott_WUaS, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T96040: Wikibase special pages (tracking)

2020-09-20 Thread abian 
abian added a subtask: T195446: [Story] Prefil language/lexical category on 
Special:NewLexeme via URL parameter.

TASK DETAIL
  https://phabricator.wikimedia.org/T96040

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: PokestarFan, Luke081515, Liuxinyu970226, aude, Aklapper, Akuckartz, 
darthmon_wmde, Nickleh, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, 
QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T195446: [Story] Prefil language/lexical category on Special:NewLexeme via URL parameter

2020-09-20 Thread abian 
abian added a parent task: T96040: Wikibase special pages (tracking).

TASK DETAIL
  https://phabricator.wikimedia.org/T195446

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Aklapper, Liuxinyu970226, abian, VIGNERON, Lydia_Pintscher, 
Lea_Lacroix_WMDE, Akuckartz, darthmon_wmde, Dinadineke, DannyS712, Nandana, 
tabish.shaikh91, Lahi, Gq86, GoranSMilovanovic, Soteriaspace, Jayprakash12345, 
JakeTheDeveloper, Mahir256, QZanden, merbst, LawExplorer, _jensen, rosalieper, 
Scott_WUaS, Wikidata-bugs, aude, TheDJ, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T255720: Error message when trying to create duplicate item doesn't contain link to item that would be duplicated

2020-09-20 Thread abian 
abian added a parent task: T96040: Wikibase special pages (tracking).

TASK DETAIL
  https://phabricator.wikimedia.org/T255720

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Moebeus, jhsoby, Aklapper, Akuckartz, darthmon_wmde, Nandana, lucamauri, 
Lahi, Gq86, GoranSMilovanovic, Jayprakash12345, QZanden, LawExplorer, _jensen, 
rosalieper, Scott_WUaS, Jonas, Wong128hk, Wikidata-bugs, aude, Lydia_Pintscher, 
Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T96040: Wikibase special pages (tracking)

2020-09-20 Thread abian 
abian added a subtask: T255720: Error message when trying to create duplicate 
item doesn't contain link to item that would be duplicated.

TASK DETAIL
  https://phabricator.wikimedia.org/T96040

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: PokestarFan, Luke081515, Liuxinyu970226, aude, Aklapper, Akuckartz, 
darthmon_wmde, Nickleh, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, 
QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T96040: Wikibase special pages (tracking)

2020-09-20 Thread abian 
abian added a subtask: T190761: Language selector on Special:NewItem matches 
only language code, not language name.

TASK DETAIL
  https://phabricator.wikimedia.org/T96040

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: PokestarFan, Luke081515, Liuxinyu970226, aude, Aklapper, Akuckartz, 
darthmon_wmde, Nickleh, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, 
QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T190761: Language selector on Special:NewItem matches only language code, not language name

2020-09-20 Thread abian 
abian added a parent task: T96040: Wikibase special pages (tracking).

TASK DETAIL
  https://phabricator.wikimedia.org/T190761

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Lea_Lacroix_WMDE, thiemowmde, Aklapper, hoo, Akuckartz, darthmon_wmde, 
Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, 
_jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T96040: Wikibase special pages (tracking)

2020-09-20 Thread abian 
abian added a subtask: T219499: [Problem] `Special:SetAliases`, 
`Special:NewItem` and `Special:NewProperty` separates aliases with | character 
but have no way to make a | part of one alias' text.

TASK DETAIL
  https://phabricator.wikimedia.org/T96040

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: PokestarFan, Luke081515, Liuxinyu970226, aude, Aklapper, Akuckartz, 
darthmon_wmde, Nickleh, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, 
QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T219499: [Problem] `Special:SetAliases`, `Special:NewItem` and `Special:NewProperty` separates aliases with | character but have no way to make a | part of one alias' text

2020-09-20 Thread abian 
abian added a parent task: T96040: Wikibase special pages (tracking).

TASK DETAIL
  https://phabricator.wikimedia.org/T219499

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: sarhan.alaa, Lydia_Pintscher, alaa_wmde, Lea_Lacroix_WMDE, thiemowmde, 
Greta_Doci_WMDE, Tarrow, Addshore, Aklapper, Akuckartz, darthmon_wmde, Nandana, 
Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, 
Scott_WUaS, Jonas, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T195415: Special:NewItem - fields direction should be defined according to the language

2020-09-20 Thread abian 
abian added a parent task: T96040: Wikibase special pages (tracking).

TASK DETAIL
  https://phabricator.wikimedia.org/T195415

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: eranroz, abian
Cc: Aklapper, gerritbot, Ladsgroup, Amire80, eranroz, Akuckartz, darthmon_wmde, 
Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, 
_jensen, rosalieper, Scott_WUaS, Srdjan, MuhammadShuaib, LNDDYL, Psychoslave, 
Wikidata-bugs, aude, Huji, Gryllida, Shizhao, Arrbee, Mbch331, Jay8g
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T96040: Wikibase special pages (tracking)

2020-09-20 Thread abian 
abian added a subtask: T195415: Special:NewItem - fields direction should be 
defined according to the language.

TASK DETAIL
  https://phabricator.wikimedia.org/T96040

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: PokestarFan, Luke081515, Liuxinyu970226, aude, Aklapper, Akuckartz, 
darthmon_wmde, Nickleh, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, 
QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T96040: Wikibase special pages (tracking)

2020-09-20 Thread abian 
abian added a subtask: T263360: Newcomers do not understand the difference 
between Item and Lexeme when creating an entity.

TASK DETAIL
  https://phabricator.wikimedia.org/T96040

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: PokestarFan, Luke081515, Liuxinyu970226, aude, Aklapper, Akuckartz, 
darthmon_wmde, Nickleh, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, 
QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T263360: Newcomers do not understand the difference between Item and Lexeme when creating an entity

2020-09-20 Thread abian 
abian added a parent task: T96040: Wikibase special pages (tracking).

TASK DETAIL
  https://phabricator.wikimedia.org/T263360

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Lydia_Pintscher, abian, Akuckartz, darthmon_wmde, Nandana, Lahi, Gq86, 
GoranSMilovanovic, Mahir256, QZanden, LawExplorer, _jensen, rosalieper, 
Scott_WUaS, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T96040: Wikibase special pages (tracking)

2020-09-20 Thread abian 
abian added a subtask: T214307: Clean up input placeholders on NewEntity pages 
(Special:NewItem, Special:NewProperty, ā€¦).

TASK DETAIL
  https://phabricator.wikimedia.org/T96040

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: PokestarFan, Luke081515, Liuxinyu970226, aude, Aklapper, Akuckartz, 
darthmon_wmde, Nickleh, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, 
QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T214307: Clean up input placeholders on NewEntity pages (Special:NewItem, Special:NewProperty, ā€¦)

2020-09-20 Thread abian 
abian added a parent task: T96040: Wikibase special pages (tracking).

TASK DETAIL
  https://phabricator.wikimedia.org/T214307

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Aklapper, Lucas_Werkmeister_WMDE, Akuckartz, darthmon_wmde, Nandana, Lahi, 
Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, 
Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T263360: Newcomers do not understand the difference between Item and Lexeme when creating an entity

2020-09-20 Thread abian 
abian created this task.
abian added projects: Wikidata Lexicographical data, Wikidata.

TASK DESCRIPTION
  **Problem:** Newcomers to Wikidata don't know what an "Item" or a "Lexeme" is 
and don't understand the difference between both. This is not a problem with 
visible consequences until they want to create an entity and need to choose 
between "Create a new Item" (Special:NewItem) and "Create a new Lexeme" 
(Special:NewLexeme), when they end up creating an entity of the wrong type. The 
introductory texts on both special pages are proving insufficient to understand 
the differences and it is well known that many users do not read those texts. 
This can be confirmed by the fact that some users, being initially on the right 
special page, access the other page through the link in the introductory text 
and end up creating an entity of the wrong type, and also by the high 
percentage of newcomers who write labels and descriptions with unjustified 
capital letters, or write full sentences as descriptions, even though this is 
explained as being wrong in the corresponding introductory text.
  
  **Possible solutions:** Create a special (or non-special) page that serves as 
an entry point ("Create an entity") to choose which entity to create based on 
the user's intentions and that does not use technical or Wikidata terms (no 
"Item", "Lexeme", etc.), improve the current special pages to highlight their 
differences with the interface itself (e.g. the language requested in 
Special:NewItem refers only to the language in which the label, description and 
aliases are currently written, while the language requested in 
Special:NewLexeme refers to the entire entity), include missing checks in the 
data on Special:NewItem and Special:NewLexeme to detect problems (e.g. the 
"lexical category" is not a lexical category, a Lexeme with the same lemma, 
language and lexical category already exists, etc.), include more fields on 
both special pages to make clear what kind of data the entity will be able to 
store, etc.

TASK DETAIL
  https://phabricator.wikimedia.org/T263360

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Lydia_Pintscher, abian, Akuckartz, darthmon_wmde, Nandana, Lahi, Gq86, 
GoranSMilovanovic, Mahir256, QZanden, LawExplorer, _jensen, rosalieper, 
Scott_WUaS, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T207648: If users can't edit a Wikipedia article, don't encourage them to edit its Wikidata item

2020-09-19 Thread abian 
abian closed this task as "Resolved".
abian claimed this task.
abian added a comment.


  `.mw-editable` was implemented and is being used, and the possible remaining 
loose ends are expected to be resolved with the extension of #wikidata-bridge 
<https://phabricator.wikimedia.org/tag/wikidata-bridge/> to all Wikipedias.

TASK DETAIL
  https://phabricator.wikimedia.org/T207648

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: MZMcBride, Addshore, MGChecker, Krinkle, Haros, Krenair, Ivanhercaz, 
Sjoerddebruin, Agabi10, Lydia_Pintscher, abian, Aklapper, Akuckartz, 
darthmon_wmde, Dinadineke, DannyS712, Nandana, tabish.shaikh91, Lahi, Gq86, 
GoranSMilovanovic, Soteriaspace, Jayprakash12345, JakeTheDeveloper, QZanden, 
merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, 
TheDJ, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T76230: [Epic] data quality and trust

2020-09-19 Thread abian 
abian closed subtask T207648: If users can't edit a Wikipedia article, 
don't encourage them to edit its Wikidata item as "Resolved".

TASK DETAIL
  https://phabricator.wikimedia.org/T76230

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: 99of9, Cirdan, Hjfocs, AfroThundr3007730, Agabi10, Capankajsmilyo, 
Herzi.Pinki, SandraF_WMF, Tbayer, abian, Aklapper, Ricordisamoa, Elitre, 
Liuxinyu970226, Lydia_Pintscher, NavinRizwi, Akuckartz, darthmon_wmde, 
DannyS712, Nickleh, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, 
LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Dinoguy1000, 
Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T207651: Purge the necessary Wikimedia pages immediately when an edit is reverted on Wikidata

2020-09-19 Thread abian 
abian closed this task as "Declined".
abian added a comment.


  I have no news that this is happening right now, and I assume that, thanks to 
#wikidata-bridge <https://phabricator.wikimedia.org/tag/wikidata-bridge/>, this 
will be under control from now on.

TASK DETAIL
  https://phabricator.wikimedia.org/T207651

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Dipsacus_fullonum, Aklapper, Lydia_Pintscher, abian, Akuckartz, 
darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, 
_jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T76230: [Epic] data quality and trust

2020-09-19 Thread abian 
abian closed subtask T207651: Purge the necessary Wikimedia pages immediately 
when an edit is reverted on Wikidata as "Declined".

TASK DETAIL
  https://phabricator.wikimedia.org/T76230

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: 99of9, Cirdan, Hjfocs, AfroThundr3007730, Agabi10, Capankajsmilyo, 
Herzi.Pinki, SandraF_WMF, Tbayer, abian, Aklapper, Ricordisamoa, Elitre, 
Liuxinyu970226, Lydia_Pintscher, NavinRizwi, Akuckartz, darthmon_wmde, 
DannyS712, Nickleh, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, 
LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Dinoguy1000, 
Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T260728: too wordy Wikidata Bridge dialog when direct editing is not supported

2020-09-14 Thread abian 
abian added a comment.


  In T260728#6459405 <https://phabricator.wikimedia.org/T260728#6459405>, 
@Charlie_WMDE wrote:
  
  > Hi Abian, I am the designer working on the Bridge.
  
  Hi, Charlie. Then congratulations on the good work; despite the doubts I'm 
raising here, I think the interface is very well thought out.
  
  >> Omit either the description ("At the moment [ā€¦] cannot be edited because 
it contains more than one value") or the title of the error ("Editing multiple 
values is currently not supported") when they both communicate the same idea 
with a similar level of detail.
  >
  > We are working within the constraints of WMF styleguide, in this case for 
notices and error messages.
  
  *zips his mouth*
  
  > That being said, Iā€™m happy to adjust the text to make it less redundant. I 
will be looking into this as part of a small round of fixes we can make to the 
bridge. If you have any suggestions in mind yourself, feel free to let me know!
  
  For example, would it be possible to include as a title a first sentence (the 
consequence), and as a description another sentence (the cause), as if they 
were contiguous sentences in the same paragraph?
  
  //**The car has stopped.**//
  (Or "you can't edit this directly from Wikipedia.")
  
  //We have run out of gasoline.//
  (Or the reason why you can't edit this directly from Wikipedia in this 
particular case, without repeating that you can't do it.)
  
  Although I'm sure there will be better optionsā€¦
  
  >> Avoid showing the text "Edit the value on Wikidata" twice (both in the 
explanatory text and on the button).
  >
  > Iā€™m happy to explain my decision here. From a UX point of view it makes 
sense to add some redundancy here. The reason being that the best practice for 
button labelling should clearly indicate the action the button will perform. 
The explanatory text should also be exactly that, an explanation of the option. 
Removing it here would defeat the purpose of the text. It could be possible to 
change the text a bit so the sentence doesnā€™t exactly repeat, but that would 
mean that now we put a burden on the editor, to bridge the gap between the text 
and the button label, to realise that that is in fact the action the text is 
talking about. Navigating a UI is already a hindrance, because the way the 
editor thinks will never be exactly along the lines of how the system works and 
how the UI communicates it. Reducing any room for misinterpretation is key. 
Sometimes that comes at the cost of redundancy.
  
  I'm not sure I understand this part. Why is the explanatory text necessary 
when it says the same thing as the button and it has to do it with the same 
words?
  
  >> Omit an explanation ("Depending on the template used, it might be possible 
to overwrite the value locally using the article editor") that does not help 
the user make a decision: it does not indicate whether, in that case, the value 
should be defined locally or not, and it does not explain how to do it.
  >
  > The reason why we didnā€™t include instructions here is because our goal is 
simply to let editors know of their options, not provide tutorials on how to 
follow through with them. Same goes for the first option, to edit on Wikidata. 
If the editor chooses to edit the value locally, which is something we do not 
encourage, it is up to them to make sure they make the edit compliant with the 
rules of the wiki. I do not believe that informing of options also requires us 
to explain how to make the edit.
  
  I agree; I wasn't referring to a tutorial, but to the fact that indicating 
that the option to edit locally "might be possible" (or might not be) just 
doesn't provide much value to the user in my opinion, and actually the two 
options might (or might not) be possible or applicable in different 
circumstances. That's why I imagined there was a particular motivation 
underlying that text that had been thought out but perhaps not written down.
  
  >> Consider converting the second suggestion's hyperlink into another button. 
This button could have the same format, or a less eye-catching one (e.g., white 
background), to show it is a less preferred option.
  >
  > We chose to go with a link here because It is common to either use links or 
buttons to help the editors navigate inside the Wiki. Since we want to 
discourage editors from editing a value locally, we chose the least intrusive 
option for that action. Making it a white button, would draw more attention to 
it than weā€™d like to, even though it would be less than the first button.
  
  Okay.
  
  >> Move the text "If at all possible, we recommend that you instead add the 
value to Wikidata via the button above" to the first suggestion, as it is not 
related with the second one. Consider rephrasing this suggesti

[Wikidata-bugs] [Maniphest] T260737: Some types of edits with Wikidata Bridge do not have an applicable selector

2020-09-14 Thread abian 
abian added a comment.


  Hi, Charlie. šŸ–
  
  In T260737#6459414 <https://phabricator.wikimedia.org/T260737#6459414>, 
@Charlie_WMDE wrote:
  
  >> Okay. Then the description might be incomplete; for example, if I change a 
territorial administrative unit to a lower one, I wouldn't consider that the 
previous value "was not correct and has never been". I personally would think 
that I would have improved the original value, but not that the original value 
was wrong, and I wouldn't know what to choose. In this situation people might 
choose arbitrarily (if they didn't have much time) or they might feel forced to 
ask about the consequences of these decisions and about Wikidata's policies on 
when to add values and when to replace them.
  >
  > Iā€™m not sure i understand the scenario correctly, but i would think, if it 
was a mistake, then choosing the first option ā€œcorrectingā€ would be correct, if 
the unit has changed then the ā€œoutdatedā€ option would be the correct one to 
pick. Can you clarify?
  
  I'm thinking of the scenario where the reader doesn't consider the original 
value to be incorrect or outdated but wishes to reflect a more precise/complete 
value. For example, they want to change "musem" to "history museum", or 
"cancer" to "prostate cancer", or "Berlin" to "Friedrichshain". In any case, 
this will hopefully be resolved with the possible rewording (the addition of 
"less [ā€¦] complete or precise").
  
  >> First I thought of population figures for a municipality, the number of 
employees in a companyā€¦ mainly of quantities, but I think this would apply to 
any other data type. If I read that a village has a population of 432 according 
to the infobox, but I have just checked that today there are 276 inhabitants 
according to an official source, I know that the value from the official source 
can be considered correct now, but I don't know if the previous figure was 
correct at some point in the past or not. It seems to me that this situation 
will occur often, as normally we don't know the full history of anything and we 
can't rule out that a value may have been correct an unknown number of years 
ago.
  >>
  >> As to what the related action should be... in my opinion, the value should 
be overwritten if it had no qualifiers or references, and preserved if it had a 
reference or a qualifier (in this case, the new value should have a preferred 
rank, and the original value should be downgraded to normal value if it had 
been marked as preferred). But this is only my opinion, and I know it's a mess; 
when in doubt, adding the value might be the lesser of two evils. (?)
  >
  > That seems like a reasonable conclusion. Is there something that would stop 
you from doing exactly that in the bridge? Currently we can not display 
qualifiers unfortunately, but references can already be viewed. What you said 
about the lesser evil makes a lot of sense to me. Maybe youā€™re suggestion of 
putting the ā€œoutdatedā€-option first, would serve a second purpose. People will 
more likely select the first option when in doubt.
  
  Great point, I hadn't thought of that. :-)
  
  >> I am going to make some suggestions gathering all this together:
  >>
  >> - **The order of the options could be changed** so that the most specific 
or less ambiguous option ("I updated") appears first. This might let the user 
know that the wording of the second option is no longer covering the first case 
("I corrected" does not include updating, because that option has already been 
mentioned).
  >> - "I updated an outdated value / The previous value used to be correct but 
now is outdated."
  >>   - ā†’ "I updated **the (or "a")** value / The previous (or "original") 
value **may have been** (to cover the doubtful case) correct but now is 
outdated."
  >> - "I corrected an incorrect value / The previous value was not correct and 
has never been."
  >>   - ā†’ "I corrected **or completed the (or "a")** value / The previous (or 
"original") value was **less** correct**, complete or precise**."
  >>
  >> These are just my suggestions, feel free to adapt or rule them all out if 
they aren't useful.
  >
  > I will run these past our technical writer. Thank you for the suggestions! 
They both make a lot of sense to me!
  
  Perfect; from what we've discussed, I think the rewording would be enough to 
resolve this task. Thank you!

TASK DETAIL
  https://phabricator.wikimedia.org/T260737

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Lea_Lacroix_WMDE, Charlie_WMDE, abian, Aklapper, Akuckartz, darthmon_wmde, 
Michael, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, 
rosalieper, Scott_WUaS, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T262397: Create visual permalinks for item statements and values

2020-09-13 Thread abian 
abian added a comment.


  I think this is similar to T218402 
<https://phabricator.wikimedia.org/T218402>.

TASK DETAIL
  https://phabricator.wikimedia.org/T262397

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, Aklapper, MavropaliasG, cristiana023, Akuckartz, JanJaquemot, 
Demian, darthmon_wmde, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, 
QZanden, LawExplorer, _jensen, rosalieper, JGirault, Scott_WUaS, Wikidata-bugs, 
aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T262756: Avoid invalid characters for a certain spelling variant

2020-09-13 Thread abian 
abian created this task.
abian added projects: Wikidata Lexicographical data, Wikidata.

TASK DESCRIPTION
  **Problem**: Due to the complexity of lexicographical data on Wikidata and 
the wide range of spelling variants, languages and dialects, some users add 
forms and lemmas with incorrect spelling variant codes.
  
  **Acceptance criteria**: In those cases where it is possible to determine a 
set of valid characters for a spelling variant, users should at least be 
notified when they include characters outside that set. For example, users 
should be warned when they introduce strictly traditional Chinese characters 
(`zh-hant`) with a spelling variant `zh-hans` (simplified Chinese) and vice 
versa.

TASK DETAIL
  https://phabricator.wikimedia.org/T262756

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, Akuckartz, darthmon_wmde, Nandana, Mringgaard, Lahi, Gq86, 
GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, 
Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T262741: "Wikidata API format usage" Grafana dashboard is empty

2020-09-12 Thread abian 
abian created this task.
abian added projects: Graphite, Wikidata.
Restricted Application added a subscriber: Aklapper.

TASK DESCRIPTION
  **Problem**: The "Wikidata API format usage 
<https://grafana.wikimedia.org/d/00169/wikidata-api-format-usage>" Grafana 
dashboard is accesible but is not displaying any data.
  
  F32283274: no-data-api.png <https://phabricator.wikimedia.org/F32283274>

TASK DETAIL
  https://phabricator.wikimedia.org/T262741

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, Aklapper, Akuckartz, darthmon_wmde, Nandana, Robin.guo, Imarlier, 
Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, 
Scott_WUaS, Wikidata-bugs, aude, Mbch331, fgiunchedi
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T157774: Make it impossible to set the same content in the same language for label and alias

2020-08-31 Thread abian 
abian added a comment.


  I have simplified the description and removed from it the features that would 
never have been possible, leaving the description as in T212869 
<https://phabricator.wikimedia.org/T212869>.

TASK DETAIL
  https://phabricator.wikimedia.org/T157774

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Epidosis, PokestarFan, Lydia_Pintscher, Izno, abian, Aklapper, Akuckartz, 
darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, 
_jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T157774: Make it impossible to set the same content in the same language for label and alias

2020-08-31 Thread abian 
abian renamed this task from "A label and an alias should never be the same in 
the same language and item in Wikidata" to "Make it impossible to set the same 
content in the same language for label and alias".
abian updated the task description.

TASK DETAIL
  https://phabricator.wikimedia.org/T157774

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Epidosis, PokestarFan, Lydia_Pintscher, Izno, abian, Aklapper, Akuckartz, 
darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, 
_jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T157774: A label and an alias should never be the same in the same language and item in Wikidata

2020-08-31 Thread abian 
abian added a comment.


  In T157774#6423086 <https://phabricator.wikimedia.org/T157774#6423086>, 
@Epidosis wrote:
  
  > I think that "lowest" priority is maybe a bit too low. While a solution 
isn't found, maybe a bot can be programmed in order to remove  duplicate 
aliases and (if possible) to send a standard warning message to the users who 
added them.
  
  It might be time to revisit this task now that the very similar T212869 
<https://phabricator.wikimedia.org/T212869> is resolved and the editing 
frequency is a problem at the technical level.

TASK DETAIL
  https://phabricator.wikimedia.org/T157774

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Epidosis, PokestarFan, Lydia_Pintscher, Izno, abian, Aklapper, Akuckartz, 
darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, 
_jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T260737: Some types of edits with Wikidata Bridge do not have an applicable selector

2020-08-31 Thread abian 
abian added a comment.


  Hi, LĆ©a; I hope you have enjoyed the summer (which isn't technically over). 
:-)
  
  Thank you for the explanation. The risk I see in having two such opposite and 
assertive options ("incorrect", "was not correct and has never been", etc.) is 
that, in the grey area, or in case of doubt, users might end up choosing 
randomly, and that, from what you say, might not be ideal because it would have 
consequences on how values are finally reflected.
  
  > We think that completing a value or making it more precise can be 
considered as "correcting". The action behind it would be the same (editing the 
existing value).
  
  Okay. Then the description might be incomplete; for example, if I change a 
territorial administrative unit to a lower one, I wouldn't consider that the 
previous value "was not correct and has never been". I personally would think 
that I would have improved the original value, but not that the original value 
was wrong, and I wouldn't know what to choose. In this situation people might 
choose arbitrarily (if they didn't have much time) or they might feel forced to 
ask about the consequences of these decisions and about Wikidata's policies on 
when to add values and when to replace them.
  
  > About "I know the original value is not applicable today but I cannot 
determine if it was correct at some point in the past or not.", is that a 
theoretical example, or did you encounter this situation in the past? If so, 
can you tell us more about this example?
  > If someone is facing this situation, what should be the related action on 
Wikidata?
  
  First I thought of population figures for a municipality, the number of 
employees in a companyā€¦ mainly of quantities, but I think this would apply to 
any other data type. If I read that a village has a population of 432 according 
to the infobox, but I have just checked that today there are 276 inhabitants 
according to an official source, I know that the value from the official source 
can be considered correct now, but I don't know if the previous figure was 
correct at some point in the past or not. It seems to me that this situation 
will occur often, as normally we don't know the full history of anything and we 
can't rule out that a value may have been correct an unknown number of years 
ago.
  
  As to what the related action should be... in my opinion, the value should be 
overwritten if it had no qualifiers or references, and preserved if it had a 
reference or a qualifier (in this case, the new value should have a preferred 
rank, and the original value should be downgraded to normal value if it had 
been marked as preferred). But this is only my opinion, and I know it's a mess; 
when in doubt, adding the value might be the lesser of two evils. (?)
  
  ---
  
  I am going to make some suggestions gathering all this together:
  
  - **The order of the options could be changed** so that the most specific or 
less ambiguous option ("I updated") appears first. This might let the user know 
that the wording of the second option is no longer covering the first case ("I 
corrected" does not include updating, because that option has already been 
mentioned).
  - "I updated an outdated value / The previous value used to be correct but 
now is outdated."
- ā†’ "I updated **the (or "a")** value / The previous (or "original") value 
**may have been** (to cover the doubtful case) correct but now is outdated."
  - "I corrected an incorrect value / The previous value was not correct and 
has never been."
- ā†’ "I corrected **or completed the (or "a")** value / The previous (or 
"original") value was **less** correct**, complete or precise**."
  
  These are just my suggestions, feel free to adapt or rule them all out if 
they aren't useful.

TASK DETAIL
  https://phabricator.wikimedia.org/T260737

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Lea_Lacroix_WMDE, Charlie_WMDE, abian, Aklapper, Akuckartz, darthmon_wmde, 
Michael, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, 
rosalieper, Scott_WUaS, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T166470: Include links in Wikidata HTTP responses to different entity representations as Link headers

2020-08-28 Thread abian 
abian added a comment.


  This is already working for the HTML pages of Wikidata.
  
  In T166470#6199846 <https://phabricator.wikimedia.org/T166470#6199846>, 
@abian wrote:
  
  > [X] A request for a page that is not a Wikibase entity does not generate a 
response with links to alternative structured representations.
  
$ curl --head 'https://www.wikidata.org/wiki/Wikidata:Main_Page' | grep 
'link:' # existing page in the Wikidata namespace
ĀÆ\_(惄)_/ĀÆ
$ curl --head 'https://www.wikidata.org/wiki/EntitySchema:E2' | grep 
'link:' # existing page in the EntitySchema namespace
ĀÆ\_(惄)_/ĀÆ
$ curl --head 'https://www.wikidata.org/wiki/Q7' | grep 'link:' # 
non-existing Item
ĀÆ\_(惄)_/ĀÆ
  
  
  
  > [X] A request for a Wikibase Item generates a response with links to 
alternative structured representations.
  
  
  
$ curl --head 'https://www.wikidata.org/wiki/Q5' | grep 'link:'
link: <https://www.wikidata.org/wiki/Special:EntityData/Q5.json>; 
rel="alternate"; 
type="application/json",<https://www.wikidata.org/wiki/Special:EntityData/Q5.php>;
 rel="alternate"; 
type="application/vnd.php.serialized",<https://www.wikidata.org/wiki/Special:EntityData/Q5.rdf>;
 rel="alternate"; 
type="application/rdf+xml",<https://www.wikidata.org/wiki/Special:EntityData/Q5.n3>;
 rel="alternate"; 
type="text/n3",<https://www.wikidata.org/wiki/Special:EntityData/Q5.ttl>; 
rel="alternate"; 
type="text/turtle",<https://www.wikidata.org/wiki/Special:EntityData/Q5.nt>; 
rel="alternate"; 
type="application/n-triples",<https://www.wikidata.org/wiki/Special:EntityData/Q5.jsonld>;
 rel="alternate"; type="application/ld+json"
  
  
  
  > [X] A request for a Wikibase Property generates a response with links to 
alternative structured representations.
  
$ curl --head 'https://www.wikidata.org/wiki/Property:P39' | grep 'link:'
link: <https://www.wikidata.org/wiki/Special:EntityData/P39.json>; 
rel="alternate"; 
type="application/json",<https://www.wikidata.org/wiki/Special:EntityData/P39.php>;
 rel="alternate"; 
type="application/vnd.php.serialized",<https://www.wikidata.org/wiki/Special:EntityData/P39.rdf>;
 rel="alternate"; 
type="application/rdf+xml",<https://www.wikidata.org/wiki/Special:EntityData/P39.n3>;
 rel="alternate"; 
type="text/n3",<https://www.wikidata.org/wiki/Special:EntityData/P39.ttl>; 
rel="alternate"; 
type="text/turtle",<https://www.wikidata.org/wiki/Special:EntityData/P39.nt>; 
rel="alternate"; 
type="application/n-triples",<https://www.wikidata.org/wiki/Special:EntityData/P39.jsonld>;
 rel="alternate"; type="application/ld+json"
  
  > [X] The link headers are well formatted.
  
  They follow the pattern `<` +  + `>; rel="alternate"; type="` +  + 
`"`.
  
  > [X] All the alternative structured representations listed are available.
  
  They are.
  
  > [X] All the alternative structured representations available are listed.
  
  They are. According to Special:EntityData 
<https://www.wikidata.org/wiki/Special:EntityData>: "json, php, n3, ttl, nt, 
rdf, jsonld".
  
  > [X] All the alternative structured representations listed are about the 
requested Wikibase entity.
  
  They are.
  
  And it also seems to work on test.wikidata.org (and, by extension, any 
Wikibase installation from now on).
  
$ curl --head 'https://test.wikidata.org/wiki/Q10' | grep 'link:'
link: <https://test.wikidata.org/wiki/Special:EntityData/Q10.json>; 
rel="alternate"; 
type="application/json",<https://test.wikidata.org/wiki/Special:EntityData/Q10.php>;
 rel="alternate"; 
type="application/vnd.php.serialized",<https://test.wikidata.org/wiki/Special:EntityData/Q10.rdf>;
 rel="alternate"; 
type="application/rdf+xml",<https://test.wikidata.org/wiki/Special:EntityData/Q10.n3>;
 rel="alternate"; 
type="text/n3",<https://test.wikidata.org/wiki/Special:EntityData/Q10.ttl>; 
rel="alternate"; 
type="text/turtle",<https://test.wikidata.org/wiki/Special:EntityData/Q10.nt>; 
rel="alternate"; 
type="application/n-triples",<https://test.wikidata.org/wiki/Special:EntityData/Q10.jsonld>;
 rel="alternate"; type="application/ld+json"

TASK DETAIL
  https://phabricator.wikimedia.org/T166470

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Lucas_Werkmeister_WMDE, Ladsgroup, Lydia_Pintscher, Addshore, daniel, 
Aklapper, abian, Akuckartz, Iflorez, darthmon_wmde, alaa_wmde, Nandana, Lahi, 
Gq86, GoranSMilovanovic, Chicocvenancio, QZanden, LawExplorer, _jensen, 
rosalieper, Scott_WUaS, Jonas, Wikidata-bugs, aude, Mbch331, Krenair
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T166470: Include links in Wikidata HTTP responses to different entity representations as Link headers

2020-08-28 Thread abian 
abian updated the task description.

TASK DETAIL
  https://phabricator.wikimedia.org/T166470

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Lucas_Werkmeister_WMDE, Ladsgroup, Lydia_Pintscher, Addshore, daniel, 
Aklapper, abian, Akuckartz, Iflorez, darthmon_wmde, alaa_wmde, Nandana, Lahi, 
Gq86, GoranSMilovanovic, Chicocvenancio, QZanden, LawExplorer, _jensen, 
rosalieper, Scott_WUaS, Jonas, Wikidata-bugs, aude, Mbch331, Krenair
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T260768: Remove signal: Number of sitelinks

2020-08-26 Thread abian 
abian added a comment.


  Side note: Please keep in mind that data quality is often understood as the 
"fitness for use" (http://www.semantic-web-journal.net/system/files/swj414.pdf) 
or "purpose" 
(https://www.cio.com/article/3124402/ensuring-the-quality-of-fit-for-purpose-data.html)
 of the data. From the RfC "Data quality framework for Wikidata 
<https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Data_quality_framework_for_Wikidata>":
  
  > Following Lukanyenko et al., 2014[1], we define data quality as ā€œthe extent 
to which stored information represents the phenomena of interest to data 
consumers (and project sponsors), as perceived by information contributorsā€.
  
  As a result, relevance has traditionally been considered a data quality 
dimension: all things being equal, the data that is most relevant to users 
(more linked/shared/used) can also be considered of higher quality. The 
mentioned RfC also proposed 
<https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Data_quality_framework_for_Wikidata#Interlinking>
 that sitelinks were a relevant data quality dimension for Wikidata in 
particular:
  
  > The extent to which data are sufficiently interlinked to other resources, 
either within or without Wikimedia.
  >
  > - Description and examples: Items should be linked to equivalent entities 
in other knowledge bases; Items should have an appropriate number of links to 
other Wikimedia projects.
  
  This side note is not to force anyone to rethink this task or to change the 
way in which ORES is being used, only to warn that probably not many more 
signals are being used to determine whether the data ultimately meets people's 
needs (the decisive indicator and high-level synonym of "data quality"), and 
that some definitions and objectives reflected in different places under the 
common name of "data quality" are unfortunately less and less aligned.

TASK DETAIL
  https://phabricator.wikimedia.org/T260768

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: guergana.tzatchkova, abian
Cc: abian, Aklapper, Lydia_Pintscher, guergana.tzatchkova, Akuckartz, 
darthmon_wmde, Michael, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, 
LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Ladsgroup, 
Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T166470: Include links in Wikidata HTTP responses to different entity representations as Link headers

2020-08-19 Thread abian 
abian added a comment.


  Everything looks good to me on https://wikidata.beta.wmflabs.org/. Thank you, 
folks!
  
  It's pending the opposite, that those formats point to each other and to the 
HTML version. This step is important because:
  
  - unlike the HTML version, where the link headers also appear in the content, 
with the alternative formats the links don't appear anywhere;
  - some agents give more credit to reciprocal links.
  
  I don't know if I should try to modify 
repo/includes/LinkedData/EntityDataRequestHandler.php 
<https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Wikibase/+/refs/heads/master/repo/includes/LinkedData/EntityDataRequestHandler.php>
 or if we'll finish earlier by leaving this to the experts from the beginning. 
What do you think?

TASK DETAIL
  https://phabricator.wikimedia.org/T166470

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Lucas_Werkmeister_WMDE, Ladsgroup, Lydia_Pintscher, Addshore, daniel, 
Aklapper, abian, Akuckartz, Iflorez, darthmon_wmde, alaa_wmde, Nandana, Lahi, 
Gq86, GoranSMilovanovic, Chicocvenancio, QZanden, LawExplorer, _jensen, 
rosalieper, Scott_WUaS, Jonas, Wikidata-bugs, aude, Mbch331, Krenair
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T260737: Some types of edits with Wikidata Bridge do not have an applicable selector

2020-08-18 Thread abian 
abian updated the task description.

TASK DETAIL
  https://phabricator.wikimedia.org/T260737

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, Aklapper, Akuckartz, darthmon_wmde, Michael, Nandana, Lahi, Gq86, 
GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, 
Wikidata-bugs, aude, Lydia_Pintscher, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T260737: Some types of edits with Wikidata Bridge do not have an applicable selector

2020-08-18 Thread abian 
abian created this task.
abian added projects: Wikidata-Bridge, Wikidata.
Restricted Application added a subscriber: Aklapper.

TASK DESCRIPTION
  **Problem**: As a user, when I'm editing Wikidata from Wikipedia with 
Wikidata Bridge, sometimes I don't have a radio button representing the type of 
edit I'm making. For example, I don't have an applicable option when:
  
  - I'm completing or making more precise the original value, which I already 
considered correct but less detailed.
  - I know the original value is not applicable today but I cannot determine if 
it was correct at some point in the past or not.
  
  I should know which option to choose in these cases, either from the two 
existing options (in which case the descriptions should be rewritten) or from 
new ones.

TASK DETAIL
  https://phabricator.wikimedia.org/T260737

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: abian, Aklapper, Akuckartz, darthmon_wmde, Michael, Nandana, Lahi, Gq86, 
GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, 
Wikidata-bugs, aude, Lydia_Pintscher, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T260728: too wordy Wikidata Bridge dialog when direct editing is not supported

2020-08-18 Thread abian 
abian created this task.
abian added projects: Wikidata-Bridge, Wikidata.
Restricted Application added a subscriber: Aklapper.

TASK DESCRIPTION
  **Problem**: As a user I find this dialog (which includes messages 
`wikibase-client-data-bridge-unsupported-datatype-error-*` and 
`wikibase-client-data-bridge-bailout-*`) a bit confusing because of its 
verbosity, its repetitions and the inconsistency between the button of the 
first suggestion and the hyperlink of the second.
  
  F32187667: confusing-message.png <https://phabricator.wikimedia.org/F32187667>
  
  **Suggestions for improvement** (non-exhaustive list):
  
  [ ] Omit either the description ("At the moment [ā€¦] cannot be edited because 
it contains more than one value") or the title of the error ("Editing multiple 
values is currently not supported") when they both communicate the same idea 
with a similar level of detail.
  [ ] Avoid showing the text "Edit the value on Wikidata" twice (both in the 
explanatory text and on the button).
  [ ] Omit an explanation ("Depending on the template used, it might be 
possible to overwrite the value locally using the article editor") that does 
not help the user make a decision: it does not indicate whether, in that case, 
the value should be defined locally or not, and it does not explain how to do 
it.
  [ ] Consider converting the second suggestion's hyperlink into another 
button. This button could have the same format, or a less eye-catching one 
(e.g., white background), to show it is a less preferred option.
  [ ] Move the text "If at all possible, we recommend that you instead add the 
value to Wikidata via the button above"  to the first suggestion, as it is not 
related with the second one. Consider rephrasing this suggestion in fewer words 
(e.g., simply write "(recommended)" next to the first button or suggestion).
  [ ] Indicate the name of the parameter in quotes, in italics or with other 
style differences to avoid it being confused with the rest of the dialogue, 
especially when the name is made up of several words (see screenshot).

TASK DETAIL
  https://phabricator.wikimedia.org/T260728

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Aklapper, abian, Akuckartz, darthmon_wmde, Michael, Nandana, Lahi, Gq86, 
GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, 
Wikidata-bugs, aude, Lydia_Pintscher, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

  1   2   3   4   5   6   7   8   >