About this board

Auto-copying page names as month item labels

Deryck Chan (talkcontribs)


Is there any chance MatSuBot may be configured so that it doesn't copy the "Portal:時人時事/" ("Portal:Current events/") part of the page name when handling month items?

Reply to "Auto-copying page names as month item labels"
Melderick (talkcontribs)

Hi Matěj

Volonteers have been testing the new version of moveClaims for a few months now. I only got positive feedback so I think you can merge it with your version whenever you have some free time.

Feel free to contact me for any support.

Melderick (talkcontribs)

Hi again, 2 persons mentioned that they used the wrong tab to move a statement from an item to a property (instead of moving it to another property of the same item).

I didn't know that the original code could do that. I have added a quick check in performMove and generate an error (differenttype) if oldentity and newentity don't start with the same letter. If you think moving to a different type is an interesting feature to keep, we could create a popup asking to confirm the move/copy.

Matěj Suchánek (talkcontribs)

Yes, this was intentional. Lexeme support, for example, was a goal. I don't believe it's a good idea to except properties just because of wrong input.

Feel free to work on this further, I'm not sure when I'll be available to update it.

Melderick (talkcontribs)

Hmm then how about having a warning and request a confirmation when you try to move a statement from :

Q1 to P1

L1 to P1

(Eventually P1 to Q1 or L1)

From what you said we want to keep moving from Q1 to L1, right ?

Another suggestions was to use a different color scheme for each tab to alert them but I am not a big fan of this.

Matěj Suchánek (talkcontribs)

Having reconsidered, I think the warning is a good idea. Although moving claims from an item/lexeme to a property should be possible, I suppose it's very rare.

Melderick (talkcontribs)

Hi Matěj, I finally found a way to manage the confirmation.

So, when you press Move/Copy to another entity, it checks that both entities are of the same type (meaning : both starts with the same letter). When it's not the case, it prints :

The current entity $1 and the new entity $2 has to be of the same type. Use the above checkbox to override this control.

And a new checkbox appears : Allow type mismatch:

Now, if you check it and press Move/Copy again, it will accept to do it.

If you press Move/Copy with the checkbox unchecked it will print the same message again.

Of course, every time you open the dialog, the checkbox is unchecked and hidden.

What do you think ?

Now that I have read our past discussion, I wonder if all this control should not be made only if the new entity is a property ? Allowing a flowless copy/move between an item and a lexeme...

Matěj Suchánek (talkcontribs)

Hi, thanks for continuing work on this. I wouldn't block moving to lexemes, I believe Lids are not ambiguous. Unlike Pids which has been confused recently. (@Spinster: As you did that mistake, would you find this feature useful?)

@Jura1: You have recently moved content to Property:P8150, what do you think?

Spinster (talkcontribs)

Hello @Matěj Suchánek - yes, I was confused because I thought I was moving a statement from one property to another in the same Wikidata item. If that is a feature you are thinking about: that would indeed be very useful (especially for statements with references which would be tedious to swap to another property in the same item). Thanks for all the work you do!

Melderick (talkcontribs)
Spinster (talkcontribs)

@Melderick Thanks, I just did some tests in the sandbox indeed. The modification is great, thank you - it has indeed prevented me from making that mistake. I think, however, that I found a bug (at least when editing in the sandbox): when I attempt to move a claim from one property to another in the same item right after creating that claim, it gives me the error message 'There was an error editing the entity: no-such-entity' - but when I reload the item, it works fine. Or is this intentional?

Melderick (talkcontribs)

@Spinster hmm I have tried to move a newly created claim and I got no error. Can you reproduce the bug ?

Reply to "moveClaims"
Vanbasten 23 (talkcontribs)

About this edition thank you very much. I was thinking about to program this, and now i see that you did it, perfect!!! Thanks!!!

Matěj Suchánek (talkcontribs)

Yeah, you are welcome. In fact, I had made the bot quite some time ago but the query it used began timing out, so I had to find some time and optimize it (with some compromises).

