Template talk:Infobox language/Archive 9

Archive 5

←

Archive 7

Archive 8

Archive 9

Archive 10

Archive 11

Remove automatic ref for Glottolog?

Some language
Language family	unclassified
Language codes
ISO 639-1	xx
ISO 639-2	xxx Lang
ISO 639-3	xxx – inclusive code Lang Individual codes: xxx – Dialect 1 xxx – Dialect 2
ISO 639-6	xxxx
Linguist List	xxx Lang
Glottolog	xxxx  Lang
AIATSIS	Xnn Lang
Guthrie code	G.nn
Linguasphere	nn-XXX-x

Currently, the default behaviour for the infobox, when given a Glottocode, is to generate a reference with a citation to Glottolog and display it right after the Glottocode. I don't think this is really necessary – the Glottocode is itself already a link to the relevant entry, and more generally, it's not common for infoboxes to duplicate identifiers in this way (as you can see from glancing at any random article about a chemical compound or a human gene, for example).

It can also lead to problems: as pointed out earlier this year, the citation is by necessity formatted as a citation of a particular version of Glottolog, which will be incorrect whenever the content of the Glottolog entry has changed in more recent editions (as the ones used on Wikipedia tend to be kept up to date, as Drmccreedy will probably be able to attest).

Should we remove this automatic reference for Glottolog? Should we do the same for the Guthrie and AIATSIS identifiers? – Uanfala (talk) 17:00, 24 October 2020 (UTC)

Yeah, there's no reason for references like that. Identifiers are basically self-referencing and don't need the help. --Izno (talk) 18:09, 24 October 2020 (UTC)

I recommend to introduce a parameter to suppress the reference. The Glottolog reference should be there by default, because without it, many of our language stubs will look even more undersourced than they already do now. Without Ethnologue ref, they might even become completely unreferenced and unnecessarily will attract the PROD squad. –Austronesier (talk) 18:40, 24 October 2020 (UTC)

There is already |glottofoot=no. I'm not sure that a vacuous reference is the right response to concerns about sourcing. At least the Ethnologue reference is there to support a speaker figure. Kanguole 21:46, 24 October 2020 (UTC)

If the PROD squad decide to PROD a language article, we'll easily find out about such a nefarious deed through the article alerts. But then, this only works if the articles' talk pages are already tagged with the projects' banner. Well, guess what, it turns out that many aren't: Wikipedia talk:WikiProject Languages#Those articles have eluded us. – Uanfala (talk) 01:56, 26 October 2020 (UTC)

I agree that we should eliminate the redundant references for Glottolog and AIATSIS (Guthrie is a bit different). Ideally all identifiers should be rendered consistently, with the ISO 639 links to LoC or SIL also marked as external links, and none of them having redundant pseudo-references. Kanguole 20:05, 24 October 2020 (UTC)

I think the link to Glottolog is enough and that the automatic reference can go away. Although I share the concern that this may lead to "unsourced" challenges. DRMcCreedy (talk) 21:39, 24 October 2020 (UTC)

Now that all the articles using this infobox have been tagged with the WP:LANG banner, does that address the PROD concern and shall we move ahead with removing the Glottolog and AIATSIS pseudo-references? Kanguole 12:20, 24 November 2020 (UTC)

I'm good with that. DRMcCreedy (talk) 17:23, 24 November 2020 (UTC)

There's one last step though! – Uanfala (talk) 23:07, 24 November 2020 (UTC)

References

That other task

Before the pseudo-reference can be disabled, there's one more thing to do. Sometimes, the named reference from the infobox would be used again from within the article text. That would break if we changed the infobox now. There are sixty or so articles where the full reference would need to be edited in. Anybody willing to help? I'm aware this is only marginally more exciting than talk-page tagging.

