• Is it useful to have a single value constraint here? I would suggest to remove this constraint.
• For humans we have name in native language (P1559) instead, which should be marked as incompatible with this property then.

—MisterSynergy (talk) 09:19, 2 February 2017 (UTC)Reply

I added a conflicts constraint meanwhile; most items that use this property are of one of the following types: language (Q34770), work (Q386724), event (Q1656682), organization (Q43229), geographic location (Q2221906), name (Q82799), anatomical structure (Q4936952), ethnic group (Q41710), award (Q618779), position (Q4164871), animal (Q729). Maybe we can limit it to something similar…? —MisterSynergy (talk) 12:28, 2 February 2017 (UTC)Reply

User:MisterSynergy description on native label (P1705) says "label for the items" and Wikidata entries are called items so it can be used on any items, and you can't just remove them, search engines may use this property. Mjbmr (talk) 13:05, 2 February 2017 (UTC)Reply

I only shifted items about humans from P1705 to P1559, which is the correct property to use for humans instead of this one, and some non-human items from P1559 to P1705 since they do not have a “native language”. It is not useful to duplicate identical data in two properties as it was the case for a couple of hundred items, and it is also difficult if we spread data with identical meaning to different properties.

As far as I can see there is no data lost, otherwise feel free to point to such problems and I will correct that. Search engines have to use the correct property anyway, and for humans it is P1559. —MisterSynergy (talk) 13:15, 2 February 2017 (UTC)Reply

User:MisterSynergy I already had name in native language (P1559) on my humans so to me you just removed native label (P1705) from my humans and it's a huge lost. Mjbmr (talk) 13:21, 2 February 2017 (UTC)Reply

Could you please provide an example/diff link? If both properties hold the same value, what’s the loss if we reduce redundancy? There are barely any humans with P1705, and nobody would expect this information there… —MisterSynergy (talk) 13:25, 2 February 2017 (UTC)Reply

Hi,

@Jura1, Fexpr, Letzi', Adert, Harmonia Amanda, MisterSynergy: (biggest users of this property according to NavelGazer)

When should we use native label (P1705) and when should we use official name (P1448)? The description are overlapping « label for the items in their official language (P37) or their original language (P364) » and « official name of the subject in its official language(s) » and indeed a request shows that a lot of item have the same value with both property (and same as the label itself...) :

SELECT ?item ?itemLabel ?original ?official WHERE {
	?item wdt:P1705 ?original ; wdt:P1448 ?official .
	filter ( ?original = ?official)
	SERVICE wikibase:label { bd:serviceParam wikibase:language "fr" }
}

Is it ok and/or expected to triple information like this? (and should then launch a bot in order to be consistent on all items) or should we use only the more precise property official name (P1448)?

Cdlt, VIGNERON (talk) 10:24, 23 February 2017 (UTC)Reply

Thanks for this topic. I see potential to streamline these properties as well. Particularly native label (P1705) and official name (P1448) have overlapping scope (as mentioned by you), and the person-specific name in native language (P1559) and birth name (P1477)/married name (P2562) also lead to redundancies. There’s also the rarely used name (P2561). Until now I only used P1559 a lot, and made sure that its type constraint is not violated any longer by use in non-person items.

It could be an option to more clearly define the scope of all these properties and force it with constraints, or to “merge” some of them into each other, maybe with more qualifier use. I’m open for any suggestion at this point. —MisterSynergy (talk) 10:51, 23 February 2017 (UTC)Reply

I think this property must be used very carefully (and almost never be used) with places. Let's have a look at the examples at the top of this page.

Pirelli Tower (Q920809) → Pirellone (or any other valid name in Italian): OK, because this tower was built in an Italian-speaking country, its "original language" is Italian.

Moscow (Q649) → Москва. Are you sure russian is the "original language" of Moscow? Or is it Old Church Slavonic (Q35499) or another older, prehistoric, forgotten language? I don't think we will ever know the "original language" of Moscow, or of any old town or city. This property should be avoided with old places because they don't have any "original language". El Caro (talk) 13:48, 23 February 2017 (UTC)Reply

I don't think either property should be used on people. Other than that, I think P1705 is easier to use. As people may not focus on the same aspects, either property has it's advantages. Which ones would you want to remove? I think blind bot edits are dangerous on either.
--- Jura 09:56, 25 February 2017 (UTC)Reply

@Jura1: I'm just pointing out problems with the description of native label (P1705) :

• the description in not the same in different languages: description in French and Italian is only about « original language » but in English, German, Spanish, etc. is both about « official and original language »
• the description in English, German, Spanish, etc. is overlapping with official name (P1448) description (description in Italian even explicitly recommand to use official name (P1448), @ValterVB: who added this precision). The request above shows that there is indeed overlapping and duplicate values.
• « original » is not documented.

I'm maybe wrong but as a start I think we should remove the « official » part in the description (ie. going with the spirit of the French and Italian description). And give more explanation about the meaning of « original » (maybe something along « the name in the current/local/original/native? language, not the original name », advices and inputs are welcome here). Plus, a {{Complex constraint}} could probably be created to solve (at least partially) the comment « potentially possible i.e. using country (P17) or original language of film or TV show (P364) with mapping table to language code the value might be created from current label ».

