User talk:Solidest

Jump to navigation Jump to search

About this board

78.162.128.147 (talkcontribs)

Hello, Solidest.

Can you add the Wikilink ie:Categorie:Valuta from Interlingue Wikipedia, which I just created, to the corresponding but protected Wikidata page of "Category:Currency" (Q6959409)?

Thank you in advance. 78.162.128.147 17:16, 19 October 2024 (UTC)

78.162.128.147 (talkcontribs)

Can you add it? You were the last person who updated that page. 78.162.128.147 23:33, 19 October 2024 (UTC)

Solidest (talkcontribs)

Hi, I've added it, but you should make such requests in the appropriate place or either register an account and do it yourself next time.

78.162.128.147 (talkcontribs)
Reply to "Request"
Vargenau (talkcontribs)
Solidest (talkcontribs)

Greetings. I do all merge edits in semi-automatic mode via QuickStatements. And the fact that items are not merged completely (the original page is not changed to redirect) is a bug of QuickStatements, that should fixed by Magnus. We have a special bot that goes and finalises such unfinished merges by placing redirects. But here, since I or someone else made additional edits (via prepared dumps, which updates in a few weeks), specifically descriptions in two languages here, they remain unmerged. I'm not sure if I can find such cases to merge them manually, but I'll try later today. Presumably there could be several hundred/thousands of such cases that have appeared over the years - I've already spotted them before.

Vargenau (talkcontribs)

Hello,

Thank you for your answer.

Has a bug been filed for QuickStatements?

I have fixed several pages, but there are so many that it is impossible to do all by hand.

Best regards,

Solidest (talkcontribs)