So, the starting point is with these search results. What I would normally do is go to an article, find the reference in question, make some basic checks (is the ref actually needed here? does the information match the latest version of Glottolog?), and if all is well, replace it with a full citation, something like: <ref name="Glottolog4.3">{{cite web| editor-last1= Hammarström| editor-first1 = Harald| editor-last2 = Forke| editor-first2 = Robert| editor-last3 = Haspelmath| editor-first3 = Martin| editor-last4 = Bank| editor-first4 = Sebastian| year = 2020|title = INSERT_LANGUOID_NAME_HERE| work = [[Glottolog]] 4.3| url = https://glottolog.org/resource/languoid/id/INSERT_GLOTTOCODE_HERE}}</ref>. – Uanfala (talk) 23:07, 24 November 2020 (UTC)

Good point. Also 53 with <ref name="AIATSIS"/>. Kanguole 23:26, 24 November 2020 (UTC)

I should be able to help in a few days. DRMcCreedy (talk) 23:45, 24 November 2020 (UTC)

I've added standalone references to all of the articles that piggybacked on the Glottolog pseudo-references. DRMcCreedy (talk) 20:45, 1 December 2020 (UTC)

Well, that was premature. There are 59 naughty references that don't use quotes, so the original search didn't show them. This updated search shows them. I'll start updating those articles now. DRMcCreedy (talk) 21:38, 1 December 2020 (UTC)

I've done these missing Glottolog references now. DRMcCreedy (talk) 04:10, 2 December 2020 (UTC)

Also, Glottolog is a fairly weak reference for anything except statements about what Glottolog says. It would be better to consult whatever references Glottolog used, but unfortunately it usually just gives a bare list of references with no indication of what supports what, and sometimes they cover a different part of the tree. AIATSIS is more reliable. Kanguole 11:37, 25 November 2020 (UTC)

Agree, I'd maximally use Glottolog as source for a name or alt-name (including Harald's occasionally weird creations: ever come across subgroups ending in "-esic"?). –Austronesier (talk) 12:13, 25 November 2020 (UTC)

Did we really think this would be over so quick?

So, I've removed the Glottolog pseudorefs [1]. There's one complication though. Until now, the expectation has been that each glottocode entry would be accompanied by another parameter supplying the name that Glottolog has used to refer to that language. This would be either |glottoname= (to be displayed in the infobox, right after the glottocode), or |glottorefname= (not displayed in the infobox, only used in the Glottolog reference). Less than 10% of articles [2] have used the former. The rest – over 8,000 articles – use the latter parameter, which now has no visible output. What do we do now?

1. Promote |glottorefname= into |glottoname=, so it is always displayed in the infobox.
2. Don't display it, but hold on to it, as the information it contains may still prove of some use at a later date.
3. Deprecate it, leading to the eventual removal of the parameter.

Any thoughts? – Uanfala (talk) 19:39, 14 January 2021 (UTC)

• I think |glottoname= serves its purpose well e.g. in cases where we lump when Glottolog splits, e.g. in Ding language. But AFAICS, |glottorefname= could be deprecated. –Austronesier (talk) 19:51, 14 January 2021 (UTC)

I think we should stick with glottorefname as the default. Displaying the name to the infobox just clutters it to no purpose. We don't add ISO names after the ISO code, for example, and that would be more justified. As noted above, glottolog names are often rather odd, and they are not common in the lit.

The reason for displaying the name with glottoname was to clarify which was which when there was more than one code in the infobox, just as we do with ld[n] when there is more than one ISO code. — kwami (talk) 12:16, 2 February 2021 (UTC)

Blue on purple is difficult to read

At present, this infobox includes a purple box with information about IPA symbols. This results in black text or (worse) blue linked text on a purple background, which lacks contrast and is therefore difficult to read. Could some other, easier to read color combination be used, please? Cnilep (talk) 01:31, 11 March 2021 (UTC)

Thanks for the report. The colors were AA-level accessible. I have improved the contrast while preserving the intended color as much as possible. This changed the accessibility from an AA to an AAA level (see MOS:CONTRAST). – Jonesey95 (talk) 04:41, 11 March 2021 (UTC)

Undefined Reference

Kwamikagami added this template to the Avok language page, where it generates an undefined reference error. I can't figure out, from the template's documentation, how to fix the error. How is this template meant to work? -- Mikeblas (talk) 15:46, 7 April 2021 (UTC)

The documentation attempts to explain that |ref= can contain a full ref or one of a set of defined codes. "ELP" is apparently not one of those defined codes, or it doesn't work in that article, so I have removed it from that article. – Jonesey95 (talk) 16:01, 7 April 2021 (UTC)

It works if the ref is added manually, but not if it's inherited from Wikidata. We should say where the number comes from, though. — kwami (talk) 21:39, 7 April 2021 (UTC)

These don't work because the automatically generated ELP link no longer comes with a pseudoreference (see #ELP and Glottopedia links above). Simply saying the ref was ELP isn't a good idea – this is a website and its content will change as it gets updated. I don't think it had any explicit versioning last time I checked, so when citing it we'd need at least an access date. – Uanfala (talk) 21:55, 7 April 2021 (UTC)

ELP and Glottopedia links

Southern Yukaghir
Language family	Yukaghir Southern Yukaghir
Language codes
ISO 639-3	yux
Glottolog	sout2750
ELP	Forest Yukagir
Glottopedia	Kolyma-Jukagirisch

The template has recently been expaned with support for links to Glottopedia and to the Endangered Languages Project (ELP). There are a handful of articles linking to the former, but close to 3,000 linking to the latter (largely pulled from Wikidata after this recent task). There's an example to the right taken from the the current version of the Southern Yukaghir article.

References

I have no opinion on whether the ELP and Glottopedia entries should be linked in the infobox, or from the External Links section. If they're going to be linked in the infobox though, then there should be a better way to present the links. At the very least, they shouldn't appear in the "Language codes" section, because they're not language codes (and neither do they look or function like ones). And is there any need to display the names of the articles linked ("Forest Yukagir" and "Kolyma-Jukagirisch" in the example)? As far as I can tell, their purpose is as visual anchors for the links, and they don't have any particular significance; even the names used by Glottolog and SIL aren't usually displayed. One way to solve those two issues is to move those links into a separate section called something like "External links" or "Further resources", and then format them as a simple horizontal list, with the displayed text of each link simply the name of the resource ("ELP", "Glottopedia")? Any other ideas?

Also, could we please drop the automatic pseudo-references? If we didn't want them for Glottolog, we definitely won't want them here. – Uanfala (talk) 19:01, 4 February 2021 (UTC)

I haven't followed the changes here in detail, but Tungag language is currently showing a big red error message in the infobox. – Jonesey95 (talk) 02:20, 5 February 2021 (UTC)

This appears to have happened because the Wikidata item had a claim for "endangeredlanguages.com ID" that was empty. This should have fixed it. – Uanfala (talk) 18:08, 5 February 2021 (UTC)

Thanks! I knew someone here would have the fix. It might be useful to test for the existence of that ID and output a tracking category rather than a big bold red script error. – Jonesey95 (talk) 18:59, 5 February 2021 (UTC)

I believe RexxS should be in a good position to comment on such a proposal. On a related note, we're in the undesirable situation where the formatting of the ELP parameter is sometimes done in Lua (that's at Module:Endangered Languages Project, which is invoked by Template:Endangered Languages Project, which is used for the first occurrence of an ELP link in the infobox), and sometimes it's done in template code right here (for second and subsequent ELP links [3]). Is there a way for the formatting to be all done in one place (ideally this template), and have the module only do the Wikidata lookup? – Uanfala (talk) 21:19, 2 March 2021 (UTC)

