This is an archive of past discussions. 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.

It has come to my attention that SIL's classification is not always accepted by some native linguists of some languages. Could it at least be mentioned that the classification is not "definitive" but SIL's or from any other resources?--- moyogo 04:25, 11 November 2005 (UTC)

I felt I had to flag up a major edit to the template. I have re-added two proposed sections: 'ISO/DIS 639-3' and 'Pronunciation'. I am not sure if the latter will work, but its worth adding if the main objection has been overcome. My attention was drawn to a new possibility with templates: we can now define a default for a parameter. The syntax is {{{parameter|default}}}. This allows us to add a new parameter and then define it in each article. In the past, we have had to work the other way round. Thus, the {{{rank}}} parameter now has the default text: not in the top 100. This text has been added by hand into most articles, but does not need to be any more. I hope this is a step in the right direction. -- Gareth Hughes 14:12, 11 November 2005 (UTC)

Linking directly to Ethnologue in the template is probably not a good idea. The main problem is that some languages will have multiple ISO 639-3 codes (each covering a separate dialect of the language). Therefore, the parameter string will be a list of codes, which cannot be plugged into a single URL. -- Gareth Hughes 15:11, 11 November 2005 (UTC)

• we can have params unique-iso3 and multiple-iso3. the unique-iso3 can have the link, the other goes without.
• for mulitple codes we can use a template, e.g. insert the template three times, asume the codes are aaa,aab,aac: {{iso639_3_link|aaa}} {{iso639_3_link|aab}} {{iso639_3_link|aac}} any problems? Tobias Conradi (Talk) 15:49, 11 November 2005 (UTC)

I've added {{{pronunciation}}} and {{{iso3}}} to Arabic language as an example (note the ISO 639-3 code differs from SIL14). The first point above — using a different variable for multiple-coded languages so that unique codes can link to Ethnologue — would work. The multiple parameter could default to nothing. However, incorporating mini-templates for each language code in the multiple parameter may be tricky. I came across real problems with this when I last worked on the modular template proposal. The problem was that parameter strings were not carried through every level of the template. However, the new default settings might make the implementation of this easier. Can I try a mock-up of the syntax to see if it will work? -- Gareth Hughes 16:37, 11 November 2005 (UTC)

Based on your edit at Arabic language I've been adding the native pronunciations of languages in the "pronunciation" field (e.g. ˈgeːlʲgʲə nə ˈheːrʲən at Irish language, kəmˈrɑːɨg at Welsh language, ˈkɑːlʲəkʲ nə haˈɫapə at Scottish Gaelic language, ˈɪŋglɪʃ at English language, dɔytʃ at German language, and fʁɑ̃sɛ at French language. I hope this is what this field is intended to convey; if not, let me know and I'll change them to ˈaɪɹɪʃ, wɛlʃ, ˈskɑtɪʃ ˈgælɪk, ˈɪŋglɪʃ, ˈdʒɝmən, and fɹɛntʃ. -- Angr/ _{tɔk tə mi} 01:20, 12 November 2005 (UTC)

Hi. I've removed the {{{pronunciation}}} section because I don't really think it's necessary. First off, some people might have that for the "native name" section. Also, what's the point? -- Hottentot

I agree that it may not be needed. However, I have seen a few places where it has been asked how the name of a language should be pronounced. {{{nativename}}} should be the languages own name for itself, in native script if possible. I see that parameter as being very different from <{{{pronunciation}}}. It is significant that Hertevin language, Tigrigna language and many others are not pronounced as they are written. This is valid and useful information. I think that we should think of some way to provide IPA help to Wikipedia users. -- Gareth Hughes 16:35, 12 November 2005 (UTC)

I still think it takes up too much space. Should we have some sort of vote? -- Hottentot

