Page MenuHomePhabricator

Uzume (Uzume)
User

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Wednesday

  • Clear sailing ahead.

User Details

User Since
Dec 26 2014, 1:37 PM (392 w, 2 d)
Availability
Available
LDAP User
Uzume
MediaWiki User
Unknown

Recent Activity

Sun, Jun 26

Uzume added a comment to T181714: Two cases of failing upload, followed by a successful upload with a different file name.

I believe, in general (there might be some cases for certain privileges that setting it is required I am not sure), users are not required to set an email address in preferences. That said, yes, bots can attempt to send users emails:

Sun, Jun 26, 10:17 AM · IA Upload
Uzume added a comment to T179736: Fixable vs. unfixable IA Upload failures: overview.

Is it the case that the zip files we want are identified by format = 'Abbyy GZ' in the files' list? That seems to identify the jp2 and tif zip files in the items I've looked at.

Sun, Jun 26, 10:01 AM · IA Upload
Uzume added a comment to T166303: Add indicator to see if a queued task is dead on not on IA-upload.

It would be nice if the jobs metadata and the logs were kept longer. That said all jobs should have a master timeout and die that makes them all end up in the completed/aborted bucket. That bucket can then be cleaned after a longer period. This allows one to manually retry jobs by clicking a button on the aborted ones if one can ascertain from the logs that the error was somehow temporal.

Sun, Jun 26, 9:22 AM · IA Upload
Uzume added a comment to T161456: Use Commons (individual files?) as a source for building DjVu files.

