Help talk:Aliases

From Wikidata
Jump to navigation Jump to search

Text in brackets[edit]

This page needs a section about aliases containing extra disambiguation text in brackets. --Yair rand (talk) 18:35, 11 December 2012 (UTC)[reply]

Inverted name for people[edit]

I think the rule: "You should always include: Inverted name for people", is not useful. We need separate fields for "family name" and "surname". --Kolja21 (talk) 20:08, 4 January 2013 (UTC)[reply]

I agree. I'm not sure what was being alluded to there. I know that many Asian cultures list their surname before their given name (so I'd be Manguard Sven), but because they're always consistent about that, it shouldn't be a problem. If I were known both as Sven Manguard and Manguard Sven, and different documents used different orders, then doing aliases like that makes sense. I've removed the section. Sven Manguard Wha? 06:10, 5 January 2013 (UTC)[reply]
Thanx! --Kolja21 (talk) 06:19, 5 January 2013 (UTC)[reply]

Phonetic transcription[edit]

Do you think en:phonetic transriptions are usefull aliasses in a given language?--Giftzwerg 88 (talk) 10:28, 5 January 2013 (UTC)[reply]

No, it's better to provide a link to Wiktionary. --Kolja21 (talk) 03:06, 6 January 2013 (UTC)[reply]

Typographic variants for non-letter characters[edit]

Different dashes, different amount of space around separators, different apostrophes, colons instead of dashes, ... A lot of Wikipedia redirects are word-identical to the article title except for non-letters. An example from Q2291213

  • fr label: Before Crisis: Final Fantasy VII
  • fr aliases:
    • Before Crisis : Final Fantasy VII
    • Final Fantasy VII -Before Crisis-
    • Final Fantasy VII: Before Crisis
    • Before Crisis -Final Fantasy VII-

As I understand it, there is no need to list these variants because search is (or someday will be) intelligent (fuzzy) enough to handle that. I suggest that this should be added to the help page – in the section "You should not include", near capitalization variants. -- Make (talk) 12:25, 9 January 2013 (UTC)[reply]

+1 (the problem: the English Wikipedia loves redirects. other Wikipedias have far less.) --Kolja21 (talk) 13:18, 9 January 2013 (UTC)[reply]

Unicode and accents[edit]

