User talk:Quesotiotyo/Year 3

This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

Querying edits to 'former doctoral candidate' descriptions

Hi, I wonder if I could ask about the changes made to all the Wikidata items for past LSE doctoral candidates removing the word ‘former’ from description.

I used the description ‘former doctoral candidate…’, as I wanted to make it clear that they were former doctoral candidates, whose thesis was now completed, which is not the same as ‘doctoral candidate’ who is current. This also followed the format that I know another university involved in the PCC Wikidata pilot has used when creating Wikidata items for authors who have written a thesis in the past.

This is my first Wikidata project and it would help me to understand and learn more about why the changes were made. Thanks, Best wishes HelsKRW (talk) 10:19, 11 August 2022 (UTC)

Hello there @HelsKRW, thank you for the question.

In general, it is best to write descriptions in a neutral tense. Help:Description advises against using words such as "current", as this information will inevitably fall out-of-date. While "former" does not have this same issue, its use can in effect confer currency to descriptions which lack it. It also adds very little in terms of illustrating why an item exists (one of the purposes of a description) or locating a particular item in a search list (another purpose). It could in some cases be useful in disambiguating two items with the same or very similar labels and descriptions, though it would be better to use some bit of information that differs between the two items and is unlikely to change. This level of detail is usually added only when needed, though in your case I think it would be perfectly acceptable to add the year in which the doctorate was given to all of the descriptions. This was done with more than two hundred thousand items created for the Mathematics Genealogy Project (Q829984) (which I imagine overlaps somewhat with the items that you are working on) as well as for several thousand created for University of Washington ETD authors. This would make it clear that these individuals are former doctoral candidates and would provide a date of reference for those items that currently do not have any.

If you ever have more questions, please reach out and I will try my best to answer them. :)

--Quesotiotyo (talk) 19:00, 12 August 2022 (UTC)

Thank you for taking the time to give further details about descriptions - it is helpful to understand how I can improve the data. I've come across some overlap with the Mathematics Genealogy Project as I've been working through it all! Thanks again for your help - much appreciated HelsKRW (talk) 08:48, 16 August 2022 (UTC)

Misunderstand re: native labels

Punjabi is a language with multiple writing systems, Punjabi names should not have separate items just because of this. The result would be that every Punjabi person has to have several surname item links just because of this which would be silly. Middle river exports (talk) 20:46, 12 August 2022 (UTC)

Chandra (Q37166198) is a Latin-script name. Please create a separate item for names written in other scripts instead of trying to repurpose existing ones. Thank you.

--Quesotiotyo (talk) 20:55, 12 August 2022 (UTC)

Sorry, but I don't think you've quite understood what I meant. Indian language names do not have one script. If we take the writer Duni Chandra, he spells his name variably as Chandra, ਦਾੰਦਰਾ, and چندرا. Does he seriously need 3 name items? There is nobody who uses this name for which Latin script is the *only* script applicable. So it should be deleted in favor of a multilingual name item.

People modeling this wrong has caused lots of inaccuracies on items for Indian people. Asha Bhosle's name was linked to the Latinized version of Arabic عشا instead of Indic آشا which is not pronounced the same. Because English is an official language of India, every Indian name has a Latin spelling. We can't say a name "belongs" to a script when the only people using this rule are only using Latin script languages. Otherwise we are basically saying only Latin script names get to have items. How can we model illiterate people if we follow this so strictly - are they nameless? What about people who use languages with no standard spelling, who write their name differently in different contexts? I do not even use the same spelling in Latin script every time I write my name in it, then I have two spellings I use for writing in Arabic, and 2 for Punjabi. I do not have 6 names.

If you wish to create script specific entities on Wikidata, lexemes are likely better suited to your intent. These are meant to contain this kind of information, there has never been a need to put duplicates on the same name for every person who writes with multiple scripts. Middle river exports (talk) 16:35, 14 August 2022 (UTC)

If we take the writer Duni Chandra, he spells his name variably as Chandra, ਦਾੰਦਰਾ, and چندرا. Does he seriously need 3 name items?

That is correct, since Wikidata treats those as three completely different names. The statements can be qualified using applies to name of subject (P5168) to show which version of his name each goes with. I don't see how it would be possible to model this with only one statement.

There is nobody who uses this name for which Latin script is the *only* script applicable. So it should be deleted in favor of a multilingual name item.