• I've removed the automatic pseudo-references for ELP with this edit to the module. This doesn't apply to manually added second and subsequent ELP links – the code for these sits in the infobox template, and I'm thinking we should update them when we have a clearer idea of how the links should be displayed in the first place. – Uanfala (talk) 22:08, 5 March 2021 (UTC)

I suspect it won't be practical to have the ELP links housed entirely at Wikidata. The problem is that Wikidata also connects corresponding articles across different WP's, and the versions in other WP's may have different scopes and therefore need different ISO, Glottolog and ELP codes than WP-en does. This is especially common for Australian and South American languages, but occurs everywhere. For example, an WP-en article may be named after a particular language variety, but include other lects that our sources report are dialects of the same language. (When the language as a whole has no dedicated name.) The corresponding WP-es or WP-fr article, however, may only describe the nominal lect. Wikidata should therefor only have the codes for the nominal lect, with others to be added locally as needed. There are also cases where WP-en has an article on the "X-Y language" (where X and Y each have an ISO code), but the Wikidata entry it links to is specifically for the "X language". If we force Wikidata to cover the scope of the WP-en article, then it may be overly broad for other WP's, and if someone from say WP-fr corrects the Wikidata entry to generate the proper scope for WP-fr, then here on WP-en we will lose info without any change appearing on the watch lists of the people monitoring the article.

Another place the infobox param is needed is when there are multiple info boxes on a page, such as our articles on ASL-based sign languages and Malay-based creoles. In those, most info box shouldn't have an ELP link, and those that do will each need a different one. (And similarly for Glottolog if someone tries migrating that over to Wikidata, which IMO would be more of a headache than it's worth.)

As for Glottopedia, there probably aren't more than a dozen articles worth linking to. Agreed, those aren't language codes, that was just a convenient place to put the links. Also, the purpose of the links -- a place to find info on the language -- is similar to the purpose of Glottolog. AFAIK hardly anyone ever uses Glottolog codes to identify a language, so that's really more of an 'external links' param as well.

I have no objection to adding an 'External links' section for ELP, Glottopedia and (IMO) also Glottolog and maybe LinguistList. Especially for cases where multiple Linguasphere codes are added, the 'Language codes' section can sometimes be cluttered.

And no objection to replacing the Glottopedia and ELP language names with some other placeholder. — kwami (talk) 22:54, 7 April 2021 (UTC)

IPA notice

This template was recently changed to use {{IPA notice/msg}}, which had the effect of adding the sentence

For the distinction between [ ], / / and ⟨ ⟩, see IPA § Brackets and transcription delimiters.