Reply to "Dates"
Herzi Pinki (talkcontribs)

Hi, stumbled across your import from de:WP: from (the current version at the time of import). Coordinates differ, it is unclear to me, why. As the decimal values are identical. Might be caused by different precisions, see also https://phabricator.wikimedia.org/T250627 Just to get your support on the phab-ticket.

Matěj Suchánek (talkcontribs)

Hi, the precision is determined by Pywikibot, specifically this method. As for the bug report, you've got the point that the looks strange but I cannot help with debugging now.

Reply to "unclear import of coordinates"

Need a means to create edition from File:

Billinghurst (talkcontribs)

I tried to cheat to create an edition using the WEF framework tool from Commons from the file, with the intention to delete the File: link after completion, though was rightfully defeated by AF/37. It would be really useful if there was a means to create the item from the file and leave the c: ink empty, and then I can reverse inhale the Q-item into the book template, or in the situation of a book item at Commons, just then delete the c: link.

Billinghurst (talkcontribs)

Even the ability to create an inhaleable file. I find it totally annoying to have to flick back and forth between screens and add fields one by one, whereas WEF allows a one-off push. Works well from elsewhere, though cannot do it natively from Commons.

Here I wanted to create the data file first as there will be nothing at enWS for a while until the transcription is done, and there won't ever be the work at enWP. So the first step introduction of a work to WMF wikis is inhibited.

Matěj Suchánek (talkcontribs)

Hi, sorry to hear that. My first thought was if WEF could be told not to add links to file but export the rest. If not, what do you suggest? An exception for new items if exported using WEF from Commons?

Billinghurst (talkcontribs)

WEF has an import function, though I haven't found any specs for its use. We already leverage the book template to import into the fields at our Index: ns through the script s:en:MediaWiki:Gadget-Fill_Index.js which leverages the same script frWS s:fr:MediaWiki:Gadget-Fill_Index.js.

Maybe it is better to create a pull mechanism at this end where {{book}} is used. All out of my pay scale, I just know that there has to be a better way.

Reply to "Need a means to create edition from File:"
Jura1 (talkcontribs)
Matěj Suchánek (talkcontribs)

The filter is supposed to catch descriptions identical to labels. But the detection for new items was created when items were created from scratch, not in a single edit. (The filter really is hackish.) I will fix this.

There is also Special:AbuseFilter/74 which we already talked about.

Jura1 (talkcontribs)

Thanks for looking into filter 64.

Indeed, I had in mind that other filter (74) we already talked about.

Reply to "filter 64"
Jura1 (talkcontribs)

I wonder if we should have a warning filter for edits like this:

Matěj Suchánek (talkcontribs)

There isn't much information the filter would use to identify those: Special:AbuseFilter/examine/1182552819. Except for the edit summary and the amount of removed data. quarry:query/42666 shows this would also catch some maintenance, mass-edits and edits using moveClaims. (Moreover, edit_delta look different in the logs, doesn't it?)

Jura1 (talkcontribs)

