Help talk:Label

From Wikidata
Jump to: navigation, search

Help:Label[edit]

Copied from Wikidata:Project chat.

Shouldn't we have a help page for labels like we do have one for descriptions? This help page would need to contain guidelines on the capitalization of labels. Currently, I do not find an agreed basis for such changes. --Leyo 14:27, 22 November 2012 (UTC)

Some relevant discussions: 1 2 3 4 5. --Yair rand (talk) 14:37, 22 November 2012 (UTC)
Thanks. As far as I see only #4 is on the capitalization.
Would you agree that we need the proposed help page? --Leyo 14:40, 22 November 2012 (UTC)
Yes, that's why I linked to relevant previous discussions, so we have what to build a standard from. Still, the issues could use some further discussion. --Yair rand (talk) 14:44, 22 November 2012 (UTC)
I also support making a help page for labels — however, much like Yair rand, I think some more discussion is in order. —Theopolisme (confess) 18:38, 22 November 2012 (UTC)
Strong support. Wagino 20100516 (talk) 23:32, 22 November 2012 (UTC)
What exactly needs to be discussed more in addition to the capitalization? --Leyo 13:17, 23 November 2012 (UTC)

I think there should definitely be a Help:Label page. If someone creates a proposed guideline for Labels we could then discuss the specific guidelines and publish it when consensus is reached. Things other than capitalisation that need to be explained are:

  • No disambiguation in the Label, leave it to the Description. (e.g. "London, England" should just be "London")
  • What happens if there is no page in your language, use a foreign Label, or translate it? Is no label better than a non-translated one?
  • Labels for varients within one language such as Canadian and British English (though this could be covered by the language fallback).

There may be others but that's all I can think of for now. Delsion23 (talk) 13:24, 23 November 2012 (UTC)

No disambiguation: agree. Translation of labels: from which language? Maybe it's better to leave it blank, since searches will also find the interwikis. Besides: no attributes forming part of the name, like "New York City" or "City of New York"; it should be "New York" as label and "city" as description, I think. (At least in my language, I'm not sure if that's also applicable in every language). Regards. --Dalton2 (talk) 14:47, 23 November 2012 (UTC)
Agree with Delusion — no disambiguation in labels. I think we should go ahead and start working on a draft at Help:Label...when that page is relatively stable and has community approval, we can go about thinking about how to publicize it (and Help:Description, for that matter) - perhaps tooltips/links on Special:CreateItem ... but for now, I agree, writing it is the goal. —Theopolisme 15:26, 23 November 2012 (UTC)
OK, I was bold and drafted Help:Label. --Leyo 16:05, 23 November 2012 (UTC)
  • Symbol support vote.svg Support the #1 and the #3, but I Symbol oppose vote.svg Oppose to the #2: the use of lowercase in the label. We would have to change all labels for all languages​​. The problem is that it should be done manually. Bots, which have so far added the labels, they have never considered this rule too. Should have been set at the beginning of the project, not now. Now it is useless and harmful in my opinion. How many of you knew that it was necessary use the lowercase for the first letter? How many of you have entered the lowercase? Raoli (talk) 23:04, 23 November 2012 (UTC)
  • Symbol support vote.svg Support #1, #2 and #3. The technical difficulty to achieve #2 arises from the automatic work done by the bot, and it's impossible for it to do it better since it's a task that requires human intelligence. Common names appear in lowercase in dictionaries and encyclopedias, and the case is also a piece of information. For example, it's not the same a planet that something called Planet. I think that technical difficulty is not a solid argument, and neither is aesthetics. It's a matter of patience and dedication, and the result is undoubtedly better than leaving all the labels in uppercase. --Dalton2 (talk) 23:28, 23 November 2012 (UTC) Regarding translations, I prefer to find the more appropiate name for the entity the item represents in my own language, better than directly translating it; and I prefer to leave it blank when one is not hundred per cent sure about it. If there's only one interwiki and it's impossible to find the corresponding name in any other language, then probably it's acceptable to translate it, but in some cases the name is not translatable, so that decision must be taken with care. --Dalton2 (talk) 00:17, 24 November 2012 (UTC)
  • Symbol support vote.svg Support #1, #2 and #3. I agree Dalton. --Rondador 23:35, 23 November 2012 (UTC)
  • Symbol support vote.svg Support #1, #2 and #3. If you can translate the label ok, otherwise better without label. For the initial letter I agree with Dalton, I think it is better to use a system similar to that of wikitionary rather than wikipedia. --Beta16 (talk) 23:52, 23 November 2012 (UTC)
  • Symbol oppose vote.svg Oppose about the lowercase letters in the beginning of the description, it's a nonsense. In the beginning of the sentence we must write with uppercase letters. Symbol oppose vote.svg Oppose about desambiguation because there are a lot of pages in Wikipedia with the same name, per example french communes with the same name as Saint-Aubin (more 54), it's a nonsense if we don't keep the desambiguation. We are encountering problems with Gadget-autoEdit.js gadget which is doing the contrary, too. Symbol support vote.svg Support about Scientific versus common names -- Bertrand GRONDIN  → (écrire) 16:03, 10 December 2012 (UTC)