to the IPA notice. I attempted to approximate the previous state of this infobox, but was reverted. My view is that the message is redundant (as IPA and Help:IPA are already linked), and unnecessarily increases the size of the infobox. (See also Template talk:IPA notice#brackets) Kanguole 14:51, 9 March 2021 (UTC)

Agreed. Fine as an option, but overkill for the default behaviour. — kwami (talk) 21:43, 7 April 2021 (UTC)

Made the brackets notice an opt-in, and added examples to the doc page. But hiding the intro, which I didn't touch, doesn't work. I don't think I did anything to affect that. — kwami (talk) 21:54, 7 April 2021 (UTC)

The infobox currently doesn't use {{IPA notice/msg}}. |preamble= works only for /msg, not {{IPA notice}}. Nardog (talk) 16:22, 8 April 2021 (UTC)

EGIDS level

It is possible that the template could be changed so that there is an option to add a language's EGIDS level, similarly to how Template:Speciesbox has an animal's conservation status? --Mad Mismagius (talk) 21:39, 13 April 2021 (UTC)

Could, if someone wanted to go to all that effort (either here on in Wikidata). But is that something we'd want? A lot of the level judgements seem quite arbitrary. 04:16, 14 April 2021 (UTC)

We could possibly try to enlist support from WikiProject Languages, but yes it would take a long time to get every language. Ethnologue has the EGIDS level data for every language, and the fact that Ethnologue is consistently cited as the native speaker population source for smaller languages' pages is evidence to me that it would be a fine source in this regard. I think it would be an important piece of information to add to the infobox so that a person could quickly judge a language's vitality, as with animals' conservation status. --Mad Mismagius (talk) 04:58, 15 April 2021 (UTC)

Family code

I see that many conlangs are tagged with iso3=none. Shouldn't it be iso3=art? In general, when a code for the exact dialect or language is not registered, is it right to put the family or main language code somewhere? I see:

iso2

the ISO 639-2 code for the language (not for its family);

--Error (talk) 17:09, 15 April 2021 (UTC)

Personally, I'm opposed to adding family/generic codes to individual codeless languages. That would be potentially misleading to our readers and wouldn't furnish them with any useful information about the language. The only use would be for tagging something in a library, etc., and for that the reader can refer to our article ISO 639-2. — kwami (talk) 22:27, 15 April 2021 (UTC)

I strongly oppose using ISO 639-2 codes, like art, for -3 (iso3) parameter values. DRMcCreedy (talk)

iso2comment

In Roncalese dialect, I added: | iso1 = eu | iso1comment= (shared by all the Basque dialects) | iso2b = baq | iso2t = eus | iso2comment= (shared by all the Basque dialects) It is rendered as:

Language codes

ISO 639-1 eu (shared by all the Basque dialects)

ISO 639-2 baq (B) (shared by all the Basque dialects)

eus (T)

that is, the iso2comment value appears after the iso2b value but not the iso2t value. --Error (talk) 17:12, 15 April 2021 (UTC)

Roncalese does not have an ISO code, so that section should be blank. Someone added the same wording to one other Basque dialect, but the rest have only their dialect codes. (Which are themselves of dubious utility.) — kwami (talk) 22:29, 15 April 2021 (UTC)

Proposing a field for adding a video (oral history) of a native speaker

A language, particularly one that is only spoken and does not have a writing system, is incomplete without audiovisual materials to help a [Wikipedia] reader understand how the said language is spoken by a native speaker. What can be a better place other than Wikipedia to share the same? I am proposing a field that would allow, within the infobox, a space (and not just a single field) for embedding a Commons video (or a hyperlink to a reliable source such as SOAS-ELAR or ELP if a video is not available on Commons), preferably an oral history (containing conversational language), with some basic metadata about the video:

• name of the speaker
• approximate age and gender of the speaker (essential from an anthropological pov)
• location of the speaker (with due consideration of consent)
• summary of what is spoken in the video

It is idea if the video has captions/subtitles but that is not something that can be enforced on uploaders. --Psubhashish (talk) 10:07, 23 May 2021 (UTC)

That goes against the purpose of the infobox. Add such audios into the body of the article if you think it would help, but not into the infobox. Roger 8 Roger (talk) 10:47, 23 May 2021 (UTC)

I think it would be nice to have a video in the infobox as an illustration, just as biological taxonomy articles have images of the species, but once you start adding fields for biographic info of the speaker it becomes too much. At that point the info box becomes a summary of a person rather than of a language.

There's also the complication of whether it should start playing automatically. If it did, we'd get a lot of repetitive sound when visiting language articles, which could end up being just noise. But if it didn't autoplay, it wouldn't function as an illustration, as a mere image of a speaker wouldn't illustrate the language.

Another place something like this would make sense would be in articles on pieces of music, but I've never seen that on WP. Instead, people add links to sound files below the infobox. I think something similar would probably be more appropriate here. — kwami (talk) 04:14, 24 May 2021 (UTC)

Articles on songs (especially on pop singles) often have audio samples within the infobox (see the Infobox song documentation), but those articles are specifically about a song, which is 100% a thing that is made of sound. Languages are much more than the sounds of someone speaking the language. I think it is sufficient to place an audio/video sample, if desired, below the infobox. I don't know why Kwamikagami would bring up autoplay, though; no web site should ever hate its viewers that much. – Jonesey95 (talk) 05:19, 24 May 2021 (UTC)

That was my point. To be an illustration, like an image would be, it would need to be on autoplay rather than a video still. Thus IMO it should not be used as an infobox illustration.

Are you referring to the possibility of adding {{Audio sample}} under the 'misc' parameter? I think something like that would be acceptable for a language as well. Oral languages are also "100% a thing that is made of sound." You could argue that a song is also much more than the sounds of someone singing the song (cultural and political import, history of influences, novel musicality, sheet music, etc.), but that doesn't mean that a sample of someone singing the song isn't a nice addition to the article. — kwami (talk) 06:56, 24 May 2021 (UTC)

I also think adding an option to a link of audio or video would be a good idea, since language is mostly auditory. I think it would also be a good option to allow for linking to videos for languages that are not spoken (ie Sign languages). It might better to establish a standard spoken text instead of an open ended biography. The most universally available might be Lord's prayer, but to be secular it also might be useful to pull from the UN - Declaration of Human Rights database. It has audio files of the document read out for over 500 languages, second after the Bible. Bluealbion (talk) 17:19, 6 June 2021 (UTC)

@Roger 8 Roger has already mentioned that the infobox is not the place for it. Good sound examples right after the infobox certainly can be an enrichment, as long as they're selected with care; we had mass addition of Wikitongues videos a while ago, some of which were really bad (non-native speakers, semi-speakers, long intros using the standard/national language instead of the intended minority language etc.). It should remain a nice-to-have thing using only the best samples; once it becomes a parameter, people might tend to fill it with anything out of sheer horror vacui. And no, we shouldn't standardize it with the Lord's prayer (cultural bias) or the Declaration of Human Rights (unnatural register for many smaller languages, usually packed with loans from the dominant national language). –Austronesier (talk) 20:38, 7 June 2021 (UTC)

ConLang Code Registry

Since there are several parameters just for conlangs and many of them don't have standard codes, you may want to add a parameter for the ConLang Code Registry. The list is extensive, and Rebecca G. Bettencourt operates the Under-ConScript Unicode Registry. --Error (talk) 20:31, 6 April 2021 (UTC)

What do people think? We have more conlang articles than we used to; last time I remember s.t. like this coming up we didn't even have articles for all the conlangs with ISO codes, with the argument that they weren't notable. — kwami (talk) 22:29, 7 April 2021 (UTC)

I added the art-x-... codes, though was reverted for Enochian. For the [q...] codes, I'd like to see some indication that they're useful as identifiers. — kwami (talk) 00:11, 19 April 2021 (UTC)

@Error: The conlang registry seems to be defunct. At least, no-one seems to be maintaining it this year. Two langs were added in 2020, but in April I submitted a dozen additional languages that were as or more notable than many of those already included, and didn't hear anything back. There have been other times I tried contacting them and didn't get a response. — kwami (talk) 22:34, 7 June 2021 (UTC)

@Kwami:: Pity. Thanks for telling us. However, for the conlangs that managed to get registered, it is best than nothing, isn't it? --Error (talk) 22:57, 7 June 2021 (UTC)

It would be if anyone used them. Does anyone use them, though? If it's just a dead-end proposal, I don't know if it's worth the space and effort. — kwami (talk) 05:32, 8 June 2021 (UTC)

Please use accessible plain lists

This template currently generates an unbulleted list using <br>. This is deprecated in favour of {{plainlist}} or {{unbulleted list}} for accessibility reasons; please change the template accordingly. Hairy Dude (talk) 20:24, 28 June 2021 (UTC)

• The same goes for the list of ISO 639-3 codes generated for {{Infobox language}} via {{Infobox language/codelist}}. Hairy Dude (talk) 20:32, 28 June 2021 (UTC)

  No problem. Please make required changes to Template:Infobox language/ref/sandbox — Martin (MSGJ · talk) 18:14, 30 June 2021 (UTC)

•  Not done: According to the page's protection level you should be able to edit the page yourself. If you seem to be unable to, please reopen the request with further details. Drill it (talk) 20:03, 30 June 2021 (UTC)
  • The change concerns a subpage that has higher protection. – Uanfala (talk) 21:11, 1 July 2021 (UTC)
• Hairy Dude, here's a ping in case you haven't noticed. That looks straightforward, but it will be a good idea to try it in the sandbox first, and you're better placed than most to do that. – Uanfala (talk) 21:10, 1 July 2021 (UTC)

Add wals

Hi, I think codes from the World Atlas of Language Structures (WALS) could be added: https://wals.info/ I quote: "The World Atlas of Language Structures (WALS) is a large database of structural (phonological, grammatical, lexical) properties of languages gathered from descriptive materials (such as reference grammars) by a team of 55 authors." They have 2,662 codes corresponding to ISO 639-3 codes or to dialects of these codes. For instance:

• For French: WALS fre = ISO 639-3 fra
• For ISO 639-3 ajp (South Levantive), WALS has:
  • arv (Arabic, Negev)
  • apa (Arabic, Palestine)

Adding them would enable users to access structural properties of the language in one click in the infobox for all these languages. (And because WALS is licensed under a Creative Commons Attribution 4.0 International License, we could add all these features to Wikidata by the way...) What do you think? A455bcd9 (talk) 18:20, 14 July 2021 (UTC)

Formatting of families and early forms

In Template talk:Infobox language/Archive 8#Novel formatting idea, Goszei suggested using ∟ as the marker for the nested lists of families and early forms. I've implemented that in the sandbox, but I'm in two minds about it. The effect can be seen in the test cases. Kanguole 21:50, 18 August 2021 (UTC)

I have since found out about Template:Tree list, which I think is the more correct way (semantically and visually) of creating a list like this. — Goszei (talk) 23:08, 18 August 2021 (UTC)

If a tree list can be used, it would be a nice and familiar way to display these relationships. – Jonesey95 (talk) 23:59, 18 August 2021 (UTC)

Both would produce nested HTML lists (as does the existing implementation); the difference is in the applied style, e.g.:

{{tree list}}	using U+221F as marker
Niger-Congo? Atlantic–Congo Volta-Congo Benue–Congo Bantoid Southern Bantoid Bantu Northeast Bantu Northeast Coast Bantu Sabaki Swahili	Niger-Congo? Atlantic–Congo Volta-Congo Benue–Congo Bantoid Southern Bantoid Bantu Northeast Bantu Northeast Coast Bantu Sabaki Swahili

(Tree lists also support branching, of course, but that isn't relevant here.) Tree lists use a fair bit more horizontal space, which is good for article text but a problem for narrow infoboxes, and the spacing is hard-wired into the CSS file. Kanguole 09:29, 19 August 2021 (UTC)

• And there's also a fourth option: not using any indentation at all and just having a flat vertical list, as is done for the classification of organisms in {{Taxobox}}. – Uanfala (talk) 12:16, 19 August 2021 (UTC)
  • A flat list is certainly an option, but I think {{Taxobox}} does something different: multiple named fields for the levels of classification, which isn't possible here. Kanguole 15:16, 19 August 2021 (UTC)

Use proper list for standards

Currently the "standards" parameters are formatted as:

| label11 = {{longitem|Standard forms}}
| data11 = {{#if:{{{standards|}}}|{{{standards}}}
|{{#if:{{{stand1|}}}|
<div>{{{stand1|}}}</div>
<div>{{{stand2|}}}</div>
<div>{{{stand3|}}}</div>
<div>{{{stand4|}}}</div>
<div>{{{stand5|}}}</div>
<div>{{{stand6|}}}</div>
}}}}

These divs have no semantics. They should be a list instead. They should also not display the later ones if earlier ones don't exist; instead, they're all shown (though they're empty); for example, there are two empty divs after the four given standards at Sardinian language.

Replace with:

| label11 = {{longitem|Standard forms}}
| data11 = {{#if:{{{standards|}}}|{{{standards}}}
|{{#if:{{{stand1|}}}|{{plainlist|
*{{{stand1|}}}{{#if:{{{stand2|}}}|
*{{{stand2|}}}{{#if:{{{stand3|}}}|
*{{{stand3|}}}{{#if:{{{stand4|}}}|
*{{{stand4|}}}{{#if:{{{stand5|}}}|
*{{{stand5|}}}{{#if:{{{stand6|}}}|
*{{{stand6|}}}}}}}}}}}}}}}}}}}

Tested in sandbox. Hairy Dude (talk) 12:32, 29 August 2021 (UTC)

Thank you, Hairy Dude, this looks great. Just one thing before we make the change to the main template: do you think it might be better if the conditionals are independent (rather than nested), so that if a given parameter is set it will get displayed regardless of whether the previous ones are set too? (With the proposed version, if for example |stand3= is set but |stand2= isn't, then it won't display.) – Uanfala (talk) 13:32, 29 August 2021 (UTC)

Yes, that might make sense. Hairy Dude (talk) 14:55, 29 August 2021 (UTC)

That's done now [4]. The parameters |stand2= to |stand6= should work independently of each other, but they still require |stand1= to be set. – Uanfala (talk) 18:04, 29 August 2021 (UTC)

Thanks! Hairy Dude (talk) 14:14, 30 August 2021 (UTC)

Capitalisation of "constructed"

Change "constructed language" to "Constructed language" (capitalization) UserTwoSix (talk) 21:41, 9 February 2022 (UTC)

That's the default display of the string "constructed language" at the root of the "family tree", right? Many infoboxes seem to capitalise at the start of each field, even if the term isn't a proper name, and this is done by some conlang articles, like Esperanto or Interlingua. Others however (Afrihili, Lojban...), avoid initial upper case. In the current situation, any value here – either the current, or the proposed one – is likely going to negatively affect some articles. I don't have an opinion, and I'd be happy to flip the value if no-one objects in a few days, but I reckon this may warrant some discussion first. – Uanfala (talk) 23:48, 9 February 2022 (UTC)

 Done – Uanfala (talk) 13:57, 24 February 2022 (UTC)

Template-protected edit request on 5 March 2022

According to Template:Ethnologue25: "For a reference to the Ethnologue population figures, enter "e25" in the ref parameter of "Infobox language". This will automatically generate a reference based on this template, and is easier for other editors to update."

e24 but not e25 (see: Levantine Arabic). I think the template has to be updated to support e25. A455bcd9 (talk) 12:03, 5 March 2022 (UTC)

 Done – Jonesey95 (talk) 15:33, 5 March 2022 (UTC)

Thanks! A455bcd9 (talk) 15:55, 5 March 2022 (UTC)

Yes, thanks, Jonesey95! I was looking into this when all of a sudden it was fixed. You taught me something (again), so thank you very much! P.I. Ellsworth - ed. ^put'r there 16:22, 5 March 2022 (UTC)

Does "speakers" field not show if "extinct" is present?

I'm working on an equivalent template on another Wikipedia (though that's irrelevant) and I've noticed complex and unnecessary dependency of the "speakers" field to the "extinct" field, that causes the former to not show up when the latter is present. You can notice how Hebrew language does not show the field, even though it's entered ("15 million") in the code. It's safe to assume like 90% cases where extinct is entered, there should be no speakers, though this doesn't account for revived languages and special cases.