About not using it for people, I tend to agree and there is already a constraint for that, so - if there is no objection - I think we should clean these constraint violations (here we can use PetScan to remove native label (P1705) as the 77 human (Q5) with native label (P1705) all already have a name in native language (P1559) with the exact same value).

I forgot to ping

Ash Crow
Dereckson
Harmonia Amanda
Hsarrazin
Jura
Чаховіч Уладзіслаў
Joxemai
Place Clichy
Branthecan
Azertus
Jon Harald Søby
PKM
Pmt
Sight Contamination
MaksOttoVonStirlitz
BeatrixBelibaste
Moebeus
Dcflyer
Looniverse
Aya Reyad
Infovarius
Tris T7
Klaas 'Z4us' van B. V
Deborahjay
Bruno Biondi
ZI Jony
Laddo
Da Dapper Don
Data Gamer
Luca favorido
The Sir of Data Analytics
Skim
E4024
JhowieNitnek
Envlh
Susanna Giaccai
Epìdosis
Aluxosm
Dnshitobu
Ruky Wunpini
Balû
★Trekker

  Notified participants of WikiProject Names

Cdlt, VIGNERON (talk) 11:36, 25 February 2017 (UTC)Reply

I think it tends to be the label in the official language somehow associated with the item (not necessairly the item's official language). The label isn't necessarily the "official name" of the item. Depending on the use, you may want one or the other. If it's identical, you'd probably display just one. Maybe we want to look into item where you think this creates problems.
--- Jura 17:11, 26 February 2017 (UTC)Reply

I came here for the same reason. Pity there wasn't a clear answer. Rehman 14:42, 13 October 2019 (UTC)Reply

At Special:Permalink/703379123#Why_is_native_label_(P1705)_subject_to_a_single-value_constraint @Jmabel, Jc86035: noted that this property has conflicts in multicultural communities where people speaking different languages have different native names for topics including places, people, and events. I agree.

Support remove the single value constraint. Blue Rasberry (talk) 13:49, 27 June 2018 (UTC)Reply

Support as the one who originally raised the issue elsewhere. - Jmabel (talk) 15:48, 27 June 2018 (UTC)Reply

Support per my own comments. Jc86035 (talk) 05:17, 28 June 2018 (UTC)Reply

Support Pmt (talk) 05:28, 30 June 2018 (UTC)Reply

Support remove the single value constraint. --Davidpar (talk) 12:42, 25 November 2018 (UTC)Reply

• Removed the single value constraint, and added a complex constraint on this page. The new "single value (per input language) constraint" looks for multiple values with the same language code; we cannot do this with the conventional single value constraint. —MisterSynergy (talk) 20:19, 25 November 2018 (UTC)Reply

The label requires a 639-1 value. This is a problem when the language has only a 639-3 (which is the vast majority of languages). How can you introduce the native label for Dagara (Q11004218) when its only code is dgi? --Marcmiquel (talk) 14:00, 8 June 2019 (UTC)Reply

• @Marcmiquel: codes are those defined per Help:Monolingual_text_languages. There it's explained how to request missing ones (might take a couple of months though). --- Jura 16:01, 8 June 2019 (UTC)Reply

Following the removal of the single value constraints, many items have now more statements than they actually should have.

• What is the plan to clean this up?
• How should we notify the users that do such incorrect additions.

The single value constraint took care of most of that. ----- Jura 16:51, 30 January 2020 (UTC)Reply

I'm remove the some 1300 values added to name items (e.g. Laga (Q37330527)). To avoid that this happens again, I added a suggestion constraint. --- Jura 18:20, 1 March 2020 (UTC)Reply

Now it shows a problem again when having two values (with different language codes) in officially bilingual areas as well. That seems no perfect solution to me. --J budissin (talk) 11:57, 9 March 2020 (UTC)Reply

Hi there,

This is a very broad, open-ended question. How should P1705 be used on Q101352 (family name). I've seen multiple different takes which suggests to me there's no consensus.

Please consider examples such as:

• Smith (clearly English, though used in various countries)
• Luty (present in Polish, present in English, etymology totally different)
• Muller vs Müller, Kwasniewski vs Kwaśniewski (in non-umlaut countries you're likely to see Muller more often Müller)
• Surnames that may come from non-latin scripts

Should surnames get the native label in multiple languages and that's all? Wouldn't it make sense to include the native label based on the source language, too?

I'm totally open to me being confused and, e.g., conflating native label with language of work or name Property:P407 in terms of what I'd like to accomplish, but even if I'm not getting it right, other Wikipedians seems to have similar problems and vary in how they approach this topic (e.g., some have been deleting native labels set to a specific language and retaining only the native label set to multiple languages; others leave all other labels alone, but add preferred rank to the instance with multiple languages; others list out multiple native labels: e.g., in the case of Muller they might do Muller (multiple languages), Muller (German), Müller (German).

Here's a few conversations I've had about this:

User talk:Quick-O-Mat (scroll down to Kwasigroch - removal of native label)

User talk:Gymnicus (scroll down to Setting (multiple languages) to preferred rank / adding described at for Internet Dictionary of Polish Surnames)

I appologize in advance if I've caused havoc by including native labels set to Polish for surnames that are chiefly Polish. Itorokelebogile (talk) 08:09, 20 September 2023 (UTC)Reply