But the disambiguation is needless as it is already disambiguated in the description. What's the point in writing the disambiguation in both fields? The lower case at the beginning of a description will make it easier for it to be machine read. It's easier for a computer to add a capital for the beginning of a sentance than it is for it to make it a lower case in the middle of a sentance (as a computer may not be able to know if it's supposed to be a pronoun or not). Delsion23 (talk) 00:23, 11 December 2012 (UTC)

Colors[edit]

I think that colors are helpful in distinguishing, but if consensus says not, I don't have problem. —Theopolisme 16:21, 23 November 2012 (UTC)

See Help talk:Description#Colors. I think we should discuss this in one place (here or there) only. --Leyo 16:25, 23 November 2012 (UTC)
Sure, sounds fine. —Theopolisme 16:29, 23 November 2012 (UTC)
I think we should not discuss the use of colors about itself but for its usefulness. The color is just a ploy to help you remember a specific thing or rule (as well as advertising logos). To try to remember just a concept you can then also use a different font family or other expedient. This is what I know about. Raoli (talk) 16:38, 23 November 2012 (UTC) p.s. The colors in the sections of Help:Description try to distinguish the section from the other to ensure that your brain associates color and images to text and MEMORIES it.
I know what the intention was, but I still think it's more distracting than helpful. People from Latin countries tend to like things more colorful. --Leyo 16:47, 23 November 2012 (UTC)
Then it is simple, every tongue shall decide whether to adopt the colors or not. So who wants them puts us the colors and who does not want not. --Raoli (talk) 16:51, 23 November 2012 (UTC)
I second that the colors add nothing but are very distracting. This is also Sven Manguard 18:43, 27 November 2012 (UTC)

Subscripts and similar[edit]

The correct label for Q61124 would be “C19H21N”. There are surely many similar cases in other subjects as chemistry. Should we add a statement on that? --Leyo 16:43, 23 November 2012 (UTC)

I suppose it's not difficult to include subscript and superscript (anything else?). I think that by now it should be enough with allowing the inclusion of codes like <sup></sup> and <sub></sub>, but in the future there could be a WYSIWYG editor to be more consistent with the spirit of the database. I Symbol support vote.svg Support. Regards. --Dalton2 (talk) 11:10, 24 November 2012 (UTC)
Couldn't we just use the subscript and superscript numbers included in Unicode? See w:en:Unicode subscripts and superscripts#Superscripts and subscripts block. --Yair rand (talk) 08:12, 26 November 2012 (UTC)
I had this idea, too. But I fear that it might cause problems if converted to plain text (with no unicode characters). --Leyo 08:41, 26 November 2012 (UTC)
Every inline text formatting (in Wiki syntax or HTML markup) should be allowed. Sometimes it will also be desirable to include links (but the problem will be on how to resolve those links if the same Wikidata set must be used across several wikis, it may work however in a locally installed Wikidata extension to a wiki. We should not tolerate external links to specific Internet domains, but sometimes it will be helpful to have links pointing to external wikis via pagename prefixes using the wiki syntax of links. For some cases, we'll need to include inlined images, or even TeX math formulas.
So what is the use of Wikidata: we should allow storing in a field any content that is writable in Wiki syntax (including template calls ?), because the purpose of Wikidata is to allow storing a collection of small wiki elements as if they were in the same page for the same data row.
I don't know exactly how Wikidata works, but for me it's just a GUI interface for editing these template subpages (one for each row) from a base page listing all rows in a given data table (acting like a topic selector). However there are differences : the main page (for the topic) can uses a mechanism to infer some default values (when no value is given for a specific key, i.e. a specific column in tabular data), and the main page can also format the data returned by calling the subpage as a template transclusion, performing additional #if's where needed, to use data from another column or by compting it.
A wikidata row should be like a subpage of a main page listing the subpages using template calls, and where each subpage uses a "#switch to return the value matching a key (the name of a column in tabular data). I have alreasdy experimented this since several years, using templates using only the wiki syntax (without using wikidata which did not exist), and various templates in Wikipedias are using such technics to store tabular data which may contain optional columns for optional attributes in a data row. The name of the subpage is like the row id.
Wikimedia already attaches several (keyed) lists of metadata to each page : an history of versions, a list of categories, a list of interwikis, and some other informations. Wikidata is a generalisation of this, allowing performing queries. But it will only be valuable if it can also query the content of a table (or query) by return how many rows it contains, and by allowing performing a loop on its rows and navigating it by limited ranges. Verdy p (talk) 14:00, 26 November 2012 (UTC)

I added H₂O: Just Add Water for the label to have an example. If we disallow unicode characters in the label, we may at least allow them for aliasses. --Leyo 00:17, 4 December 2012 (UTC)

If we disallow unicode in any area, most languanges will be incompatible, so I think it's safe to assume that unicode is fine everywhere, hm? --Yair rand (talk) 00:20, 4 December 2012 (UTC)

No page in English[edit]

Separating into sections for accessibility. —Theopolisme 17:12, 23 November 2012 (UTC)
What should be done if there is no page in English and there is no (agreed) translation?

I think that we should follow several steps: 1) We ask: are there any sources in English for the name? If the answer is yes, we check if they all agree. If they do, we have the name. If they don't, we choose the name that appears in the most reliable source or sources from the ones available. If there aren't any sources in English, we ask: 2) are there any sources in other languages than the original one for the name? If the answer is yes, we check if they all agree (i.e., if they are literal translations of each other). If they do: we do a literal translation. If they don't agree or there aren't any, 3) we do a literal translation (if possible) or copy the untranslated name into the English field (to be determined by the community). Please read the thread below about references for labels and aliases. Regards. --Dalton2 (talk) 11:27, 24 November 2012 (UTC)
In Spanish, we give preference to linguistic sources, specially the works published by the Association of Spanish Language Academies, and, alternatively, other reliable sources related to language. That's what is written in our manual of style. In other languages, maybe they also follow the institutions which appear in this list. I can see that there is no language regulatory body for the English language. That's bad news. For the rest of the languages, I think that it would be reasonable to allow references for the labels. --Dalton2 (talk) 11:55, 24 November 2012 (UTC)
I think that this section can't be the same for both English and the rest of the languages. The points already added are clearly English centric, and thus they can't just be translated into other languages. For example, in Spanish we follow common use, but that common use is endorsed by the sanction of the Academies when available. Also, if the item is a proper noun that has an article on a Wikipedia from another language using a Latin-derived alphabet, we don't always use that: location names are often translated into Spanish. Points 4 and 5 refer to the level of confidence of the user: we don't rely on confidence, we rely on reliable sources. Confidence might be applied only in the case that there are literally no sources available, and in such case the translation would be temporary until a proper sourced translation appears. Wikidata shouldn't be original research based on users' opinion, not even for the labels. And finally, we don't use 'common use' as what it literally means; it is assumed that common use is refered to academic environment, and not vulgar speech; that's what Academies sanction. --Dalton2 (talk) 23:41, 27 November 2012 (UTC)
(edit conflict) I put a five step process in that takes into account Dalton2's suggestion as step 1. If anyone disagrees, we can tweak it. Sven Manguard Wha? 23:42, 27 November 2012 (UTC)