I've been talking to my template guru ( SEWilco) who has been showing me some of the hidden mysteries of templates. I used {{ if}} to include a link to a language's Ethnologue entry if an ISO 639-3 is defined. You'll see that Arabic language has a link, whereas Afrikaans doesn't (it hasn't been added yet). Now that I've discovered how to do that, I'm going to have a look at the modularity proposal again. This will make the majority of instances of the template much shorter (i.e. the 'official' bits will be automagically removed when not needed). Can we leave the 'pronunciation' issue dormant for a moment, until the template's full flexibility has been tested? -- Gareth Hughes 20:53, 12 November 2005 (UTC)

can ISO 639-3 talk be kept in the ISO 639 section? Tobias Conradi (Talk) 12:37, 13 November 2005 (UTC)

I've just made the template collapsable. If {{{nation}}} is left undefined in an article, the 'Ranking', 'Official language of' and 'Regulated by' rows will automatically disappear. Therefore, if a particular language doesn't use these parameters, just leave them out, and the template will automatically simplify itself (see Koy Sanjaq Surat for a collapsed version). I've tested this in a few places, and it seems to be working fine. You can see {{ language/one}}, {{ language/two}} and {{ language/official}} as the sub-templates that are now called, or not, by the main template. I'm not sure if I can explain how it works: I hardly understand it myself. I hope the newly collapsable version doesn't caus any problems, and meets with general approval. -- Gareth Hughes 23:44, 12 November 2005 (UTC)

I noticed on Abkhaz language, that there's this extra space right above the Not in top 100 section. I was wondering if there's any way to remove it. Thanks. -- Hottentot

I see that you and Tobias have had a look at the new template design. I should try to write down how it works, because it is complex. The extra space has probably been called by {{ language/official}}. I shall have a look at it, to see what might cause the problem. As you have probably noticed, the {{{iso3}}} parameter can only be a single code entry or nothing at the moment (don't try iso3=, as that will create a link to Ethnologue). The next stage is allow a list of ISO 639-3 codes. Until we have found an easy way to do that, it is best not to implement the linking feature to the {{{sil}}} parameter, as most article already define it. If you feel that any occurrence of the template could do without the 'official' section, just remove the {{{nation}}} parameter, and the template will remove the entire section. -- Gareth Hughes 13:07, 14 November 2005 (UTC)

OK. I've sorted the problem of the extra space. In the {{{family}}} parameter, the last line gives the name of the language in bold. This should not have a <br> tag at the end, as this creates unneeded white space at the bottom of the cell. I think the old version of the template was ableto ignore this mistake, but the new one isn't able to ignore it. If yoy see white space, delete the last <br> tag. -- Gareth Hughes 13:19, 14 November 2005 (UTC)

I highly appreciate the work you're doing, Gareth! I have a question. I don't think we should tie the 'Ranking' thing to the national or official status of a language. There are languages which have enough speakers to enter into some ranking and yet are not official languages (the Northern Berber languages of Morocco would be an example, I suppose). On the other hand, there are also languages that do not have that many speakers but still are the national or official language of one or another country; Temne language, for example. Why not make the 'ranking' parameter fully optional? — mark ✎ 14:28, 15 November 2005 (UTC)

I had thought of that, and it would be possible to have the ranking element appear/disappear depending on whether its parameter is defined or not. I linked it with the official module because the two generally run together, but, as you have pointed out, this rule has very many exceptions. I think this is a good case to separate the two. I'll have a go at it. -- Gareth Hughes 14:49, 15 November 2005 (UTC)

OK. That wasn't too difficult. If the {{{rank}}} parameter is not defined in the article, that line disappears. This happens independently of whether the official section is used or not. -- Gareth Hughes 15:16, 15 November 2005 (UTC)

Some languages which lack ISO 639-2 codes of their own have instead a general code like aus (Australian languages) or afa (other Afro-asiatic), following Ethnologue 14. But is this appropriate? -- Ptcamn 18:23, 14 November 2005 (UTC)

What would the answer to your question help? Do you want to convince ISO to change their codes? IMO Wikipedia should take this as given. Furthermore the ISO 639-3 codes change the situation for lots of languages Tobias Conradi (Talk) 13:48, 15 November 2005 (UTC)

The latest addition is what I call the 'family array'. It is an easier way to enter information into he 'Genetic classification' box. The traditional method of entering text into the {{{family}}} parameter still works. Therfore, if there is anything that doesn't fit the new system, you can still use the old one. The problem with this old system was that you had to type the formatting (<br>&nbsp;) into the parameter on the article page. I've now added that formatting into the template, so that you do not need to add on the article page. In the new system, the {{{family}}} parameter is not used. Instead, you add the following to the template call in the article:

|fam1=top level language family
|fam2=next level down
|fam3=next level down again

I've set up the template to accept parameters up to and including {{{fam10}}}. More levels can be added if needed. In this system, the last |famn= is the most immeadiate language group to which a langauge belongs: you do not write the name of the language itself in these parameters, that is added automatically. If you want any of the parameters to link to an article about a language family, you simply type:

|fam8=[[language family]]

I'm working on using a similar system to allow us to incorporate lists of language codes. -- Gareth Hughes 12:04, 15 November 2005 (UTC)

You can see the new system in action in Abkhaz language ( Talk · history · watch) and Syriac language ( Talk · history · watch). -- Gareth Hughes 12:20, 15 November 2005 (UTC)

can the leading space(line) be removed? Tobias Conradi (Talk) 13:45, 15 November 2005 (UTC)

I don't see anything, which article are you looking at? -- Gareth Hughes 13:49, 15 November 2005 (UTC)

Can dialects be included to use the template? Some also have 639-3 code because in ethnologue they are regarded as language. Tobias Conradi (Talk) 13:45, 15 November 2005 (UTC)

I've just shelved {{{iso3list}}} and replaced with an array of parameters that allow you to enter a list of languages/dialects with their ISO 639-3 codes. If you want to use more than one ISO 639-3 code, leave out {{{iso3}}} (which is used for entering a single code), and use the format below:

|lc1=aaa|ld1=Ghotuo|ll1=Ghotuo language
|lc2=bbb|ld2=Barai|ll2=Barai language
|lc3=ccc|ld3=Chamicuro|ll3=Chamicuro language
|lc4=ddd|ld4=Dongotono|ll4=Dongotono language
|lc5=eee|ld5=E|ll5=E (linguistics)
|lc6=ggg|ld6=Gurgula|ll6=Gurgula language

In this format, lc stands for 'language code' (the ISO 639-3 of that language/dialect), ld stands for 'language dialect' (the name of the language/dialect to appear in the infobox) and ll stands for 'language link' (Wikipedia's link to an artcle on the language/dialect). The lc will automatically link to the Ethnologue page. The ll parameter does not have to be defined if the link is the same as the contents of ld. Each language/dialect is automatically linked, on the basis that we want an article about each of them. However, I'm not sure if this is wise, and I'll put in a workaround for unlinked languages/dialects if needed. I hope you like it! -- Gareth Hughes 14:04, 15 November 2005 (UTC)

For example purposes, Syriac language is using the list of ISO 639-3 codes now. As you can see, continuing to include all the SIL14 codes makes a little cumbersome.

I would ditch the SIL14 codes altogether. It is not Wikipedia's job to provide a mapping from SIL14 onto SIL15/ISO3. Besides, Ethnologue itself does it already and in doing so quite explicitly notes that the old coding system has been superseded (see [1]) — mark ✎ 17:48, 15 November 2005 (UTC)

To complicate matters: I have seen quite a few articles where the SIL14 code in the template has been updated to the SIL15/iso3 code. What to do with these? — mark ✎ 17:54, 15 November 2005 (UTC)

I'm all for ditching the SIL14 codes. The spot for the ISO 639-3 codes is now obvious, so I hope people will start filling it in. I see this as a transitional period: we add ISO 639-3 codes for a little while, and then remove SIL14 from the template (we don't have to remove the codes from the articles). The information is still there, and we can carry on adding ISO 639-3 codes until it is done (is it ever done?). -- Gareth Hughes 18:11, 15 November 2005 (UTC)

I would not oppose if they where ditched today. Garzo good work! I inserted code-tag to make the codes all same length and thus align better. mdash is quiet long isn't it? maybe use "-"? Another prob: if this is a language template, how can there be links to multiple WP-language-articles in the code section? Either the template is used for a language-collection (Syriac) or Syriac is a language and then the sub-"languages" are dialects. Tobias Conradi (Talk) 10:51, 16 November 2005 (UTC)

Thanks, Tobias! We could ditch SIL14 codes right away: I don't think anyone would miss them, and it would be an encouragement to get the ISO 639-3 codes in the infobox. I originally had just a space between the code and the name of the dialect in the code list, and I added the m-dash to spread it all out a little more. I agree that with a very long name the line could get too long. I really just wanted to avoid squashing the name up against the external link symbol. On the last point, I think the Chinese language infobox is a case in point. The WP precedence is that we do not make sharp distinctions between language and dialect, or between different level of (sub-)families and (sub-)groups. Where there are multiple ISO 639-3 codes, a language may have several dialects, which may be considered languages in their own right. -- Gareth Hughes 12:15, 16 November 2005 (UTC)

I've added in some more flexibility to the template today, so here's the 'heads-up'. As mentioned above, the template is now suitable for sign languages. You use {{{signers}}} instead of {{{speakers}}}, and the template automatically sets itself up for a signed language. It also sets the coloured bar to silver.

You might not be into constructed languages, but the template can be used for them also. Two new parameters are used for conlangs: {{{creator}}} and {{{setting}}}. The former replaces {{{states}}}, and is used for naming the creator and date of creation of the conlang (it also automatically makes the coloured bar black with white text). The other new parameter replaces {{{region}}}. It is purposefully vague, and can contain geographical inforamtion, original intention for creating the language or its use in literature.

The new parameter {{{extinct}}} can be used instead of {{{speakers}}} to replace that field in the infobox with information about language extinction. This would usually be the approximate year of extinction, but could contain other information. This allows the template to be used appropriately for long-extinct languages.

I hope you like these new possibilities. I've included information on all parameters at the top of this page. You can see an example of each of these new types of template in the following three articles: Auslan, Esperanto and Akkadian language. -- Gareth Hughes 22:43, 16 November 2005 (UTC)

It seems that the infobox for all the Unclassified languages (that use the color #dddddd) got all messed up. What happened? See example here. -- Hottentot 01:12, 17 November 2005 (UTC)

I've changed the colour coding for isolate to lightgrey. For some reason the template has difficulty coping with #, and I didn't think of testing it with isolates. I'll have a look at the template, and see if I can see what was causing the glitch. Otherwise, I think this is a reasonable replacement. -- Gareth Hughes 01:34, 17 November 2005 (UTC)

Not really. lightgrey and silver almost identical. Is there a better color we can use? -- Hottentot 01:41, 17 November 2005 (UTC)

You could use gray (that's quite distinct), or look at web colors. The # does something very odd to the syntax: something that I didn't expect. -- Gareth Hughes 02:22, 17 November 2005 (UTC)

Thanks. I looked at web colors. It turns out that gainsboro is apparently identical (or very, very close) to #dddddd, so I'm going to switch to that from lightgrey. -- Hottentot 03:14, 17 November 2005 (UTC)

The # sign at the beginning of the parameter definition is treated as the wiki mark-up for an item in an ordered list. The simplest workaround is to use <nowiki>...</nowiki> tags around the hexidecimal code. However, using colour names rather codes might be the easiest all-round solution. -- Gareth Hughes 21:58, 18 November 2005 (UTC)

The {{Ido language}} has a section for a seal or symbol of a language that we've been using and the new template doesn't have that which made the Ido page look a bit worse, and I reverted it. I would try putting it in myself but this big template scares me and I don't want to mess around with it. Mithridates 03:30, 17 November 2005 (UTC)

I think I remember Mark wanting an option for placing a language map at the top of the infobox. I'll put in a sub-template that can add this in. I'll keep it flexible, so it can be used for various purposes. -- Gareth Hughes 11:23, 17 November 2005 (UTC)

OK. I've just updated Ido with the new sub-template. If you want to look at the innards, they're at {{ language/image}}, and are called into play by {{ if defined call2}} in the main template. The practical side of things are the parameters: {{{caption}}} places text in the left-hand column (e.g. 'Seal' or 'Language map'), and {{{image}}} defines the image using normal image mark-up (the template doesn't do anything fancy for you). These two parameters could be used to add anything as a new top line to the template, so it's very flexible. -- Gareth Hughes 11:58, 17 November 2005 (UTC)

Yeah, long time ago, I had a map incorporated into the infobox at Nafaanra language, but I separated it at the first redesign of the language template (check out Laal language for another example). Mustafaa, I believe, has kept using the old template, with incorporated map, on some articles. And indeed, the best use for such a feature, if it is introduced now, would be for maps. I would prefer the bottom of the infobox for that, however. — mark ✎ 12:00, 17 November 2005 (UTC)

I just tested this at {{ Nafaanra}} (see this revision) but I don't think it's going to work; the place is too small for a map. It would be better if the map were at the bottom, if it could span the two columns and if it could have a caption like normal thumb'ed images have. But even then, I'm not sure; sometimes maps need to be broader, or sometimes they're ridiculously long (what about this one?). Maybe we should just keep it distinct from the template. — mark ✎ 12:09, 17 November 2005 (UTC)

There will always have to be some limits of size so that the infobox doesn't get overburdened. I've implemented {{{map}}}, which does exactly what you asked for. You can see an example at {{ Nafaanra}}. By the way, are you going to subst this into the article now? -- Gareth Hughes 12:56, 17 November 2005 (UTC)

Thank you! And yes. Back then I had the feeling that Google didn't index the first paragraph of articles properly when it started with the language table gibberish, but in retrospect I don't think that was the reason. It's still a mystery to me how Google chooses the description it shows in the search results though. — mark ✎ 13:23, 17 November 2005 (UTC)

I hope you're all enjoying the changes I've made to the template over the last few days. They were all mostly things that we had been wishing for for a while. I think there are three issues that we'll want to deal with in the near future:

1. Pronunciation: Do we want to have the pronunciation of the name of the language in the template? I feel a bit ambivalent about this one.
2. Writing system: There wasn't much discussion, but this has been mentioned before. I feel that if we want to add writing system to the infobox it should not be an opt-out thing: you can have too much flexibility.
3. Dropping SIL14: I think this is more of an issue of when do we do it, rather than if. If the row is removed from the master template, the parameters in the articles just remain as dummy calls.

Looking at this template's equivalents in other-language Wikipedias, they mostly follow the pattern here. However, there are a few different styles we might be interested in.

• The German and Esperanto templates divide up the ISO 639-2 code field to allow for the seperate bibliographic and typographic codes at that level. We could write a subroutine to allow such a setup if required. Therefore, unlike these templates, one had to opt into the split field.
• The Spanish version explicitly allows for first- and second-language speakers on seperate rows in the 'speakers' field. I think I would prefer the flexibility we have at present, rather than forcing this layout.
• The Italian and Polish templates incorporate those little template links to Wikipedia version in that language and Unicode information. At present, these things just tend to float around with the template.
• The Portugese version, as well as having a little section for links and notes at the bottom (and possibly being the most aesthetically pleasing) has space for the writing system to be added.

There are some interesting things to look at there. Do you think we should develop the possibility of using the template with reconstructed proto-languages? Also, we might want to think about how we organise the colours for creoles and pidgins. -- Gareth Hughes 02:26, 19 November 2005 (UTC)

• i would like colors depending on fam1 (no need to have color in mind and have future color flexibility).
• Don't care about B/T codes.
• add writing system(S!)
• drop SIL now
• allow pronounciation file.

Tobias Conradi (Talk) 07:28, 19 November 2005 (UTC)

• What about {{ IPA notice}}? I think it would make sense to incorporate it into {{ language}}, as we intend every language article to use IPA transcription eventually.
• I agree with Tobias: drop SIL 14 now.
• I don't know how easy or difficult it is to automagically pick the famcolor depending on fam1, but if it is possible it would be a really good idea. It would be an immense help for maintaining the colors and for keeping them consistent throughout Wikipedia.

— mark ✎ 10:25, 19 November 2005 (UTC)

Thanks for the feedback, guys. You both mentioned dropping SIL14, so I think I'll just be bold and do it. By the way, the change of link address really help: I think it was Novial language where there was an ISO 639-3 code that Ethnologue just wasn't interested in. The automation of colours is something that had crossed my mind. I saw that someone decided that tomato/pink colours should be swapped (for some strange reason), and it's a lot of work to do a colour change manually. As {{{fam1}}} is currently set up to be a wikilink to the top-level language family. If this parameter, or, perhaps easier, a newly defined parameter were used to define the family colour, the in-article definition would have to be spot-on: one would have to write Afro-Asiatic, and not Afroasiatic, Afro-asiatic, Afro-Asiatic languages or any other variant spelling. I think that remembering this is as easy as remembering yellow. Using the parameter in this way would also force the article to display the parameter's information exactly, abandoning the flexibility we have at the moment. I would like to see a proposal of how this might work. Incorporating the {{ IPA notice}} shouldn't be too difficult. It'd probably have to change shape to match the infobox, and it might replace the rather vague language links at the bottom. I'll have a try at providing a split row for ISO 639-2 B/T codes: it'll have to be optional anyway. Providing a row for a writing system shouldn't be a problem, but sign languages will probably want to opt out automatically. The pronunciation row can be un-commented whenever we feel ready for it (opt out for sign languages again), but we could do with a decent explanation about what we expect from it in the usage section above. -- Gareth Hughes 17:55, 19 November 2005 (UTC)

for me it's easier to remember the writing "Afro-Asiatic" etc. (capital, hyphen) than the colors. Isn't is good to force people in one writing (for fam1). I would also like to have "Afro-Asiatic" instead of Afro-Asiatic languages. It could be expanded automaticly? (Same structure for all fam1?) But maybe this is asked too much. Can we get rid of the language name in the classification? Isn't it clear that at the end the language itself follows? Tobias Conradi (Talk) 19:00, 19 November 2005 (UTC)

I've added a few little tweaks here and there. SIL14 has gone, and you can now define the B/T codes for ISO 639-2 in seperate fields (side by side). The {{ IPA notice}} has now been placed as a footerin the template. However, there are two possible variations: one is to replace this with {{ IndicText}}, the other is to replace it with a sign language footer (I felt IPA may not be relevent). The IPA notice is the default, but sign language defalts automatically change this to their own footer. The Indic one has to be specified with |notice=Indic. Although Indic text articles are also likely to use IPA, Indic text often presents more difficult display problems. Let me know if there are other modules needed: we might want a 'no notice' possibility. I'm not sure I like the colour of the notices: I simply transferred the colour of the existing notices across. I'm working on introducing a new parameter, {{{fam}}}, which would automatically define {{{fam1}}} and {{{familycolor}}}. It would be difficult to use an existing parameter, because it has to be very strictly defined. I'm having a bit of difficulty working out which way round the defaults should go at the moment. -- Gareth Hughes 13:07, 20 November 2005 (UTC)

tried to delete the IPA color. I prefer pure white or whatever the bgcolor in the page is. suggest: use familycolor, allow for colors and groups. if familycolor=limegreen (show limegreen) if familycolor=afroasiatic (show colorname). for each groupcolor and each groupname an include has to be designed that give the color value. SEWilco used such a technique. Tobias Conradi (Talk) 16:20, 20 November 2005 (UTC)

Tried? You've done it: you might just need the browser/page to refresh. I'm a bit sceptical about using the same parameter. Which template did SEWilco use this technique on? -- Gareth Hughes 16:51, 20 November 2005 (UTC)

• I'm in favour of having pronuncation of the native name. For me it's important to be able to say the native name correctly. I can't do that if it's only in a script I don't know (eg Tigrinya language) or even in Latin but with a language-specific use of the alphabet (eg Hungarian language). Also it helps to assert the primacy of speech over writing, and can be used when there is no writing system.
• A standard system of recording number of first and additional language speakers would be good. I suspect that the figure for most languages is the first language speakers rather than really the total.
• A standard option of removing may from the IPA notice would be nice - it sounds odd on a page where you know very well that it is in use. Gailtb 22:40, 22 November 2005 (UTC)

Also a comment about the rank - the list which is linked to above doesn't actually have any numeric ranking. That's going to make it frustrating to get the ranking for a language which is not right near the top. Wikipedia:WikiProject Language Template points to a totally different list. (It also has a different usage for "region".) When the edits settle down, a bit more help /guidance /consistency for us mere mortals could be useful. :-) Gailtb 23:14, 22 November 2005 (UTC)

I really don't know about ranking. My main interest was making that part of the infobox optional. The Swahili article interestingly uses rank to mention that it is the third most-spoken first language in Africa. The states/region thing has been unclear for a while. I beieve that the original idea was to make the first field purely for sovereign states, and to have the second field specify where within that state the language is spoken. However, with widespread languages, it is often more convenient to make the second field describe the larger geographical area, with the first simply listing the countries covered. I think your idea about numbers of speakers is good. I think we should go for a two-way split, first/additional language. This could be programmed into the template as an option, while still allowng the more vague single field to be used. I also think that the general wording needs to be tightened up. Good calls all. -- Gareth Hughes 23:46, 22 November 2005 (UTC)

It looks like every article that has uses a space in-between the template code and the 1st paragraph gives the article an extra white space at the top of it, such as in Adyghe. Is there any way to get rid of it? -- 67.160.197.22 20:46, 19 November 2005 (UTC)

It is not a problem with the template. The problem is with the way the template was implemented in that article. I've corrected and updated the page. -- Gareth Hughes 21:02, 19 November 2005 (UTC)

But then that means that you have to have the template code and the 1st paragraph right next to eachother without a space between them. that's not how it used to be. -- 67.160.197.22 22:22, 19 November 2005 (UTC)

SEWilco used "array" technique in Flag template(s). Something about template array is written at Wikipedia_talk:WikiProject_Flag_Template#country_shortname_alias_xxx maybe he knows more. I think we need two templates for each group, one that is called by color the other by groupname. But both containing a color. I think we cannot do

if param1=darkgreen then darkgreen
elsif param1=germanic then darkgreen
elsif param1=lightgreen then lightgreen
elsif param1=roman then lightgreen

Tobias Conradi (Talk) 17:07, 20 November 2005 (UTC)

I see what you mean. I set up a similar array a while back for {{ hiero}}. The array is in place now, but I haven't switched it on yet. The old problem of #dddddd has come back. Now we have to remove the nowikis, or, better still, replace it with Isolate. I'll switch it on, and they'll all go white until fixed by hand. The table shows how the array works. -- Gareth Hughes 23:27, 20 November 2005 (UTC)

The arrays are now in the main template, and all seem to be functioning properly. The only glitch is the expected problem of language isolates appearing white. You can now set {{{familycolor}}} to any of the names in this table, rather than to a colour. -- Gareth Hughes 00:21, 21 November 2005 (UTC)

cool! This really helps (at least me, if I add the template to new languages). can we insert the color-overview somewhere more easily to reach? The Language family article starts prominently with a map but the legend is unreadable. Can we use the color templates in the lang-article? Tobias Conradi (Talk) 10:01, 21 November 2005 (UTC)

I've compacted the array into a single template: {{ language/familycolor}}. Any changes there take effect across the project. You can call the array from outside of {{ language}}. If you want to call the colour for a Papuan language, the syntax is {{language/arraysort|familycolor|Papuan}}, which returns {{language/arraysort|familycolor|Papuan}}. I chose the long syntax because it means we can use the very handy {{ language/arraysort}} to set up other arrays. I hope this is sufficient information about how this works. Ask if I haven't explained any of it right. -- Gareth Hughes 16:04, 21 November 2005 (UTC)

Honduras Sign Language - I only filled in few variables. e.g. no speakers. The tmp is broken right now. Tobias Conradi (Talk) 10:22, 21 November 2005 (UTC)

The sign-language version of the infobox relies on {{{signers}}}, and if that's defined, you don't have to set {{{familycolor}}}. The problem is that the footer notice for sign languages is currently residing at {{ language/Sign}}. I'm just going to move this now to stop this glitch happening: I just didn't think anyone would find it overnight! -- Gareth Hughes 11:46, 21 November 2005 (UTC)

This template has really improved in the past few days, but I was wondering what we should do about the color of Unclassified languages. Unclassified language articles using an infobox are Jalaa, Laal, Ongota, and Shabo. Jalaa & Laal formerly used #dddddd, which is incorrect because #dddddd is for Language isolates. My suggestion is that we use the color white. What does everyone else think?

Another issue is about the Chukotko-Kamchatkan languages. All those articles currently use #dddddd, but none of the languages are isolates. We need to find a different color for those languages. -- Hottentot 22:24, 21 November 2005 (UTC)

Using white for unclassified languages is OK, I think. — mark ✎ 08:04, 23 November 2005 (UTC)

White is the default colour. If the value of {{{familycolor}}} is anything not listed in the array, it should come out white. Local settings might override this, so it can be forced by either not defining {{{familycolor}}} at all, or by setting it to 'Default' (which does the same thing). I've expanded the list in {{ language/familycolor}} a little, to allow for various spelling variations (e.g. 'Na-Dene' and 'Na-Dené' can both be used). I think it's good to remember that the colour coding we are using is often more stylistic than scientific. Some colours represent fairly well established genetic language families, albeit with ragged edges. Other colours simply represent areal classification, where no genetic relationship can be proved. Still others represent languages by type (sign and constructed languages). The #dddddd category has often been used as a catch-all. Should we place a language in that category if there is a reasonable hypothesis that it is not an isolate (Japanese and Korean)? Are isolates unclassified languages, or have they been classified as classless? The latter is the scientific approach, but, in practice, many language isolates are still open cases. There was the initial idea not to use too many colours. Thus, a huge, diverse language family uses the same colour throughout. I think we should be very careful about introducing new colours into the scheme. However, this does raise the question of what we do with very small language families, like the Chukotko-Kamchatkan languages. In other cases, a non-genetic classification is used (e.g. the light blue of American languages), so we could cautiously introduce a colour for Palaeo-Siberian languages. Further problems arise when we try to choose a colour for a pidgin or creole language. Well, there are lots of issues. It might be better to take these over to WikiProject Languages. -- Gareth Hughes 11:06, 23 November 2005 (UTC)

yes. colors to the project. Maybe a subpage there, so I can only watchlist the colorpage. Tobias Conradi (Talk) 16:29, 23 November 2005 (UTC)

First I want to say a big THANKYOU to garzo for all the work improving the language templates. Second, I want to propose a small change: the default parameter for the "family" with sign languages is currently fam1="sign language". I would rather the default was family="unknown" and fam1 set to nothing. Most contributors to this page will be aware that sign languages emerge naturally in communities with deaf people, and are not all related to each other; however the notion that sign language was invented by someone and spread around the world is a persistent myth. Even the 'family color' classification scheme is, for the most part, about 'genetic' groupings of spoken languages, whereas for sign languges the "family color" actually refers to the primary mode of the language (signed) rather than whether they are language isolates, or belong to a group of related languages, etc — although I am not proposing changing the color scheme, just the default parameter.

Thirdly, I'm still not convinved we need a seperate category for "spoken in" and "region". Look at English language, for example. What is the "region" setting but a duplication of the information already in the "spoken in" category? Similarly for Chinese language. At the other end of the spread of languages, have a look at Ojibwe language, for example, which is "spoken in" Canada and the US, and the "region" is "in Canada, blah blah region and in the US, blah blah region". Again, I can't help but feel that one of these categories is redundant (in this case, the former). Can't we just merge these two potentially confusing categories?

ntennis 02:41, 23 November 2005 (UTC)

Thank you. I'll alter that default right away. I would propose that the solution to this problem with 'states'/'region' would be to make 'region' optional in the same way that 'rank' was made optional. Thus, if a language's infobox doesn't want it, it doesn't have to have it. On the other hand, the more options there are, and the more flexible the template becomes, the less it looks like a unified style across the project. -- Gareth Hughes 11:15, 23 November 2005 (UTC)

I think it is advisable to keep providing more specific information on the location and distribution of the language; it's not enough, I think, to just mention in which state(s) it is spoken. Therefore, I think merging the two is more sensible than just making region optional, even though it will require more work in adjusting individual articles. We could have a transitional period in which 'region' is optional while the details instead are being added to 'states'. — mark ✎ 10:40, 25 November 2005 (UTC)

I've introduced a new sub-template at {{ language/statesregion}}. This is how it all works:

1. If {{{states}}} is defined, then the first row displays 'Spoken in: {{{states}}}'.
2. If {{{states}}} is not defined, then the first row displays 'Spoken in: {{{region}}}'.
3. If neither {{{states}}} nor {{{region}}} are defined, then the first row displays 'Spoken in: —'.
4. If only one or other of {{{states}}} and {{{region}}} is defined (XOR), then the old 'region' row is skipped.
5. If neither or both of {{{states}}} and {{{region}}} are defined, then the second row displays 'Region: {{{region}}}'.

For sign languages, the same process occurs, but 'Spoken' is changed to 'Signed'. For conlangs, the two rows are always displayed with 'Created by: {{{creator}}}' and 'Setting and usage: {{{setting}}}' instead. I've run some simple tests, and it appears to work well. Let me know if there are any glitches. -- Gareth Hughes 16:31, 25 November 2005 (UTC)

This is a small issue that can wait until bigger issues are resolved but I'll put it here now so I don't forget. It seems that the template is triggered into sign language mode in one of two ways: by assigning a value to the "signers=" parameter or by familycolor=sign. Oftentimes even an estimate of the number of signers is just not possible — but when familycolor=sign and no "signers=" value is assigned, it seems that the family is still given as "sign language" rather than "unknown".

Also, I don't know how easy it is to make a further change, but if it's not too tricky I would prefer the when the family is unknown to just have the text "unknown" in the infobox, not "unknown" followed by the language name. (see German Sign Language for example). Thanks! ntennis 01:33, 17 January 2006 (UTC)

That's what I really like! you can define familycolor and don't need to assign any genetic value - you already get the main class. I found this out lately when adding new stub articles. I lately only filled in region and left out state. I think the two should be merged. Tobias Conradi (Talk) 03:20, 20 January 2006 (UTC)

Have made some boolean templates that you can use if you feel to (might render the code easier), see Category: If Templates for syntax -- AzaToth ^talk 12:24, 23 November 2005 (UTC)

Thank you for letting us know about these. Although in some places they might reduce he syntax, in others they would increase it, as these return a generic true/false response, whereas the if-routines in the template are prepared to return specific responses. -- Gareth Hughes 13:11, 23 November 2005 (UTC)

I particularly like the way that {{ booleq}} works: very clever! I can see a couple of uses for this and {{ boolor}}. This is timely, as I was just about to rewrite the {tl|language/official}} call routine (I had made quite a mess of it, and much of it is redundant), the boolor routine would fit beautifully into the new call routine. -- Gareth Hughes 13:29, 23 November 2005 (UTC)

I made them to simplify creation of logical templates, I understand that it can be hard to rewrite a big template like this, but they are ment to be in aid of the creator (It might reduce the esoteric look on the template). the {{ booleq}} isn't exactly a boolean operator, but it returns a boolean so I call it a boolean operator :). I came up with the idea, when I thought "can I retrive a parameter based of the value of another parameter", and it did work. -- AzaToth ^talk 13:57, 23 November 2005 (UTC)

Have made a minor change in template if, all current use is ok, but you can use the optional parameters expr,then and else instead. this might make it look better -- AzaToth ^talk 18:54, 24 November 2005 (UTC)

Also if you would like to know, there is a template {{ switch}} now also to be used -- AzaToth ^talk 04:46, 25 November 2005 (UTC)

By using switch in some sub templates, you'll remove a lot of ifs, and the code seems more nice. Also, this is only 1 sub-template-call :) – AzaToth ^talk 17:08, 25 November 2005 (UTC)

{{ Switch}} seems to be having some difficulty with the day of the week on its talk page. I do like the design, but I'm not yet convinced how well it handles. -- Gareth Hughes 14:03, 27 November 2005 (UTC)

• It's not a problem of {{ Switch}}, it me that missunderstood how {{ CURRENTDOW}} work, I thought sunday was number 7, but it's number 0; _{→ Aza Toth} 14:55, 27 November 2005 (UTC)

Ah, I see. Well, I think we should trial switch with these arrays. I'll start implementing it. -- Gareth Hughes 18:15, 27 November 2005 (UTC)

language/familycolor

{{switch
  |{{{1|}}}
  |case: Afro-Asiatic=yellow
  |case: Afro-asiatic=yellow
  |case: yellow=yellow
  |case: Niger-Congo=orange
  |case: orange=orange
  |case: Nilo-Saharan=gold
  |case: gold=gold
  |case: Khoisan=goldenrod
  |case: goldenrod=goldenrod
  |case: Indo-European=lawngreen
  |case: lawngreen=lawngreen
  |case: Caucasian=lightgreen
  |case: lightgreen=lightgreen
  |case: Altaic=yellowgreen
  |case: yellowgreen=yellowgreen
  |case: Uralic=limegreen
  |case: limegreen=limegreen
  |case: Dravidian=mediumspringgreen
  |case: mediumspringgreen=mediumspringgreen
  |case: Austronesian=tomato
  |case: tomato=tomato
  |case: Austro-Asiatic=lightcoral
  |case: Austro-asiatic=lightcoral
  |case: Austroasiatic=lightcoral
  |case: lightcoral=lightcoral
  |case: Sino-Tibetan=pink
  |case: pink=pink
  |case: Australian=orchid
  |case: orchid=orchid
  |case: Papuan=violet
  |case: violet=violet
  |case: Tai-Kadai=lavender
  |case: lavender=lavender
  |case: American=lightblue
  |case: lightblue=lightblue
  |case: Na-Dene=deepskyblue
  |case: Na-Dené=deepskyblue
  |case: deepskyblue=deepskyblue
  |case: Eskimo-Aleut=lightcyan
  |case: lightcyan=lightcyan
  |case: Isolate=#dddddd
  |case: isolate=#dddddd
  |case: language isolate=#dddddd
  |case: #dddddd=#dddddd
  |case: Sign=silver
  |case: sign=silver
  |case: sign language=silver
  |case: silver=silver
  |case: Conlang=black
  |case: conlang=black
  |case: constructed language=black
  |case: black=black
  |case: Default=white
  |case: white=white
  |default=white
}}

language/genetic

{{switch
  |{{{1|}}}
  |case: Afro-Asiatic=[[Afro-Asiatic languages|Afro-Asiatic]]
  |case: Afro-asiatic=[[Afro-Asiatic languages|Afro-Asiatic]]
  |case: yellow=[[Afro-Asiatic languages|Afro-Asiatic]]
  |case: Niger-Congo=[[Niger-Congo languages|Niger-Congo]]
  |case: orange=[[Niger-Congo languages|Niger-Congo]]
  |case: Nilo-Saharan=[[Nilo-Saharan languages|Nilo-Saharan]]
  |case: gold=[[Nilo-Saharan languages|Nilo-Saharan]]
  |case: Khoisan=[[Khoisan languages|Khoisan]]
  |case: goldenrod=[[Khoisan languages|Khoisan]]
  |case: Indo-European=[[Indo-European languages|Indo-European]]
  |case: lawngreen=[[Indo-European languages|Indo-European]]
  |case: Caucasian=[[Languages of the Caucasus|Caucasian]]
  |case: lightgreen=[[Languages of the Caucasus|Caucasian]]
  |case: Altaic=[[Altaic languages|Altaic]]
  |case: yellowgreen=[[Altaic languages|Altaic]]
  |case: Uralic=[[Uralic languages|Uralic]]
  |case: limegreen=[[Uralic languages|Uralic]]
  |case: Dravidian=[[Dravidian languages|Dravidian]]
  |case: mediumspringgreen=[[Dravidian languages|Dravidian]]
  |case: Austronesian=[[Austronesian languages|Austronesian]]
  |case: tomato=[[Austronesian languages|Austronesian]]
  |case: Austro-Asiatic=[[Austro-Asiatic languages|Austro-Asiatic]]
  |case: Austro-asiatic=[[Austro-Asiatic languages|Austro-Asiatic]]
  |case: Austroasiatic=[[Austro-Asiatic languages|Austro-Asiatic]]
  |case: lightcoral=[[Austro-Asiatic languages|Austro-Asiatic]]
  |case: Sino-Tibetan=[[Sino-Tibetan languages|Sino-Tibetan]]
  |case: pink=[[Sino-Tibetan languages|Sino-Tibetan]]
  |case: Australian=[[Australian Aboriginal languages|Australian]]
  |case: orchid=[[Australian Aboriginal languages|Australian]]
  |case: Papuan=[[Papuan languages|Papuan]]
  |case: violet=[[Papuan languages|Papuan]]
  |case: Tai-Kadai=[[Tai-Kadai languages|Tai-Kadai]]
  |case: lavender=[[Tai-Kadai languages|Tai-Kadai]]
  |case: American=[[Indigenous languages of the Americas|American]]
  |case: lightblue=[[Indigenous languages of the Americas|American]]
  |case: Na-Dene=[[Na-Dené languages|Na-Dené]]
  |case: Na-Dené=[[Na-Dené languages|Na-Dené]]
  |case: deepskyblue=[[Na-Dené languages|Na-Dené]]
  |case: Eskimo-Aleut=[[Eskimo-Aleut languages|Eskimo-Aleut]]
  |case: lightcyan=[[Eskimo-Aleut languages|Eskimo-Aleut]]
  |case: Isolate=[[language isolate]]
  |case: isolate=[[language isolate]]
  |case: language isolate=[[language isolate]]
  |case: #dddddd=[[language isolate]]
  |case: Sign=[[sign language]]
  |case: sign=[[sign language]]
  |case: sign language=[[sign language]]
  |case: silver=[[sign languages]]
  |case: Conlang=[[constructed language]]
  |case: conlang=[[constructed language]]
  |case: constructed language=[[constructed language]]
  |case: black=[[constructed language]]
  |case: Default=—
  |case: white—
  |default=—
}}

I see no reason to put the iso codes in an HTML code element. These are not computer language code samples (which the code element is intended for), and their position in a table makes the usual monospace font formatting an unnecessary distraction. Any objections to removing the <code> tags?— Michael  Z. 2005-11-26 19:12 Z

The addition of the <code> tags was a fairly recent thing. The tags are containing code after all, so there is something that sounds appropriate about them. I think the issue is more to do with the aesthetic. I actually liked the change to a monospace font for the codes; I feel it sets them apart as codes. -- Gareth Hughes 21:20, 26 November 2005 (UTC)

Well, the code element "designates a fragment of computer code" [2], which doesn't really describe ISO language codes. For the visual style, it might be more appropriate to add the attribute style="font-family:monospace;" to the respective table cells, or to surround each language code with <abbr style="font-style:normal; font-family:monospace;">...</abbr>, since the codes serve as standardized abbreviations representing the languages.

That said, this is all a bit nitpicky, and I won't argue any further if you'd really rather leave them in code elements. — Michael  Z. 2005-11-26 22:58 Z

I don't think <abbr> tags are allowed in wikitext. Would <span> be OK? -- Gareth Hughes 18:38, 27 November 2005 (UTC)

use of tt is widespread for these kind of things in WP Tobias Conradi (Talk) 23:09, 28 November 2005 (UTC)

<samp> is fine. Span would be okay too in text, but in a table you may as well put the style attribute onto the table cell which is already there. — Michael  Z. 2005-11-29 00:58 Z

Not all of the contents of the table cells use monospace throughout (especially, for ISO 639-3). Even though it's not big or clever, I'm tempted to use <samp> to do the trick. -- Gareth Hughes 11:56, 29 November 2005 (UTC)

The centre alignment of the text in the IPA note at the bottom is a bit distracting, too. In my browser, the first line fills the width of the table, and the second line consists of just the word "Unicode" centred by itself. I see no reason for this not to remain in Wikipedia's default left-margin text alignment. Any objections to changing this? — Michael  Z. 2005-11-26 19:16 Z

As I've been viewing the footer full screen it has seemed fine, but, taking your point, I'll switch it to left alignment. -- Gareth Hughes 21:23, 26 November 2005 (UTC)

Every so often I think that we've arrived at the updated template we are looking for, and then the new ideas start to come in. Some of the latest additions are:

1. You now only need to use one geographical field in the template: {{{states}}} or {{{region}}}. You can still use both, but, if only one is used, it defaults to the 'Spoken/Signed in:' left-hand column.
2. {{ Switch}} is now handling the arrays. Boolean templates are handling most of the options now. Some of the template calls have been rationalised. The routine for making lists of multiple ISO 639-3 codes is now at {{ language/codelist}}, which neatens the syntax in the main template.
3. As no one objected, I've added two new colours: for , and for a or a . Don't use the colour names in {{{familycolor}}}: they haven't been included in the arrays.

I hope that's all useful to you. -- Gareth Hughes 21:17, 29 November 2005 (UTC)

Hey, thanks about #3! -- Hottentot 00:32, 1 December 2005 (UTC)

1. IMO fontcolor should be run by familycolor
2. can't familycolor be derived from fam1 (, fam2, fam3)? maybe at least for the most common cases. Tobias Conradi (Talk) 17:29, 2 December 2005 (UTC)

Yes, I have thought about taking away {{{fontcolor}}}. No article actually uses that parameter usefully. I think it is only necessary on the black background of conlang infoboxes, and then it is handled automatically. I've spoken with Mark about deriving {{{familycolor}}} from {{{famn}}}. The problem is that these parameters can be set to all sorts of different values (almost all are formatted as internal links too), and would be difficult to draw up an array to cover all the possible values and variations. I feel (even though it may seem backward logic) that {{{famn}}} should be kept fexible so that we can enter the most appropriate text and links, and that we continue to use {{{familycolor}}} to define the presentation colour of the infobox, as it is a more well-defined field. Doing things the other way round does work, though. If you leave out {{{fam1}}}, it is automatically supplied by {{{familycolor}}} from the array {{ language/genetic}}. I know this is all a bit backwards, but it makes the template much easier to write. -- Gareth Hughes 18:05, 2 December 2005 (UTC)

Hi. I just noticed that appears to be a Template:Dialect, created by 70.25.200.220 ( talk · contribs) sometime in August. I didn't know that such a template existed, but the problem is that the template doesn't look so good -- its defalt color is grey, and doesn't look as nice as this template. What do you think we should do with it? Should we use it or delete it? Any thoughts? It is currently used on four articles: Michif language, Newfoundland Irish, Bungee language, and Scottish Gaelic in Canada -- Hottentot 03:07, 2 December 2005 (UTC)

Well, you've caught me at a time when I feel ready to go on the rampage against the use of the word dialect. The word is totally subjective. Now that {{ language}} has greater flexibility, I think that {{ dialect}} should be put up for deletion, and all instances of it in articles replaced with {{ language}}. -- Gareth Hughes 15:08, 2 December 2005 (UTC)

• Agree, We have here the "template that's fits them all" _{→ Aza Toth} 15:45, 2 December 2005 (UTC)

I've converted all articles that used {{ dialect}} to {{ language}}, and have nominated it for deletion on TFD. -- Gareth Hughes 16:14, 2 December 2005 (UTC)

100% agree Tobias Conradi (Talk) 17:25, 2 December 2005 (UTC)

Everyone needs to give this page a read. It describes the negative system impact of "templates within templates". I'll be back later to talk about how we're going to eliminate them fromt his template, as soon as I do some experiments. -- Netoholic @ 18:03, 9 December 2005 (UTC)

WP:AUM seems to be in open discussion of this right now, and extended template syntax seems to be the correct answer. I'm unsure how the server load of this template is measured, but pages that include the template appear to load no less quickly than those without it. -- Gareth Hughes 22:42, 9 December 2005 (UTC)

extended template syntax is a proposed (i.e. hypothetical) extension to the way Templates are handled by the software. What is being used here in this template is NOT "extended template syntax", as described on that page. Some "clever" folks have found an ugly way to "fake out" the software. As far as page load times, please don't assume these have no cost. WP:AUM is currently being assaulted by these "clever" folks, but it has been endorsed in the past by both the ArbCom and the MediaWiki developers. -- Netoholic @ 22:51, 9 December 2005 (UTC)

In the past being the key phrase there. Wikimedia has far more computing power now than back then, and I'm not so sure these templates cause much of an effect now. Dan100 ( Talk) 08:45, 11 December 2005 (UTC)

I propose that this template should be moved to Template:Infobox language, mostly because this is an infobox _{→ Aza Toth} 10:34, 12 December 2005 (UTC)

support. even if it is very nice and short now, but we should take care of WP as a whole and stick to this format. Then, within thousands of templates the Infoboxes can be quickly identified. Tobias Conradi (Talk) 15:45, 12 December 2005 (UTC)

I don't believe there is any guideline that says that an infobox template has to have infobox in its name, though some do. To make this change, we would have to alter every article in which the template occured, using a redirect here in the meantime. This is a huge amount of work for what is a hidden, internal stylistic change without a guideline to back it up. Maybe we should have a list for those who support the change and want to do it/programme the bot. -- Gareth Hughes 17:03, 12 December 2005 (UTC)

technically this is no problem. Move the template. And look for a guy with a bot. There are lot's of bot guy around, I think. Tobias Conradi (Talk) 18:26, 12 December 2005 (UTC)

OK then. There are a number of sub-templates that this one uses that will have to be moved too. The links that reference them in the template itself will have to be changed too. The question is why: why do we need to move this at all (because it is an infobox is no real answer)? -- Gareth Hughes 19:00, 12 December 2005 (UTC)

of course exactly only because it is an infobox. This is a real answer. See Wikipedia:Infobox_templates, lots of conforming and lot of unconforming Infoboxes. It's nice to see from a template name that it is an infobox. Template:Language can be lots of things, but Template:Infobox Language is very clear. BTW use uppercase L, because it is not a Infobox language but a Infobox named Language. Seems to be favored way for new templates anyway. Tobias Conradi (Talk) 20:08, 12 December 2005 (UTC)

Why does it matter? I really doubt a whole bunch of non-editors will be looking at this template. -- Khoikhoi 02:30, 13 December 2005 (UTC)

Maybe read the above. There are thougth(s) of why it matters. Nobody claimed non-editors would look at templates at all. one more ref how others stick to standards: Special:Allpages/Template:Infobox - BTW: if it does not matter to you, we could move? Tobias Conradi (Talk) 15:42, 13 December 2005 (UTC)

But what's the point of sticking to standards if non-editors aren't gonna see it? -- Khoikhoi 00:06, 14 December 2005 (UTC)

to the help of editors? ;-) Tobias Conradi (Talk) 15:56, 14 December 2005 (UTC)

BTW: IMO it's nothing that has to be done immediatly. Just something that IMO should be done some day. If anybody has the bot and the in-template references can be fixed. do it (IMO). Tobias Conradi (Talk) 15:59, 14 December 2005 (UTC)

I noticed that the colors for Australian and Papuan languages are very similar, and it's almost hard to tell the difference unless they are side-by-side. I suggest we make the color darker or lighter for one of them. Any thoughts? -- Khoikhoi 03:05, 14 December 2005 (UTC)

I see what you mean. The current colours are for and for . We might want to move one or both to plum and/or magenta. -- Gareth Hughes 11:54, 14 December 2005 (UTC)

I like plum, if you ask me. — mark ✎ 14:00, 14 December 2005 (UTC)

Plum is nice, but magent is not nice, I would suggest: #fd79da for and #eba9ee for _{→ Aza Toth} 17:34, 14 December 2005 (UTC)

As you can see from my last post, the colours have been updated to those proposed by AzaToth. They are now more distinct. -- Gareth Hughes 17:51, 14 December 2005 (UTC)

They look a lot better now. -- Khoikhoi 02:15, 15 December 2005 (UTC)

If we get a bot, maybe other usefull stuff could be done. Tobias Conradi (Talk) 17:46, 15 December 2005 (UTC)

• change reference Template:Language to Template:Infobox Language
  • the original Template:Language should be moved there first
    • User:Netoholic is blocking this with his language template
    • User:Cyrius reverted the move of Netoholics template to Template:Infobox Language new and after the second reversion blocked Netoholics version to be moved somewhere else, he gave no reason as of now Tobias Conradi (Talk) 16:07, 7 January 2006 (UTC)
• add iso3 codes to those articles that have unique mapping to iso3
  • we have to compile a list of language articles and the codes.
• put regions and states together?
• change values of familycolor from color name to familyname
  • does every colorname only have one familyname it can be changed to?
    • it's best to choose the highest name on the list as that's usually preferred; some classes don't need to be searched (Paleosiberian, Creole/Pidgin/Mixed, Sign, Conlang) as they are either new or rarely use the parameter; there may be a couple of wrong results due to the original swap of Sino-Tibetan/Austronesian by hand, but the change to a name will make the mistake obvious (e.g. Maori getting familycolor=Sino-Tibetan). Gareth Hughes 23:59, 15 December 2005 (UTC)
  • should we only allow one spelling for the family, eg all lowercase no hyphen? (could reduce size of template)
    • the idea behind a few different choices was to allow a little human flexibility; the array {{ language/familycolor}} isn't too big to manage. Gareth Hughes 23:59, 15 December 2005 (UTC)
• change {{{nation}}}
  • what's that?
    • articles with rank=Not in top 100 or rank=''Not in top 100'' could have that text removed; also nation=none, agency=none or similar null strings could be removed, but it's difficult to guess all the different sorts of nothing there may be. Gareth Hughes 23:59, 15 December 2005 (UTC)
    • nation=list of countries in which it is an official language
      • better: official=
• split {{{family}}} into {{{famn}}}
  • what problems could occur?
    • the articles have implemented {{{family}}} in different ways; I think human intervention might be easier here. Gareth Hughes 23:59, 15 December 2005 (UTC)
• change some of the variable names?
  • like what? Gareth Hughes 23:59, 15 December 2005 (UTC)
  • ...

Well, I didn't want to get into that position, and I hope that in the future the template will be easier to understand and edit. I've been making quite a few changes by hand, but I don't think a bot would be able to do much of these other changes. Language coding is complicated enough as to require some human thought. Splitting {{{family}}} into {{{famn}}} parameters also probably requires human attention. Putting region and states together is rather an optional thing in my mind: if you can't think of anything useful to put in two geographical fields, leave one of them out. A lot of infoboxes use {{{rank}}}, {{{nation}}} and {{{agency}}} with no useful information (stopping the infobox compacting). There a few regular things that seem to be put in these otherwise null strings, so the bot would have to be given a sense of what is an obviously useless string. Probably the most useful thing a bot could do is to learn {{ language/familycolor}} and change all definitions of {{{familycolor}}} that are colour names into language-family names. This would end the current silliness of pink=tomato! -- Gareth Hughes 18:47, 15 December 2005 (UTC)

I put some of your thoughts in the above list. some stuff is marked with question mark. maybe you can add some further thoughts to these. Tobias Conradi (Talk) 22:56, 15 December 2005 (UTC)

OK. I've added some bits to it. Gareth Hughes 23:59, 15 December 2005 (UTC)

Hi all. I would like to trigger a conversion of this master piece from usage of template:if ( talk) to the faster and server friendlier template:qif ( talk). I have done a try (without the noinclude section) at User:Adrian Buehlmann/language 2005-12-15-1 ( diff). Note: this is a manual conversion.

What do you think? Or would any of the local experts do the conversion? Please feel free to edit User:Adrian Buehlmann/language 2005-12-15-1 as you see fit (open house user sub-page, also the associated talk page). – Adrian | Talk 21:58, 15 December 2005 (UTC)

You've obviously made a straight switch between {{ if}} with numbered parameters and {{ qif}}. It seems that {{ qif}} hasn't thrown up any problems so far. I suggest we change to the new template and see what happens. I imagine {{ language}} is a pretty good test for any logic template! -- Gareth Hughes 00:41, 16 December 2005 (UTC)

Yes. Thanks for the reply. Yea this is a nice master piece of if logic and I can say that, although it's a tough one I found it quite straight to convert thanks to its clean structure and good indenting. However, I'm very reluctant to just throw my proposal in, as this is obviously very delicated stuff and I'm not an expert of the field. Yes, I've done a stright convert to qif, but we could easily do that in two steps and switch to the named parameters variant of if as a first step. I could do a search and replace on User:Adrian Buehlmann/language 2005-12-15-1 from qif to if and put that into Template:Language as an intermediate step. A good idea would be if I do this when you are around on wikipedia so you can quickly see if something breaks and revert. Maybe you could leave a message on my talk when you're online. Alternatively, of course I would also be happy if you do the conversion yourself (you don't have to use User:Adrian Buehlmann/language 2005-12-15-1, maybe it would even be better if you don't use that because you know the structure of Template:Language much better than I do). I Hope I did not give too many options :-). What do you think? Thanks! – Adrian | Talk 08:57, 16 December 2005 (UTC)

I Hope I did not give too many options :-) - have you considered using {{ switch}} to present your thoughts? :P — mark ✎ 09:25, 16 December 2005 (UTC)

I know switch. But my intention was not to do development on template:language. My goal is just to eliminate if by doing (stupid) status-quo preserving conversion jobs to qif. I cannot comment on using switch at the moment. – Adrian | Talk 10:44, 16 December 2005 (UTC)

Warning: User:Adrian Buehlmann/language 2005-12-15-1 is out of sync at the moment. This change would need to be factored in . – Adrian | Talk 16:48, 16 December 2005 (UTC)

That change was helpful to the infobox on Arabic language ( talk · history · watch). I used {{ qif}}, and it can be easily factored in. I would suggest that this change be made to User:Adrian Buehlmann/language 2005-12-15-1 and the whole lot shifted in here. There doesn't seem to be much reason to do this in stages: the template is already using {{ qif}} indirectly. Verifying that everything is working properly is a bit difficult. There are nearly a thousand articles that use the template, and they implement it in anumber of different subtle ways. In the highly unlikely event that the change wrecks the infobox entirely. it can be just reverted. It is far more likely that if there's a problem it will affect a few infoboxes in a not too spectacular way. So, it might take a few days to see if everything is fine. -- Gareth Hughes 17:40, 16 December 2005 (UTC)

OK. I will go for it. Hold on your breath :-). – Adrian | Talk 17:53, 16 December 2005 (UTC)