Do you mean among people on Wikidata, or just in general? You may be right about the former, but certainly not the latter. And name items do not have to be used as the value of a statement in order to exist (as evidenced by the nearly 160,000 family name items we currently have that are not used by any of the family name properties).

We can't say a name "belongs" to a script when the only people using this rule are only using Latin script languages.

This is simply not true. Name items exist and are being used for a variety of writing systems, and the basic principles should apply for any of them. Yes, Latin-script names make up the current majority, but that should be expected considering that most humans in Wikidata use that script for their name.

How can we model illiterate people if we follow this so strictly - are they nameless?

Huh? Being literate is required in order for a person to have a name? I am completely baffled by what you are trying to say here.

I do not even use the same spelling in Latin script every time I write my name in it, then I have two spellings I use for writing in Arabic, and 2 for Punjabi. I do not have 6 names.

If you write your name six different ways, those would require six different name in native language (P1559) statements to display. So in that sense you would indeed have six names.

If you wish to create script specific entities on Wikidata, lexemes are likely better suited to your intent.

The name properties are not currently set up to use lexemes. As lexemes are language-specific and names are script-specific, it would not make sense to use them (English Wiktionary gets this laughably wrong and I'm glad that the same mistake hasn't been made here).

These are meant to contain this kind of information, there has never been a need to put duplicates on the same name for every person who writes with multiple scripts.

There is a need to do this since it cannot be guaranteed that everyone who uses one form of a name necessarily uses every form of that name. It is perfectly fine for a property to have multiple values...just not for native label (P1705) on name items, though. :)

--Quesotiotyo (talk) 21:54, 15 August 2022 (UTC)

Edit request

Hello. Can you edit Q746359 page ? Please add the link of ja:楽器製造業. Because the page is protected now.--126.234.123.99 07:57, 14 September 2022 (UTC)

It looks like someone else has already done this at Q16879932. --Quesotiotyo (talk) 16:59, 14 September 2022 (UTC)

Public transport in Phoenix

Re [1] - the bot just imports short descriptions from the English Wikipedia, you should change it at en:Public transport in Phoenix if you have a better short description. The bot will automatically re-import from there. Thanks. Mike Peel (talk) 08:51, 15 September 2022 (UTC)

What makes for a good short description on Wikipedia is not always what makes for a good description here. Maybe the bot shouldn't be importing them if it can't tell the difference. And it certainly should not be re-adding anything that was previously removed. --Quesotiotyo (talk) 17:56, 15 September 2022 (UTC)

Just fix it on enwiki, or add a different description here if you want. Mike Peel (talk) 18:01, 15 September 2022 (UTC)

Well I would add "public transport in Phoenix" as the description but the software doesn't like it when I try to do that. :) --Quesotiotyo (talk) 18:09, 15 September 2022 (UTC)

No, it wouldn't, since it should be different from the label. Thanks. Mike Peel (talk) 19:13, 15 September 2022 (UTC)

Hi, just a reminder of this conversation, please do also remove bad labels from enwiki so the bot doesn't re-import them in the future. :-) Thanks. Mike Peel (talk) 06:03, 31 May 2023 (UTC)

Removing occupation politician

Could you please state your rationale for removing occupation politician, it's useful for me to match with upcoming datasets.

It's also in accordance with the Wikidata description of politician: "person involved in politics; person who holds or seeks positions in government"

Thank you Germartin1 (talk) 03:18, 16 September 2022 (UTC)

Also many of them might already have been a member in a local/regional parliament. Germartin1 (talk) 03:22, 16 September 2022 (UTC)

Hi,

All of these people had "political candidate" in the English description and a candidacy in election (P3602) statement but nothing suggesting that they have held any office, therefore political candidate (Q19772737) is the better option to use in light of what is currently known. The value can always be changed should any further information arise.

--Quesotiotyo (talk) 03:40, 16 September 2022 (UTC)

Yes, but I'm really not happy with that since practically every politician is also political candidate. And it just adds redundant data. Germartin1 (talk) 09:22, 16 September 2022 (UTC)

What redundant data? Q82955 can replace Q19772737 as the more accurate value; there generally wouldn't be a need to have both.

--Quesotiotyo (talk) 16:38, 16 September 2022 (UTC)

Q108561162

