Template talk:Infobox language/Archive 5

Archive 1

←

Archive 3

Archive 4

Archive 5

Archive 6

Archive 7

→

Archive 10

Altaic languages does not work in the field "familycolor"

Hi. Altaic family doesn't work. When I use "|familycolor = Altaic", This appear: "(specify language family under 'fam1')". When using "fam1", there is no problem. Can someone explain about this? Thanks. Winter Gaze (talk) 12:33, 25 November 2011 (UTC)

Yes, it's done purposefully, because Altaic is not a demonstrated language family. We only use it for the constituent families (Turkic etc.) and a the best known individual languages (Turkish, Mongolian, etc.) Otherwise listing languages by their established family is adequate. — kwami (talk) 02:13, 29 November 2011 (UTC)

"ld" parameters linking to dab pages

Hi folks. I disambiguate incoming links to a number of dab pages, several of which happen to be language names that also have other uses. English is an obvious example of that.

When an "ld" parameter in this infobox is populated with just the name of a language, this frequently creates links to dab pages, which should normally never be linked to, and I can't figure out a way to fix those links. The normal way to disambiguate such a link is to pipe it: [[English language|English]], for example. However, I've just tried this with a case where I need to do it (the infobox at Norwegian Sign Language, if anyone would like to look), and piping doesn't work; the article title ("Norwegian language") is displayed instead of the intended text ("Norwegian"). Is there another way to solve this problem? Thanks, --Tkynerd (talk) 00:32, 11 December 2011 (UTC)

The "ll" parameters take care of the links. In the case of NSL, they should be set to "none". Also, piping will work when "ll" is set to none, though the idea was that "ld" would be the display and "ll" the link in place of piping. (I have no idea why.) — kwami (talk) 01:07, 11 December 2011 (UTC)

Thanks for fixing the parameters at the NSL article! --Tkynerd (talk) 02:15, 11 December 2011 (UTC)

Remove parameter?

Is this s.t. we should get rid of? Is there any reason to use separate ld and ll parameters, rather than normal piping? About 430 articles would be affected. — kwami (talk) 01:10, 11 December 2011 (UTC)

I've hard-linked the ones that needed it, and will rem. the ll coding now. — kwami (talk) 09:10, 28 January 2012 (UTC)

Language not = ethnicity

The explanation of the "ethnicity" parameter says "the name of the article for the people and the language will generally be the same". This seems wrong to me. An article on a language should discuss it as a language - relationships to other languages, structure, sounds, writing etc. An article on an ethnic group talks about where they come from and where they live, traditions, culture and so on. To me they are quite different types of article. E.g. English people and English language. We should encourage cross-linking, as with this parameter, but should not encourage articles that confuse the two subjects. Comments? Aymatth2 (talk) 21:13, 12 December 2011 (UTC)

What we meant was that the name will generally be the same. 'Chinese' is spoken by 'the Chinese', for example, rather than 'Putonghua' is spoken by the 'Han'. I'll try to word it more clearly, or maybe it should just be deleted, as it's covered in the MOS. — kwami (talk) 22:01, 13 December 2011 (UTC)

How about: "For an article on the 'ABC language', there will often (but not always) be a corresponding article on the 'ABC people'. This parameter provides a link". Something like that. Aymatth2 (talk) 00:57, 14 December 2011 (UTC)

That works too, except that it doesn't have to be a link (some editors do not like red links), and in other cases it's used for ethnic population, to contrast with number of speakers. — kwami (talk) 07:41, 14 December 2011 (UTC)

script = Latin now links to the script

Setting 'script=' to Latin or Latin alphabet now redirects to Latin script, which is generally where we want to go. (Easier than manually changing a thousand articles.) For the infobox at Latin, where we really want the alphabet, just add s.t. else like a non-breaking space, and it will not redirect. — kwami (talk) 17:13, 30 January 2012 (UTC)

Native speakers

I've noticed that someone has changed the "Total speakers" header to "Native speakers". For natural languages, this is a fair deal, but it gets us into trouble in the case of constructed languages. The only constructed language that has ever had native speakers is Esperanto (not to mention one isolated case in Klingon). In all other cases, the number would obviously be zero. Which means that in many articles, the information currently listed will have to be changed.

However, in the case of constructed languages, the number of native speakers is quite irrelevant. The only number that is kind of informative is the number of users. The term "speakers" is often used in this context as well, but it should be said that it is very hard to tell how many people can actually speak a constructed language, just because nobody has the means to determine how fluent a person really is. The term "users" would at least include those who have learned it to some degree and are able to write with the help of a dictionary.

This issue is going to cause lots of needless trouble. Would it be possible to modify the template in such way that in the case of constructed language the header says something like total users instead of native speakers? —IJzeren Jan _Uszkiełtu? 09:35, 6 October 2011 (UTC)

We could key it to change the wording for artificial languages. But in general, we give numbers of native speakers, and sometimes an additional figure for 2nd/total, so "total" would not work for natural-language articles where the two figures differ. — kwami (talk) 12:43, 6 October 2011 (UTC)

How's that? — kwami (talk) 12:50, 6 October 2011 (UTC)

I see you have already taken care of it. Thank you for that. It's excellent! And sorry for my late response, but I've been away for a week. Cheers, —IJzeren Jan _Uszkiełtu? 07:42, 13 October 2011 (UTC)

This change has also caused a problem in the article on the Irish language. Can some expert tell us how to make the parameter display as "Total speakers" rather than native speakers? I am not sure how to do this. Thanks. ComhairleContaeThirnanOg (talk) 11:02, 17 February 2012 (UTC)

I can help you with that, but what figure would you use, since the authors of the article have not been able to find a sourced figure? (The 1.7M is acknowledged to be incorrect for L2 speakers.)

I put in what we have for Ireland from the latest source (2004). — kwami (talk) 11:31, 17 February 2012 (UTC)

No, if we do actually want a figure for native speakers in the infobox, that's fine. Though I think you are perhaps right to be reticent about the Examiner source. However, the 1.7m figure for L2 speakers is correct per the 2011 census - see pdf ccensus tables: http://www.cso.ie/en/media/duplicatecsomedia/newmedia/census/census2006results/volume9/tables_1-17.pdf (obviously this is self-reported, however, and as you say the difficulties with it are noted in the article). ComhairleContaeThirnanOg (talk) 11:57, 17 February 2012 (UTC)

Self-reporting is about as reliable as a newspaper. People report they speak a language even when they don't (well at least) because they think they should, or because they think learning it in school or being able to say a few pleasantries counts as speaking. For many languages it wouldn't matter too much (say, the number of Laotian speakers in Ireland), but Irish is psychologically important, which means you can't trust what people tell the census. I found a linguistic source, but it's dated (20 yrs). I think we're going to need to stick with linguistic sources for this, just as we do with other emotionally charged languages like Croatian. — kwami (talk) 12:15, 17 February 2012 (UTC)