Disagree. This is not the English Wikidata. This is the multilingual Wikidata. I think the label should be in Unicode, including any accented letters. For items for which there is no generally used transliteration the label should be in the language and script normally used for that item. Remember that this info will be imported into data boxes in lots of languages. Why would these languages have databoxes with a heading in English? Filceolaire (talk) 02:32, 7 January 2013 (UTC)

Every language has their own labels. Unless you've set your language to English, you're not going to ever even see the English label. Because of that, each language can tailor labels to their needs. Sven Manguard Wha? 22:11, 7 January 2013 (UTC)
This policy should be not be translated word by word in every language. But be adapted for each language to tell if what to do if there is not a page in that language. Carsrac (talk) 17:44, 14 February 2013 (UTC)

References[edit]

One more issue about labels that should be discussed is their scope. Maybe the developers didn't have in mind a rigorous use of labels. But, if the scope is not only internal use, then they also should have references to keep the reliability of the database. And the same should apply to the aliases. That way Wikidata could act as a reliable source for, for example, the titles of the articles in Wikipedia themselves, something that doesn't exist so far, at least in an official way. And, internally, references would also prevent subsequent changes to labels (or aliases) without a solid base to do them. Opinions? --Dalton2 (talk) 18:57, 23 November 2012 (UTC)

Symbol support vote.svg Support I strongly agree with this point. I believe referencing should be a standard policy. --SynConlanger (talk) 20:30, 17 August 2015 (UTC)

Italics[edit]

There are IMO some labels or parts of them such as binomial names or descriptors in chemistry would need to be written in italics. Examples:

Currently, it does not seem to be technically possible. If we agree that there is a need for italics in labels, we might request for this by opening a bug. Thoughts? --Leyo 09:10, 24 November 2012 (UTC)