It is incorrect to assign unknown value unless you have evidence to that effect. We should record what is on the record, not what you assume from that. The newspaper may have records, the author may be known to many, so best to record what is shown.  — billinghurst sDrewth 00:29, 17 September 2022 (UTC)

Obituary: Mrs W. H. Carvosso (Q108561162)author (P50)no value does not make sense. The obituary did not write itself. unknown value is the correct way to show the author was not given. Either change it back or remove the statement altogether.

Thanks,

--Quesotiotyo (talk) 00:54, 17 September 2022 (UTC)

Town vs. Village of Deposit, New York

It should be noted that the Wikidata infobox that you claim is for the Village of Deposit, New York was placed in the commons category for the Town of Deposit, New York. Alao, there seem to be some non-village images there. ----DanTD (talk) 00:41, 18 September 2022 (UTC)

Thank you for pointing that out; I do have a tendency to overlook the Commons sitelinks since they are all alone at the bottom. --Quesotiotyo (talk) 01:06, 18 September 2022 (UTC)

English labels

Hi @Quesotiotyo:, you've reverted the use of Japanese text as an English label https://www.wikidata.org/w/index.php?title=Q90232990&oldid=prev&diff=1734832606

My reason for using the Japanese text is that there is no English title for this article, but if we don't have a value for the English label then this item can appear as unlabelled in searches, or when used as a value elsewhere in Wikidata (e.g., when being cited). Ideally I guess we would have labels in the corresponding language, but in many cases we don't. You'll find many cases in Wikidata where the label in English is not, itself, English, e.g. Die Fledermaus (Q464930). Rdmpage (talk) 09:28, 23 September 2022 (UTC)

Help:Label#Items_without_pages_on_Wikimedia_sites suggests using transliteration for proper nouns written in non-Latin scripts with no established translation, should you feel that it would be better to have something than nothing at all. My preference would be to leave it blank in order to signify that no English title exists, and hope that someone with the ability to provide a translation will eventually do so.

--Quesotiotyo (talk) 16:55, 23 September 2022 (UTC)

Re: Wwwyzzerdd

Hi, I noticed that you are a user of my browser extension wwwyzzerdd. I am considering applying for a Wikimedia grant to further its development (for one thing it needs to be rewritten to be compatible with manifest v3 before the 2023 deadline). As part of that I'm contacting some users to get some feedback. If you have some time I would appreciate if you could tell me:

• How do you find the extension? Is it useful to your work?
• What features / functionality would you like added? Are there bugs that you'd like fixed?
• What browser/OS do you use?

Thanks, any feedback is appreciated. BrokenSegue (talk) 03:31, 28 September 2022 (UTC)

Yes, thank you for creating and sharing this handy little tool! It has proven helpful for quickly spotting connections on WP that we are missing here and adding them with a few simple clicks. I am very pleased with how it currently works and have not encountered any issues so I would prefer that it remains as is.

--Quesotiotyo (talk) 20:33, 1 October 2022 (UTC)

Uncorrect revert by you

Hi Quesotiotyo, you've reverted my edit of Q219124 (Nomination 2018 for Academy Award for Best Writing, Original Screenplay). Your affirmation that it is not correct is wrong. That is proven by the reference (Src: hollywoodreporter.com) I had delivered. Indeed Guillermo del Toro was not the winner but a finalist - just as I stated! Have you been tired or otherwise driven to uncarefully reading it? Well, we all make some mistakes now and then. I think you should apologize and we forget it. Of course I've reverted your uncorrect revert. --Just N. (talk) 18:36, 29 October 2022 (UTC)

@Justus Nussbaum: The Hollywood Reporter article is about the Golden Globe Awards, which is not the same as the Academy Awards. Also, del Toro was nominated for Best Screenplay for Pan's Labyrinth in 2008, not 2018.

--Quesotiotyo (talk) 21:00, 29 October 2022 (UTC)

Merge request

Hello.

Can you merge the Wikidata page of "Odelya Halevi" (Q114792484) with the Wikidata page of "Odelya Halevi" (Q38778155)? They are both about the same actress.

Can you also merge the Wikidata page of "Yorai Oron" (Q6579622) with the Wikidata page of "Yorai Oron" (Q99677452)? They are both about the same musician.

Can you also merge the Wikidata page of "Will Mellor" (Q95771776) with the Wikidata page of "Will Mellor" (Q3246903)? They are both about the same actor.

