Lea_WMDE created this task.Lea_WMDE triaged this task as "Normal" priority.Lea_WMDE added projects: Discovery, German-Community-Wishlist, Wikidata, Wikidata-Query-Service, TCB-Team.
TASK DESCRIPTIONTesting deepcategory more thoroughly, we think there might be a problem related to umlauts.
See the
WMDE-leszek added a comment.
Good point @Jakob_WMDE. This could be fixed using LexemeSerializationUpdater I believe. The point would be to change the "datatype" property of the JSON object in the text table. If the value was "wikibase-lexeme-form" it should become "wikibase-form" (and similar
RexxS added a comment.
I agree that caching would introduce predictable lag whenever a short description is changed, but I doubt that the descriptions are going going to be changed very often, if at all.
If the worry is vandalism, then the caching is irrelevant. The vandalism is just as likely to
Addshore added a comment.
It might make sense for EntityDocument to have a clear() method in the interface.
Then in EditEntity::clearEntity instead of creating a new Entity you could create a copy() and call clear() which would have special handling for Lexeme (and also special handling for
Addshore created this task.Addshore added a project: Lexicographical data.Herald added a subscriber: Aklapper.Herald added a project: Wikidata.
TASK DESCRIPTIONF17006897: image.png
This comes down to EditEntity::clearEntity which will make an api request to wbeditentity for a lexeme with the
Ladsgroup claimed this task.Ladsgroup added a project: Wikidata-Ministry-Of-Magic.Herald added a project: User-Ladsgroup.
TASK DETAILhttps://phabricator.wikimedia.org/T190460EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: LadsgroupCc: gerritbot,
gerritbot added a project: Patch-For-Review.
TASK DETAILhttps://phabricator.wikimedia.org/T190460EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: gerritbotCc: gerritbot, Lydia_Pintscher, Ladsgroup, matej_suchanek, Aklapper, Versusxo, Majesticalreaper22,
gerritbot added a comment.
Change 426892 had a related patch set uploaded (by Ladsgroup; owner: Amir Sarabadani):
[mediawiki/extensions/Wikibase@master] Prune usages and subscriptions after deleting a page
https://gerrit.wikimedia.org/r/426892TASK
Jakob_WMDE added a comment.
Changing the data type IDs will probably cause some "Unknown data type 'wikibase-lexeme-form'" errors on the test system. Does that need to be addressed? Any newly created property will work just fine.TASK DETAILhttps://phabricator.wikimedia.org/T191976EMAIL
Lucas_Werkmeister_WMDE added a comment.
Are you sure this is a bug in the query service? As far as I can tell, ?geo is always the coordinate location of Q791 – did you mean to select ?other_geo?TASK DETAILhttps://phabricator.wikimedia.org/T192152EMAIL
daniel added a comment.
Oh, I just realized. You could fake this using a fake sitelink. On wikidata, an item's sitelinks points to articles in sister projects like wikipedia. It should not be hard to allow pages on non-mediawiki sites to be references in the same way - or even just pretend to
daniel added a comment.
A good example of how to add a custom entity type is https://www.mediawiki.org/wiki/Extension:WikibaseMediaInfo. The entry point for defining an entity type is the wiring file at
gerritbot added a project: Patch-For-Review.
TASK DETAILhttps://phabricator.wikimedia.org/T191976EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jakob_WMDE, gerritbotCc: gerritbot, Lydia_Pintscher, Aklapper, WMDE-leszek, Versusxo, Majesticalreaper22,
gerritbot added a comment.
Change 426887 had a related patch set uploaded (by Jakob; owner: Jakob):
[mediawiki/extensions/WikibaseLexeme@master] Change data type IDs for forms and senses.
https://gerrit.wikimedia.org/r/426887TASK DETAILhttps://phabricator.wikimedia.org/T191976EMAIL
Jakob_WMDE claimed this task.
TASK DETAILhttps://phabricator.wikimedia.org/T191976EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jakob_WMDECc: gerritbot, Lydia_Pintscher, Aklapper, WMDE-leszek, Lahi, Gq86, Cinemantique, GoranSMilovanovic, QZanden,
gerritbot added a project: Patch-For-Review.
TASK DETAILhttps://phabricator.wikimedia.org/T191973EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Addshore, gerritbotCc: gerritbot, Aklapper, Lydia_Pintscher, WMDE-leszek, Versusxo, Majesticalreaper22,
gerritbot added a comment.
Change 426882 had a related patch set uploaded (by Addshore; owner: Addshore):
[mediawiki/extensions/WikibaseLexeme@master] Disable senses in ExternalLexemeSerializer
https://gerrit.wikimedia.org/r/426882TASK DETAILhttps://phabricator.wikimedia.org/T191973EMAIL
Liuxinyu970226 added a comment.
@Mbch331:
@Lydia_Pintscher Considering GerardM's last comment is this still a go or is it now a no go? Just want to be sure, before I start making a patch with the result it will never be merged.
just rejectTASK DETAILhttps://phabricator.wikimedia.org/T165648EMAIL
TheDJ added a comment.
API every time the page was reloaded
But we have parser output caching, so that means that a page reload doesn't query the api every time (by design). So any change to the value would not be reflected in the HTML, until someone changes the page on commons.wp (or waits until
Addshore claimed this task.Herald added a project: User-Addshore.
TASK DETAILhttps://phabricator.wikimedia.org/T191973EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AddshoreCc: Aklapper, Lydia_Pintscher, WMDE-leszek, Lahi, Gq86, Cinemantique,
Yurik added a comment.
thx, clearly this wouldn't be used for wikidata. @daniel could you point me to the relevant code plz, or perhaps something similar, or maybe sketch the implementation approach? I was thinking that this would be the only real path to solve this, possibly with a custom
gerritbot added a comment.
Change 422426 abandoned by Jakob:
Disallow Lexemes having no lemmas
Reason:
Alternative solution as discussed in https://phabricator.wikimedia.org/T189185
https://gerrit.wikimedia.org/r/422426TASK DETAILhttps://phabricator.wikimedia.org/T189185EMAIL
eranroz added a comment.
Notes:
This works based on user language, not sitelang (e.g uselang can workaround it: https://www.wikidata.org/w/index.php?title=Q3013215=2880827=292663898=250877025=fa )
Setting the directionality should be to the sitelang without the site prefix e.g [[fa:FATITLE]]
daniel added a comment.
For a 3rd party site, it would not be terribly hard to implement a new entity type that extends the Item type to have an additional immutable string ID. This would be done by a custom extension on top of Wikibase. I don't think we'd deploy such a thin on Wikidata, though -
ReleaseTaggerBot edited projects, added MW-1.31-release-notes (WMF-deploy-2018-04-17 (1.31.0-wmf.30)); removed MW-1.31-release-notes (WMF-deploy-2018-04-03 (1.31.0-wmf.28)).
TASK DETAILhttps://phabricator.wikimedia.org/T189538EMAIL
gerritbot added a comment.
Change 419335 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Merge view/init.mw.php into view/WikibaseView.php
https://gerrit.wikimedia.org/r/419335TASK DETAILhttps://phabricator.wikimedia.org/T189538EMAIL
Lydia_Pintscher updated the task description. (Show Details)
CHANGES TO TASK DESCRIPTION...- language code property: name: `$wgLexemeLanguageCodePropertyId` value: "P219" (?)8"
- $wgLexemeEnableSenses: falseTASK DETAILhttps://phabricator.wikimedia.org/T184745EMAIL
WMDE-leszek added a comment.
It is probably not needed for this task, but it would be of great if I could run the tests locally. I don't know which mediawiki-vagrant role to enable to get WikibaseLexeme running. wikibase_repo, wikidata...?
sadly we didn't get to adding any vagrant role yet.
I
Lydia_Pintscher closed this task as "Declined".Lydia_Pintscher added a comment.
Sorry but the fact that we assign the IDs the way we do is baked deeply into the whole system and I don't think it is worth it to change it.TASK DETAILhttps://phabricator.wikimedia.org/T192249EMAIL
Micru added a comment.
So if I understand correctly, you would like to have custom Entity IDs instead of the usual Q followed by an integer (Q). On Wikidata normally the Entity IDs are not visible, what the user sees is the label of the entity. So I assume that in the use case of OSM you could
Mbch331 added projects: Easy, Need-volunteer, Community-consensus-needed.
TASK DETAILhttps://phabricator.wikimedia.org/T155425EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Mbch331Cc: PKM, Mbch331, Lydia_Pintscher, jhsoby, GerardM, Aklapper, Bugreporter,
101 - 131 of 131 matches
Mail list logo
