Template talk:Infobox language/Archive 5
This is an archive of past discussions about Template:Infobox language. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
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 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)
- 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)
- 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)
- 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)
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
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
- 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.
- Note on returning
- 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 enterfamilycolor=unclassified
orfamilycolor=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)
- 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
- 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)
- Found it. This is where it goes strange: when any
- Yes we can. So, you say, there is input like
Edit request (18 March 2012)
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
- 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).
- 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
- 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 thefamily=
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)
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
| ||
---|---|---|
|
- 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)
- 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)
- 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)
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 [when?] (or maybe [year needed], [time needed], [date missing]). And when the whole reference wrt speakers is missing, there is [citation needed]. 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)
- No, it's not OR, it's just an indication that the data is old. — kwami (talk) 04:06, 31 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)
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)
- 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)
- 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)
- 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)
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
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)
- 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)
- 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
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your 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
|
---|
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:
or maybe 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)
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)
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)
|
- 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)
- All fine with me. The check list (parameters) can be adjusted as wanted, just add or remove
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://wiki.riteme.site/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
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
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)
- 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)
- the free encyclopedia that anyone can edit my arse. — Lfdder (talk) 12:12, 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)
- In a week's time when this might get noticed, that is. — Lfdder (talk) 12:03, 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).