Yours sincerely, 31.200.11.65 09:43, 31 October 2022 (UTC)

Done, done, and done. --Quesotiotyo (talk) 02:21, 1 November 2022 (UTC)

Thank you very much. 31.200.11.65 06:19, 1 November 2022 (UTC)

Q107506450

Hello, you have reverted my edit on Q107506450 with a (vague) comment "this does not make sense". Let me explain. I have put the name of the architects who created the building design in P2093, because they do not have their wikidata item (and thus could not be introduced in P84). In my understanding, this is exactly what P2093 is for. Therefore, if you do not have any strong arguments against this, please put it back. --JiriMatejicek (talk) 16:45, 4 November 2022 (UTC)

Buildings do not have authors. If you want to use architect (P84) then you will have to create an item first (if you are certain that one does not already exist). author name string (P2093) is for written work items and should only be used as a substitute for author (P50).

--Quesotiotyo (talk) 17:15, 4 November 2022 (UTC)

My understanding of 'author' is apparently broader than yours, which may be related to language. I am Czech and in Czech the term 'author' is not limited to written works, but relates to various creative works, including music, visual art and architecture. The term 'author of a building' is quite common. Even in the P2093 aliases, you can see 'creator name string' and 'maker name string'. Thus, I do not see anything wrong with my approach.

In general, I recommend that you revert other people's edits only if you are _absolutely sure_ they are wrong. If it's just a matter of personal view, leave them alone. --JiriMatejicek (talk) 15:25, 9 November 2022 (UTC)

The exact wording of the label is a formality. One needs to consider the purpose and domain of a property to determine its function. The proposal discussion and property specifications make it clear that it is intended to be used on written works.

A specific creator name string property was proposed in the past as a counterpart to author name string (P2093) for use on items where creator (P170) would be used rather than author (P50) (noting that the latter is a subproperty of the former), partly because P2093 would not be appropriate in those cases. The proposal was ultimately withdrawn due to a suggestion by user Jheald to "[u]se creator (P170) = somevalue with qualifier object named as (P1932) = <string>". This method prevents the need to have a bunch of name string properties for any and every property that could have a name as the value. I myself have not seen this implemented anywhere that I can recall but will plan on trying it out in the future. If you do not feel that the architectural firm for the abovementioned building warrants its own item, this might be the solution that you are looking for.

--Quesotiotyo (talk) 20:34, 9 November 2022 (UTC)

Hello,

sorry for a late reply and thanks for giving this more attention. While I don't think the other approach is better than mine, I appreciate the rationale behind it and the fact that it comes from some consensus instead of just one person's view. Of course, it makes sense to follow the majority, but I have no idea how widespread that approach is. Anyway, both approaches are only workarounds, so I will try to create new items for creators who are significant enough. --JiriMatejicek (talk) 16:16, 14 December 2022 (UTC)

ODNB versus The Peerage

You have objected just now to my removal of a death date, referenced to https://www.thepeerage.com/, when it contradicts a date referenced to the Oxford Dictionary of National Biography.

This doesn't seem too reasonable to me. The Peerage is compiled by Darryl Lundy, and often references private communications from other family history researchers. It is deprecated as a reference on Wikipedia. I don't think it is particularly accurate on dates. On the other hand the ODNB is a standard scholarly work. Of course it has some proportion of errors also, but there is really no comparison.

I would say that dates from The Peerage are no better than "imported from Wikipedia" dates, and Wikidata is generally improved by removing them in favour of a reputable substitute. Charles Matthews (talk) 16:48, 16 November 2022 (UTC)

Help:Statements#Add_only_verifiable_information

Help:Ranking#Deprecated_rank

--Quesotiotyo (talk)

The Indigenous Famous Six (Q95685593)

Re [2], the problem was the categories on enwiki, which said that the article was about a living person. now changed - but needs more categorisation work on enwiki really. Thanks. Mike Peel (talk) 08:32, 21 November 2022 (UTC)

Adding aliases identical to the label

Regarding adding aliases, I'm not sure what the policy is. When I add a dataset, I add all the aliases from that dataset as there might be slight altercations of the name, which will be useful for matching in the future. Personally, I think it doesn't do harm adding the same aliases as the label. I think if Wikidata doesn't want this, they should hard-code this rule to prevent this from happening. It would be rather inconvenient to fetch all labels with OpenRefine and then only add aliases which do not match with current label on Wikidata. Let me know what you think, I appreciate your work! Germartin1 (talk) 00:28, 15 January 2023 (UTC)