There is a workaround speakers2 value that shows up inside the extinct field, but I think that's a wrong place. It's safe to assume editors entering both the speakers and extinct values know what they are doing, so I'd recommend just making them show up independently and simultaneously. Correct me if I'm wrong, thanks. -Vipz (talk) 13:42, 27 May 2022 (UTC)

Just as the inclusion of the "extinct" field causes the "speakers" field to be hidden, so too the inclusion of the "revived" field should cause the "speakers" field to be unhidden. However, I tend to agree with your assertion that editors know what they are doing so it would be more logical to simply not have the "extinct" field cause the "speakers" field to be hidden. Ggdivhjkjl (talk) 14:55, 27 May 2022 (UTC)

There's also the complication that when a language is "revived", what is created isn't the same as what went extinct. Modern Israeli is a different language from Biblical Hebrew; Wexler doesn't even classify them as the same language family. And Hebrew's the only case I know of where there's an L1 community of a revived language. The 'speakers' param is supposed to be for native speakers, so what other case of an extinct language with L1 speakers do we have to worry about? — kwami (talk) 05:25, 20 June 2022 (UTC)

"Population" parameter

Does the current template give an option for a custom parameter? There is currently a debate going on in the talk page of Cypriot Greek, regarding the confusion that might arise from the "ethnicity" parameter. If no such custom option exists, can a "population" parameter be introduced in the template? I believe this more general name would be useful for articles that discuss linguistic varieties of ethnic subgroups in general, and would take care of any possible confusion. Any other suggestions are welcome. Demetrios1993 (talk) 20:44, 31 May 2022 (UTC)

