User Details
- User Since
- Nov 12 2016, 7:19 AM (331 w, 4 d)
- Availability
- Available
- IRC Nick
- mahir256
- LDAP User
- Mahir256
- MediaWiki User
- Mahir256 [ Global Accounts ]
Thu, Mar 2
I am here just to second the aforementioned concerns and would support a format that merely displays any gloss, rather than give up, if neither my interface language nor any in its fallback chain are present on a sense.
Feb 13 2023
As there are both form identifiers and sense identifiers, having wikidata:identifiers for forms and senses would be useful, and as there are around 12.1 million forms and around 300,000 senses, I am willing to supplement Nikki's offer by removing 6.7 million more unnecessary triples from a variety of places.
Feb 8 2023
Jan 11 2023
Nov 11 2022
This may be related to UniversalLanguageSelector (whose Hindi Transliteration input method was used to type the word in question).
Oct 27 2022
This task asked for lexeme support as well and T320889 hasn't happened yet.
Oct 16 2022
Oct 12 2022
Sep 8 2022
Sep 7 2022
Aug 30 2022
Aug 22 2022
Aug 19 2022
Aug 16 2022
Aug 3 2022
Jun 22 2022
Here's an example of this phenomenon on iOS 12.5:
May 26 2022
(Perhaps being tired of my complaints raised in another forum led to the dearth of detail in the initial task description, but...)
When I click "edit source" on that page, and I type "Z10004" into the dropdown next to "value" for the field whose label is "catena" and save, the field's type changes from "Reference^(String)" to "Reference^(Reference)", rather than to "Reference^(Catena)" as I would expect.
- Is there any indication it is specific to Beta cluster? (i.e. does the same workflow work as expected in a dev environment?)
The type creation interface on notwikilambda.toolforge.org is broken, since on adding fields to a type in the CreateZObject page there I am not prompted to name these fields nor shown the ID (Z12345K2 etc.) that they would have, so I have no clue as to this point.
May 25 2022
tools-sgebastion-10.tools.eqiad1.wikimedia.cloud:/home/mahir256/2fa-reset-request.txt should contain a link to this task.
May 21 2022
May 19 2022
May 9 2022
I will fully accept the first two bullet points you mentioned, and to some extent the third bullet point, but believe the fourth is somewhat limited and must take issue with the fifth.
May 7 2022
May 6 2022
Apr 12 2022
Apr 11 2022
Yes, w.wiki/bKf (for all train lines emanating from St Pancras) and w.wiki/4xyY (for the path from Narvik to Singapore) use that service.
Mar 20 2022
Let me rephrase, then: please tell that user "Would you mind re-hosting all of your scripts on Meta, rather than on wmflabs, and adjust your documentation to follow suit, given that people find those scripts so extremely useful that they enable them for everyone, even with the apparently mistaken assumption that wmflabs is a production server?"
As this is not the first task involving the use of @Pathoschild's script, you may wish to complain to that user that people find those scripts useful enough to consider them a default staple for others.
Mar 17 2022
This may be substituted with the same font hosted on wmflabs's FontCDN:
The two references to fonts.googleapis.com use fonts which exist on wmflabs's FontCDN and can thus be substituted accordingly:
Mar 13 2022
Feb 9 2022
Is this better merged into T298633 as a general graphical-programming-language support task?
Dec 22 2021
I'd like to suggest a change to infer the spelling variants from P220 or P305 per T284882.
Dec 14 2021
I must agree with Xover's comment regarding the provision of a next link on a main page. While attempting to provide such a link using JavaScript and the mw.Api may be possible, I do not think that it is necessarily the most efficient use of resources when loading a Wikisource page, given that each time a page is loaded the table of contents portion of an index needs to be rendered again (meaning after ProofreadPage does so once) to determine which link to add. (The alternative would be to add the next link manually to the page, which does not fully comport with the underlying motivation behind this task.)
Nov 24 2021
Nov 22 2021
Now that we are on wmf.9, I see that for this index, with "data": "toc" set for the table of contents ("Remarks"), and without using the trick mentioned in T285610#7267935 on that index, the second chapter still does not link to the first chapter or vice versa. Is there something we need to refresh on our end for the effects of this patch to be visible?
Nov 21 2021
Nov 12 2021
We have an as-yet unused "Query:" namespace ; perhaps it could be opened for storing queries longer than 2000 characters? (A redirection mechanism such that a visit to any page in that namespace takes you to query.wikidata.org might be useful, and there ought to be a system, similar to what is done with CSS pages, that ensures that a query is syntactically correct before it can be saved to that namespace.)
Nov 9 2021
If we're rejecting tlh as a monolingual text code (and not as a lexeme language code), would someone like to do the honors and purge the Lexeme: namespace of Klingon lexemes?
Nov 7 2021
Per https://www.mediawiki.org/wiki/Wikibase/Indexing/RDF_Dump_Format#Truthy_statements, "Truthy statement predicates have prefix wdt: with the property name (e.g. wdt:P2)" and "[I]f there is a preferred statement for property P2, then only preferred statements for P2 will be considered truthy. Otherwise, all normal-rank statements for P2 are considered truthy." As your screenshot indicates, "visual artist" is a preferred occupation statement (the little shaded up arrow on the left) and the other occupations are normal-rank statements (the little shaded dot between the two blank arrows).
Oct 31 2021
I'd be interested in such a thing for bnwiktionary.
Oct 24 2021
Oct 23 2021
I would like to propose bn.wiktionary as a test project for this, with an intended use case being the construction and display of inflection templates for nouns and verbs.
Sep 30 2021
Sep 29 2021
For those who would like a clarification,
please refrain from editing the task description while the discussion is ongoing.
this is the former part of Lucas's message
It is inappropriate to masquerade your personal opinion as the hard-won consensus that we are trying to achieve here.
and this is the latter part.
please refrain from editing the task description while the discussion is ongoing. It is inappropriate to masquerade your personal opinion as the hard-won consensus that we are trying to achieve here.
This message (especially the latter part) is enough of a reason to undo the changes made to the ticket since Nikki's comments were added, irrespective of what opinions I may hold of any of it (which should not be assumed as was done in the diff that stains this task). The sea lion I am removing from this ticket is also free to impugn Lucas's or Lydia's credibility or emotional strength as well.
@Lucas_Werkmeister_WMDE that should have been. I removed Mahir256 as they seem to be doing nonsensical edits to subscribers.
The presence of the user I am removing—not just here, but in any other discussion forum really—has made @Nikki (and others, both actually and potentially) sufficiently uncomfortable directly opining here and in those other fora that others like myself relay their opinions here for them. Unless that user wishes to impugn the credibility or emotional strength of Nikki and those other individuals, I contend that my actions in this regard are entirely sensical.
Sep 27 2021
The following is a comment made in another forum regarding this ticket by User:Nikki, who has allowed me to repost it here after some copy-editing in good faith:
Sep 20 2021
Aug 28 2021
Yes, one of the goals is item cleanup, so such an error should be triggered.
Aug 27 2021
I'd be interested to learn of a situation in which the addition of a label in this code with the intent described would cause things to backfire.
Are any of these actually useful?
This task is not intended to answer this question; since someone has found it useful to have access to this specific string in every language, using 'mul' is a more efficient way to address that.
Wikipedia disambiguation pages are handled very badly in general on Wikidata. It requires real structure and not a language code hack.
Can you elaborate of what's not "real" about the mul code with respect to disambiguation pages? While I'm sure there's much to improve for that category of item, that's not necessarily an argument against the introduction of this code for other purposes demonstrated.
This sounds like the right behavior. What if in some language the label was different? Asking seriously.
If the label in some other language is different from the "mul" one, then there's absolutely no harm for another language to add a different label. With respect to astronomical objects, on the typical multi-labeled item, only the Bengali label (and the Malayalam one, if it exists) is different from the rest, and thus would be preserved in the presence of a "mul" code; all others, being identical to that of the "mul" code, would be eliminated. (Again, if later one of those languages needs a different label from that of the 'mul' code, it is free to add that different label, and not the same one.)
As with the galaxy, it doesn't look wrong.
See the argument re: galaxies.
Aug 13 2021
Aug 11 2021
Aug 7 2021
If the recent--judging from when label statistics started to note them--introductions of languages of Cameroon as languages for labels/descriptions/aliases is any indication, this request is likely for the same thing.
Jul 30 2021
While I've undone edits on the last three of Nikki's examples (since those examples are frankly quite ridiculous), I otherwise agree with what is stated in that comment.
Jul 29 2021
I also don't think disallowed codes should be excluded from a revert, in the interest of keeping behavior consistent with how deleted items/properties are dealt with.
Jul 20 2021
Jul 6 2021
Jul 5 2021
Jul 2 2021
Jun 29 2021
Jun 28 2021
Noting that no formal documentation of the behavior of concern in this task was yet provided by this task's objector, despite the assertion made that it exists:
Jun 27 2021
The relevant piece of logic which this task considers was introduced in this commit, three years before Wikidata's launch and thus three years before the idea of pulling in information for an index page would have been conceived. We on the Bengali Wikisource, in the interest of modernizing the functionality of our site beyond the old days of direct {{header}} use and pre-Scribunto capabilities, are trying to embrace the benefits that Wikidata provides to the extent that it can support the metadata of index pages, and this necessarily extends from the slow discontinuation of certain index fields to the integration of their replacements in main namespace pages, in addition to the sometimes semi-automatic maintenance of some other namespaces. I can accept that such an attitude as we espouse may be foreign and uncomfortable to certain Wikisourcerors, but that doesn't mean that the software—which I feel the need to assert we wish to share with those Wikisourcerors—should continue to hold other communities back (or that the effort to defend what's being requested in this task is misplaced).
We are using the "wikidata-item" field as the dedicated field for the Qid. As (implied, maybe should have been expressed better?) in the sentence following that to which you replied, a link to where the work is transcluded would have been the use for the "title" field before, but that link has been migrated to a sitelink on a Wikidata item, which can be retrieved using Lua's mw.wikibase functionality, thus making it redundant to retain it in the index page.
As part of an effort to increase integration of the Bengali Wikisource with Wikidata, we have begun migrating most information within index pages that can be migrated to Wikidata items. As a result, the only free-text field in ProofreadPage that is frequently non-empty before the pagelist is the "wikidata-item" field, holding the Qid of the work's item. The "wikidata-item" field is used directly within our implementations of "Module:Header template" and "MediaWiki:Proofreadpage index template" in retrieving the migrated information for display in the appropriate places. Turning that field into a link makes processing it, even if it's merely a matter of stripping the link syntax, just a bit more complicated than it needs to be. If the information above the pagelist field is already on the Wikidata item, then adding a link to any of the fields above the pagelist becomes redundant.
and some sketch of a hypothetical better solution.
The simple fix I propose is a direct solution to the problem and to the extent I am aware of would not adversely affect most other generated headers. (I'd be interested in seeing where an adverse effect might occur, if at all.)
Yes, I'm aware that throwing in an extra link is one way to sidestep the issue, but I wonder if the underlying assumption is worth hardcoding in the extension at all.