Thank you for explaining why this is happening. I can understand not wanting to add additional steps to what is I am sure a lot of work preparing these datasets in OpenRefine. Yes, it would be nice if the software were able to prevent this from happening (like it does with the description field). It is actually quite simple to query for redundant aliases and remove them via QuickStatements though, so I say don't worry about it. They will get cleaned up eventually and are not doing much harm in the meantime.

--Quesotiotyo (talk) 23:34, 16 January 2023 (UTC)

Series ordinal on women’s names

Hi can you explain this edit removal of second family name? Thanks in advance, Jane023 (talk) 05:20, 20 January 2023 (UTC)

Her married name was "Woodman", not "Woodward". --Quesotiotyo (talk) 05:23, 20 January 2023 (UTC)

Thanks for correcting that! I assume you just forgot to add series ordinal back, so I just did it for you. Jane023 (talk) 10:42, 22 January 2023 (UTC)

I did not see a need to include it, since a woman's maiden name necessarily comes before her married name. --Quesotiotyo (talk) 19:35, 23 January 2023 (UTC)

Merge request

Hello.

Can you merge the Wikidata pages of "Josh Sills" (Q108053572) and "Josh Sills" (Q112051762)?

They are about the same American football player.

Yours sincerely, 31.200.22.67 20:57, 1 February 2023 (UTC)

Merged, thanks. --Quesotiotyo (talk) 21:16, 1 February 2023 (UTC)

Thank you very much. 31.200.22.67 21:16, 1 February 2023 (UTC)

Buena Vista Social Club (Q842415)

You undid my revision as "incorrect". Was because it was unsourced? Because I restored it with a source provided. If not, please tell me why. Magiciandude (talk) 14:54, 24 February 2023 (UTC)

@Magiciandude Ry Cooder (Q318374) won for the album Buena Vista Social Club (just as the source that you added states). The band itself did not win the award.

--Quesotiotyo (talk) 21:43, 24 February 2023 (UTC)

How not a museum?

[3] (George Washington Carver National Monument (Q967224)). Preserved buildings, interactive exhibit areas, exhibit building, plus grounds. We consider Mount Vernon (Q731635) a museum, and at least from the description in en-wiki this doesn't sound any less so. - Jmabel (talk) 19:12, 5 April 2023 (UTC)

The national monument houses a museum, but the two should not be equated (the Mount Vernon item is a mess and will have to be untangled). I have moved it to has facility (P912); never used that property before but I believe that that is correct. If you would like to create a specific item for the museum itself, that can be linked via has part(s) (P527) instead.

--Quesotiotyo (talk) 19:35, 5 April 2023 (UTC)

That seems reasonable. I turned to Mount Vernon as the most obviously major analogous site. Further thought: a museum doesn't have to be a building, and may contain much acreage and many buildings. Mystic Seaport would be an extreme example. But, yes, disentangling this into multiple Q-items is probably the best way to model it. - Jmabel (talk) 20:16, 5 April 2023 (UTC)

About subject named as in WikiTree person ID (P2949)

I am using dates with it, since there were 100s of people with the same name in the past. Since this is genealogy related, dates are essential in identifying the correct person and preventing conflation and invalid links. Also on WikiTree the subject is named with the birth/death years See: https://www.wikitree.com/wiki/Cross-12636 I would keep such naming convention unless it is totally against the rules. It proved helpfull many times in the past. If not, I have no idea how to remove existing 180000 dates in the subject named. I use quickstatements for editing and it doesn-t support an update of a qualifier. Lesko987a (talk) 10:10, 6 April 2023 (UTC)

I understand that the dates are important but they are not a part of a person's name (even on WikiTree -- see https://www.wikitree.com/treewidget/Cross-12636/1001), hence they should not be used with subject named as (P1810). Might I suggest that you add them to date of birth (P569) and date of death (P570) instead? There are currently over 60,000 items (https://w.wiki/6YVH) with a WikiTree person ID (P2949) but that are missing both DOB and DOD, and it looks like quite a lot of these can be supplied from WikiTree. I think it would be helpful to transfer these dates from P1810 to the correct properties. Is this something that you would consider doing, or would like help doing?