Indeed not really great. Maybe:

  • page_namespace: 0
  • edit_delta: > 200
  • user_editcount: < 20000
  • summary: wbremoveclaims-remove:1 , but no tool (#)
  • removed_lines: .*P248 .+P248 .+ (for two stated in (P248))
  • page_age: > 86400
Matěj Suchánek (talkcontribs)
Reply to "referenced statements deletion"
Jura1 (talkcontribs)

seems this went through

Matěj Suchánek (talkcontribs)

We didn't catch removals. Fixed.

Reply to "filter 101"
Jura1 (talkcontribs)
Matěj Suchánek (talkcontribs)

Done what you had wished.

Jura1 (talkcontribs)

Thanks. It seems to work as intended.

Jura1 (talkcontribs)

Do you think this could work for something like a glossary?

One of the questions would be how much formatting one would want to include. There seem to be at least three aspects:

  1. bold/italics
  2. anchors to other entries
  3. {{See}}

Depending on how it's done, the text might be usable outside Wikidata (by stripping formatting or generating links).

Matěj Suchánek (talkcontribs)

Interesting. It's likely to become more "obscure" to amend present entries. Also, it's somewhat striking that only English definitions are stored on items, whereas the translations are done as before. I wonder if lexicographical data model could help.

Anyway, I can't see a gain right now. What problem you think will this solve? Do you think this will encourage more translators? You mentioned reuse outside Wikidata but I'm sure what you mean with that.

Jura1 (talkcontribs)

Specifically for Wikidata:Glossary:

  • The current page doesn't seem to be much used (looking at pageviews), updated (looking at edits) or expanded by other contributors (are the additions in the last two years limited to "Sense", "Form", "Lexeme", "Wiki", all available in other glossaries?)
  • One can't find easily what has or doesn't have an entry.
  • Duplication with other glossaries happens.
  • The relation to Wikidata items about the concept is missing, making it rather unstructured.
  • There is a risk of anchor duplication.
  • Entries may be out of sync from the help page they point to. Editors of the help page may not be aware of the glossary entry.
  • By adding the glossary entry to items, one could query them directly with WQS. Users could generate a glossary for their concepts on the fly. Duplication with other glossaries would be less likely.

Personally, I found the formatting of the current page fairly complex, but maybe I'm too much used to Wikidata. Still, I don't think the rewrite done in 2016 (User:Filceolaire/Draft:Glossary) made it into the current format. The additions since the initial version seem somewhat limited. Others edits are probably still done entry by entry (entries can be fairly unrelated), so that wouldn't change much. To change several at once, one could do it on a spreadsheet and use QS.

  • We could store the translations on items as well, but it would complicate translators' work. The use of the translation extension seems to be the main benefit of the current format.
  • That it is the English version that is stored primarily isn't much different from today. To get translations, one will be able retrieve conviently named pages like Translations:Help:Glossary/15397819/fr (identified by the number of the QID the entry is on).
  • Other approaches for some of the above are possible. Not sure about the glos function on lexemes. Maybe it's just that I don't like typing into 16-character display field. Its output on Listeria would be similar.

Obviously, a link to edit the entry is needed. Would it be better at the beginning or the end of the entry?

Jura1 (talkcontribs)
Reply to "filter 91"

Opět: na datech japonština s čínským přepisem do pchin-jinu

Kusurija (talkcontribs)

Tuto chybu považuji za nutné odstranit, pokud to nejde jinak, tak aspoň kompletním odstraněním přepisů z japonských položek (protože v japonštině to zní absolutně odlišně).

Matěj Suchánek (talkcontribs)

Bohužel nemám dostatek informací, abych mohl tento problém řešit (ani odkaz na předchozí diskusi, vzhledem k tomu, že tato je uvozena "Opět:"). Pokud jde o problém UI, neřešil bych ho, protože to je pro Wikidata podřadné. Pokud jde o nějaký špatně zavedený postup, doporučuju o tom informovat všechny.

Kusurija (talkcontribs)

Co je UI?

Matěj Suchánek (talkcontribs)

Uživatelské rozhraní (User Interface). Tedy jestli to je věc prezentace na stránkách wikidata.org nebo jestli je to (systematický) problém s ukládáním dat.

Kusurija (talkcontribs)

Aha. Stejně nerozumím otázce. Kde? Nu, dejme tomu, že jsou teď důležitější věci. Příklad: Nagasaki - u japonského 長崎市 [nagasakiši] se zobrazí "transliterace": 長qishi, u Ósaky u japonského 大阪市 [Ósakaši] - da阪shi u její čtvrti Konohana se u japonského 此花区 [konohanaku] zobrazí cihuaqu. Jinde jsou ty rozdíly ještě markantnější. Uznejte, že cihuaqu není rovno [konohanaku].

Matěj Suchánek (talkcontribs)
Reply to "Opět: na datech japonština s čínským přepisem do pchin-jinu"