I am translating this page in Italian and I have a question when is says: «Unicode free versions of items where the label contains unicode (accent marks are all done by unicode [...]» So are all accented characters rendered using unicode (and should have an accent-free alias?). To make a clear example should I add "Kaka" among the alias in Q531814 (Kaká)? -- CristianCantoro (talk) 13:01, 28 January 2013 (UTC)[reply]

Any language can decide by there own which rule they want to have, as these Labels/Descriptions/Aliases are only shown to the people using this languages. Personally I would prefer not to use the translation exentsion for these 3 guidelines. --Sk!d (talk) 21:15, 28 January 2013 (UTC)[reply]

Non-article items[edit]

Example 1

If I type: "Wikipedia:Politiche di blocco degli utenti" in the search box (the it.wiki version of Wikipedia:Blocking policy) I don't get redirected to Wikipedia, but the correct link: Wikipedia:Politiche di blocco degli utenti (Q175291) is displayed. So I'm a bit confused on how to translate:
«If you input "Wikipedia:Blocking policy" into the search bar in the upper right, it will take you directly to the page "Blocking policy" on Wikipedia. In other words, not only would you be unable to find the item on Wikidata, but it would take you directly to the URL "http://en.wikipedia.org/wiki/Blocking_policy" (which isn't a functioning page).»
Since I'm not redirected and the correct item is displayed anyway.
More disturbing is the fact that the sentence:
«Sul sito esiste una pagina il cui nome è "wikipedia:Politiche di blocco degli utenti"»
(i.e. «There is a page named "wikipedia:Politiche di blocco degli utenti"» on this wiki.) With a link to the non existent page enwiki:Politiche di blocco degli utenti is displayed (in blue, moreover) on top of the search. Is this a bug that should be reported? -- CristianCantoro (talk) 14:12, 28 January 2013 (UTC)[reply]

Example 2

An analogous situation is present for a search of "Aiuto:Osservati speciali", the anlogous of en:Help:Watching pages, which cause no problems in Italian since "Aiuto:" is not a namespace on Wikidata. -- CristianCantoro (talk) 14:22, 28 January 2013 (UTC)[reply]

I copied the German article to Help:Alternativnamen see discussion here and here. I am not sure how to replace the current page Help:Aliases/de with a redirect to Help:Alternativnamen and change the language linking on the top of the page to link to the correct German article. --Sk!d (talk) 21:38, 28 January 2013 (UTC)[reply]

Uniqueness[edit]

If the alias can be used for search, is there any uniqueness enforcements? Or possibly some sort of a popup that shows other meanings of the alias if duplicates are allowed? The doc should clarify this. --Yurik (talk) 10:33, 13 February 2013 (UTC)[reply]

Delete translation tool from this page[edit]

I suggest that we delete translation tool from this page, because every language can define their own rules for aliases. See also Wikidata:Administrators'_noticeboard#Help_talk:Aliases.23Help:Alternativnamen. --Stryn (talk) 07:02, 21 February 2013 (UTC)[reply]

+1. --Kolja21 (talk) 21:30, 21 February 2013 (UTC)[reply]
I think this would be wrong, we should create rules that are as similar as possible across all languages. John Erling Blad (WMDE) (talk) 09:24, 25 February 2013 (UTC)[reply]
Each language has its own characteristics. I think the rules for labels, descriptions and aliases, unlike other guidelines, should be specific to each language, although similar. --β16 - (talk) 09:50, 25 February 2013 (UTC)[reply]
I agree. Even being different, the rules should be almost the same. - Sarilho1 (talk) 15:09, 22 March 2013 (UTC)[reply]
The rules differ in the languages on some topics. The spelling rules are different in German in comparions to other european languages, to non latin alphabets the rules don´t apply at all. They need transscription rules. There are also differences what is included as aliases. The dewiki has other rules for redirects and therefore also for possible aliases. The rules for accents difffer also. The french may have lemmata with accents the german usualy don´t have accents and if they have, they don´t know which one and where to put it, so the lemma has no accents, even if it is taken over from the french. So there must be more freedom with the rules and improvements in the english version may not be helpfull in the other languages.--Giftzwerg 88 (talk) 17:27, 22 March 2013 (UTC)[reply]
Either something is an alias in a given language or it is not. They are definitely not mirroring redirects, redirects are 90% spelling errors. Problems regarding the differences comes because the rules are over specified. Keep it simple, make it work for all languages. — Jeblad 02:44, 24 March 2013 (UTC)[reply]
In dewiki spelling errors are not allowed for redirects. Very common spelling errors (the ones that appear also common in newspapers or books) or obsolete writings may lead to a "Falschschreibungsseite" which explains the chosen spelling as error or obsolete and gives the correct spelling which brings you with an extra click to the desired site. Spelling errors are therefore not allowed for aliases in German.--Giftzwerg 88 (talk) 16:32, 24 March 2013 (UTC)[reply]
+1. This definitely needs to be done for alisases. If a language would like to have similar rules like the English language they can watch the edits and translate them manually. --Sk!d (talk) 02:54, 24 March 2013 (UTC)[reply]

✓ Done --Beta16 (talk) 21:39, 10 April 2013 (UTC)[reply]

(en) add "location, state" to alias?[edit]

For locations that have in Wikipedia article titles in the format "location, state", it would be convenient to find these easily at Wikipedia. Adding these article titles as alias seems a good way to achieve this. Sample: Q984361 ("Enid") would receive the alias "Enid, Oklahoma". --  Docu  at 06:42, 24 March 2013 (UTC)[reply]

The advice I got at Wikidata:Project chat/Archive/2013/12#How to handle disambiguation qualifiers on place name labels is that the place name should be shorted to its core name, and the well-known disambiguation form you mentioned should always added as an alias. For example, for the item you mentioned, the label should be just "Enid" and then an alias of "Enid, Oklahoma" should be added. Lately, I've also been adding the abbreviation of the form "Enid, OK" as well. (The two-letter abbreviation is a well-established form in Canada and the U.S.) It appears that the search box on Wikidata is not smart enough to find the same thing without the comma yet, though. (Searches of the form "Enid OK" would be quite common.) It seems that it would be simple for a bot to determine when no other populated place with the same name exists in the same state/province, and when that is the case, fix the label and make sure the "Town, Qualifier" form is among the aliases. --Closeapple (talk) 02:22, 4 May 2014 (UTC)[reply]

Translate extension[edit]

Please use translate extension for this page. --fryed-peach (talk) 07:32, 9 May 2013 (UTC)[reply]

No, it was here, but it's deleted, see #Delete_translation_tool_from_this_page. --Stryn (talk) 09:14, 9 May 2013 (UTC)[reply]
Every language has some different rules for redirects and spellings, transscriptions and so on. So policy on aliases is not projectwide, it is localised. You can translate it without the tool into every language and make it available by naming it Help:Aliases/+languagecode. --Giftzwerg 88 (talk) 09:53, 9 May 2013 (UTC)[reply]

Other languages as alias?[edit]

In several items I have found the translation to other languages as alias. In my opinion this is not correct since the translation of them can be already checked in the page itself in the sitelinks section. However I'd like to know your opinion and eventually propose the inclusion of a new line in the "You should not include" section of the guidelines, something like "Translations of the item to other languages". Thanks in advance! --Quico (talk) 21:45, 8 June 2013 (UTC)[reply]

The name of place in the local language is generally a good alias in any language. --  Docu  at 07:20, 9 June 2013 (UTC)[reply]
I've just started here and had this same question. I plan to work on linking the Scottish Gaelic wikipedia with WikiData as it should be. There are a lot of place names where the Scottish Gaelic is given as an alias for English, French, Lithuanian etc. when the Gaelic name would not be used or recognized in that language. For example: Dundee. I agree with Quico and would like to see guidance on this, or hear alternative positions. Susan.nls (talk) 17:11, 21 February 2017 (UTC)[reply]

What to add and what not?[edit]

Hello, sometimes I wonder what should be accepted as alias, and this help page is rather short. For example, is a literary pseudonym a good idea? All of them, or only the most famous? And what about nick names, such as "The Old Man from Rhöndorf" for Konrad Adenauer? Z. (talk) 19:25, 26 September 2013 (UTC)[reply]

Updates as part of documentation overhaul[edit]

Hi all, I recently made some edits to Help:Aliases as part of a larger sitewide documentation overhaul (more info on this here).

To compare my edits with the previous version please see the diffs here

Major changes include the following:

  • removed old screenshot - I have replaced it with a newer one (knowing full well that this too will soon need to be replaced as per the UI redesign)
  • updated content so it now refers to Wikimedia sites more generally vs. just Wikipedia articles which was the case before
  • moved around content and update section headings to be similar to that of the Help:Label and Help:Description pages (i.e. first cover general principles and then language-specific guidelines)
  • added an example to criteria on unicode characters

Please let me know if you have any concerns about these changes or suggestions on further improving the documentation. Here are issues I would also like specific feedback on:

  • What needs to be done to get this page from proposed to accepted guideline like Help:Description?
  • are there too few screenshots? Is the one in there helpful?

Thanks. -Thepwnco (talk) 20:51, 19 June 2014 (UTC)[reply]

  • This page in a nutshell should be rephrased to be more generic. At the moment it is focused on Wikipedians - who else would get why an alias would be a redirect and what about non-article items? That is all Wikipedia-specific terminology.
  • I would make the layout catchier with highlighted examples for DOs and DON'Ts.
  • Make Follow Wikimedia namespace conventions less prominent. In general, I would recommend trying to not expose users to such content anyway, unless the user has the deliberate intent to access it - but that is a technical matter. The only puropse of such Wikimedia namespace contents being stored in Wikidata is maintenance. A regular user will have no use with such content when, for example, stumbling upon it hitting "Random item". It is more or less for specialists.
  • There probably should be a screenshot of an item with actual aliases. Maybe even a screenshot that demonstrates the purpose of aliases by displaying a search result (or search box suggestions) for an item that appears in the search results / suggestions because of its alias.
    Random knowledge donator (talk) 18:34, 25 June 2014 (UTC)[reply]

Using alias as label?[edit]

"The label on a Wikidata entry is the most common name that the entity would be known by to readers" makes sense in some way. However, this principle leads to such strange results like in the example of Xavi. In the real world, Xavier Hernández i Creus' alias is Xavi - in Wikidata it is supposed to be flipped around? What indeed is missing on Xavi Hernández (Q17500) at the moment of writing, is a dedicated statement that additionally lists the alias "Xavi" for machine-readability. That would be far more consistent and avoids any discussions about which is the most common name of an item... Random knowledge donator (talk) 19:42, 28 June 2014 (UTC)[reply]

What to do with plurals?[edit]

I've found many items with (Portuguese) aliases which are just the plural form of the label, probably created by a bot based on existing redirects. Shouldn't these be removed? Helder 14:12, 6 July 2014 (UTC)[reply]

Any suggestions? Helder 12:45, 17 October 2016 (UTC)[reply]
I have the same question; should 'puppy' have the alias 'puppies'? Is there no standing policy? Will this become mute as items are linked to lexemes? --Emain Macha (talk) 09:58, 21 November 2018 (UTC)[reply]
I don't see any problem with retaining pluralisms, especially when they involve more than just adding 's' or 'es' to the end of a word (e.g. 'geese' for 'goose'). Josh Baumgartner (talk) 04:00, 21 February 2021 (UTC)[reply]
If plurals are to be included in English, should all inflected forms of a noun be included in non-English languages, and if not, why not? Or does it make more sense to avoid entering plurals altogether, systematically? I randomly looked at muskrat (Q26283) and it has no plural.
What is the use case for having plural? Even machines could from the plural from singular, couldn't they? --Dan Polansky (talk) 05:44, 18 May 2023 (UTC)[reply]

How to add alias?[edit]

The page does not explain how to add an alias. Jc3s5h (talk) 14:46, 13 July 2015 (UTC)[reply]

Einstein, Albert[edit]

Hello. Are these kind of aliases desired? [1] Emijrp (talk) 20:42, 21 March 2017 (UTC)[reply]

@Emijrp: Jarekt says no. I'd second. --Marsupium (talk) 07:52, 7 June 2018 (UTC)[reply]
  • "not allowed: Alternative word order for people names" - WHAT?? It is the most useful usecase of aliases I know! Otherwise how to find the correct person by surname (in English) or by name-patronymic (in Russian)? --Infovarius (talk) 12:43, 19 September 2019 (UTC)[reply]
  • Seems to be default in Russian .. (obviously, the Russian guideline could say something else, but then this part should probably be in the English part, if not dropped entirely) --- Jura 11:48, 2 February 2020 (UTC)[reply]
  • Frankly, I'm not sure that it's a Right Thing™. Even though it's currently useful for the search box in the upper right (that seems to use "leftmost longest" matching), it's really nothing but a sheer redundancy that could and should be fixed in software rather than manually supported by a lot of tedious edits and a lot of the resulting garbage in the database. If we are going to resolve this fundamentally, I'd rather file a Phab ticket to improve the search algorithms, rather than legitimize our current highly sub-optimal workarounds. And please also note that there are already no such problems with Special:Search, if only anyone can be so kind as to use it. — Mike Novikoff 02:40, 3 February 2020 (UTC)[reply]
@Mike Novikoff: It would be great if a software solution could be implemented to deal with this. I applaud you for pursuing that avenue. In the meantime, I don't see a problem with permitting last-name-first aliases if people see fit to add them to bridge the gap to the time when software is ready to take over. At that point it would super simple to have a bot go and clean up the alternate aliases that are covered by the software. Josh Baumgartner (talk) 03:57, 21 February 2021 (UTC)[reply]

To-do list for guideline status?[edit]

Is there a to-do list, for what we need to do / decide / discuss, to get this page confirmed as an agreed upon guideline? Quiddity (talk) 18:55, 9 October 2017 (UTC)[reply]

@Quiddity: Perhaps start with a list of items that have been discussed on this talk page and reached a conclusion, or at least have no objections, as a Phase 1, and then other issues in discussion here as a Phase 2 list? I would guess that a short list of a few non-controversial bits will be a lot easier than a grand attempt to capture everything. Josh Baumgartner (talk) 03:23, 21 February 2021 (UTC)[reply]

Remove "always"[edit]

We want to make the creation of new items as easy as possible. To that goal, it doesn't make sense to have a strong requirement to add aliases. As a result I propose to remove "always" in "You should always include". Keeping guidelines as short as possible to express the desired meaning is another reason for not using unnecessary words. If you disagree, what good do you think is done by including always in that sentence? ChristianKl15:33, 23 December 2017 (UTC)[reply]

@ChristianKl: I agree with you. This appears resolved now, at least through the screen I see when I create a new item. If it still says 'always' some other form, I'd support taking care of that. Josh Baumgartner (talk) 03:18, 21 February 2021 (UTC)[reply]

None[edit]

I've reverted a few rounds of this. I know it's supposed to be "common sense", but in light of this response from one of the people adding it, could we please include a statement that very explicitly says "If it doesn't need an alias, then leave it blank instead of putting in 'none'"? WhatamIdoing (talk) 17:09, 23 August 2019 (UTC)[reply]

You mean "description", right? But this is also valid for aliases, indeed. --Matěj Suchánek (talk) 07:01, 24 August 2019 (UTC)[reply]
This diff shows an alias of 'none' being assigned. The bot operators already have a fix on the way. WhatamIdoing (talk) 20:04, 24 August 2019 (UTC)[reply]

Abbreviations[edit]

Should abbreviations (including acronyms and initialisms, contractions, and other shortenings) be included in the "Alias" field? Some abbreviations are frequently used in both the written and spoken words but others are only used in the written word, but not in the spoken word. For example "NATO" is often used in both the spoken and written word as an abbreviation for "North Atlantic Treaty Organisation". On the other hand "Maj." is frequently used in the written word, but in the spoken word, once uses the word "Major". Furthermore, where do we draw the line? If an abbreviation was used historically, but is no longer in use today, should it be included - ie, shoudl Wikidata only concentrate on current usage? If aan alias is no longer in common use, shoudl it be flagged as "(historic)"? Comment please? – The preceding unsigned comment was added by Martinvl (talk • contribs) at 23:15, 3 January 2020 (UTC).[reply]

If we think of aliases as of something that just helps users find the relevant item (do they have any other purpose?), shortenings like "Maj." are certainly redundant with "Major" since they add nothing to the search functionality. And as a general rule of thumb I'd consider just that: the probability that any user will ever search for a particular combination, plus whether it can or cannot be found already (e.g. the starting part of a longer term is redundant, hyphens are not distinguished from whitespace, and so on). — Mike Novikoff 00:55, 4 January 2020 (UTC)[reply]
May I suggest adding the following to "Criteria for includion and exclusion:
Inclusion
  • Acronyms that have been registered as trade marks, that are used in an organisation's own website or that are so widely known that they are seldom spelt out in full (such as "NATO", "EU", "US").
Exclusion
  • Acronyms that are not source-accredited.
Martinvl (talk) 11:05, 8 January 2020 (UTC)[reply]
What means "not source-accredited"? I don't think we should exclude abbreviations just because they are not used by the subject of the item. --- Jura 09:04, 25 January 2020 (UTC)[reply]
@Jura1: Would you be happy if we were to replace the text "Acronyms that are not source-accredited" with either the text "Acronyms that are infrequently used" or "Acronyms that lack notability in their own right". Martinvl (talk) 17:53, 25 January 2020 (UTC)[reply]
@Martinvl: I disagree with the exclusion any acronym or initialisation that has been used in the real world, even if it has only been infrequently used, because it may help users find the relevant data. And how would you define "notability in their own right", because if they have ever been used they may be useful for searches? DeFacto (talk) 19:22, 25 January 2020 (UTC)[reply]
@DeFacto: All of the various sources that you have quoted (which are in single figures) that give the abbreviation "IBWM" actually read "International Bureau of Weights and Measures (IBWM)" so anybody searching Wikidata for more information can do so by entering the full English name of the organisation. Moreover, people who are searching for "Integrated water building management" or "In Bed with Madonna" will not get a spurious link. By restricting the list to "notable in their own right", we will ensure that relevant acronyms are not swamped in a morass of trash. Martinvl (talk) 16:46, 26 January 2020 (UTC)[reply]
Martinvl: I don't quite get the sequence .. are you saying that users are to search first elsewhere what IBWM means and then type the full name in Wikidata? The usual way I search is that I type an abbreviation and then select the item from the choice given (e.g. type "fr" and select either France or French language)
Some of your explanations work for short name (P1813), but for the alias field that seems to complicate searching too much. --- Jura 11:48, 2 February 2020 (UTC)[reply]

──────────────────────────────────────────────────────────────────────────────────────────────────── @Jura1: What I am saying is that the acronym "IBWM" occures so infrequently when referring to the "International Bureau of Weights and Measures" compared to the acronym "BIPM" (derived from the French "Bureau international des poids et mesures") that including it in Wikidata would not only create clutter, but would also create confusion. At a first guess, I would say that for every time that "IBWM" is used in the English language literature in this way, the acronym "BIPM" is used at least 100 times, maybe 1000 times.

User:DeFacto has found a few references (half of which date from the 1960's) where the acronym "IBWM" is used rather than "BIPM" that he want to add "IBWM" to Wikidata. It is my contention that since "International Bureau of Weights and Measures" only use "BIPM" in their English-language publications, Wikidata should do likewise. My own investigation suggests that the use of "BIPM" became the norm in 1971 when the BIPM, the National Physical Laboratory (NPL - a UK government body) and the National Institute for Science and Technology (NIST - a US government body) cooperated in translating the first edition of the SI Brochure from French into English.

If you read the BIPM's flagship document, the SI Brochure (9th edition) you will find the acronyms used in the publication are catalogued on pages 106 (in French) and 211 (in English). A comparison of these lists will reveal that some organisations:

  • base their acronyms and names on one language only (eg BAAS: British Association for the Advancement of Science)
  • base their acronyms on one language, but spell out the organisation's names in both English and French for example
  • BIPM: Bureau international des poids et mesures/International Bureau of Weights and Measures using French as its lead language
  • IERS: Service international de la rotation terrestre et des systèmes de référence/International Earth Rotation and Reference Systems Service using English as its lead language
  • treat both English and French equally for example
  • OMS: Organisation mondiale de la santé and
  • WHO: World Health Organization
  • have an acronym that is not based on any particular language for example
  • ISO: International Organization for Standardization/Organisation internationale de normalisation

Finally, may I draw to attention that in the English Wikipedia :EN:MOS:CAPSACRS requries that any acronym should be "source-attested", not just that it exists somewhere. May I also draw to attention that this particlar issue has been the subject of a lengthy debate at en:Talk:International Bureau of Weights and Measures#Use of the English name (and acronym) for this organisation Martinvl (talk) 21:43, 2 February 2020 (UTC)[reply]

@Martinvl: Wikidata isn't only interested in data and facts since the 1970s though. That a different acronym was more common before more recent standards and conventions were implemente is not a good reason to exclude it from the database of human all knowledge. And given that it was a lot more common in the pre-www era, it is no surprise that searches only turn up a fraction of its usage - just those places where it has been scanned into a repository using OCR. DeFacto (talk) 07:11, 3 February 2020 (UTC)[reply]
@DeFacto: It is not for you to say what Wikidata is interested in (unless you can provide a reference), nor is it for me to say, but it is up to the Wikidata community at large to decide. Since you and I disagree, the best that we can do is to identify in clear terms what the basis of our disagreement is and let the community decide. If appropriate, the community will make a ruling that applies not only to us, but to everyone in similar circumstances. Martinvl (talk) 18:29, 3 February 2020 (UTC)[reply]
@Martinvl, Defacto: For English aliases, it should be okay to include any acronym that some users may utilize in searching in English for the item. English initialisms for sure should be included, but it is also okay to include non-English initialisms as English aliases is some people may know an organization by that (e.g. "FIA" for the Fédération Internationale de l'Automobile or "VVS" for the Russian Air Forces). It is not important to limit aliases to any particular usage threshold and even initialisms in limited use or no longer applicable due to a name change should be retained. Josh Baumgartner (talk) 02:58, 21 February 2021 (UTC)[reply]

Question[edit]

If the alias of an organisation is also the short name for the organisation (eg "NATO" is the short name for the "North Atlantic Treaty Organisation", should "NATO" be recorded as an alias or as a short name? Martinvl (talk) 16:28, 14 January 2020 (UTC)[reply]

  • @WhatamIdoing: Both does sound a reasonable idea, but there is a much more important underlying question - to what degree is each used to export data? The short name property certainly is, that after all is one of the functions of Wikidata, but is the alias field ever exported, or is it only used for navigation purposes? Martinvl (talk) 17:41, 22 January 2020 (UTC)[reply]
  • I think it should be both as the "alias"-field makes it searchable, but the statements enable queries. While it's possible to query aliases, one can't query a specific type of alias nor add references to aliases. See also #Alias_as_duplicate_of_content_in_statements? below. --- Jura 09:04, 25 January 2020 (UTC)[reply]
  • @Martinvl, WhatamIdoing, Jura1: I agree with using both as they both do their own thing. The problem with aliases as far as a data export is concerned (as I think Jura speaks to) is that there is no way to cite or qualify aliases, so it really is uncontrolled data. While statements are ideal for exporting qualified, cited data, they are not as easily searchable and are far too rarely populated as yet to be an effective way to find an item, whereas aliases are quick and easy to add and so many more items have them vs. name statements. Josh Baumgartner (talk) 02:41, 21 February 2021 (UTC)[reply]

Regional indicator symbol as English alias[edit]

At Wikidata:Project_chat#Content_deletion_by_Sapphorain, there is a discussion the centers on the practice of including regional indicator symbols in (English) aliases for countries.

A regional indicator symbol is an Unicode character equivalent of the country code (e.g. "US") and can look like a flag. Including it makes it searchable in the search box on the top right corner. --- Jura 09:04, 25 January 2020 (UTC)[reply]

 Support including unicode characters that may be used to refer to an item as an alias. I won't get any use of these but if it helps someone, I don't see the harm. Josh Baumgartner (talk) 02:28, 21 February 2021 (UTC)[reply]
 Oppose I think there is value in linking these unicode characters to the item somehow, but it does not make sense to me to include them as aliases. They (the ones I've seen) aren't aliases in any meaningful sense but are small icons of flags. A flag is not an alias of a country - it is the country's flag. Emojis are not aliases. Unless we want 🍆 to be an alias of eggplant (Q12533094) as well? This seems like a silly path to go down. Nate Wessel (talk) 18:50, 3 May 2021 (UTC)[reply]
If people are using that symbol (e.g., in text messages) to refer to eggplants, then why wouldn't we want it to be an alias for the subject? Isn't that what it means for something to be an alias? WhatamIdoing (talk) 22:57, 6 May 2021 (UTC)[reply]

Alias as duplicate of content in statements?[edit]

Another question discussed at Wikidata:Project_chat#Content_deletion_by_Sapphorain is if aliases should or should not duplicate content from statements.

See also #Question above. --- Jura 09:04, 25 January 2020 (UTC)[reply]

@Jura1: If something would be a good alias, it shouldn't be excluded just because it also the value of a statement. However, not all statement content makes a good alias, so while I would not preclude statement values from use as aliases (names and such are fine as aliases) but would certainly not want to see all statement values replicated in the alias list. Josh Baumgartner (talk) 02:33, 21 February 2021 (UTC)[reply]
What is the use of replicating part of the statements or description to an alias? An alias should be an alternativ to the label and not label + statment. From my point of view adding label + statment to aliases is pure database pollution. It doesn’t add any value and could be added automatically by using the existing data. DaSch (talk) 20:36, 6 March 2022 (UTC)[reply]

Name variations used for artists across time[edit]

Many items for artists include name variations used across centuries in different languages, e.g. in English aliases at Leonardo da Vinci (Q762).

Discussions should be found in Wikidata:Project chat's archives.

This generally also includes alternative name orders and common misspellings. --- Jura 09:04, 25 January 2020 (UTC)[reply]

I personally see no harm in allowing a broad range of name-order options in the alias list, including abbreviations for names and use of nicknames. Due the many ways of the same name being presented, it can be frustrating trying to find a person if you have to try several variations until you finally hit on the one used in the label. Josh Baumgartner (talk) 02:36, 21 February 2021 (UTC)[reply]

Spanish aliases[edit]

Spanish aliases include names without diacritics. A bot occasionally completes them. --- Jura 09:04, 25 January 2020 (UTC)[reply]

I think the policy for Spanish aliases shouldn't be made on this English page but on the Spanish equivalent of it. ChristianKl11:09, 25 January 2020 (UTC)[reply]
While I agree that policy for Spanish aliases shouldn't be made on this English page, there is a case for including names without diactritics if that version is frequently used in the English version. I tried a small test by entering the name "Massilhan" which I know to be the Occitan language version of the name "Marseillan". Up came "Marseillan" with a note that "Massilhan" is the Occitan version. Martinvl (talk) 14:43, 25 January 2020 (UTC)[reply]
Agree with both of you ;) --- Jura 11:48, 2 February 2020 (UTC)[reply]
 Support including English aliases that are anglicized versions of non-English labels or aliases for an item. Non-diacritic versions of Spanish terms sound more appropriate being added as English aliases than as Spanish ones, but whether to include them there as well is a matter for the Spanish speaking community to decide. Josh Baumgartner (talk) 02:07, 21 February 2021 (UTC)[reply]

label with disambiguator (English aliases)[edit]

Aliases can include the label with a disambiguator (e.g. "Matrix (film)" for The Matrix (Q83495)). --- Jura 09:04, 25 January 2020 (UTC)[reply]

  •  Support ChristianKl12:31, 25 January 2020 (UTC)[reply]
  •  Support as well, especially since users may paste in an article name (with dab) into the search window and so this actually helps in those cases. Josh Baumgartner (talk) 02:00, 21 February 2021 (UTC)[reply]
  •  Oppose aliases should be alternative wording and should not duplicate the label. To distinguish items the description should be sufficient. This disambiguation could also be added from the statements of an item. This is polluting the data with unnecessary information. It also leads to different kinds of aliases. Aliases that are true aliases and aliases that are used for disambiguation. That should not be the usecase of aliases but of descriptions. DaSch (talk) 20:42, 6 March 2022 (UTC)[reply]
  •  Support Yes. The point is to make it easy to select the desired entity by typing. Sorely needed. E.g. "thesaurus (IR)". Actually, I think the disambiguators should be in the labels to greatly reduce the ambiguity that plagues statements in Wikidata, but having it as alias is better than nothing. --Dan Polansky (talk) 05:48, 18 May 2023 (UTC)[reply]

Titles without "The" (English aliases)[edit]

A frequent practice is the inclusion of titles of works without the initial article. Sample "Matrix" for The Matrix (Q83495). --- Jura 09:04, 25 January 2020 (UTC)[reply]

Words other than nouns[edit]

Maybe it's worth mentioning that a concept can be expresses with words other than nouns. --- Jura 11:48, 2 February 2020 (UTC)[reply]

@Jura1:  Question do you have an example of where it has been an issue to do so? I agree with your sentence as a concept, I just am interested to see the practical application of the idea. Josh Baumgartner (talk) 02:08, 21 February 2021 (UTC)[reply]

State some usecases?[edit]

Samples:

  • select values when adding manually statements with properties of item-datatype
  • find items with the searchbox (top right corner)
  • select items on query.wikidata.org with w d : Ctrl Space
  • do string matching with another dataset
  • select items when adding data with voy:Template:listing
  • find items with Special:Search

Maybe it would be good to state some of the uses for aliases. Above a few. Some of the text might need revising as it mainly addresses the last usecase. --- Jura 11:48, 2 February 2020 (UTC)[reply]

 Question How important is it to evaluate 3rd party use cases vs. internal WD use cases? Josh Baumgartner (talk) 02:25, 21 February 2021 (UTC)[reply]

Sub-class and instances as aliases for a parent class?[edit]

I was under the impression that aliases should be limited to those that apply to the item itself, and names of sub-classes or instances of a class should not be included in the list of aliases. Sometimes I see the labels and aliases of sub-classes applied to a parent class, possibly as a way of making the parent class also show up when searching for a specific sub-class? man (Q8441) and woman (Q467) are subclasses of adult human (Q9584157) but 'adult human' doesn't list 'man' and 'woman' as aliases. However in some other instances I have seen this done, for example I have come across some product families which list several versions of the product as aliases, even when those versions have items of their own. Sometimes it seems just a remnant of when those version items had not been created yet, but lately I've been seeing some added even after those other items are there. Is this something we should be requiring, encouraging, discouraging, or prohibiting this alias proliferation? Josh Baumgartner (talk) 02:22, 21 February 2021 (UTC)[reply]

Same alias for multiple languages[edit]

 Question Is there value to keeping identical aliases for multiple languages? I know for searching it doesn't seem to add any value, as for example, if my search text is an alias in Danish, I'm just as quickly going to find it as if it is in English, regardless of my language setting. Currently, if they apply, I often add the same alias to multiple languages, but wonder if this is just extra work and maybe even causes an unnecessary load on the system, or if it actually serves a good purpose and should be continued. Thanks! Josh Baumgartner (talk) 06:47, 22 February 2021 (UTC)[reply]

Alternative word order[edit]

I think it should be included instead. It is impossible to search for a person without surname at the first place (just by name). --Infovarius (talk) 14:27, 12 July 2021 (UTC)[reply]

Alias for British/American English spelling[edit]

If I am creating an item for a scholarly article containing the British English spelling of a word like digitisation or polarisation, should I include an alias with the American English spelling digitization or polarization? Looking at the help page for Alias I think not, but I'm relatively new to Wikidata and hope a more experienced editor can advise. Thanks. HelsKRW (talk) 09:35, 15 December 2021 (UTC)[reply]

Since the Alias field provides an entry into the article, both British and American spellings should be included. There is of course a supplementary question as to which should be the principal English-langauge entry and which should be the alias. Here, I suggest that the guidelines in en:WP:ENGVAR be followed. Martinvl (talk) 15:15, 5 January 2022 (UTC)[reply]
It would be better to use the en-gb and en-us to specify which spelling belongs to which dialect than put that information into aliases where it's unclear what dialect of English it refers to. ChristianKl13:53, 14 March 2023 (UTC)[reply]

Capitalization of taxon common names in labels and aliases[edit]

I created a discussion under Help talk:Label about capitalization of taxon common names in labels and aliases.UWashPrincipalCataloger (talk) 03:49, 2 January 2022 (UTC)[reply]

Alias identical to label[edit]

Hi, I've encountered an item in which the first alias is identical to the label.

As far as I've seen, this is not the way aliases are supposed to be used; as alternative names, they shouldn't include the main name.

  1. Do I understand correctly? Is it okay to remove it?
  2. I suggest to add this explicitly as a guideline to this help page, to make it more clear (maybe under "you shouldn't:", or simply at the top or somewhere else).

Thanks! E L Yekutiel (talk) 07:41, 11 February 2024 (UTC)[reply]

I feel like it should be enforced programmatically that an alias can't duplicate the label, just like it doesn't allow an alias to be the same as another alias (in a given language). --NoInkling (talk) 07:09, 8 April 2024 (UTC)[reply]
Thanks @NoInkling!
As far as I remember, I've removed that specific occurence. I'll verify.
I agree with your suggestion (but have no idea about the internal workings of MediaWiki, nor whether my opinion matters... but you do have my support, for what it's worth).
In any case, if it will turn out that what we say here is widely agreed upon, I'd consider adding it also as a policy here (so that people will understand the reasoning). E L Yekutiel (talk) 07:31, 8 April 2024 (UTC)[reply]