--Quesotiotyo (talk) 20:46, 6 April 2023 (UTC)

I did think of adding dates to wikidata. The problem I have is that I can't really tell how correct the date on WikiTree is. It can be correct or just an aproximate guess based on the relatives. We have some indicator of how correct the date is, but I can't say for sure. Dates also get corrected on WikiTree as someone finds the sources and updating the P569 and P570 is even more problematic. That is the reason I didn't do that already.

On the Name Displays page there is also Long Name with Dates: William Cross (1809-1862) that displays exactly that and is used even as a h1 on the page. On wikitree you can hower the link and see the dates instantly, so that form is not used everywhere.

Another aspect is that the P2949 is a link to a page so the subject is the page and page's name includes dates.

My idea of setting the P569 and P570 was:

• If WikiData has a date and it matches WikiTree, I would just add a reference to that date. This can be fully automated.
• If WikiData has no date and WikiTree has the exact/certain flag set for the date, I would add the date and reference to that field. This can be fully automated.
• If WikiData has no date and WikiTree has no exact/certain flag set for the date, I wouldn't add the date and reference to that field. The date might get changed in the future.
• If WikiData and WikiTree have different dates, I wouldn't add it to wikidata. As you can see on the WikiTree's suggestion report, there are over 10000 different dates on connected profiles.

And when the date on WikiTree changes and was added to wikidata with the WikiTree reference, I would have to delete/deprecate the reference to the old date and add the new one. But that is something I can't do using quickstatements, since it is not supported. Do you know of another way to do this automatically?

Another question on the date's references. Which ones should be added? You used stated in=WikiTree, WikiTree person ID=Cross-12636, subject named as=William Cross and retrieved=6 April 2023. The problems I see are that WikiTree person ID and subject named as can change over time. Is it possible to just reference the P2949 identifyer at the bottom of the page. I do maintain the P2949 if things change on WikiTree. Lesko987a (talk) 07:34, 7 April 2023 (UTC)

Thank you for the response. I like your plan to add the dates that are marked as exact/certain on WikiTree; I think that would be a great idea. As for the uncertain dates, this would be an ideal use for EDTF, but I am not sure if Wikidata will ever support that. I still think that having these dates would be better than having nothing at all, even if some of them will be updated in the future. I mean, they are already there in subject named as (P1810) with no easy way to change them. If better information becomes available, it can be added as a separate value and the appropriate ranking can then be applied (Ranker (Q105394978) is a useful tool for doing this en masse). Also, please do this with any changes to WikiTree person ID (P2949) (instead of overwriting the older value as you did here).

For the particular reference that you asked about, those properties were selected by the UseAsRef script that I use. I wouldn't worry about trying to keep individual references up-to-date; so long as retrieved (P813) is included, the other details should be interpreted as having been valid at that point in time. References that contain only stated in (P248) (not counting where the value is a specifically created source item) have always seemed incomplete to me; even if further information is available down below with the corresponding identifier, having it included with each statement makes querying for it much simpler and allows the statement groups to be disseminated individually without losing that connection.

--Quesotiotyo (talk) 07:05, 8 April 2023 (UTC)

Q131333

The problem with the data is that the source cited did not actually state the information that was claimed. When a statement's only reference is "imported from [language] Wikipedia", and that Wikipedia has no statement supporting the claim, then that information is unsupported by a reference. --EncycloPetey (talk) 16:32, 6 April 2023 (UTC)

It was right there in the wikitext, second line ("Nome"): https://it.wikipedia.org/w/index.php?title=George_Eliot&action=edit&oldid=64651685 --Quesotiotyo (talk) 20:53, 6 April 2023 (UTC)

Thanks

Thanks for fixing my Findagrave location errors, are you working on adding more Findagrave entries? Is there a tool where we put in the Findagrave ID and most info is migrated automatically? RAN (talk) 04:45, 7 April 2023 (UTC)

You're welcome, and yes, I am planning on creating items for the remaining U.S. cemeteries soon. And no, I don't know of any tools that will import the information automatically, but hopefully when I'm done you will no longer need one. :)

--Quesotiotyo (talk) 07:10, 8 April 2023 (UTC)

Labels not in English