@Demetrios1993: Can you list a couple other examples where this label could apply? The simple solution would be giving the ethnicity field an alias (e.g. "population=") that would also trigger the name to display as "Population", as not to introduce a duplicate field for the same thing. I'm not really sure this is a needed addition, because: 1) "Population" is a confusing descriptor - population of the language? That would be "number of speakers". Ethnic group names? That's what "ethnicity" means. 2) Do you intend the new field "Population" to have "Greeks (Cypriots)" or "Greek Cypriots" or something else? What does the descriptor "population" here exactly mean and why can't it be under "Ethnicity"? It looks like to me like a lot of tinkering for one-off case introduced by an IP. -Vipz (talk) 19:47, 19 June 2022 (UTC)

Thanks for your reply Vipz. Some other articles that come to mind, where this label would be ideal, are the Cappadocian Greek and Pontic Greek articles. Their entries would be Cappadocian Greeks and Pontic Greeks respectively; these pertain to ethnic Greek subgroups as well. Of course, this isn't limited to Greek subgroups, but applies to all ethnicities or ethnic groups that are composed of distinct subgroups. Another case that comes to mind are the Frisians. Specifically, the West Frisian languages, North Frisian language, East Frisian language, and Saterland Frisian language, currently include the parameter "ethnicity", and their respective entries are West Frisians, North Frisians, East Frisians, and Saterland Frisians. A "population" label (or some other option per #1 below) would be more ideal, as these are all Frisian subgroups and not distinct ethnicities; they all belong to the Frisian ethnic group.