I think the issues with that could be:

  • the OCR from IA is of better quality than we can do on Labs (I think I'm right in saying they use Abby FineReader, we use Tesseract or Google Cloud Vision API);
Sun, Jun 26, 9:14 AM · All-and-every-Wikisource, IA Upload, Commons

Fri, Jun 24

Uzume added a comment to T285124: Trying to get property 'key' of non-object.

@Samwilson After pruning old job items via the fix for T183338, the line moved from 150 to 111 but it is possible it was fixed. Is this still happening?

Fri, Jun 24, 7:39 AM · IA Upload
Uzume added a comment to T286701: IA-Upload: retry failed commons uploads (504 errors).

Why not just use direct URL upload to begin with? Let Commons pull it from IA Upload then we do not have to worry about teaching addwiki async chunked uploading as IA Upload's part would be downloading instead (and from the perspective of IA Upload, another request is inherently asynchronous). This has the added benefit of transparency as we would have to provide the media URL and file description metadata anyway.

Fri, Jun 24, 7:21 AM · IA Upload, Community-Tech

Thu, Jun 23

Uzume added a comment to T296834: IA-Upload: DLI conversion failure for in.ernet.dli.2015.226478.

This depends how how you are trying to process that. That IA item does not have an existing DjVu file (it was created well after March 2016 when they stopped making those).

Thu, Jun 23, 9:05 PM · Internet-Archive, IA Upload
Uzume added a comment to T300705: pdf2djvu solves difficult cases.

Currently IA Upload uploads DjVu obtained via three possible sources:

  1. Use existing DjVu
  2. From original scans (JP2)
  3. From PDF (maybe of lower quality)
Thu, Jun 23, 7:27 PM · IA Upload
Uzume renamed T300761: Text layer mismatch with page images on DjVu created from original scans (JP2) from Text layer mismatch with page images on djvu created from original scan (JP2) to Text layer mismatch with page images on DjVu created from original scans (JP2).
Thu, Jun 23, 5:38 PM · IA Upload, Commons
Uzume renamed T300761: Text layer mismatch with page images on DjVu created from original scans (JP2) from Text layer mismatch with page images on djvu created with Abbyy finereader 15 to Text layer mismatch with page images on djvu created from original scan (JP2).
Thu, Jun 23, 5:24 PM · IA Upload, Commons
Uzume added a comment to T300761: Text layer mismatch with page images on DjVu created from original scans (JP2).

I too have run into this issue and I do not think it is is so much of an issue with the OCR layer being on the wrong pages per se as the
Jp2DjvuMaker including extraneous pages from the jp2 set and thus the OCR layers effectively no longer match up with resultant pages.

Thu, Jun 23, 5:17 PM · IA Upload, Commons

Jan 18 2022

Uzume added a comment to T161976: Feature request: add detection for page language to Scribunto.

For reference, {{PAGELANGUAGE}} mentioned in the description was added in T59603, however, it only allows one to obtain the language of the page being rendered (since it does not take any arguments unlike {{PAGENAME}} and friends) not the content language of arbitrary pages despite arbitrary page content being available via getContent on mw.title objects.

Jan 18 2022, 12:46 PM · MW-1.38-notes (1.38.0-wmf.20; 2022-01-31), Patch-For-Review, MediaWiki-extensions-Scribunto
Uzume added a member for MediaWiki-ContentHandler: Uzume.
Jan 18 2022, 12:15 PM
Uzume updated the task description for T299369: Consider removing global $userLang from onPageContentLanguage hook.
Jan 18 2022, 12:11 PM · Sustainability (Incident Followup), MediaWiki-extensions-WikimediaIncubator, Technical-Debt (Deprecation process), Platform Engineering, MediaWiki-ContentHandler, Performance-Team (Radar)
Uzume added a comment to T299369: Consider removing global $userLang from onPageContentLanguage hook.

I am hoping that a resolution here can lead to a resolution of T161976 for which the fix was reverted due to T298659 and ultimately resulted in this issue. I believe if page content is available during the rendering of another page that the purported content language of the available page content should also be available during the page render (much like the content model already is).

Jan 18 2022, 12:08 PM · Sustainability (Incident Followup), MediaWiki-extensions-WikimediaIncubator, Technical-Debt (Deprecation process), Platform Engineering, MediaWiki-ContentHandler, Performance-Team (Radar)

Jan 11 2022

Uzume added a comment to T298659: BadMethodCallException: Sessions are disabled for load entry point.

The entry point for this problem seems to be ContentHandler::getPageLanguage(), as called by the recently added Scribunto code for mw.title.pageLanguage. This method does not logically depend on the context/user language, except for where it passes $wgLang as third parameter to HookRunner::onPageContentLanguage.

This seems like a bad idea and not something that is imho reasonable to support in MediaWiki, and incompatible with the general model of how this feature works. For one, it would break any assumption that this is persistable to the database.

I feared the Translate extension might depend on thit, but from a Codesearch query we find it is actually not recongising this parameter at all. Instead, it is LiquidThreads and WikimediaIncubator using these to make some of their wiki pages act like a special page, in that they automagically render in the UI language. This is strange since we already expose the use language to the parser and allow it to be used. Rather, the hook is additionally forcing the internal page language to be perceived as if it were the current user language. Perhaps in the short-mid term we can find a different way to support the underlying need there.

Jan 11 2022, 3:49 AM · MW-1.38-notes (1.38.0-wmf.17; 2022-01-10), Growth-Team, MediaWiki-Recent-changes, MediaWiki-extensions-Scribunto, Wikimedia-production-error

Jan 10 2022

Uzume added a comment to T197516: pairs() doesn't preserve the order of parameters passed to the module.

The problem with this is that this affects the MediaWIki core code since the Scribunto extension just uses the core template frame code to parse the parameters and arguments. That code makes no attempt to retain original order and is thus this information is lost (despite such order being available to parser functions like #invoke in general). To make matters more complex, parameters and arguments are not only available (likely out of order) for the current #invoke frame but also the parent wikitext template frame. Wikitext template's also need both numbered and named parameters but so far have had no need to retain original ordering. Since Scribunto allows access to the parent frame args which also does not retain the original ordering they were given in this necessitates a core change to fix such.

Jan 10 2022, 2:48 AM · MediaWiki-extensions-Scribunto

Nov 24 2021

Uzume added a comment to T296337: SDoC {{#statements}} parser function gives bad data in some situations.

It should probably be noted that there are Wikidata items that state they represent (P31) Wikimedia categories (Q4167836). Some of those have category sitelinks at Commons, i.e., Q9013822 sitelinks to Category:Text logos). These should probably not be considered in error despite also having P373 "Commons category" statements claiming the same value. Having a MediaInfo entity's statements linking to such Wikidata items might be considered erroneous (depending on the claims).

Nov 24 2021, 4:55 PM · StructuredDataOnCommons

Nov 23 2021

Uzume added a comment to T296337: SDoC {{#statements}} parser function gives bad data in some situations.

I am not sure if this is actually unexpected. {{#statements:P195|from=M89709639}} yields <span><span>[[Category:Media contributed by Toledo-Lucas County Public Library|Toledo-Lucas County Public Library]]</span></span> because of the P195 claim on M89709639 that points to Q7814140 which in turn has the commons sitelink that points to Category:Media contributed by Toledo-Lucas County Public Library (I doubt that sitelink is really correct and could use to be fixed, e.g., {{#property:P373|from=Q7814140}} also yields Media contributed by Toledo-Lucas County Public Library).

Nov 23 2021, 11:59 PM · StructuredDataOnCommons

Nov 14 2021

Uzume added a comment to T18691: RFC: Section header "share" link.

That doesn't seem feasible, and it's outside of the scope of this task

I never suggested such was feasible or in scope, however, I do think it deserves a discussion point as the reason for wanting such external linking is actually even larger for editor created anchors than for sections. As such, they help define the problem here and possible arguments for or against the proposals here.

Nov 14 2021, 11:20 PM · Tech-Ambassadors, User-Jdlrobson, Platform Team Workboards (Clinic Duty Team), TechCom-RFC, Design, MediaWiki-Interface
Uzume added a watcher for TechCom-RFC: Uzume.
Nov 14 2021, 8:40 PM
Uzume added a comment to T18691: RFC: Section header "share" link.

It should be noted that while these work:

the following does not work nor refer to the same thing:

but rather one has to use something like:

Nov 14 2021, 4:13 PM · Tech-Ambassadors, User-Jdlrobson, Platform Team Workboards (Clinic Duty Team), TechCom-RFC, Design, MediaWiki-Interface

Jun 26 2020

Uzume added a comment to T161976: Feature request: add detection for page language to Scribunto.

I actually did not do that. I think somehow I must have edited/submitted and older version (though I am not sure how as that was not my intention).

Jun 26 2020, 4:58 AM · MW-1.38-notes (1.38.0-wmf.20; 2022-01-31), Patch-For-Review, MediaWiki-extensions-Scribunto

Jun 23 2020

Uzume edited projects for T161976: Feature request: add detection for page language to Scribunto, added: Patch-For-Review; removed Patch-Needs-Improvement.

@Aklapper Does it really need triage? There was already a patch for it (thought it seems to need to be updated). I can see how the patch itself needs triage but the issue seems well understood. Anomie already clarified that mw.language.getPageLanguage was not the right thing and demonstrated that a pageLanguage field of mw.title objects was the way to go. What further triage does this issue really need? I only assigned it to Anomie so that he would respond based on the patch he created. I understand if he wanted to remove himself at this point in time but the point was to get him to make such a statement.

Jun 23 2020, 7:49 AM · MW-1.38-notes (1.38.0-wmf.20; 2022-01-31), Patch-For-Review, MediaWiki-extensions-Scribunto

Jun 22 2020

Uzume updated the task description for T30299: An image redirect from a foreign shared File Repository overrides local wiki page..
Jun 22 2020, 7:55 AM · MediaWiki-Redirects

Jun 21 2020

Uzume added a comment to T254102: Make getContent() work for interwiki pages.

I highly doubt this sort of functionality will arrive anytime soon. The main issue is that if a Scribunto module supplies different output based on different input from remote wikis, how does Mediawiki track the links and maintain the page rendering caches (so cached output gets properly updated when a dependency changes)? To accomplish this sort of dependency tracking the link tables would have to somehow be expanded to support cross wiki linking so that things like [[Special:Whatlinkshere]] can list remote page transclusions, etc. (perhaps you read that getContent causes the page to be recorded as a transclusion and this is why).

Jun 21 2020, 3:24 PM · Crosswiki, MediaWiki-extensions-Scribunto
Uzume moved T254102: Make getContent() work for interwiki pages from Backlog to Transclusions on the Crosswiki board.
Jun 21 2020, 3:23 PM · Crosswiki, MediaWiki-extensions-Scribunto
Uzume moved T207932: Special:Notifications should display all cross-wiki notifications anytime whatever their status from Backlog to Notifications on the Crosswiki board.
Jun 21 2020, 3:23 PM · Growth-Team-Filtering, Crosswiki, Growth-Team, Notifications
Uzume moved T235856: Enable cross-wiki searching for 3+ new languages/projects (stretch) from Backlog to Search on the Crosswiki board.
Jun 21 2020, 3:22 PM · Crosswiki, Discovery-Search
Uzume moved T243412: Allow cross-wiki notifications to work without CentralAuth from Backlog to Notifications on the Crosswiki board.
Jun 21 2020, 3:21 PM · Growth-Team-Filtering, Crosswiki, Notifications, Growth-Team
Uzume assigned T161976: Feature request: add detection for page language to Scribunto to Anomie.

@Anomie Can we get your change from over three years ago merged? This is an easy and straightforward fix but Gerrit is reporting some sort of merge conflict even though Jenkins had no issues with it.

Jun 21 2020, 1:42 PM · MW-1.38-notes (1.38.0-wmf.20; 2022-01-31), Patch-For-Review, MediaWiki-extensions-Scribunto

Jun 20 2020

Uzume edited Description on Wikimedia-Hackathon-2020.
Jun 20 2020, 8:38 AM

Jun 16 2020

Uzume added a comment to T192462: mw.wikibase.entityExists returns false for redirected entities.

So quick question from people who need this (ping @Uzume and @eranroz): Should mw.wikibase.entityExists('Q123') return true in case Q123 is redirect all the time or when it's redirecting to an existing entity?

Jun 16 2020, 12:48 AM · MW-1.34-notes (1.34.0-wmf.22; 2019-09-10), Wikidata-Campsite (Wikidata-Campsite-Iteration-∞ (On Hold)), User-Ladsgroup, Wikidata, MediaWiki-extensions-WikibaseClient, Wikibase-Lua

May 14 2020

Uzume added a comment to T250763: Cannot use SyntaxHighlight: "Unable to run external programs, proc_open() is disabled".

This is actually a regression when the extension moved from GeSHi (PHP) to Pygments (Python): T85794: Convert SyntaxHighlight_Geshi from Geshi to Pygments (was: Don't register 250+ modules) Since MW is PHP the extension can just use GeSHi as a library without having to fork a separate process via one of the unsafe functions removed in the hardened PHP.

May 14 2020, 12:35 AM · SyntaxHighlight

Jan 24 2020

Uzume added a comment to T128173: Represent editions as interwiki links on Wikisource.

The issue becomes how to represent multiple edition links in Mediawiki toolbars across multiple WMF wikis across their projects. Currently, as implemented via WD sitelinks, we only allow one link per wiki per project per WD item. This is in part owning to the limited space in the Mediawiki toolbars where such links are displayed. Even across wikis within a single project when only a single link is allowed per wiki, there can sometimes be a *very* large number of links (there are many languages in Wikipedia alone and already there are mechanisms that limit the number of sitelinks displayed in the toolbar by default).

Jan 24 2020, 9:00 AM · Patch-For-Review, MW-1.35-notes (1.35.0-wmf.36; 2020-06-09), All-and-every-Wikisource, Wikidata

Jan 23 2020

Uzume added a member for All-and-every-Wikisource: Uzume.
Jan 23 2020, 3:46 AM
Uzume added a member for SDC General: Uzume.
Jan 23 2020, 3:18 AM

Jan 13 2020

Uzume added a comment to T128173: Represent editions as interwiki links on Wikisource.

@beleg_tal: I agree with your statements, especially "interwiki system needs to be flexible enough to accommodate different data models", however, I do not think this is an inherently Wikidata issue.

Jan 13 2020, 4:42 PM · Patch-For-Review, MW-1.35-notes (1.35.0-wmf.36; 2020-06-09), All-and-every-Wikisource, Wikidata

Jan 10 2020

Uzume added a comment to T54971: [Goal] Sitelinks and arbitrary accesses to Incubator, OldWikisource and BetaWikiversity.

I think we can remove OldWikisource from this task as concepts from this task that apply to it are now adequately covered by:

This task can now focus on just Incubator and BetaWikiversity.

Jan 10 2020, 12:25 AM · All-and-every-Wikisource, incubator.wikimedia.org, Goal, Community-Wishlist-Survey-2016, Wikidata, MediaWiki-extensions-WikibaseRepository
Uzume updated the task description for T138332: Interwiki links to/from Multilingual Wikisource.
Jan 10 2020, 12:07 AM · User-Ladsgroup, Wikidata-Campsite (Wikidata-Campsite-Iteration-∞ (On Hold)), MW-1.36-notes (1.36.0-wmf.28; 2021-01-26), User-notice, All-and-every-Wikisource, Wikidata
Uzume added a comment to T138332: Interwiki links to/from Multilingual Wikisource.

This should not be a blocking issue if we disregard T206426: Storing multiple sitelinks to a multilingual wiki which I do not think we should consider implementing except for possibly allowing sitelinks to be prefixed (a la Special:MyLanguage/) on their way to their target wiki. See my comment on that task.

Jan 10 2020, 12:06 AM · User-Ladsgroup, Wikidata-Campsite (Wikidata-Campsite-Iteration-∞ (On Hold)), MW-1.36-notes (1.36.0-wmf.28; 2021-01-26), User-notice, All-and-every-Wikisource, Wikidata
Uzume raised the priority of T138332: Interwiki links to/from Multilingual Wikisource from Low to Medium.
Jan 10 2020, 12:01 AM · User-Ladsgroup, Wikidata-Campsite (Wikidata-Campsite-Iteration-∞ (On Hold)), MW-1.36-notes (1.36.0-wmf.28; 2021-01-26), User-notice, All-and-every-Wikisource, Wikidata

Jan 9 2020

Uzume added a comment to T128173: Represent editions as interwiki links on Wikisource.

I am not sure this is a good idea or not (its seems like there maybe a few proposals) and I am against implementing this in Wikidata beyond how it already implements things (multiple linked records with one sitelink per wiki per item). That said, I see no issue with some wiki client like a Wikisource one implementing such a thing locally, e.g., perhaps traversing through linked Wikidata items via Scribunto Lua modules, to find all the sitelinks of all edition items of a specific work item they are all linked to, or other similar arrangements it wants to.

Jan 9 2020, 10:17 PM · Patch-For-Review, MW-1.35-notes (1.35.0-wmf.36; 2020-06-09), All-and-every-Wikisource, Wikidata
Uzume added a comment to T206426: Storing multiple sitelinks to a multilingual wiki.

I am against having multiple site links per wiki per WD item. On the other hand, I am not against having a translation system for these sitelinks and it might be good to have some method to automatically prefix item sitelink links to multilingual wikis using something like Special:MyLanguage/.

Jan 9 2020, 9:51 PM · Wikidata

Dec 9 2019

Uzume added a comment to T199887: Client equivalent of haswbstatement.

FYI: I made a comment on T185313: mw.wikibase.entity:getBacklinks (lua API in wikibase client) about the possibility creating a query service that stores results in Tabular Data (which is available at page render time via Extension:JsonConfig and Scribunto Lua).

Dec 9 2019, 5:08 PM · Wikidata-Campsite, Discovery-Search, Wikidata
Uzume added a comment to T185313: mw.wikibase.entity:getBacklinks (lua API in wikibase client).

I agree that Special:WhatLinksHere is probably not the right semantics for this request, haswbstatement might be better semantics, however, those need to be well defined so people know if in fact they would address this request.

Dec 9 2019, 4:53 PM · Wikidata-Campsite, patch-welcome, Wikibase-Lua, Wikidata, MediaWiki-extensions-WikibaseClient

Oct 23 2019

Uzume added a comment to T213300: Only confirmed users should read Wikidata's Special:MostLinkedPages.

I disagree. The availability of ones password does not fall into "security by obscurity" because it is, in general, not obscurely available from other sources (and if it is, that is an entirely different type of security issue). The point being, security should clearly delineate who has access to what and make all things available to such persons and noting of what they should not have access to. Since the concept of most linked pages is available via other public means this clearly falls into that the category of "security by obscurity" (unless you plan to secure the data through all means of access which seems to go beyond this proposal).

Oct 23 2019, 1:42 AM · Wikidata.org, Wikidata

Oct 11 2019

Uzume added a comment to T213300: Only confirmed users should read Wikidata's Special:MostLinkedPages.

I do not think this is a good idea. This amounts to security through obscurity and in general is not a good practice. The same data could be found in a number of other ways (e.g., api.php which would be even more useful to a potential vandal bot) and in the end does nothing to actually prevent any vandalism to begin with (just attempts to deter it by obscuring which pages have the most links). Also unconfirmed users (e.g., anonymous IPs) might have valid reasons to what to know which pages are most linked. We already punish such editors enough for the faults of troublemakers. I do not see this as a great way to protect our content from vandalism and it definitely punishes other users.

Oct 11 2019, 12:38 AM · Wikidata.org, Wikidata
Uzume added a member for Wikidata.org: Uzume.
Oct 11 2019, 12:24 AM

Oct 5 2019

Uzume added a comment to T47607: move Wikidata section to the top of Special:SpecialPages.

@jeblad: This seems like a problem:

Oct 5 2019, 4:48 PM · Wikidata, MediaWiki-extensions-WikibaseRepository

Apr 20 2018

Uzume added a member for Wikibase-Lua: Uzume.
Apr 20 2018, 1:01 PM

Apr 19 2018

Uzume added a comment to T127169: The property parser function and mw.wikibase.entity.formatPropertyValues should resolve item redirects when formatting Snak values.

This might get resolved by T112658, at least for the parser function.

Apr 19 2018, 10:28 AM · Wikibase-Lua, Wikidata, MediaWiki-extensions-WikibaseClient
Uzume added a comment to T157868: Lua functions do not resolve redirects.

This might get resolved by T112658.

Apr 19 2018, 10:27 AM · User-Addshore, MW-1.37-notes (1.37.0-wmf.3; 2021-04-27), Wikidata-Campsite (Wikidata-Campsite-Iteration-∞ (On Hold)), wdwb-tech, Wikibase-Lua, MediaWiki-extensions-WikibaseClient, Wikidata
Uzume added a comment to T192462: mw.wikibase.entityExists returns false for redirected entities.

This should probably be handled more generally along the lines of T157868 and T127169. This is exactly why I felt it was better to implement a mw.wikibase.resolveEntityId that returns the resolved eid or nil if it does not exist rather than just the true or false of mw.wikibase.entityExists. If we had a mw.wikibase.resolveEntityId we could funnel all code through it that needed to check for existence and redirection instead of making every other function handle redirection, etc.

Apr 19 2018, 10:21 AM · MW-1.34-notes (1.34.0-wmf.22; 2019-09-10), Wikidata-Campsite (Wikidata-Campsite-Iteration-∞ (On Hold)), User-Ladsgroup, Wikidata, MediaWiki-extensions-WikibaseClient, Wikibase-Lua

Apr 17 2018

Uzume added a comment to T179638: Property filter to reduce computing time of mw.wikibase.getEntity().

Perhaps this ticket is old but it seems to me we already have such filters with mw.wikibase.getBestStatements and mw.wikibase.getAllStatements. Of course those do not pull multiple properties in a single execution but they do filter to a single property without pulling the expensive complete set/tree of property data. One could easily create a function to execute one of these multiple times and combined the results to get what is requested in this ticket.

Apr 17 2018, 1:05 PM · Wikibase-Lua, MediaWiki-extensions-WikibaseClient, Wikidata

Apr 12 2018

Uzume added a comment to T127169: The property parser function and mw.wikibase.entity.formatPropertyValues should resolve item redirects when formatting Snak values.

This seems partially redundant with T157868, however I am not sure about mw.wikibase.entity.formatPropertyValues. I agree that Wikibase parser functions like {{#property:…}} should probably properly redirect, however, from Scribunto I would rather see mw.wikibase.getEntity and add a mw.wikibase.resolveEntityId implemented or perhaps also have mw.wikibase.getAllStatements and mw.wikibase.getBestStatements redirect.

Apr 12 2018, 3:21 PM · Wikibase-Lua, Wikidata, MediaWiki-extensions-WikibaseClient
Uzume added a comment to T157868: Lua functions do not resolve redirects.

T143970 seems like it was recently closed but I still think we need a resolveEntityId(eid) that returns nil when there is no such entity but redirects for merged items, etc. It could also potentially work like resolvePropertyId and return a valid entity ID when given an unambiguous label or alias.

Apr 12 2018, 2:56 PM · User-Addshore, MW-1.37-notes (1.37.0-wmf.3; 2021-04-27), Wikidata-Campsite (Wikidata-Campsite-Iteration-∞ (On Hold)), wdwb-tech, Wikibase-Lua, MediaWiki-extensions-WikibaseClient, Wikidata
Uzume added a comment to T143970: In Lua modules, there is no way to test for validity of Wikidata entity IDs.

Does entityExists properly handle redirects (e.g., merged entities) and if so how do we get the entity ID we are redirected to?

Apr 12 2018, 2:53 PM · MW-1.31-release-notes (WMF-deploy-2018-04-10 (1.31.0-wmf.29)), Wikidata-Ministry-Of-Magic, MediaWiki-extensions-WikibaseClient, Wikidata

Feb 10 2018

Uzume added a comment to T185557: Create the easy function mw.wikibase.property('P21', 'Q8023', 'en').

I have no issue with discussion and I believe this an adequate forum for such a discussion. My point was your requests are significantly lacking (and need discussion and focus) before they can be considered for possible implementation.

Feb 10 2018, 6:28 AM · Wikibase-Lua, patch-welcome, MediaWiki-extensions-WikibaseClient, Wikidata

Feb 8 2018

Uzume added a comment to T185557: Create the easy function mw.wikibase.property('P21', 'Q8023', 'en').

I agree. This request is poorly specified. For one, labels, descriptions, and sitelinks are not properties. Also how should these property values be handled? There are many property data types where the data is not necessarily a single scalar value. Also property claims can have unknown or no value in addition to a value. This ignores what to do when there are multiple property claims for the same property (or any comment about ranks) and is unclear how qualifiers or references should or should not be handled by this interface (although the second line in the description of this task quotes a qualifier access).

Feb 8 2018, 2:20 PM · Wikibase-Lua, patch-welcome, MediaWiki-extensions-WikibaseClient, Wikidata

Jan 23 2018

Uzume added a comment to T185313: mw.wikibase.entity:getBacklinks (lua API in wikibase client).

Well, although I can some similarities between this one and T99899, I believe there are different use cases involved. Lookup for external identifier is mostly needed in javascript (e.g. notify user that wikidata instance with the same imdb-id already exists) and can be implemented either via Markus resolver or directly via sparql endpoint (e.g. https://ru.wikipedia.org/w/index.php?diff=84445799). I can imagine some use cases where it would be nice to have it in lua (e.g. for additional decoration of wikipdate articles), but its exotic stuff. In contrast, building lists andbased on wikidata is more straightforward case and must be pure severside (for performance reasons), so I'd see a need for backlinks in lua.

Jan 23 2018, 4:02 PM · Wikidata-Campsite, patch-welcome, Wikibase-Lua, Wikidata, MediaWiki-extensions-WikibaseClient

Jan 21 2018

Uzume added a member for ParserFunctions: Uzume.
Jan 21 2018, 3:45 AM
Uzume added a member for MediaWiki-extensions-Scribunto: Uzume.
Jan 21 2018, 3:42 AM

Jan 20 2018

Uzume added a comment to T185313: mw.wikibase.entity:getBacklinks (lua API in wikibase client).

This seems like a more generalized version of T99899 (see also T149108).

Jan 20 2018, 8:44 PM · Wikidata-Campsite, patch-welcome, Wikibase-Lua, Wikidata, MediaWiki-extensions-WikibaseClient

Jan 15 2018

Uzume added a comment to T123196: Access to item from talk page.

@Tacsipacsi It sounds like you want: mw.wikibase.getEntityIdForTitle(mw.title.getCurrentTitle().subjectPageTitle.prefixedText)

Jan 15 2018, 10:01 AM · Wikidata, MediaWiki-extensions-WikibaseClient
Uzume added a comment to T143970: In Lua modules, there is no way to test for validity of Wikidata entity IDs.

We need a resolveEntityId(eid) that returns nil when there is no such entity. It should also handle redirects from merged items, etc. (also solving T157868). It could also potentially work like resolvePropertyId and return a valid entity ID when given an unambiguous label or alias.

Jan 15 2018, 9:18 AM · MW-1.31-release-notes (WMF-deploy-2018-04-10 (1.31.0-wmf.29)), Wikidata-Ministry-Of-Magic, MediaWiki-extensions-WikibaseClient, Wikidata
Uzume removed a member for Wikidata: Uzume.
Jan 15 2018, 6:55 AM
Uzume added a member for MediaWiki-extensions-WikibaseClient: Uzume.
Jan 15 2018, 6:54 AM
Uzume added a member for Wikidata: Uzume.
Jan 15 2018, 6:52 AM
Uzume added a comment to T182147: more convenience functions for Lua.
  • A boolean entityExists (T143970).
    • Use case: Currently, I see a lot of code that does if getEntity( … ) then, which is super-expensive for no reason. The cheapest workaround that currently exists is getEntityUrl, but thats awkward to use in an if.
Jan 15 2018, 3:49 AM · Wikibase-Lua, MediaWiki-extensions-WikibaseClient, Wikidata