Hi @Quesotiotyo: You have deleted the English label in 40 items created by myself. These 40 items are titles of doctoral dissertations not published in English neither translated to it. So I had respected the original title (in Russian, in Japanese, etc. ...). I think is better to have a label than anything, but if you prefer no description in English, I not oppose. You have not deleted labels in languages like French, Portuguese, Deutsch, etc. (see for exemple Q116977173): I do not understand why...

Please, do not delete the labels in catalan, because in cawiki we use authomatically the label of the doctoral dissertation in the infobox of scientists. Ferran Mir (talk) 07:58, 15 April 2023 (UTC)

I went back and added title (P1476) statements to those items; that property is what the infobox template should be using, not the label. It should also obtain the publication date and URL from the thesis item itself; those properties need not be duplicated as qualifiers on academic thesis (P1026) statements. As for titles in French, Portuguese, etc., those are allowed as labels for other Latin-script languages if a translated title is not available. Per Help:Label#Items_without_pages_on_Wikimedia_sites, you may add transliterated titles for publications in Russian, Japanese, etc.

--Quesotiotyo (talk) 23:48, 22 April 2023 (UTC)

McCarthy (Q24419041)

Sorry, not intentional, regards JotaCartas (talk) 21:18, 21 April 2023 (UTC)

Yes, another mistake! BM JotaCartas (talk) 23:53, 21 April 2023 (UTC)

Your Last revertions of JotaCartas edits

Hi, May be I am wrong, but I think that is better to have a "transliteration" of the Cyrillic characters in en:label than to have nothing. But do as you wish ... I don't intend to do more of this in the near times. Best regards. JotaCartas (talk) 00:44, 22 April 2023 (UTC)

Furthermore, I can give you the list of my 77 edits of this kind for you to review ... if you want. Thanks. JotaCartas (talk) 00:55, 22 April 2023 (UTC)

Transliteration, yes; translation, no. See the third point here and the fourth point here. Labels such as "Gate (name of house)" (Q58062124) and "No rise" (Q57445857) are not correct.

--Quesotiotyo (talk) 01:14, 22 April 2023 (UTC)

Hi again, I edited the items you refereed ( I Did It My Way 😊), but please feel free to correct/revert accordingly to the rules. By now JotaCartas (talk) 01:42, 22 April 2023 (UTC)

Çelik

Hi. Why did you revert my edit? I see that in Italian, German, English, Turkish and so on the last name is the only meaning of "Çelik" (with the additional information that in Turkish it means "steel"). I see no need to keep "Çelik (surname)" and "Çelik (disambiguation)" separate because the content is exactly the same (the disambiguation page is always and only between multiple people who have "Çelik" as their surname). I find it unhelpful to prevent the reader from navigating between the same disambiguation page in the various languages in which it is available. Let me know what do you think :) Melquíades (talk) 11:55, 24 April 2023 (UTC)

Hello! See the third example at Help:Merge#Examples and Wikidata:WikiProject Names/Disambiguation for reasons why you should not merge a name item and a disambiguation item. Sitelinks can and should be moved if the article does not match the item it is attached to (rather than adjusting the item to fit the article). I can see that this is the case for en:Çelik; it covers both the family name and the given name, so I will be creating a new item and moving the sitelink there instead of adding instance of (P31)given name (Q202444) to Çelik (Q56537961): family name. I will take a look at the sitelinks at Çelik (Q1158653): Wikimedia disambiguation page and see if any of them need to be adjusted as well. As for improving interlanguage links, this can be done by adding sitelinks to redirect pages; here is an example of how to do this for a family name within a disambiguation page: Wikidata:Sitelinks_to_redirects#Disambiguation_page_and_family_name.

Please let me know if you have any other questions.

--Quesotiotyo (talk) 15:04, 24 April 2023 (UTC)

That's perfect, thank you so much for you detailed explanation! :) Melquíades (talk) 02:54, 27 April 2023 (UTC)

it's too early…………--Zyksnowy (talk) 17:50, 26 April 2023 (UTC)

Saint Kitts and Nevis

I give in. I created a clone of Nevis just because you dislike the idea of it being a first-level subdivision. For symmetry, you should demolish Saint Kitts (Q204989) in a similar way. Hroptatyr (talk) 09:17, 2 June 2023 (UTC)

Name

If you check my recent contributions you'll see that I have had to fix hundreds of items that use the wrong name item for given and family names, and it's because "name: given name and family name" overrides the correct name items when using QuickNames and presumably similar addons. Why would the more succinct "name" description be worse? It's not like these items should be used for anything, they should only exist to point to the relevant given and family names. —Xezbeth (talk) 03:49, 17 June 2023 (UTC)