I just did some googling, in both English and Irish, but didn't find anything that looked very convincing. Time to look in books I guess, though I don't have any within reach myself. ComhairleContaeThirnanOg (talk) 12:56, 17 February 2012 (UTC)

Unexplained style effect

In some language infoboxes used, I see style "fam4=yeai", in a single row only. (see Edo language). What is the meaning of that styling? And, should it not be made clear somehow? -DePiep (talk) 14:15, 24 February 2012 (UTC)

Go to the superior node. It's an acronym. — kwami (talk) 14:56, 24 February 2012 (UTC)

A bit in a commanding mood today? Anyway MOS:ALLCAPS states we use regular caps, not small caps. And I created an answer to the other question, on how to notify a reader of this. See Igbo language. I am in a constructive mood today :-) . -DePiep (talk) 16:01, 24 February 2012 (UTC)

It's not a "command", it's an instruction, on where to go if you want an explanation. If you ask a question, don't take offense because someone answers it, or we'll start ignoring your questions. — kwami (talk) 05:33, 25 February 2012 (UTC)

Edit request (family-color) 16 March 2012

• Topic: {{Infobox language/family-color}} subtemplate.
• Proposed change: move all code from the {{Infobox language/family-color/sandbox}} to the live page {{Infobox language/family-color}} (full replacement). Note that this is a subpage of a subtemplate (not the main template's /sandbox).
• Changes made, now in the sandbox:

In general: Only code reorganising, no material changes

(1) Moved #default to end of #switch:-code, to keep overview (more standard way of writing). By #switch:-documentation, this has no effect in workings.

(2) Remove suggestive "white" or "{{{1}}}" return value for default, blank or not-found input. See note below on this. No change, it never worked as a color-setting.

(3) There were two "defaults": blank input and not-found input. Folded both defaults together into one outcome: add the category. This was the effect always.

(3) Check all input for lc and uc (made case-insensitive). Catches more.

(4) Move documentation code to its documentation page. This is a page of the subtemplate, not the main documentation.

• Effects, tested: See {{Infobox language/testcases}}. It shows that there are no differences.
• Consensus: I claim that this is a code-organising change only.
• Motivation: by organising the code into this more standard way, future changes can be overseen, performed and tested more easily. Nonsense code s removed.
• Other pages to edit? - Check documentations. Not the main template or any other page.
  -DePiep (talk) 14:39, 16 March 2012 (UTC) Edited to reflect 2nd improvement. -DePiep (talk) 16:40, 16 March 2012 (UTC)
  • Note on returning white or {{{1}}}. There were two separate default-catchings: blank input and not-found input (this could be a color name entered). The code and documentation suggested that (blank) input would return "white", a color name would retunrn that color name (like one could use {{{1}}} to get that background), and any other word would return that word, but not setting a color, i.e. background stays transparent. This did not work as expected. In these cases, the template always returned a non-color and so the background became transparent. The reason is that in these cases the [[:Category:...]] text was added to the color, so returned was the text: white[[:Category:...]], which is not recognised as a color so ignored. The current testcases for irregular input show this.

Concluding I removed this suggestive code in the sandbox, leaving the Category-adding in place. Factual behaviour with these defaults is as before: no color name is returned, and the background stays transparent. The only way to get white is to enter familycolor=unclassified or familycolor=superfamily (as before), and in this case, no Category is added (as before). Since there are few pages, and no articles (from main space) in the Category, few pages are involved in this non-change. -DePiep (talk) 16:40, 16 March 2012 (UTC)

Looks good.  Done — Martin (MSGJ · talk) 20:46, 18 March 2012 (UTC)

Thank you! (also for the checking). -DePiep (talk) 20:48, 18 March 2012 (UTC)

I see that if we put gibberish under 'familycolor', the error cat is triggered. However, if we put something under 'family', it is no longer triggered, even though the color remains transparent. Can we modify to catch errors like this, whenever no color is returned? — kwami (talk) 20:58, 18 March 2012 (UTC)

Yes we can. So, you say, there is input like family=foo nonsense, and that should trigger the category too. (I missed this route before). Will take a look, probably origin in the main template now. -DePiep (talk) 21:16, 18 March 2012 (UTC)

Questions. You say it is "no longer" triggered? Can you give an example page (article) for this? So far, quickly, I saw this: (1) number of pages in the category has not changed, (2) all calls for this /family-color template are fed with input {{{familycolor}}} (not {{{family}}}). (3) If it might have to do with {{{fam1}}} input or {{{signers|}}}{{{creator|}}} please mention that. -DePiep (talk) 21:31, 18 March 2012 (UTC)

Found it. This is where it goes strange: when any family=language-or-nonsense is entered, the whole /family-color check is not performed (so Category-adding will not happen, at all). This can produce the situation Kwami points to. Will be changed to promise: IF family-name ("familycolor") is not recognised (is not in the quilt), THEN the category will be added. -DePiep (talk) 22:16, 18 March 2012 (UTC)

This will be addressed in the edit request below (all category-check in one place: main template). -DePiep (talk) 23:16, 18 March 2012 (UTC)

Edit request (18 March 2012)

• Topic: {{Infobox language/family-color}} subtemplate.
• Proposed change: move all code from the {{Infobox language/family-color/sandbox}} to the live page {{Infobox language/family-color}} (full replacement). Note that this is a subpage of a subtemplate (not the main template's /sandbox).
• Changes made, now in the sandbox:

There is no more Category:... adding in this subtemplate. There is one rule only: if the language family-name is recognised (i.e. in the documentation "quilt"), it returns a bg color name pink or #c0dde6. If the input is not recognised, a blank is returned. Category-adding should be done elsewhere.

Minor: rm superfluous line, that would end up in the #default all together (blank input situation).

• Other pages to edit: {{infobox language}} and {{infobox language family}} use this subtemplate, and already are adjusted to perform the category-check on a single place. Documentation should be adjusted.
• Effects: one bug gone away (bug: when family=any input was entered, the category-check was not performed → unexpected missing from the category could occur (see previous thread, cmt Kwami). Now solved: whatever the family= input, the category-check is performed.
  

-DePiep (talk) 23:16, 18 March 2012 (UTC)

Done. No new articles popped up. — kwami (talk) 01:33, 19 March 2012 (UTC)

Edit request (family-color)

N Not done and not likely to be done Has been solved through other edits (see below, 16 March and 18 March). -DePiep (talk) 10:16, 19 March 2012 (UTC)

Holding the proposal, too premature

Proposal, waiting for consensus Topic: {{Infobox language/family-color}} subtemplate. Proposed change: move all code from the {{Infobox language/family-color/sandbox}} to the live page {{Infobox language/family-color}} (full replacement) Changes in sandbox: Not changed is: names and color codes currently present. (1) Grouped "default" options (resulting in white) to the end of the #switch:-code for oversight. (2) The Category:Languages without family color codes wil only be added on pages in mainspace (=Articles), not user space or template space &tc. any more (expected result: the category will be empty, no problem pages present now). (2b) To test thisin /sandbox, it adds a text referring to this category. This text is to be removed before going live. (3) Input is independent of uppercase/lowercase. "Caucasian" and "caucasian" will both return "lightgreen". (4) Separated documentation into separate page. Effects, tested: See {{Infobox language/testcases}}. It shows that there are no visible differences. Consensus: to be build through this proposal before the real edit. Other pages to edit? - Check documentations. Not the main template or any other page. Todo: if we agree, we can (a) remove the sandpbox-code and (b) go live with the code, activating {{edit request}}. -DePiep (talk) 15:00, 15 March 2012 (UTC)

I'm not getting default white. Is that working? It's s.t. I think we should avoid, actually. White has a specific meaning (a proposed family); we wouldn't want it kicking in by mistake, say at Wikipedia talk:Articles for creation/Bozal Spanish. — kwami (talk) 15:12, 15 March 2012 (UTC)

The Bozal Spanish example would be different indeed. /sandbox now says: not in the category, because not in mainspace. You want all "whites" in the category? (No problem with me, I thought I was cleaning up the category, I missed this situation; we could also keep out of the category userspace pages only). What does "s.t." mean? -DePiep (talk) 15:27, 15 March 2012 (UTC)

No, not white; just when the color is missing. Wouldn't want white for the default, just for when we want it. — kwami (talk) 18:07, 15 March 2012 (UTC)

Need a hold. The color usage is more complicated, re signers and creator input. Will have to check that logic (adding, another good reason to separate colorfrom category-checking). -DePiep (talk) 16:17, 15 March 2012 (UTC)

Below, I have asked for a protected edit to reorganise the subtemplates code. Bring some more overview. -DePiep (talk) 14:42, 16 March 2012 (UTC)

Category-check in one place only

About the category: I just discovered that the main template checks for these three inputs: {{#if:{{{familycolor|}}}{{{signers|}}}{{{creator|}}}|<!--OK, one is present-->|<!--Add the cat-->[[Category:Languages without ...]]}}.
For this reason I propose (change the sandbox): do all Category-checking in one spot, the main template. It would read like, simplified: if:family-color=white OR ({{{family-color|}}} missing AND {{{signers|}}} missing AND {{{creator|}}} missing) THEN add the Category. Technically, all required checks can go there. -DePiep (talk) 15:39, 15 March 2012 (UTC)

Bot request for references (feedback needed)

There's a bot request here for adding ethnicity, reference, and date fields to all boxes which do not have then, and to add a ref section to all articles with boxes that do not have one. This is just to make it easier for us to overtly ref our articles, rather than just covertly ref'ing them through the SIL link as we tend to do now, but it's running into problems. Would anyone object to having this done? — kwami (talk) 04:45, 26 March 2012 (UTC)

ISO 639-3 code and Linguist List

As code is now: the infobox puts a page in Category:Languages with Linglist but no iso3 codes when no linglist=qrx qrx page exists. I think this is a bit strange. First: there is no check for input iso3= at all. Second: whether the page (at wiki) exists is not a good criteria, I'd say. Example pages: Duit language (strange), Marawan language (understandable). Should we not just check: linglist=qrx (has input) and iso3= (has no input) so in the category?
Note: I have edited the infobox wrt this category and the data21 row [1]. I kept the checking logic, and before/after there are 309 pages in the category. -DePiep (talk) 15:52, 27 March 2012 (UTC)

 Done Have read the Category introduction text. Indeed, as I suggested, it should be checking with iso3-input. I have adjusted the code. Suggestion to separate provisional dialect code not yet implemented. -DePiep (talk) 16:15, 27 March 2012 (UTC)

(date missing) note

Re this reversal [2]. So the text (date missing) is added when there is, eh, no date entered (for the speakers numbers estimation). I think that is a note to editors, as is the added Category:Language articles with undated speaker data (with 1,591 pages). So it is a maintenance/cleanup thing.
Of course, when there is no date entered, no date is shown. The note is trivial. As a warning it does not add anything, because if a reader sees no date -- well, the figure is undated, not wrong dated. In general, we do not add "incomplete" text to an article do we? If any such note is to be in mainspace, we should use (or maybe , , ). And when the whole reference wrt speakers is missing, there is . These are non-content notes btw, they are not part of the encyclopedia. -DePiep (talk) 07:29, 29 March 2012 (UTC)

One of those templates would be fine, if you think that's better. Most speakers will expect that if we list the population as 2,000, we're saying the population *is* 2,000 — which it very often is not. I've come across population data from the 1950s! — kwami (talk) 08:04, 29 March 2012 (UTC)

Declared "unknown" when speakers date is older than 30 years: WP:OR

About number of speakers (or signers). The temlate did this: When the date of estimation was older than 30 years, the text shown for likewise input would change:

• 8,400 (1992)
• unknown (8,400 cited 1979)

These pages with "unknown" are added to the maintenance Category:Language articles with old speaker data (now 339 pages).
I have removed this separation [3]. Thxts now are the same for both situations (namely, as in the fist example). The reason is that declaring the figure "unknown" is WP:OR. Adding to this, the 30-year limit is arbitrary. The category adding is not changed. -DePiep (talk) 12:49, 29 March 2012 (UTC)

If you don't like 30 yrs, you can change to a more appropriate figure, but since a language can double in size in 30 yrs, if our ref is 30 yrs old we do not know the population to better than an order of magnitude, and it is misleading to imply that we do. (Some populations are doubling every 20–25 years, but 30 is more typical.) We could perhaps reword the output.

Actually, the 'cited in' wording might be best for all entries, because the date is very easy to read as the date of the population estimate, rather than as the date of publication of the reference for the population estimate. Rarely do we know the actual date, which is why I've always tried to add the word 'census' for census data (which have their own problems, but at least have a known date). — kwami (talk) 19:45, 29 March 2012 (UTC)

Kwami, whatever I prefer does not matter. Not even we. Of course I understand the reasoning (a population can double in 30 years!). My point is: WP:(we) are not to decide that. That would be Original Research. -DePiep (talk) 21:48, 29 March 2012 (UTC)

No, it's not OR, it's just an indication that the data is old. — kwami (talk) 04:06, 31 March 2012 (UTC)

Adding the word "unknown", while there is data, is a judgement by WP. That is the OR thing. Now, since that word is edited out [4], there is no longer an OR. So I agree with this improvement. -DePiep (talk) 10:30, 31 March 2012 (UTC)

catching unsupported params

DePiep, could you add that code for catching unsupported parameters? — kwami (talk) 04:13, 1 April 2012 (UTC)

Yes. It will use Category:Language articles with unsupported infobox fields. I know state only. Any more? And, do you want empty usage (state=) catched too? -DePiep (talk) 07:52, 1 April 2012 (UTC)

Yes, we need to tag any string of symbols that is not recognized by the template. (That was the point of the bot request.) — kwami (talk) 08:05, 1 April 2012 (UTC)

Given that people have been using 'state' for years, we should probably have it accept either 'states' or 'state'. (I tried, but it didn't work right. Could do it with parser statements, but I suspect there's a more straightforward way.) There were only two articles this time, but that's because I did a sweep last year and cleaned up scores of them. When you & I are gone, people will keep doing this, because it's a very natural mistake to make.

Also, if we have 'altname' w/o 'nativename', there shouldn't be a blank space, so either 'altname' or 'nativename' should go in the second line, and the line break only occur if both are used. (This is another common mistake, because people use the lang family box as the basis for a language article, and that has 'altname' rather than 'nativename'. Also, eventually we might want to use 'nativename' for the native name, and otherwise use 'altname', so the box should accept both equally. — kwami (talk) 08:14, 1 April 2012 (UTC)

Ah, that's how you do it! I'll play around with the other one. — kwami (talk) 08:37, 1 April 2012 (UTC)

Done altname/nativename request. Added state/states input accepted (using: after the pipe there can be a fallback value -- which can be a paramter too). Cannot do: catch any unknown unsupported parameter (that's for the bot indeed). -DePiep (talk) 08:42, 1 April 2012 (UTC)

I did it a different way and for some reason there was no edit conflict. Now redone it to get rid of the main 'if' statement.

I never did understand the difference between {{{...}}} and {{{...|}}}, let alone {{{...|...}}}, and I can't find an explanation anywhere.

Removed the category, since the param is now accepted.

— kwami (talk) 08:49, 1 April 2012 (UTC)

re altname: as it is now, it always puts a break if there is nativename (so even without altame). That's two lines. The pipe allows for a "default" value, used when that is no value in the input. Using one of them two in an #if: statement has different effects (blank input vs no param at all is differentiated).([5]). -DePiep (talk) 08:54, 1 April 2012 (UTC)

As a suggestion: couldn't an altname be moved into the header above, together with the name? And the nativename in a separate row (the one it is in now). -DePiep (talk) 10:05, 1 April 2012 (UTC)

Never mind, it's OK current way. -DePiep (talk) 10:09, 1 April 2012 (UTC)

Yes, actually, that would work too, though perhaps we could have "name2" or s.t. if we want it to be the same size. (It's bad form to use a line break, because that will all get repeated down in the classification.) — kwami (talk) 10:30, 1 April 2012 (UTC)

Please, no more unexplained/unlinked meanings by format in the template. Today, I think it strange that the language-family background color (not a minor thing) is not linked. -DePiep (talk) 20:16, 1 April 2012 (UTC)

I don't follow. — kwami (talk) 00:24, 2 April 2012 (UTC)

error if only one lc code and no iso

Used to be that if you wanted, you could have a single lc/ld param, w no iso3, and it would display as code + comment (not good form; iso3comment would be better for that). But now there's a spurious line break before it. — kwami (talk) 11:54, 1 April 2012 (UTC)

flags or no flags?

Any comments on Wikipedia talk:Manual of Style/Icons#Reconstruct "Flag Icons in Infoboxes" Guideline? — kwami (talk) 12:44, 1 April 2012 (UTC)

Adding Korean iw

Resolved

Re: this self-deletion here:
The Template:Infobox language/doc documentation page is not protected (what is the misunderstanding?). Anyone can add the interwiki link [[:ko:Template:언어 정보]] nicely in the list of iws in that /doc. -DePiep (talk) 09:47, 31 May 2012 (UTC)

Template:Infobox language and Template:Infobox language/doc are semi-protected, but I mistook they are fully protected. I added the iw. --Yes0song (talk) 15:44, 31 May 2012 (UTC)

All right then. (Though to me it looks like the /doc is unprotected). -DePiep (talk) 15:49, 31 May 2012 (UTC)

When is a language "spoken" somewhere?

I start this as a spin-off of a more specific debate at Talk:Norwegian language that I just started. It occurs to me that the |states parameter is being used too liberally. I think we need some basic criteria to be fulfilled, such as:

• The language has a continous presence in the country/area
• The language has been present in the country/area for many generations, and thus forms part of a local tradition

I.e. it is not enough that ~50 000 persons of nationality X speaking Xish at any given time lives as expats in country Y where Yish is traditionally the only language, because there exist no traditions for Xish here. Xs have not likely established any communities in country Y, and the offspring of Xs that choose to settle permantly will probably barely have any knowledge of Xish left a couple of generations down; they'll all be speaking Yish as their native tongue.

A concrete example is Swedish, where the infobox currently lists the following countries:

Sweden (9.4 million)
Finland (290,000)
USA (70,000)
Spain (40,000)
United Kingdom (30,000)
Canada (20,000)
Ukraine (10,000)

Sweden is obvious, Finland is fine when you know some details about the country. The rest of the countries, on the other hand, I suspect is nothing but counting expats and similar people that have no real relevance to Swedish being "spoken" somewhere, not in a meaningful sense of the word, anyway. Njardarlogar (talk) 18:18, 14 June 2012 (UTC)

This is a real problem in a lot of articles. We get 'country inflation', with mention of every immigrant community in the world, even if the language is not being passed on past the 2nd generation. Should we change the header? Rather than "spoken in", perhaps "spoken natively in"? We have a separate section for official languages, so we don't need to worry about official-but-not-native for languages like English; we also have a 'region' section for languages w/o native speakers, such as Bokmal.

(Since this hasn't gotten any comments, I'll make the change and see if that attracts people.) — kwami (talk) 19:23, 7 July 2012 (UTC)

I understand your concern, but I'm not sure the distinction is as clear (and desirable) as it appears on first glance. For example, why should we list the USA for Spanish but not for Swedish? sephia karta | dimmi 15:14, 8 July 2012 (UTC)

Spanish has been passed along for centuries in the US, since it was part of Spain. That is, it is natively spoken there. Same for French and German ('Pennsylvania Dutch'). How stable is the Swedish-speaking population? If there are areas where the same is true, I'd say they should both be listed. But if a lang is only spoken by the (grand)children of immigrants, then it hasn't become an indigenous population. The list given for Swedish above may be fine – perhaps those are all established communities. But I've seen other cases where 20 or 30 countries are listed (often Slavic, Indic, or Dravidian languages), basically wherever immigration has been great enough for a cultural center. — kwami (talk) 17:53, 8 July 2012 (UTC)

It's just that I think it's very hard to decide of what type a population is, in practice, and that it may be the case that most commuties in fact become established, so that we shouldn't want to make the difference. Case in point, to my knowledge the Swedish population in the USA dates back to at least the 19th century. sephia karta | dimmi 16:56, 10 July 2012 (UTC)

On second thought, I agree that some immigrant communities assimilate within one or two generations. I guess I don't feel very strongly about the issue, and I am not a proponent of listing 20 something countries in the infobox of a language. We could also introduce the criterium that we only list a country if the number of speakers there surpasses a certain percentage of the total number of speakers (e.g. 1%), or if there is some special historical significance to the community.sephia karta | dimmi 17:40, 10 July 2012 (UTC)

Considering that we list language communities with only a few hundred speakers, if that's all a language has, I don't have a problem with stable immigrant languages. I think we'd need a ref that they are stably multigenerational, however, and we're only likely to find a ref if the community is somehow notable. Another possibility is to just mention 'diaspora' or 'emigrant' communities in the info box, and restrict the details to the text. — kwami (talk) 00:45, 11 July 2012 (UTC)

@sephia: Not sure whether your second comment was meant to contradict that the Swedish population in the USA dates back to at least the 19th century; but if not, the question then becomes: how many of these speak Swedish at a native level? And how many of them use it in their everyday life (voice communication abroad not counting)? Given that Swedish has ~ 9 million native speakers living in Sweden, it would seem irrelevant to mention 10 speakers in LA, 2 in NY, and 50 more spread out thinly over the rest of the country; the only ones in the U.S. to have had the language passed down over generations. I'd wager that a lot of the 70,000 figure stems from first and second generation immigrants, and that those of older generations do not speak Swedish to a degree that is worth mentioning, given the size of the language.

In my opinion, for a language to be listed as being spoken somewhere, then either:

a) it is self-evident that the location is relevant to be listed; e.g. because it is it is an official language there, or it is the only place/one of very few places where it is spoken, or something similar

b) sources can be provided to prove that the basic criteria for inclusion are met (such as e.g. the two that I listed in my first comment above). No sources, no inclusion. This is to prevent list inflation.

Njardarlogar (talk) 10:22, 30 July 2012 (UTC)

ISO 639-6

Why doesn't this template have ISO 639-6? Some variants of languages has the code, it's impossible to show the code through this template. I think ISO 639-6 has to be added to this template. --Yes0song (talk) 16:16, 27 May 2012 (UTC)

You mean, e.g. in Manx (glv) we can add:

glvs Manx Spoken

glvx Manx Traditional

That would be: multiple lines (how many max?), and the name (in text) should follow automatically? I assume no "Parent language" issue involved? [6] -DePiep (talk) 22:18, 27 May 2012 (UTC)

Is this something that people use? I see ISO-3 in the lit, for example in Maho's update of Guthrie's classification for Bantu. And the ISO-2 extensions are used for, among other things, Wikipedia's language abbreviations. I don't think I've ever seen ISO-6 used anywhere. Would it be worth adding? — kwami (talk) 03:21, 28 May 2012 (UTC)

ISO 639-6 includes codes of living languages/variants. For example, Jeju dialect of Korean or Jeju language (of course, it's a living language/dialect) has two ISO 639-6 codes: "cejm" (as Chejumal) and "chjm" (as Chejumal Spoken). Chejumal is the McCune-Reischauer spelling for Jejumal (Revised Romanization of Korean. Hangeul: 제주말) literally meaning "Jeju speech" (i.e. Jeju language/dialect). I want to add the codes to the Jeju dialect article. --Yes0song (talk) 07:18, 28 May 2012 (UTC)

I don't believe anyone uses ISO 639-6, and at a number of summer meetings I was at in Britain and Germany this year everyone expressed their extreme dissatisfaction with the codes, which are badly designed and quite minimal, and talked about setting up a new standard. Linguists at least will never be using them. If you must use a dialect code, some linguists use the LinguistList MultiTree dialect codes (this is true of AILLA). These aren't standard, but they are pretty complete. but I've never heard of anyone using ISO 639-6. By the way, LinguistList seems to have a special code for Jeju: it calls it a language. (http://multitree.linguistlist.org/codes/1mm) Kaitulai (talk) 16:23, 2 August 2012 (UTC)

Request

Please add support for a 4th & 5th LingList code and name. They are currently being used by Hittite language, Oscan language, Gaulish, and Aramaic, but do not display. — kwami (talk) 00:56, 28 July 2012 (UTC)

Okay, the article changes that Taivo was objecting to have been reverted. We still need full code support. — kwami (talk) 20:22, 1 August 2012 (UTC)

Extended content

No, no, no Kwami. You have created havoc across the language articles by removing the ISO authority links for scores of languages. That is absolutely wrong. Just because a language doesn't occur in Ethnologue does NOT mean that its ISO authority has been removed or changed or "maintained" differently. If you want to add a separate LinguistList link, fine, but removing the ISO link is wrong. These ISO codes are used far beyond Ethnologue and Wikipedia for official library, funding, and other purposes within the field. DO NOT change any more of these ISO authority codes to LinguistList codes and revert those pages that you have changed. Not a single one of these languages have lost their ISO authority. Not one. --Taivo (talk) 09:48, 28 July 2012 (UTC) I'm declining the edit-request for now as it is clearly not non-controversial. Once consensus is established, feel free to reactivate. DMacks (talk) 16:05, 28 July 2012 (UTC) Taivo, SIL is not the sole maintainer of ISO codes. They refer the reader to Linguist List themselves in several cases. They are spinning off ISO maintenance to Linguist List for all languages extinct by 1950. We don't say the ISO code is not valid, we say that it is maintained by Linguist List, which is correct according to both SIL and LL. BTW, I made the coding changes and started implementing it several months ago; I was just waiting for the full list from SIL. There are other ways we could handle this to make it more obvious. What I suggest is that we list the ISO code as it was, linking to the SIL page, and link the 'maintained by Linguist List' notice to the LL page that we link to now: ISO 639-3        zsk (maintained by Linguist List) or maybe ISO 639-3        zsk (maintained here) to save space. Would that work for you? A separate LL listing would IMO be best left for when LL has a separate language code, or an "individual use" ISO-like code (qxx series) that isn't actually ISO. — kwami (talk) 20:48, 28 July 2012 (UTC) No, Kwami, LinguistList is not the "maintainer" of ISO 639-3 codes. That authority rests solely with SIL's ISO authority. There is no instance in which maintenance decisions are made by LinguistList. I know because I often worked directly with the ISO authority to get new codes assigned and revised old codes. We do not work with LinguistList at any point in the process. It is entirely a SIL function. You are confusing "maintenance" with a web page that uses ISO codes to refer to its entries (which is what both LinguistList and Ethnologue do). The ISO 639-3 code is the root of both of these databases and must be the primary information listed in our templates. If we want to further list an appropriate LinguistList page, then that's fine with me, but the root is ISO 639-3, not LinguistList. --Taivo (talk) 22:38, 28 July 2012 (UTC) Your options are unacceptable because, as I clearly stated above, LinguistList has no role whatsoever in "maintaining" ISO 639-3 codes and our links should point directly to the ISO 639-3 entry (as they do with languages with an Ethnologue page). That is the code authority. A separate link to the LinguistList page can be added, but in no way should it override the link to the ISO 639-3 entry. --Taivo (talk) 22:40, 28 July 2012 (UTC) Here is a direct quote from SIL's official ISO 639-3 home page: "SIL International has been designated as the ISO 639-3/RA for the purpose of processing requests for alpha-3 language codes comprising the International Standard, Codes for the representation of names of languages - Part 3: Alpha-3 code for comprehensive coverage of languages." ([7]. Ethnologue and LinguistList are mentioned only as they served as original sources for the languages that needed codes, not as "cooperating partners" or in any sense as co-maintainers of the list. Sole authority for the codes rests with the SIL ISO 639-3 authority. That's the only relationship that the ISO 639-3 authority has with either Ethnologue or LinguistList. Both of those latter groups get their codes from the ISO 639-3 authority, not the other way around now. --Taivo (talk) 22:51, 28 July 2012 (UTC) All right. Currently when we link to SIL, that site links to Ethn, which is generally used as a ref for the WP article. In those cases where it doesn't link to Ethn, and if it did Ethn. would only be a rd. to LL, what would you suggest to link the WP reader to the LL entry? — kwami (talk) 01:40, 29 July 2012 (UTC) When the reader clicks on the ISO 639-3 code link, they are taken to the official ISO 639-3 page. That must always be the case. When ISO 639-3 provides a further link, fine, the reader can click on. But if ISO 639-3 doesn't provide a further link, too bad. If we want our readers to be able to go to Linguist List, then that link should be separately provided. The ISO 639-3 code link must always go to the official ISO 639-3 official code page. Nowhere else. --Taivo (talk) 02:00, 29 July 2012 (UTC) And that "maintained by" verbiage is not only unacceptable, but inaccurate as well. So at a language article like "zsk" above, we would have: ISO 639-3 zsk Linguist List zsk A language like French would look like this: ISO 639-3 fra Linguist List fra (And an interested reader could click on to Ethnologue from the ISO 639-3 link) --Taivo (talk) 02:11, 29 July 2012 (UTC) I haven't contested a link to SIL / the ISO page. My suggestions have all included links to SIL/ISO I accept that the 'maintained by' language may be inaccurate despite its use by Ethn. The problem I have with your suggestion is that it implies that [zsk] is the LingList code. (It's listed in the "Language codes" section of the info box.) That is incorrect: it's the ISO code, which is used by LingList. LingList also has their own codes, much like the Linguasphere codes that you've been adding. Sometimes they have two 3-letter codes, one ISO and one of their own; sometimes they have 2 or 3 of their own for the same thing. IMO, we should only list LingList codes under Language codes:LingList. — kwami (talk) 02:23, 29 July 2012 (UTC) My issue isn't that Linguist List does or does not have reference problems with their codes. They use ISO 639-3 codes when they can. List them however you think best except for the way you were doing yesterday, which was replacing the ISO 639-3 link with a Linguist List link. If we link to Linguist List it must be separate from the ISO 639-3 link. That's my point. --Taivo (talk) 02:36, 29 July 2012 (UTC) That's fine by me. However, since I have to make a request, and in this case would be proposing s.t. new rather than just expanding what we already have, I wanted to make sure it wouldn't be a problem. What about placing "(language entry)" after the ISO code? I'm trying to not take up much space. — kwami (talk) 02:54, 29 July 2012 (UTC) I think that we need to label "language entry" as Linguist List. Ethnologue is a "language entry" as well. I don't want to imply that the Linguist List entry is somehow better than any other "language entry". What's wrong with just a simple: "LinguistList" since that is exactly what it is? --Taivo (talk) 04:59, 29 July 2012 (UTC) And on a different line rather than following the ISO 639-3 entry on the same line. We don't want to imply any kind of equal status between the ISO 639-3 code and the LinguistList link. --Taivo (talk) 11:56, 29 July 2012 (UTC) That sounds like what we have now. How would we link to a LingList page without saying it's a LingList code? — kwami (talk) 01:48, 30 July 2012 (UTC) Sometimes it is a LinguistList code and not the ISO 639-3 code, especially if it is for a speech variety that doesn't have an ISO code. --Taivo (talk) 04:50, 30 July 2012 (UTC) There just isn't a graceful way to consistently deal with the LinguistList link. Sometimes it is a unique LL code, sometimes it is an ISO code, sometimes it is a unique LL code even when there is an ISO code. --Taivo (talk) 04:59, 30 July 2012 (UTC) Sure, and that's what we have the LL code entry for. And yes, there is currently no graceful way to link to LL when it's the ISO code. What I'm asking is any prefs on how to accomplish that. I didn't understand your comment we need to label "language entry" as Linguist List. — kwami (talk) 09:20, 30 July 2012 (UTC) I think that maybe there could be a page listing the LinguistList codes, but I am not sure at all that they belong in the language info boxes. There should never be any conflation of the official ISO codes and any other code-lists, however. -- Evertype·✆ 13:31, 30 July 2012 (UTC) Indeed, which is why I'm asking to keep ISO and LL codes distinct. — kwami (talk) 20:44, 30 July 2012 (UTC) Thinking about it further, I think that Evertype is on the right track. The Language Infobox is for "official" information, the ISO code, the number of speakers, the native name, etc., and not for "other references". The Linguist List page is nothing more than another reference, like Ethnologue, and entry in ELL2, etc. It's not an "official" reference. The Ethnologue links used to all be under "References" at the bottom of the page (many are still there) before ISO started including them on its code pages (which is beyond Wikipedia's control, of course). Perhaps the Linguist List links should just be under References at the bottom of each article instead of trying to cram them in the infobox. --Taivo (talk) 14:38, 30 July 2012 (UTC) The number of speakers, native name (usually), classification, and location are not official. The only thing official under ISO is the name and the code, and occasionally a parenthetical location when dab'ing is necessary. For a relatively small number of languages, there is also a governing body or legislation. If we really want to go official, for most languages our info boxes would be reduced to a single name + ISO code, and for many, it wouldn't even have those. If we're not going official, then LL, Lingualist, etc. codes are no more out there than our population data, since often that data comes from their documentation. The Ethn. and LL links are useful to confirm the basics of the language. From what I understand, ISO does not maintain any info on a language apart from its ISO name and whether it's still spoken. Documentation is maintained at Ethn. and LL, or at least that's how they see it. LL is not a further ref so much as a link where further refs are available when Ethn. does not have an entry, as when there is no ISO code. If we want to move Ethn, LL, Linguasphere etc. out of the info box, I suggest we keep the fields, but have them generate footnotes rather than display directly. That would be most convenient for article maintenance. Or we could have a 'documentation' section separate from the code section, which would link to the Ethn. or LL pages. That could be done with a bit of recoding and wouldn't require editing the articles. Since SIL will no longer be operating as the ISO RA, we might soon need to revamp the Ethn. links anyway. — kwami (talk) 20:44, 30 July 2012 (UTC) Where did you get the idea that SIL was no longer going to be the ISO authority? SIL will, indeed, continue to be the RA for ISO 639-3. There's been no change in that. This is still the official home page for ISO 639-3 and there is no indication whatsoever of any change. They said they're updating their web site is all, not changing authority. --Taivo (talk) 21:43, 1 August 2012 (UTC) That's what I was told by the people at LingList when I asked what the confusing wording meant. They said they should probably change it, but since SIL will no longer be the RA, they'll probably just wait. — kwami (talk) 22:59, 1 August 2012 (UTC) There's been no official announcement and no discussion in the linguistic community about it. The RA at SIL is continuing with business as usual (and I have regular communication with the authority concerning change requests). I wouldn't believe some random communication with LinguistList (which is basically just graduate students anyway) unless there is corroborating evidence. --Taivo (talk) 23:03, 1 August 2012 (UTC) I don't know where you get the idea that the LinguistList is just graduate students, Taivo. It's run by Anthony Aristar and Helen Aristar-Dry, both of whom are faculty members, and has a permanent staff of programmers and administrators and faculty, all part of the Institute for Language and Information at Eastern Michigan University. They are major players in the world of language infrastructure, and if you hear something from them, it's almost certainly right. Kaitulai (talk) 16:05, 2 August 2012 (UTC)

Not done: {{edit protected}} is not required for edits to unprotected pages, or pending changes protected pages. And it looks like everyone here is autoconfirmed. Feel free to make the edit yourself if you have consensus. Anomie⚔ 21:04, 1 August 2012 (UTC)

Taivo, I removed support for the LL note in the ISO field. Now adding support for more than 3 links in the LL field. — kwami (talk) 23:39, 1 August 2012 (UTC)

Thanks, Kwami. I was getting tired of doing them individually one by one. --Taivo (talk) 02:28, 2 August 2012 (UTC)

Extracting date year by padleft

8-Nov-2012: To avoid wp:exceeded template limits, I have changed the template to extract the date's year (such as "2006"), to compare < 30, by using function {padleft:...} rather than Template:Str_number/trim. The tactic is to extract the first 4 characters of the date, and check for #iferror on expression #expr, by using:

• {{#iferror: {{#expr: {{padleft:|4|{{{date}}}|}} }}|...then...}}

The prior use of Template:Str_number/trim could not extract the 4-digit year when followed by a reftag footnote ("<ref>...</ref>"), which had caused a year such as "2010" to appear as "20102010201" and then wp:exceeded template limits for the expansion depth of 41/40 levels. -Wikid77 (talk) 01:06, 8 November 2012 (UTC)

New languge

Hi I would like to add another link to the Catalan wikipedia there are to templates to with this but I doint want to remove the other one I would like to add them both please 178.239.50.146 (talk) 20:04, 15 February 2013 (UTC)

update tracking

Need to update tracking cats for E17. I can't do it right now. — kwami (talk) 20:52, 25 February 2013 (UTC)

A tracking category

Currently the template has a tracking category added this way: {{#if:{{{caption|}}}{{{map_caption|}}}{{{rank|}}}{{{country|}}}{{{regions|}}}{{{status|}}}{{{SIL|}}}{{{sil|}}}{{{silname|}}}{{{protolanguage|}}}{{{protoname|}}}{{{child1|}}}{{{child2|}}}{{{children|}}}{{{iso5|}}}|[[Category:Language articles with unsupported infobox fields]]|}} for Category:Language articles with unsupported infobox fields. So when one of the listed parameters is used (has input), it is triggered. After checking the reported pages (for this unused input) it could be deleted. -DePiep (talk) 09:24, 7 August 2012 (UTC)

It was, once, but they came back.

"Caption" is a common error for map/image caption, based on other templates.

"ChildX", "protoname", "iso5" appear when someone adopts a language-family box to a language by removing the "family". This is actually fairly common: Frisian and Tasmanian, for example, are considered both languages and families of languages, and either template could be (and has been) used. When we add or remove the 'family', we don't always succeed in converting all of the parameters.

"SIL" and "rank" are still found in the archives, and might occasionally be resurrected.

Certainly we want to capture "caption" and "children" when they happen. (These are fairly common, and happen repeatedly.) We might as well add a few others. — kwami (talk) 09:59, 7 August 2012 (UTC)

All fine with me. The check list (parameters) can be adjusted as wanted, just add or remove {{{param|}}} (don't forget the pipe). -DePiep (talk) 11:17, 7 August 2012 (UTC)

There's a way of detecting any unsupported parameter, discussed here. No time to figure out how to code it right now. — kwami (talk) 06:06, 21 April 2013 (UTC)

Add which Wikipedia is available in that language

this item

should be displayed in the infobox language.

The idea went to me after recognizing this:

Xhosa wiki, for example.

Task could be done by autoexec user, only. --Ossip Groth (talk) 15:23, 22 May 2013 (UTC)

Australian Institute of Aboriginal and Torres Strait Islander Studies reference

This infobox has suddenly started to produce a reference to AIATSIS with a link to the Australian Indigenous Languages Database. I noticed because it has created cite errors on pages that don't already have a reference template. I can't find any recent change that would cause it to suddenly appear now but the code is

| label29 = [[Australian Institute of Aboriginal and Torres Strait Islander Studies|AIATSIS]]{{#tag:ref|{{AIATSIS|{{{aiatsis|}}}|{{{aiatsisname|{{{name}}}}}}|{{{aiatsis2|}}}}}|name="AIATSIS"}} | data29 = {{#if:{{{aiatsis|}}}|<tt>[http://austlang.aiatsis.gov.au/main.php?code={{{aiatsis}}} {{{aiatsis}}}]</tt>{{#if:{{{aiatsisname|}}}| {{{aiatsisname}}}}} }}{{#if:{{{aiatsis2|}}}|, <tt>[http://austlang.aiatsis.gov.au/main.php?code={{{aiatsis2}}} {{{aiatsis2}}}]</tt>{{#if:{{{aiatsis2name|}}}| {{{aiatsis2name}}}}} }}{{#if:{{{aiatsis3|}}}|, <tt>[http://austlang.aiatsis.gov.au/main.php?code={{{aiatsis3}}} {{{aiatsis3}}}]</tt>{{#if:{{{aiatsis3name|}}}| {{{aiatsis3name}}}}} }}

I don't think this reference should be showing up on every page the infobox is on, it doesn't seem to have any relevance to Hainanese for example, but I don't know enough about coding or languages to tell if its working as it should or if it needs to be changed. Can someone else take a look. Sarahj2107 (talk) 10:29, 7 June 2013 (UTC)

I think I've fixed this. -- John of Reading (talk) 11:56, 7 June 2013 (UTC)

Should ld1....lnN be with wiki link or not?

I have discovered a strange thing in editing Romani language article.

If ld1 ... ld5 are with links, the references for e17 are not created correctly. If they are just as text (without link), they are displayed without a link in the infobox.

See https://en.wikipedia.org/wiki/User:Running/Romani_langbox - "Balkan Romani" is without link, the rest is with links.

Which is more "correct"?

(And now, I see that only 3 references are generated. Also not sure why.) --- Ɍưɳŋınɢ 02:46, 1 September 2013 (UTC)

• I have fixed the issue with more then 3 references. But I am still not sure what to do with the links. --- Ɍưɳŋınɢ 03:13, 1 September 2013 (UTC)

• OK, nevermind, I solved the issue with the references too, by editing Template:Ethnologue15/16/17 to have a word "reference" as the link to the ethnologue, and the name of the language put before that. (It seemed to me as the easiest solution.) --- Ɍưɳŋınɢ 03:43, 1 September 2013 (UTC)

Edit request on 10 September 2013

Change Uralic in {{Infobox language/family-color}} to use lime. There's not enough contrast against black text w/ limegreen. — Lfdder (talk) 11:56, 10 September 2013 (UTC)

And while you're at it, whoever you are, do us a favour and unprotect it. — Lfdder (talk) 11:58, 10 September 2013 (UTC)

In a week's time when this might get noticed, that is. — Lfdder (talk) 12:03, 10 September 2013 (UTC)

I hope whoever's fully protected this one gets to drink PG the rest of their lives. — Lfdder (talk) 12:07, 10 September 2013 (UTC)

the free encyclopedia that anyone can edit my arse. — Lfdder (talk) 12:12, 10 September 2013 (UTC)

Unprotected. This was a good candidate for unprotection given that the main template was only semi-protected - you could have probably just asked at WP:RFPP. (Also, that will be 50p for the swear box. :P) — Mr. Stradivarius ^{♪ talk ♪} 13:11, 10 September 2013 (UTC)

I'll donate 50p extra 'cos I'm grateful. — Lfdder (talk) 13:18, 10 September 2013 (UTC)

includeonly tag mismatches

In the source code, there are three start tags <includeonly>, but only two end tags </includeonly>. But it seems no articles are affected by this bug. Do we need to fix it? Chmarkine (talk) 03:52, 28 January 2014 (UTC)

Never mind. It doesn't seem to matter. Chmarkine (talk) 04:05, 28 January 2014 (UTC)

"Syntax error in JSON"

I tried adding Visual Editor support for the new fields, but couldn't save. I can't see the error. Here's the text:

Extended content

"glotto": { "label": "Glottolog", "description": "The Glottolog code for the language", "type": "string", "default": "", "required": false}, "glottoname": { "label": "Glottolog Reference Name", "description": "The name to appear in the info box and in the Glottolog reference footnote, if the 'name' parameter is not satisfactory", "type": "string", "default": "", "required": false}, "glotto2": { "label": "Glottolog 2", "description": "An additional Glottolog code", "type": "string", "default": "", "required": false}, "glottoname2": { "label": "Glottolog Reference Name 2", "description": "A name for the additional Glottolog code", "type": "string", "default": "", "required": false}, "glotto3": { "label": "Glottolog 3", "description": "An additional Glottolog code", "type": "string", "default": "", "required": false}, "glottoname3": { "label": "Glottolog Reference Name 3", "description": "A name for the additional Glottolog code", "type": "string", "default": "", "required": false}, "glotto4": { "label": "Glottolog 4", "description": "An additional Glottolog code", "type": "string", "default": "", "required": false}, "glottoname4": { "label": "Glottolog Reference Name 4", "description": "A name for the additional Glottolog code", "type": "string", "default": "", "required": false}, "glotto5": { "label": "Glottolog 5", "description": "An additional Glottolog code", "type": "string", "default": "", "required": false}, "glottoname5": { "label": "Glottolog Reference Name 5", "description": "A name for the additional Glottolog code", "type": "string", "default": "", "required": false}, "notice": { "label": "Font Notice", "description": "Set to 'IPA' or 'ipa' to display a notice that the article contains special IPA phonetic symbols, or to 'Indic' to display a notice that the article contains an Indic script", "type": "string", "default": "", "required": false} "notice2": { "label": "Second Font Notice", "description": "Set to 'IPA' or 'ipa' or 'Indic', as above", "type": "string", "default": "", "required": false}

— kwami (talk) 21:23, 23 March 2014 (UTC)

a) you need to wrap the whole thing inside curlies; b) missing a comma before "notice2" — Lfdder (talk) 22:06, 23 March 2014 (UTC)

Glottolog refs

Because they generate named references, if there is more than one box on a page, the glottolog parameter needs to have a different number (glotto, glotto2, etc.) in each box. Otherwise they'll all cross-link as a single ref per page. So currently we can only have 5 glottolog codes per article, not just per box. Since there aren't many articles that need more than this (I can only think of Malay creoles), perhaps we can add a manual field to support the additional boxes. — kwami (talk) 04:17, 22 March 2014 (UTC)

Because these generate references, they necessarily pick a reference style, but this may not match the style used elsewhere in the article. For example this is annoying when an article uses only short references, and so has narrow columns in a {{reflist}}. How about just making the code an external link, as is done for |iso3= and |linglist=? Kanguole 00:05, 14 April 2014 (UTC)

Linked now, add '|glottofoot=no' to the infobox to hide the footnote. — lfdder 00:35, 14 April 2014 (UTC)

For maintenance categories: using main other

Kwami asked to prevent templates &tc. showing up in maintenance categories. [8]. At least three (sub)templates are working with this category:

• {{Infobox language}}, {{Infobox language/genetic}}, {{Infobox language family}}.

I simplified by using {{main other}} for all maintenance categories in these three templates. Some 50 checks are performed, and that is {{infobox language}} alone. No actual checks (the logic) are changed, no category name has changed. Only whether a page is categorised or not has changed. Unfortunately, for now there is no test-option for non-mainspace pages (draft, sandbox).

-DePiep (talk) 14:20, 7 May 2014 (UTC)