1. Indeed, i see what you mean. Another option would be "ethnic subgroup".
2. I am already in agreement with the IP that if and when such new parameter/label is created, the entry will be Greek Cypriots (diff1, diff2).

Again, i don't find the label "ethnicity" ideal, because it could cause confusion in articles that deal with linguistic varieties of ethnic subgroups (not of different ethnicities or ethnic groups). Demetrios1993 (talk) 08:06, 20 June 2022 (UTC)

Probably in most cases of ethnic minorities. There are recurring edit wars on Basque related pages for example because national statistics record inhabitants and (on the Spanish side anyway) speakers but not ethnicity (other than 'Spanish' for Spanish nationals), so there's often tugs of war along the lines of 'not everyone living in X identifies as X ethnicity' but often you only have data on inhabitants/population vs speakers to show speaker density, but often you don't have reliable data on self-identified ethnicity. Akerbeltz (talk) 10:17, 20 June 2022 (UTC)

I don't see what the issue is, really. The label "ethnicity" doesn't imply a distinct ethnic group. It's simply for the ethnic identity of the speakers. If their identity is a tribe or other kind of sub-nation, then we just specify that. It's rather common for a dialect of a language to be associated with a particular tribe of the nation that speaks the language. Similarly for the label "official language in" -- who cares if what it's official in meets our definition of a 'state'. It could be official in a sub-state, like a county or municipality. Doesn't really matter. — kwami (talk) 23:36, 20 June 2022 (UTC)