I haven't personally reported this bug yet, as I haven't checked if anyone has already reported it or not (given that the bot that finishes the merges exists, I assume it's a known bug), but it should probably be done, even if it's a dupe.

Regarding these cases, I've managed to create a query to find all such items. This is a query for all items with a specific category description in a language without p31 and without sitelinks: https://qlever.cs.uni-freiburg.de/wikidata/h8DH0o - the results are a bit sloppy, as for some reason it doesn't exclude all items with sitelinks (given that the dump is also from 28 August). With the English description there are about 20 such cases, with the Russian description there are about 150. Now I will try to get the logs of these batches and run the merge on these items again.

Solidest (talkcontribs)
Vargenau (talkcontribs)
Solidest (talkcontribs)

Yeah, you could modify the Qlever query above with a ?item schema:description "page de catégorie d'un projet Wikimedia"@fr . line to find all French cases. I only searched and corrected English + Russian cases, as I only added those descriptions with my bot. The listed cases most likely appeared after merges via the https://www.wikidata.org/wiki/Special:MergeItems page, as the edits do not have a tag from the built-in merge gadget that places redirects properly. UPD: Never mind, this page also places the redirects correctly, then I don't know why it happens - maybe really a problem in the API as Magnus wrote.

Reply to "Incomplete merge by Sldst-bot"

TMDb movie ID removal undone for Q21716105

2
Talestalker (talkcontribs)

Hi,

I've noticed that you've reverted my edit removing the reference to the TMDb movie ID 384796 for the TV series Zločin v Polné (Q21716105) with the comment: "it's correct for WD, but needs to be resolved on tmdb as duplicate".  

This is a Czech TV series that was later edited into a TV movie version. Therefore, according to TMDb rules, only the TV series version is valid and the TV movie must be removed. I am a mod on TMDb and on Wikidata I primarily handle TMDb - Wikidata - IMDb matching and correcting errors for entries related to the Czech and Slovak film and TV industry. On TMDb, I have proposed a merge of the duplicate entry, but this has no set date for completion and the duplicate entry will thus probably remain with us for some time. Therefore, for now, I have at least removed the IMDb and Wikidata links (link needs and TMDb account) for it and locked them. On Wikidata, I deleted the link to our TMDb movie entry, because it is slated for removal, is not valid, and we don't want users to use it, even though it still exists. The only valid entry on TMDb, which incidentally Q21716105 links to, is TMDb TV series ID 79969.

When editing Wikidata, I always try to stick strictly to the rules and prefer not to make any changes if I'm not sure. However, in the matter of the validity of TMDb references, I dare say that I have inherently enough authority to determine whether a reference to our database is correct or not, so I would be happy if the link to TMDb movie ID 384796 could be removed. After all, the TMDb movie ID was only added to Wikidata by the bot, based on IMDb ID matching, which is no longer possible now that I have deleted all references to IMDb and Wikidata from our movie entry.

Thanks,

talestalker

Solidest (talkcontribs)

Greetings. Thanks for the explanation. I also do my own tracking of disabled and duplicated IDs from TMDB, and generally leave the ones to be removed from the site (as they sometimes come back due to automated tools and bots), but I have nothing against removing it now, what I have already done.

By the way if you're interested in tracking all the duplicates and multiple ids in individual Qitems, you can check them here: Movies, TV series. I've reduced the films to complex cases only, but the TV series still have a lot of merge candidates and errors.

Reply to "TMDb movie ID removal undone for Q21716105"

Managing the properties of a multimedia franchise

3
Wiccio (talkcontribs)

Hi Solidest! I am writing to you to try to understand how I should behave so that I will be better prepared in the future, as I am a relatively new user. I would like to bring to your attention this reset of one of my moveClaims: this one. Since it is a property related to a film, I had moved it from the entity page as the latter relates to the TV series. Was I wrong? (Leaving aside the fact that you have now turned the entity page associated with the film into a page associated with a children's book). If the entity associated with the film no longer exists, shouldn't this entry not be here?

Solidest (talkcontribs)

Hi. Please note that before your edits this entity was already set as p31 = written work, and the English description was incorrect. In cases where an entity has a lot of misconnected statements and sitelinks describing different things - the correct approach is to check the earliest versions of this entity and design it according to the original meaning. In this case it was also originally p31=book. So moving film statements in there was a mistake.

Speaking of franchises, they are usually arranged as a separate item with p31=media franchise and wiki articles where it is explicitly stated that it is a franchise are moved there. If the article simply describes the original work first, nowhere saying about the franchise, you can leave that article with the original work item as in this case (but you can also move it to a franchise - there's no strict approach here).

In this case, the correct thing to do would be to create a new item for the film and move all statements there. But there's a problem here - this 2005 film doesn't seem to exist, judging by the text of the articles and external ID pages, it seems to be a DVD compilation of several episodes from the series. Lumiere ID is linked to series' IMDB ID.

I think sometimes people create items for such DVD editions (need to recheck), but I think it would be more correct to report it to TMDB for deletion, and with that usually some related external IDs disappear as well. So I'd rather just remove the incorrect IDs, and moved what can be attached to the series there, which I've already done.

Wiccio (talkcontribs)

You're right, I had not checked the chronology but rather took for granted that the entity was connected to the film simply by reading the English description. It was shallow of me, mea culpa!

Thanks for the replies, now I understand, I hope to be better prepared for future edits. I will try to open a ticket on Lumiere to investigate the existence of the film for this specific case, even though I have unanswered open tickets on their portal for years. IMDb, however, is unlikely to be wrong, so as you said, probably only the TV series exists.

Reply to "Managing the properties of a multimedia franchise"
Plexci (talkcontribs)

You wrote "lower ID is preferred when merging". That's not right. There is no guideline or a rule that confirms your claim see Help:Merge. The first identifier came in October 2023 and so far this object was nearly empty. The merge in this one doesn't make any sense and you lose the history

Solidest (talkcontribs)

Lower ids merge is a common practice that works for all databases and wikis as well. I don't know where in the rules it's written, but it's something that's been followed on wikis probably since their inception. So by saying that “that's not right” you are wrong.Many tools work by linking to earlier identifiers (like Mix n match), and so that's why it's important, in addition to tracking history. But in this case it looks like you're right that the earliest ID was a redirect first, so it's ok to merge into the newer ID. But judging by the size of the history of both items - the difference in this case is not significant and both options are acceptable.

Reply to "Version of Merge"
Infovarius (talkcontribs)

а если она намеренно отличается от титула в рувики? Чтобы придать более точный смысл элементу и отличить от похожих категорий. Например, здесь.

Solidest (talkcontribs)

Надо решать через переименование самих категорий в википедии, т.к. на викидате есть механизм, который запрещает давать двум элементам категорий одинаковые метки. И такие кастомные названия скорее мешают отслеживать актуальную ситуацию, когда должны были бы помогать находить то, что нужно переименовать. Например я таким образом вчера ru:Категория:Эксперименты перенёс из Category:Science experiments (Q8717332) и создал вместо неё новую, соответствующую смыслу. Поэтому по-моему лучше точные названия добавлять в алиасы, а в основных оставлять то, что есть.

Infovarius (talkcontribs)

Спасибо за Эксперименты, я согласен. А началось всё в Q8717332, между прочим, с того, что я указал в ней более точную (с т.зр. смысла элемента), пусть и не совпадающую в русским титулом, метку. Если бы я оставил подправленную ещё одним "автоматчиком" метку "Категория:Эксперименты" никто бы, вероятно, и не заметил, что содержимое русской категории не совсем соответствует элементу.

Solidest (talkcontribs)

По сути вы были тем, кто заметил проблему и должен был ее исправить. Но вам было лень и вместо этого решили сделать ошибочную правку, в надежде, что тот, кто будет исправлять её сделает и разделение категорий за вас. Так и произошло, и это некорректный подход по решению ошибок - это буквально как заниматься вандализмом, в надежде что кроме него исправят и другие проблемы. Другие люди просто бы вряд ли стали делать что-то с категориями, и я также не стал этого делать в десятках других случаев, где просто вернул заголовок.

Infovarius (talkcontribs)

это хорошее решение, да. Но если в ВП только одна категория из ряда (и поэтому ей уточнение не положено), а в ВД их много и поэтому без уточнения было бы неправильно. Например: Категория:Родившиеся в Аксае (Дагестан) (Q32234888) (есть другие Аксаи и другие категории про них).

Solidest (talkcontribs)

Я не вижу пользы от простановки таких уточнений на ВД у категорий. У заголовоков категорий другая роль в отличии от заголовков обычных элементов, где такие уточнения важны. С категориями мы по сути работаем лишь однажды, когда проставляем утверждения и подключаем их к основному элементу — поэтому и возник механизм проверки их на дублирование. А у обычных элементов заголовки используются постоянно, т.к. элементы регулярно используются и связываются между собой. По сути заголовок категории - это имя собственное, а характеризовать их должны не кастомные уточнения в названии, а стейтменты.

Infovarius (talkcontribs)

В идеальном мире да, однажды. Но в случае неоднозначности нередка ситуация, когда интервики присоединяют в неверный элемент категории, чего вероятность можно уменьшить с правильным именованием.

Solidest (talkcontribs)

Я не понимаю почему мы должны подстраиваться под тех, кто совершает ошибки, недосмотрев что-то. Как и не понимаю почему мы должны создавать условия для таких ленивых редакторов, которые делают что-то не глядя, создавая почву для других неточностей и ошибок. Мы этого и не делаем, и это реальность, а не идеальный мир. Я получаю списки категорий в списках подобных таким: ru:Проект:Компьютерные игры/Жанры и сравниваю их с привязанными статьями. Мне нужно видеть какие категории нужно переименовывать (я таким образом там уже около 5 категорий переименовал). А подстраиваться под тех, кто якобы может совершить ошибки - лишает меня этого и поэтому я против такого подхода.

Infovarius (talkcontribs)

вы получаете списки, сравниваете с основными статьями - замечательно. Но проверяете ли соответствие русской метки (и русской категории вообще) ВСЕМ другим языкам? Если нет, то вас можно назвать ленивым редактором именно по вопросу работы с интервики. Я вот стараюсь это делать, и поэтому выбираю метку исходя из суммарного смысла по всем языкам.

Solidest (talkcontribs)

Хорошо, но я по-прежнему не понимаю почему вы считаете, что указание кастомного заголовка приносит кому-то пользу. Если вы видите, что текущее название категории неправильное и не соответствует смыслу привязанных - значит с ним и надо разбираться на вп.

Solidest (talkcontribs)

Если на ВП такое уточнение не нужно, то и на ВД оно тоже не нужно. Можно просто не ставить заголовки у несуществующих категорий, а сперва дождаться их создания и тогда уже понадобиться решать проблему уточнений на ВП. Так как по сути элементы категорий - это сущности других проектов, которые мы описываем на ВД как есть, а не пытаемся улучшать их и менять им названия.

Infovarius (talkcontribs)

а вот с этим не согласен. Викиданные не придаток Википедии. Викиданные просто более полно описывают всё, и нам нужны русские метки для всего. А на ВД без уточнений получится либо неоднозначность, либо невозможные дублирующие пары "метка-описание".

Solidest (talkcontribs)

Из моей фразы и не следует что ВД это придаток ВП. Речь ровно о том, что категории - это внешние сущности, которых не существует на ВД (хотя всё же существуют тут, но категоризуют только страницы помощи и документацию). ВД лишь описывает эти внешние сущности. Описывает утверждениями и связями с другими элементами, а заголовки передают их имена собственные, и поэтому они должны оставаться неизменными. Если же этой сущности нет, то можно дописать ей заголовок, а можно не дописывать. В случае с обычными статьями википедии - мы создаем элементы именно для концептов в первую очередь, а не для ВП-статей, и поэтому там допускаются свободные заголовки элементов. В случаях с категориями мы описываем конкретную внешнюю сущность иерархии других проектов, у которых всегда только одни названия. По сути и алиасы созданы для тех википедий, где разрешаются редиректы. Идти ли на опережение и придумывать как должна быть переименована категория на рувики - это странная практика, но наверное допустимая (только не расстраивайтесь, если такие переименования будут возвращать, ботами или теми, для кого это не очевидно и не нужно).

Infovarius (talkcontribs)

категория - не одно название. Категория тоже концепт (коллекция статей в языковом разделе, объединённая конкретным признаком). По сути чем-то похоже на элемент-класс.

Solidest (talkcontribs)

Это справедливо только в тех случаях, когда на вд сущность категорий оформлена некорректно. И это либо с первого дня неправильно привязанные категории, либо категории-мутанты, нарушающие правила ВП, либо нелепые изобретения участников ВД. Других случаев я не встречал. И это всё также должно решаться через перемещения и переименования, а не через создание видимости, что всё в порядке. Я не в одном из ваших возвратов не увидил таких случаев, чтобы ваши варианты нельзя было разрешить изменениями названиях через вп. Случаи с уточнениями регионов должны также решаться через ru:Шаблон:Категория-неоднозначность, даже если второй вариант будет красной ссылкой.

Infovarius (talkcontribs)

К тому же после ваших правок получаются дубликаты "метка-синоним": https://www.wikidata.org/w/index.php?title=Q9611123&oldid=2104061228. Т.е. некачественные данные. Если уж проводить такие ботоправки, я бы рекомендовал заменять возникающее дублирование в синонимах на прежнюю метку.

Solidest (talkcontribs)

Дублирующиеся с основными заголовками алиасы вычищаются ботами отдельно. Нужно ли сохранять предыдущие названия в алиасы - это отдельное обсуждение. Я посчитал, что не нужно, так как часто это были косяки после перемещения категорий из одного места в другое (или уровнем выше).

Infovarius (talkcontribs)

А в таких элементах ваша правка убирает совпадение категории с основной статьёй, что вероятно ухудшает соответствие.

Solidest (talkcontribs)

Не понимаю какое отношение моя правка имеет к этой проблеме. Вы против привязанной категории или против заголовка на википедии? Так отвяжите или переименуйте. Добавлять фейковые заголовки - это определённо не выход.

Solidest (talkcontribs)

Я в общем не против ваших уточнений, которые возможно пригодятся или помешают кому-нибудь раз в 5-10 лет. Но учтите, что это ваша практика нетипична, а не наоборот. И если мне когда-нибудь понадобится ещё раз найти дублирующиеся категории, то я не буду в списке из 3к+ ошибочных названий искать ваши исключения. Поэтому лучше решать каждую ситуацию так, чтобы это не проходилось делать исключениями.

Infovarius (talkcontribs)

почему моя нетипична? какими правилами обоснуете?

Solidest (talkcontribs)

Я видел откатывания другими участниками подобных случаев, и также видел аналогичные массовые переименования на других языках. Я не согласен с вашим позиционированием категорий как концептов, а не оформленных внешних сущностей. Ваш подход просто идёт в разрез с запретом на дублирование заголовков категорий (и который наоборот только подверждает мою логику), и вы пока никак не объяснили почему мы должны игнорировать эту функцию и создавать поводы для ошибок, связанных с ее работой. Во время этой группы правок что я делал - я вручную исправлял около 50 случаев блокировок дублей, которые потенциально создаёт ваш подход (польза которого фантомна).

Infovarius (talkcontribs)

это по-вашему они "ошибочные", а по-моему единственно верные. Например, в Q8797484 титул в Викисловаре отличается от титула в Википедии и он точнее по смыслу. Почему нужно отказываться от него в пользу Википедии?

Solidest (talkcontribs)

Это наверное самый абсурдный случай что я видел от вас здесь. И я не понимаю почему Викисловарь должен иметь приоритет над википедией, когда очевидно что все статьи на Википедиях имеют множественное число. Если вам кажется один вариант точнее, то предложите переименование категории, или разделите их на ед и мн число, как это часто бывает, если для вас эта разница критична.

Infovarius (talkcontribs)

и в частности в Q31102165 была убрана метка, которая совпадала с названием русской страницы. Как это согласуется с вашими принципами?

Solidest (talkcontribs)

В этом и суть этой проблемы. Нужно решать переименованием, удалением дублей и объединением и по необходимости созданием двух категорий по ед и мн числу. Так, как это делается всегда. То, что там сейчас сделано - очевидно будет приносить только проблемы и войны правок и ваш подход этому потакает.

Solidest (talkcontribs)

На будущее список всех элементов категорий с кастомными ру заголовками:

Infovarius (talkcontribs)

что-то мало. Чувствую кто-то массово попортил мои уточнения.

Solidest (talkcontribs)

Это только случаи с привязанными рувики. Все оставшиеся случаи после первого прохода вчера вручную проверял и исправлял (около 100), и это все уточнения добавленные вами что остались.

Infovarius (talkcontribs)

смотрю, всё-таки вы стали использовать пояснения для похожих имён (Q8879072). Поддерживаю

Solidest (talkcontribs)

Это для тех случаев, если название без пояснения заблокировано, да и там где нет подключенной категории на этом языке, то разницы нет как называть.

Reply to "метка категорий"
RhymeWrens (talkcontribs)

Hi, sorry if this is the wrong place to be posting this, new to Wikidata editing.

You reverted a statement I added on Q104695865, I'm guessing it's because I didn't add a reference - that's understandable; the Wikipedia page for "hyperpop" defines it as "a loosely defined electronic music movement" - perhaps distinct from "scene" in that "music movement" focuses less on community aspects, but it also refers to it as a "scene" in the 3rd sentence; do you think this is suitable to use as a reference? If not, there are other references that can be used.

My main question is, did you revert my edit because of lack of references, or something else, like a confusion of two concepts? Thanks for reading

Solidest (talkcontribs)

The problem is the concept itself. Scenes are compact formations, most often existing within a region or country. A large global genre cannot be a scene.

RhymeWrens (talkcontribs)

I see; my apologies, I only realized now that the Wikidata entry for "musical scene" is focused on communities within a specific region, despite "music scene" being described differently in other places (e.g. Music scene).

Could you suggest a more accurate statement/edit that represents hyperpop's Internet-rooted (ergo, dispersed) community aspect in the same way that Wikipedia calls it a "loosely defined electronic music movement and microgenre"? Should "music genre" simply be changed to "microgenre"?

I maybe should have posted this on the entry's talk page. :P

Solidest (talkcontribs)

Regarding microgenre - no, we don't use microgenre in instance of (P31) in the current music genre scheme (same as for “musical style”). But microgenre can be added to has characteristic (P1552) if needed.

Regarding movement, it is common on wikidata to separate concepts that are different in meaning. For example, music genre (as a unit of music classification) and music movement/community (as a group of fans) would be properly framed as two independent items and connected to each other via properties. But specific online music community will probably not go through Wikidata:Notability, so it's probably better to leave it as it is. When it comes to online community, it's probably not notable enough for wikidata, as I haven't seen any here yet. But if it's a movement in the real world, it should probably be framed as P31 = subculture (Q264965) (eg. Rivethead (Q505378) or junglist (Q1076856))

Solidest (talkcontribs)
Reply to "Edit reversion of Q104695865"

Imports of category names from enwiki

7
Florentyna (talkcontribs)

Are often very bad, because there is often the lowest systematics of categorization, and on top, often not in agreement with commons. Here I think a lot of people using the English version, and the category name should be understandable for everyone. Really bad cases are things like Template:2024TUC, any idea, what this can be? So here is human interaction much better than copy-paste by AI. If you can exclude from the bot-additions sport=badminton, it would be really helpful.

Solidest (talkcontribs)

On Commons the category names, their cohesiveness is much more often more outdated, rarely monitored, and there are much much more duplicates comparing to enwp. Commons also get freely vandalised time to time which may be not fixed for years. Comparing to enwp, where all naming is tracked and based on consesensus and discussions. So I'm pretty sure that enwp titles should be main ones and commons should be put into aliases. And this is actually how we do things in 95% cases. I gave additional reasons here Talk:Q19370206 as well, but got no respond from you there.

I see absolutely no benefit from your reverts and custom titles - all these cases are personal sympathies without practical sense (where you also don't even put enwp article titles in the main elements themselves). And double-reverts to "badminto" like this one are beyond my comprehension at all.

Solidest (talkcontribs)

Although I don't agree with your approach, I have excluded all corrections where the word badminton appears in the title

LIrala (talkcontribs)

There's also simplewiki. When two or three have different names, at least their titles should be aliases I think.

Solidest (talkcontribs)

I was planning to first move the actual titles from Enwiki, then after a week or more (when Qlever dumps are updated) add the differing aliases from Commons, and then after another week do the same with Simple wiki. And then duplicating with labels aliases will be cleaned out by other bots after a while, as it usually happens. This seems to me to be the most optimal way to do things.

LIrala (talkcontribs)

There's also categories that were deleted at enwiki and still exist in commons or simplewiki.

Solidest (talkcontribs)

I wasn't planning on doing anything with these

Reply to "Imports of category names from enwiki"

Categories death by month in (year)

2
LIrala (talkcontribs)

Several categories of death by month by year in frwiki were not imported to Wikidata. But also several categories that were imported are not put with their respective main topic. Do you think your bot or another bot could do that?

Examples: fr:Catégorie:Décès en avril 2024; Q65599191.

I also noticed a large amount of categories from eswiki weren't imported yet.

Solidest (talkcontribs)

I do almost all edits on my bot on WD via Petscan + QS - that is, I get all the titles lists manually (I then do not check existing labels or add additional subtopics) - so this is not the best option, and it's better to look for other ways to work with frwiki + eswiki. Especially considering that I manually distributed specific category subtypes in P31 with enwiki/ruwiki based on their names, and I'm not familiar with fr/es naming.

Reply to "Categories death by month in (year)"