Done. See diff. Please revert if there is something broken. Thanks! (Updated) – – Adrian | Talk 18:31, 16 December 2005 (UTC)

I've converted Template:Language/codelist ( diff). – Adrian | Talk 18:13, 16 December 2005 (UTC)

I've converted Template:Language/statesregion ( diff). – Adrian | Talk 18:21, 16 December 2005 (UTC)

Well done! It's all working perfectly as far as I can see. I picked out a few language articles that implement the template in different ways, and they are all displaying normally. -- Gareth Hughes 18:32, 16 December 2005 (UTC)

I did change all {{ if defined call}},{{ if defined call1}},{{ if defined call2}} to {{ if defined}} ( talk) _{→ Aza Toth} 18:46, 16 December 2005 (UTC)

Everything is fine. I've noticed (in the section below edit boxes) that this template is calling sub-templates that it isn't using. I haven't noticed this before, so it might be a side-effect of using {{ qif}}. The sub-templates in question are {{ language/agency}} and {{ language/codelist}}. The former is only used by a handful of constructed languages, but it appears to be called by every (?) language article with the template. The latter sub-template is only used where a language has multiple ISO 639-3 codes, but appears to be used by every language article using the template. There may be other sub-templates that are being called and not used in this way, but I just haven't had time to check for them. I think these sub-templates are called directly off the back of a {{ qif}}, and that calling them through {{ if defined}} might reduce server load. Also, if anyone is a good CSS hack, please take a look at {{ language/Indic}}: it shouldn't have borders when added into the main template. -- Gareth Hughes 13:43, 22 December 2005 (UTC)