Personally, when i read the label "ethnicity" in the infoboxes of the aforementioned examples, i see it as an implication of a distinct ethnic group; it's no mistake that three more editors reverted the IP before i got involved in that article. The thing with these aforementioned subgroups, is that they view themselves as ethnically Greek and Frisian respectively, despite of belonging to distinct subgroups or branches of those ethnicities. Hence why i made the suggestion above. It would prove useful for avoiding such misunderstandings and edit wars in the future. Demetrios1993 (talk) 13:13, 21 June 2022 (UTC)

Collapsible dialect list

For language with dozens of dialects, it would make a lot of sense if the list of the individuals dialect ISO numbers and dialect names below the ISO3 function could be collapsible. A good example is on Arabic, where this part of the infobox gets really quite out of control. Anyone home here with any thoughts on this? Iskandar323 (talk) 08:55, 15 August 2022 (UTC)

Template-protected edit request on 21 September 2022

In the code for label7, it currently says as part of the value:

{{#if:{{{signers|}}}{{#ifeq:{{Infobox language/family-color|{{{familycolor|}}}}}|silver|1}}|speakers|speakers}}

There is no reason to even do this check if the same value is used either way; this anomaly was inserted in this edit. Please do one of the following- I'd prefer the first, but the second is better than nothing:

1. replace the first "speakers" in the code above to "signers" - effectively reverting the linked edit, although the undo feature can't technically be used here.
2. replace the entire code above with the word "speakers".

Animal lover |666| 07:33, 21 September 2022 (UTC)

Support second alternative, replace with speakers. Having been involved in the Deaf community for years, this is a common usage, and does not cause offense. Compare for example, "signers of asl" with speakers of asl. The best solution is just change it to "speakers of ASL". Mathglot (talk) 09:00, 21 September 2022 (UTC)

Per Mathglot. No need to say they're "signers", since we already name it a sign language. To me, that recalls saying a sign language is composed of "gestures" rather than "words". — kwami (talk) 09:42, 21 September 2022 (UTC)

 Done — Martin (MSGJ · talk) 09:52, 21 September 2022 (UTC)

Conlang colours

Change constructed language from "black" to "#114057" (a really dark blue) because black doesn't look as good and it will still stand out. UserTwoSix (talk) 21:58, 9 February 2022 (UTC)

That does look better. See the colour palettes on the right: current (above) vs proposed (below). There's still enough contrast between conlangs and other groups, right? I would like to hear from others just in case, but otherwise I'd be happy to implement the change if there are no objections in a couple of days. – Uanfala (talk) 00:12, 10 February 2022 (UTC)

If you do so, beware of stuff like {{#ifeq:{{Infobox language/family-color|{{{familycolor|}}}}}|black|...}} sprinkled through the code. Kanguole 15:07, 10 February 2022 (UTC)

Thanks for pointing that out: it was an easy thing to overlook. I've now switched to the new colour [5]. – Uanfala (talk) 14:00, 24 February 2022 (UTC)

I'm actually in the middle of rewriting this template in Lua. Had I done this before this fix, the only edit which would have been needed woule have been in the color table (in a submodule); the main module does the test (only once) of familyColor==familyColors["conlang"]. Animal lover |666| 18:27, 21 September 2022 (UTC)

While this conversation is still here, can we move away from the highly saturated lime used for Uralic? It’s very jarring compared to the rest. — HTGS (talk) 05:26, 26 August 2022 (UTC)

Agreed with the proposed change, and also agreed with HTGS's suggestion about Uralic.  — SMcCandlish ☏ ¢ 😼  12:54, 30 August 2022 (UTC)

Template-protected edit request on 22 September 2022

In the Module:Check for unknown parameters section at the end, please fix development _body (with a space) to development_body (no space), as this is the correct name of the parameter. Animal lover |666| 18:33, 22 September 2022 (UTC)

 Completed. P.I. Ellsworth , ed. ^put'r there 22:34, 22 September 2022 (UTC)

Deprecate the signers parameter?

Given the decision in the section above, and the fact that the signers parameter is only present in 2 articles (Lesotho Sign Language with a blank value, South African Sign Language with a real value), should we cancel that parameter in this template? Animal lover |666| 03:38, 22 September 2022 (UTC)

Yes, we should; along with its alias, "speakers". Existing transclusions that use the parameter could be fixed if desires, but actually don't need to be, because fixed or not, the output is the same. Mathglot (talk) 09:06, 22 September 2022 (UTC)

Changed to 'speakers' in the two articles that had it. I tried removing 'signers' from this template to simplify the code, but I missed a pair of closing braces somewhere. (Messed up both here and in the sandbox.) If someone could remove that param please; the code is intricate enough without it. @Animal lover 666 and Mathglot: If you want to give it a try but can't edit the template, I can paste it in for you. — kwami (talk) 23:01, 22 September 2022 (UTC)

I didn't do the whole job, but I did part of it in the sandbox. Feel free to do them one instance at a time (in the sandbox, not the live template), checking the test page after each. Once each of them you have either removed successfully or given up on, paste the sandbox over the live template. Note also that the list of legitimate parameters at the bottom is the most important; it ensures that any new usage would cause the page to get categorized in the error category. Animal lover |666| 14:45, 23 September 2022 (UTC)