I was thinking more about users who are searching for a particular name to use with family name (P734) or given name (P735). If an item that says just "name" shows up first, there's no indication what kind of name it is and that a more specific value needs to be located, whereas "name: given name and family name" does (I'm not tied to that particular phrasing, though...it is a bit clunky). I will point out that Help:Description#Length states that "[o]ne-word descriptions are almost always too ambiguous, and should be avoided". I think that should especially apply when there are multiple related items with the same label and the description is necessary to readily distinguish them.

I wouldn't have thought that QuickNames relies on the description field alone to select the right item. If that is indeed the case then it is definitely something that needs to be fixed. It is probably worth noting at User_talk:Bargioni/QuickNames in order to bring this to the developer's attention.

Thanks for helping to add name statements to a bunch of the items that I created yesterday. I was impressed to see how many that you were able to get to!

--Quesotiotyo (talk) 05:19, 17 June 2023 (UTC)

please explain edit

Hi, why did you reverse this edit? She writes here name as Shay. DGtal (talk) 06:22, 18 June 2023 (UTC)

Hello,

I believe what you want is a Hebrew name instead. If an item does not already exist for the right name (I did look but could not find one) then you can easily create it. Just be sure to enter the string as it is written in Hebrew as the native label (P1705) and set writing system (P282) to Hebrew alphabet (Q33513). "Shay" and any other reasonable transliterations can then be entered using transliteration or transcription (P2440), and a bot will come along to add the appropriate labels and descriptions.

--Quesotiotyo (talk) 22:11, 18 June 2023 (UTC)

Is there a logical reason for this?

Special:Diff/1931469639 --Devrim ilhan (talk) 21:13, 8 July 2023 (UTC)

Yes, it needs to be there so that statements with a claim value of Afghanistan (Q889) will have an inherited country (P17) value. This is useful for querying purposes and for constraint checking.

--Quesotiotyo (talk) 22:34, 8 July 2023 (UTC)

Q18763713

Could please explain this deletion. Rar (talk) 07:53, 10 July 2023 (UTC)

You wrote that she was a basketball player which is not correct. She was a baseball player. --Quesotiotyo (talk) 16:27, 10 July 2023 (UTC)

Do not bother me

Hoi, when you are of the opinion that something is wrong, you change it. When you want to be annoying you revert a change. Understand that with millions of edits single edits are not of an interest to me. When you consider that everybody makes mistakes there must be a point to a revert. You only annoy, you can do your changes i am not bothered just do what you consider is right. GerardM (talk) 17:43, 10 July 2023 (UTC)

Q21441764

Thank you for this. Unfortunately this is result of using Google Translate page service, not intentional. It translates also all text fields. I don't knew that it also saves translation. Gintek (talk) 16:08, 12 July 2023 (UTC)

Jonathan Henry (Q75645895)

Hi Quesotiotyo,

I've also found the Peerage entry. How safe is it to assume that these entries are about the same person? How many Jonathan Henry's with the same birthdate may exist?--U. M. Owen (talk) 20:47, 14 July 2023 (UTC)

I was not certain that it was the same person until I found this obituary for George Ross Henry (Q75645893) (the father of The Peerage's Jonathan Henry) which mentions that his son "graduated from Trinity with a degree in Natural Sciences in 1988", which matched the education details on the other Jonathan Henry's LinkedIn profile. This plus two separate sources giving the same date of birth assured me that the items should be merged.

--Quesotiotyo (talk) 21:05, 14 July 2023 (UTC)

Then the odds tilt heavily in favor of a merge.--U. M. Owen (talk) 21:09, 14 July 2023 (UTC)

Useful or not?

You recently added a second (crypted) version of the Team GB athlete ID. Normally, there should be only one value for this ID. For me, the basic version like jon-wyatt should be more useful than your recently added versions like Q8rUiENIxvHEPIb58CYlX. Your opinion? Florentyna (talk) 08:47, 23 July 2023 (UTC)

Thank you for pointing that out. I went back and added role qualifiers for those who have both types of IDs so that they can be differentiated and I adjusted the single-value constraint as well.

--Quesotiotyo (talk) 20:43, 23 July 2023 (UTC)