Here they talked a bit about italics, but nothing conclusive. I do think that cursive is also information: it's impossible to know if a given word must be written in italics or not if that information is not contained somewhere in the item. I suppose it's not difficult to include italics, so I Symbol support vote.svg Support the proposal. By now it should be enough with allowing the inclusion of codes like '' or <i></i>, but in the future there could be a WYSIWYG editor to be more consistent with the spirit of the database. Regards. --Dalton2 (talk) 11:06, 24 November 2012 (UTC)
I also Symbol support vote.svg Support italics—it makes sense, and, almost more importantly :), sounds like it should be relatively easy to implement. —Theopolisme 15:06, 24 November 2012 (UTC)
I think that it's important information, but it still might make sense not to add it to the label. In phase two, we'll have many opportunities to add all sorts of data, including extra information about names. Perhaps we should add italics as a specific data point, so that we still have plain text in labels. (Also, I strongly suspect having HTML in labels would be really difficult to implement, but we should really ask a dev about that.) --Yair rand (talk) 08:09, 26 November 2012 (UTC)
Plain text can always easily derived from a label, even if it is (partly) in italics. --Leyo 08:39, 26 November 2012 (UTC)
This is not just for italics, a more common problem occurs with superscripts (sometimes subscripts as well) to make a significant difference (think about chemical formulas where BOTH are used, and where the charges using minus and plus should remain in superscripts, otherwise you get another formula for a different compound.
Converting them to plain-text by dropping the HTML formatting may give something wrong.
So we should accept data using some basic wiki markup or inline HTML markup. For some languages this is even the onlyalternative possible, because the markup is used to generate the correct text layout. This will be needed notably for storing translations in this first project.
For other usages of Wikidata (e.g. for attaching metadata to a wikipage, like several transliteration schemes on Wiktionnary, or alternate sort keys for different collation conventions in the same language, where these keys cannot be deduced only by UCA/CLDR tailoring rules, e.g. to index a page in distinct categories according to collation schemes, or for creating tabular data such as population, area in km² or ha, alectoral results, and to allow generating a formatted and paginated or sorted table from wikidata, it will ne less problematic).
Thanks. Verdy p (talk) 13:42, 26 November 2012 (UTC)
You can forget about italics in labels. Note that there is an bug for adding italics and it is marked as WONTFIX - bugzilla:41749. The same goes with any other wiki syntax - bugzilla:41560.--Snaevar (talk) 23:41, 27 November 2012 (UTC)

Revamp[edit]

I did a revamp today. Any thoughts would be welcome. Sven Manguard Wha? 03:17, 28 November 2012 (UTC)

Very nicely done. Maybe a bit more whitespace than necessary, though. --Yair rand (talk) 10:52, 28 November 2012 (UTC)
@Yair rand, I've taken the liberty to kill some of the white space. —Theopolisme 12:04, 28 November 2012 (UTC)
In general, the guideline looks promising, but there is one small yet significant point which concerns me.

The English Wikipedia is a haven for nationalists and trolls, and hijacking discussions about article titles are high up such users' to-do lists. Rather than mirror any consensus there, or worse yet, give such people scope to continue their arguments on Wikidata, I would prefer that we foster a culture that encourages people to contribute. In general, we should defer to the judgement of the person who took the time to give the previously neglected item a label in the first place, unless the case that another name is more common is compelling. I would therefore suggest that we add words to this effect, and drop the emphasis on deferring to the wisdom of en.wp. —WFC— 10:58, 28 November 2012 (UTC)

Does this work? This is also Sven Manguard 15:37, 28 November 2012 (UTC)
That's perfect for the lead, and the lead on its own more or less addresses my concern. Perhaps something brief in the body would help, making crystal clear that our primary concern is that the label is not an obscure term (or to phrase it another way, that we aiming for a common name – once we have one, we have little to no interest in debates over which of multiple common names to use)? —WFC— 19:49, 28 November 2012 (UTC)
Regarding the namespace section, I'm not sure Wikidata will be using other namespaces at all. Wikidata is meant to be improving the article quality, not the project quality. I'd have to ask the Development Team, though. Ypnypn (talk) 14:10, 28 November 2012 (UTC)
See Wikidata:Requests for comment/Inclusion of non-article pages. --Leyo 14:29, 28 November 2012 (UTC)
Having read through that, I'm still not entirely sure what the consensus is. Has a decision been made? This is also Sven Manguard 15:18, 28 November 2012 (UTC)

Layout sample of a Wikidata page[edit]

Why sample image are given the prefix still use an for description that doesn't comply with this rule? Can it be repaired with the others, please? Wagino 20100516 (talk) 17:49, 28 November 2012 (UTC)

It has an "an" because I fully intend to getting around to having that guideline changed. Could you please point me to the discussion where this was agreed upon, because I don't remember it having consensus, but I may be thinking of something else. This is also Sven Manguard 18:36, 28 November 2012 (UTC)
Yeah, it's proposed policy and seems like there isn't agreement/consensus that decided it, for now. Wagino 20100516 (talk) 19:20, 28 November 2012 (UTC)

General guideline or English only?[edit]

Does this proposal a general guideline for whole Wikidata or only for English language? If it is going to be general guideline and subject of translation then there are few additional points that wouldn't discussed yet. Plus, as it was mentioned above, the guideline is really English-centric. Thank you. --Zanka (talk) 21:09, 28 November 2012 (UTC)

I was operating under the assumption that each language would decide their own rules. Sven Manguard Wha? 23:55, 28 November 2012 (UTC)

Sunflower and Fireweed capitalised?[edit]

Don't these two items contradict the capitalisation rules mentioned above them as they are not proper nouns, the same as rabbit? 130.88.141.34 16:05, 29 November 2012 (UTC)

The examples have been fixed by Sven Manguard. --Yair rand (talk) 16:51, 29 November 2012 (UTC)
I meant to come and thank you here, but I seem to have forgotten. I did give a shout out in the edit summary though. This is also Sven Manguard 20:52, 29 November 2012 (UTC)

Multiple common names[edit]

I think we need a subsection outlining what to do in the case of multiple common names – from my experience on en.wp these situations lead to the most bitter, protracted disputes. In my opinion, the solution is to stick with the first common name, unless the evidence that another name is more common is overwhelming or irrefutable. I strongly feel that we should use language like that in order to discourage frivilous renames/renaming requests. However, given how controversial the area is, I'm hesitant to put my opinion straight into the draft without gauging others' thoughts first. —WFC— 22:10, 29 November 2012 (UTC)

I know what you mean. The arguments over the naming of Inter Milan (or is it Internazionale??) is a good example of a meaningless fight over titles. A policy whereby the first commonname entered is the one that sticks could possibly help. It could work in the same way it helps on en.wiki with English varients, where if an article is started in American etc. it stays that way unless there is a good reason to change it to another varient (e.g. it's an article about the Queen or something). That's not to say that if someone creates an item called "Passeridae" they can't change it to "Sparrow". Commonname always wins. If there are many commonnames, the first one wins. Delsion23 (talk) 22:24, 29 November 2012 (UTC)
Just to double-check that we're on the same page Delusion, under the sort of policy we're discussing, an item such as Q1075 or Q10676 should retain whatever label was added first? The one exception being where the creator adds a label but then immediately changes it, as appears to be the case with Q1075. Thus, Q1075 should be "color"; Q10676 should be "Mega Drive"? If that is roughly how you envisage it, then I'll add a draft paragraph in soon. —WFC— 08:06, 3 December 2012 (UTC)
On those particular items I think the issue would mainly be covered by the proposed English varients options (once English is renamed American English which is what it seems to represent unofficially). The Mega Drive would be that in en-gb but Genesis in en-ca and (proposed) en-am. Color would remain so in en-am but be Colour in en-gb and en-ca. I think the issue we are discussing is one that cannot be solved by English varients, i.e. they have 2 or more common names regardless of nationality. Examples would be Burma/Myanmar, Taiwan/Republic of China etc. Delsion23 (talk) 02:19, 5 December 2012 (UTC)
Hello,
and why not considering that if a label is for en: its content should respect the en.wp rules and so on? I mean on fr: we also have many fights about that stupids considerations (transliteration for foreign names, equivalent of color/colour problems, …). We do have rules and recommendations about that, and I guess most WP have such rules, so why not use them? Regards, Hexasoft (talk) 08:30, 26 August 2015 (UTC)

Bot setting labels with brackets[edit]

User:Yair rand pointed out that my bot is currently creating en-labels with brackets, i know this is not 100% correct but I do not think removing all brackets would be the best. It is currently not possible to distinguish if a label does need brackets. There are many labels which do not need them but for the few where its correct it will be a bigger mistake to remove this part, because it would be nearly impossible to find the later. The other labels would need a description as long as there would be no brackets. But if you would set a description you cold also remove the brackets by hand. For the de_labels MerlBot is crating a list here: Wikidata:Labels_and_descriptions_task_force/de#Bezeichnung_mit_Klammer. Yair rand would rather have no labels at all set then wrong labels. As there is no 100% chance to get everything right, this would mean you would have to do everything manually and not only correcting the mistakes. What do you think? --Sk!d (talk) 23:00, 2 December 2012 (UTC)

If the brackets are kept, we have to spend ages fixing the labels of 99% of them. If the brackets are not kept, we spend much less time fixing the 1% of articles that are the exception. Delsion23 (talk) 00:39, 3 December 2012 (UTC)
I am not sure if this is correct how would you find labels where the brackets should belong to? --Sk!d (talk) 08:23, 3 December 2012 (UTC)
Can I just clarify what the issue is? If it's a decision between an article title with brackets, or no label at all, then while I sympathise with Yair rand, I'd go as far as to say that we must go for the former. English, French, German and Italian speakers might have the manpower to add affected labels manually in a reasonable period of time, but many languages are dependent on the bots. If I search for the Persian language name of an Iranian town, I am much more likely to find what I am looking for with a label in the form of [Persian name (something useless)] than if the label is blank.

If on the other hand it's a decision between keeping all brackets and getting rid of all brackets, my opinion is the same as Delusion23's. —WFC— 07:48, 3 December 2012 (UTC)

This is currently only about en-labels. --Sk!d (talk) 08:23, 3 December 2012 (UTC)
If we are talking about English only, then on balance I just about agree with Yair rand for the time being. Hopefully someone will come up with a gadget which will eventually allow us to do it Delusion's way, marking entries which should contain brackets as such.

But to reiterate, in case the outcome of this discussion makes its way into some sort of guideline, any consensus here must be for English labels only. If we ignore French, German and Italian, bots probably provide 90% of labels for other languages. It would be wrong to radically change the nature of this support for a hundred or so relatively small languages (in terms of the number of Wikidata editors), based on a four-person conversation on what works best for English. —WFC— 09:07, 3 December 2012 (UTC)

Ok then after the update i will change my bot to remove brackets for en-labels. --Sk!d (talk) 18:09, 3 December 2012 (UTC)

How to merge two items[edit]

How to merge different items that have interwiki for different language but for the same object. For example, there are Q3506176 (Fermented milk products) with en, cs and es interwikis and Q4222225 (with no label) with ru and uk interwikis. They correspond to the same product. What should one do in such cases? --Koryakov Yuri (talk) 19:21, 17 February 2013 (UTC)

Image update required — Statements[edit]

The image on the front is lacking "Statements". It would be good if it could required to add that component.

Capitalization[edit]

According to Help:Label, "Labels begin with a lowercase letter except for when uppercase is normally required or expected". However, when I use the check sitelink tool to create a new item, all imported labels start with an uppercase letter. See for example Q5054649 or Q5190255. Should I changed them for lowercase? Andreasmperu (talk) 18:49, 23 February 2013 (UTC)

Yes, tool can't know when is needed lowercase letter and for which languages, because every language can have different rules. So you need to change them manually. --Stryn (talk) 18:52, 23 February 2013 (UTC)
Ok, thanks, I will. Andreasmperu (talk) 19:16, 23 February 2013 (UTC)

Labels for non-article items[edit]

Should we always use uppercase or lowercase in label for the first letter? Wikipedia namespace of course uppercase, but how about templates and categories? --Stryn (talk) 08:51, 28 February 2013 (UTC)

I think the status quo is fine (leaving it capitalized), since "Template:Foo" or "Category:Foo" is what appears in the title of the page, and how it is properly styled on Wikipedia (in English)--the same way that we call this page "Help:Label" and not "help:label". To depart from the default formatting would also create busy-work that is very low priority. Regards, Espeso (talk) 15:20, 28 February 2013 (UTC)
Yes, these are names, so they should retain the capitals - the same as they would within a sentence. --Avenue (talk) 18:09, 28 February 2013 (UTC)

Labels for one topic split over multiple articles[edit]

Wondering what to do in the case of Q6564355, Q6564357 and Q6564358 -- these all cover the same topic, but have been split up on enwiki in order to keep the lists to a manageable size. Should the labels therefore include the disambiguation contained within the parentheses, or should that be left to the description? Or should the label be "list of Bolton Wanderers F.C. players with fewer than 25 appearances"? Buttons to Push Buttons (talk) 21:16, 10 March 2013 (UTC)

Parentheses in non-article or disambiguation page.[edit]

For label of Q395864, "300 (disambiguation)" would be better than "300". It is easy to distinguish from normal items. It could be applied for non-article pages. The label of Q4663321 is "Wikipedia:Notability". But "Wikipedia:Notability (people)" is more helpful. -- ChongDae (talk) 05:30, 28 March 2013 (UTC)

For the former, the "(disambiguation)" part is not needed. It is already disambiguated from other items called "300" by its description. In the latter case, I agree that the "(people)" should be included as that is part of the full name of the guideline. Delsion23 (talk) 14:15, 29 March 2013 (UTC)
Yes, both are as you said. --Stryn (talk) 15:22, 29 March 2013 (UTC)
I think that Wikipedia disambiguation pages should be explicitly mentioned in this help page. Do they fit into the "Non-article items" section? They are already mentioned here: Help:Description#Non-article items. --Pabouk (talk) 01:20, 22 June 2013 (UTC)

Translate geographical names?[edit]

While countries and big cities mostly have English names that are widely known, I found translations where I'm not sure if they really make sense. And then, the question is also related to company names: There is a railway company in Switzerland, deserving two valleys and its name is Wynental- und Suhrentalbahn. The article in the English Wikipedia can be found under Wynental and Suhrental railway. But the Wikidata label is Wyna Valley and Suhre Valley Railway. Shouldn't the label be the same as the English article or even the original company name?-- Gürbetaler (talk) 22:17, 6 April 2013 (UTC)

Season in parenthesis?[edit]

En-wiki has an article called en:My Three Sons (season 9). Should it be here labelled as "My Three Sons (season 9)" or "My Three Sons", and "season 9" is the description? I've seen that some users includes "season X" on label, and some not. So how? --Stryn (talk) 20:01, 8 June 2013 (UTC)

(season 9) is really part of the item name and should be in the label. If it was a disambiguation like (TV series) or (film) it should not be in the label. HenkvD (talk) 17:32, 23 June 2013 (UTC)

Non-article items[edit]

We have to change text on Wikidata:Label#Non-article_items, because now there is also Wikivoyage links, which have been linked with Wikipedia links. So two namespaces (Wikipedia, Wikivoyage) are in the same item. --Stryn (talk) 13:16, 24 July 2013 (UTC)

Disambiguation[edit]

I would add a specific example for a desambiguation page in the subsection Examples of Wikidata:L#Disambiguation, e.g.:

Wikipedia article: Rice (disambiguation)
Wikidata label: Rice
Wikidata description: Wikipedia disambiguation page

need of first character capitalization property / flag[edit]

Hi! I changed hundreds of first characters from uppercase to lowercase mainly in Esperanto, Romanian, English. Because lack of time I did not changed these in Cyrillic scripts. I thing that one should have a property with values uppercase, lowercase, language dependent. I assume that these property / flag fields can be set automatically:

  • disambiguation pages start always with uppercase letters
  • pages from WMF projects which are using another namespaces then (Main) will start always with uppercase letters
  • humans, places will start all with uppercase letters
  • professions will start all with LOWERCASE letters
    sample query: http://208.80.153.172/api?q=claim[31:28640]
  • basic concepts will start all with LOWERCASE letters
    • special concepts may start with UPPERCASE letters

Exception handling:

  • Polish will start with an uppercase letter in enwiki but with start with a lowercase letter in most other languages. So an exception list with language codes is required here. I am not sure about Latin.

If a KISS model / implementation can be added to Wikidata it would save a lot of time and help a lot of smaller languages communities. Regards לערי ריינהארט (talk) 13:29, 12 March 2014 (UTC)

Updates as part of documentation overhaul[edit]

Hi all, I recently made substantial edits to Help:Label 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 section on Lists for Wikipedia articles - I didn't think this was so complicated a case to merit its own section; it's also my understanding that it only applies to Wikipedia (i.e. the other Wikimedia sites don't have "list of" articles) so in the interest of balance I removed it
  • 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:Description page (i.e. first cover general principles and then language-specific guidelines)
  • changed references to "entity" and "entities" to "item" and "items" - I think this is less confusing for newcomers and in any case the guidelines are more intended for items (not properties)
  • added example of using unicode

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?
  • Should this page include information on all entities rather than just items (i.e. info on properties and the soon-to-be-added queries)?

Thanks. -Thepwnco (talk) 22:08, 18 June 2014 (UTC)

In my opinion, the content of the page focuses far too much on trying to make Wikipedians familiar with Wikidata. I would shape the content more generic and remove all the "compared to Wikipedia"-like statements. That would basically mean a rewrite of nearly all content. Maybe, there could be a single section for all such Wikipedia comparisons if these are really necessary (the section Items without pages on Wikimedia sites probably needs to remain somehow in any way).
Another observation is the the glossary: "Subject" as well as "entry" should probably be replaced by "Wikidata item"/"item".
Screenshots: Just like I proposed for descriptions, I could think of a screenshot of search results (or search box suggestions) that visualize that labels do not need to be unique. Screenshots are especially helpful for technically less versatile users getting to know the project - why not have a very simple screenshot of the top of an item page with the image description that the label is the big bold text on top of the item page - something like that. There is already the screenshot of the empty label but that is likely not the first visualization of a label new users will see when visiting Wikidata.
(I did more or less just scan the page since I think, a more or less fundamental rewrite would be appropriate anyway.) Random knowledge donator (talk) 15:53, 25 June 2014 (UTC)
Thanks for your feedback and suggestions about screenshots. Can you specify if your comment on Wikipedia concerns just the Help:Label page or all of the Help pages? As mentioned above, my recent updates to the Help:Label page attempted to reduce the focus on Wikipedia by making reference to all Wikimedia sites. I can't find any phrases with "compared to Wikipedia" so please be more specific about what you think is confusing or could be improved upon. I also think that still some mention of Wikimedia sites is necessary, especially for providing information on labels (which often are derived to some extent from Wikipedia article or other Wikimedia sites page titles as per the notability criteria). Thepwnco (talk) 20:08, 25 June 2014 (UTC)

Political entity labels[edit]

I have opened a topic on applying Help:Label to the specifics of administrative entities at Wikidata_talk:Political_geography_task_force#Political_entity_labels. I looked around and couldn't see where this specifically had been discussed, but if such a discussion exists or I should move the discussion here instead of where I put it, please let me know. Please take a look and provide any commentary and insight you might have on it. Thanks! Joshbaumgartner (talk) 07:04, 9 July 2014 (UTC)

Capitalization of class names[edit]

Wikipedia applies the capitalization rules of the Chicago Manual of Style for class names if they follow the base name.

In edition 16 §8.50 Political divisions—capitalization [1] it says:

Jiangxi Province. 
Massachusetts Bay Colony; the colony at Massachusetts Bay.
New York City; the city of New York

In edition 16 §8.52 Mountains, rivers, and the like [2] it says:

Names of mountains, rivers, oceans, islands, and so forth are capitalized. 
The generic term (mountain, etc.) is also capitalized when used as part of the name.

I suggest this should be applied for English labels in Wikidata. There are other manuals of style that have other policies, but in one database one would normally one system only. Tamawashi (talk) 17:32, 9 July 2014 (UTC)

Symbol support vote.svg Support Since disambiguation words should not be included in the label at all, this should not be too much of a problem. For the most part, if an imported label from en:wiki has a non-capitalized disambiguation word included in it, that should simply be removed and put in the description (see the M1 chemical mine). Where common usage of the proper name includes the 'generic' word in general use (not just to differentiate from similarly named entities), it should be retained (e.g. Salt Lake City), but if the 'generic' word is not universally used or only used for disambiguation, it should not be in the label (e.g. Rhine is correct as opposed to "Rhine River" or "Rhine river".) Joshbaumgartner (talk) 08:05, 10 July 2014 (UTC)
@Joshbaumgartner: - At least on capitalization we seem to agree. For class name inclusion I made a proposal below. Tamawashi (talk) 12:12, 10 July 2014 (UTC)
@Tamawashi:, I hope to agree on more than merely this. Joshbaumgartner (talk) 23:08, 12 July 2014 (UTC)

Regarding the scope of the new rule: CMoS 8.50 and 8.52 do not include all physical objects, not even all geographical objects, e.g. dog breeds and streets are not included. I would like to apply the rule as broad as possible. AFAICS dog breeds and streets currently are capitalized. Tamawashi (talk) 09:35, 13 July 2014 (UTC)

Inclusion of class names[edit]

@Joshbaumgartner: If an item that contains a classname (e.g. Black River, or Washington County) is an instance of an item that is named "<classname>" (e.g. river) or "<classname> of <territorial entity>" (e.g. county of the United States) then the classname is candidate for removal. Bots could help in monitoring already. But there seem to be no bot-checkable rules yet for when it should be removed and when not. Classes could be included in a "list of items having bot enforceable class name inclusion" and marked as "include" or "remove", a non-controversial class seems to be state of the United States (Q35657) where no instance should be labeled "Foo State", i.e. they would be labeled "remove". This will not work for rivers, if "Rhine" and "Black River" shall co-exist, since they both are instance of the same class. For administrative territorial entities it could work fine. I started Wikidata:Administrative territorial entity and proposed a listing that helps in monitoring the classes including some label monitoring: Wikidata talk:Administrative territorial entity/List of subclasses. Ideally all of them that have instances and not only subclasses will get a listed in "list of items having bot enforceable class name inclusion". That avoids manual revert wars on individual items. Tamawashi (talk) 12:12, 10 July 2014 (UTC)

@Tamawashi:, I think that working towards a guideline of how label names should be constructed for different geographic entities is a good thing, though I'm not sure it warrants a new discussion since there are several discussions on this already brewing, including Wikidata_talk:Political_geography_task_force#Political_entity_labels. Creating lots of new pages and topics all over the place will make it hard to bring together voices to collaborate on the work. Joshbaumgartner (talk) 23:45, 12 July 2014 (UTC)
@Joshbaumgartner: Avoiding duplication can save time, and it seems we both would like that. If the discussion for the new rule/guideline/policy takes place in a page that is dedicated to all items that the rule shall be applied to, then it is more likely that interested people find it and the likelihood of duplication is reduced. Since Help_talk:Label is dedicated to all items (Wikidata:Glossary#Item), it looks like a candidate, but the might be a lower level page that is dedicated to all these items. The political geography TF page seems to be dedicated to a subclass of items that does not include all items the new rule should be applied to. I don't know how "political entity" is defined, would it include all proclaimed territorial entities, e.g. en:irrigation districts ? Tamawashi (talk) 09:27, 13 July 2014 (UTC)

Languages labels[edit]

See discussion. --SynConlanger (talk) 21:08, 17 August 2015 (UTC)

Title case[edit]

"Use the item's most common name, and only capitalize proper nouns"

What about the title case typography often found on movies/books/articles titles in English? I often see users remove the capital letters arguing that common nouns should not be capitalized. Like "The Empire Strikes Back" becomes "The empire strikes back" or "Back to the Future" becomes "Back to the future". Thibaut120094 (talk) 02:01, 18 August 2015 (UTC)

Oh, just saw Help:Label#Capitalization, that answer my question then. Thibaut120094 (talk) 02:12, 18 August 2015 (UTC)

Bad Example in the present help page[edit]

"The label of Helianthus annuus (Q171497) is the common name, while the scientific name (Helianthus annuus) is featured as an alias." Huh? - Jmabel (talk) 00:11, 9 December 2015 (UTC)

How discretionary, unreferenced labels violate a NPOV[edit]

The statement "In fact there are several cases, discussed below, in which it is actually desirable for the Wikidata label to be different from the Wikimedia page title" is inconsistent with a NPOV. Importantly, a "common usage" definition for a "discretionary" preferred label is not spatially or temporally verifiable. If not derived from the Wikimedia page title or a "semantically equivalent" referenced source, the label contains a localized bias imposed by the author on the entity concept.

Further, the statement "When it comes to scientific names, for example, of a species, labels should use a species' common name, however items must always also have the scientific name listed as Alias. If a species has several common names, a reasonable effort should be made to determine which of them is the most commonly used, e.g. by consulting references." seems to be a reasonable guideline. However, most of the time, there are multiple answers to the research problem of "most commonly used", particularly when evaluating an entity concept label in a temporal or spatial context. Why then is this rather important judgment of "preferred common usage" left to editor discretion? This dependency on judgment introduces a bias that violates the NPOV and if "edit wars" have been spawned from this possibility, there seems a need to fix the problem. In a scientific context, the "preferred label" is the scientific one. In common usage context, the "preferred label" is the common one. They are both right. This is a obvious polycontexture and needs to be semantically expressible in Wikidata.

It is my belief that the preferred label should either represent the Wikipedia page title as it exists, or an extended language property like dcterms:language should be added to provide in what "preferred" language context the entity is known by this label (<entity> skos:prefLabel "Helianthus annuus"@en; dcterms:language <http://example.org/zxx-x-taxon>). (Or alternatively, the data model should support preferred label, alias and description references.) Furthermore, a "hidden label" alias should be added (skos:hiddenLabel) that provides an opportunity to provide externally-sourced perhaps politically or grammatically "incorrect" alternative labels. Chjohnson39 (talk) 14:12, 20 March 2016 (UTC)

All accepted languages[edit]

Somewhere around there should be shown the full list of accepted languages for labels (with their codes). --XXN, 11:36, 23 June 2017 (UTC)

Labels for items which are sub-pages on Wikivoyage[edit]

I see that items taken from Wikivoyage sub-pages have the full Wikivoyage Pagename/Subpagename as a label. (I have only checked a few, so this may not always be true) My understanding of the general naming policy is that this is probably due to them having been harvested by a bot, and not yet improved. Am I correct in assuming that these should be changed to labels which reflect actual usage, i.e without the main article name in front, and the full Pagename/Subpagename should be given as an alias? The description will generally be adequate disambiguation in the case of dive sites, which may share a name with another site in another region, but when the location is specified, they are uniquely identified. Pbsouthwood (talk) 13:14, 7 October 2017 (UTC)

I have started to edit dive sites of the Cape Peninsula and False Bay following this principle (there are about 250 of them), See Q15266796 for the first. I am also adding country, instance of, geolocation, and where it exists, the detail bathymetric chart om Commons. If there are other properties anyone can recommend for dive sites, please let me know. Pbsouthwood (talk) 05:15, 8 October 2017 (UTC)

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)