Wikipedia talk:WikiProject Languages/Archive 2
This is an archive of past discussions about Wikipedia:WikiProject Languages. 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 2 | Archive 3 | Archive 4 | Archive 5 |
Articles for the Wikipedia 1.0 project
Hi, I'm a member of the Wikipedia:Version_1.0_Editorial_Team, which is looking to identify quality articles in Wikipedia for future publication on CD or paper. We recently began assessing using these criteria, and we are looking for A-Class and good B-Class articles, with no POV or copyright problems. Can you recommend any artcles on languages? I don't know if you've had any FAs, but we're looking for those as well. Please post your suggestions here. Cheers!--Shanel 02:47, 5 November 2005 (UTC)
- These are the featured language articles: Aramaic language — Gbe languages — Laal language — Mandarin (linguistics) — Nafaanra language — Portuguese language — Russian language — Swedish language — Taiwanese (linguistics) — Tamil language — Vulgar Latin. — mark ✎ 08:34, 5 November 2005 (UTC)
Thanks!--Shanel 22:51, 6 November 2005 (UTC)
- It's been a while since a member of our Project has contacted you. Are there any more recommendations you could have, as we Push to 1.0? Titoxd(?!? - help us) 06:38, 11 April 2006 (UTC)
- I might be setting the standards too high, but that list might need to be trimmed. Mandarin (linguistics) is no longer an FA, since it was missing too many of the requirements, Russian language is missing a proper grammar section and needs some overall improvements and Portuguese language has been receiving a constant stream of additions the past six months or so. The problem is that a lot of of these have not been of what I would call FA-quality, and there seems to be reoccuring disputes concerning both wording and factual content which aren't always constructive. It's also rather bloated (62 k), mostly due to the extremely detailed grammar section and classification section. And it needs a lot of copyediting.
- Peter Isotalo 14:07, 11 April 2006 (UTC)
- I agree; a few months back I tried to remove everything in Portuguese language that's duplicated in another article, only to be reverted every time. But then I have high standards too; in my opinion, 90% of the featured articles I've seen aren't up to what I would call FA status. Every time I read "today's featured article" I shake my head in despair at the omissions, errors, and poor writing in what is touted as "the best Wikipedia has to offer". Angr (talk • contribs) 14:29, 11 April 2006 (UTC)
Albanian peer review
The article on the Albanian language is having a peer review. This article is currently at Wikipedia:WikiProject Languages#Pages using the template needing attention, so obviously something must be wrong with it. It has undergone vast improvement over the past few days. Please comment, so that we can know what to improve. Thank you. Rex(talk) 22:03, 8 November 2005 (UTC)
color again
hi. after looking at the language map that uses these proposed colors, i have 2 suggestions concerning the current colors which i have also posted here: Image talk:Human Language Families Map (Wikipedia Colors .PNG#color. here they are:
- Austronesian color could be a little darker so that it contrasts a little more with the white background on those small islands. (maybe too much trouble?)
- the little specks of languages on US reservations are difficult to see & will remain difficult to see no what matter what we do. however, perhaps they can be brought out a little more by changing the color of the Native American languages group?
thank you. – ishwar (speak) 09:34, 10 November 2005 (UTC)
- As long as any color change retains contrast and aesthetics, and we follow it up on all the pages using the template to remain consistant, some minor tweaks probably wouldn't hurt. What do you think about adding a color code for Quechuan languages? They're probably the most widely spoken native american languages south of Canada. --April Arcus 16:21, 10 November 2005 (UTC)
- How many articles are there currently on different Quechuan languages? --Angr/tɔk tə mi 17:37, 10 November 2005 (UTC)
- One on Quechuan languages and one on Quechua language. I don't rightly know if the family is diverse enough to deserve a color here or not - Japanese and Korean certainly don't seem to warrant it. I'll have to leave the judgement to an expert. --April Arcus 22:04, 10 November 2005 (UTC)
- Um, Japanese and Korean are unrelated. As for the Quechuan languages, I don't think two articles is enough to warrant a new color. --Angr/tɔk tə mi 22:45, 10 November 2005 (UTC)
- I was referring to them as individual languages that didn't warrant their own color, not trying to suggest that they were part of a single family. I hope you don't think I'm stupid enough to imagine there's any consensus there. --April Arcus 02:26, 11 November 2005 (UTC)
- Ish, I think those are good suggestions and I concur with April Arcus. — mark ✎ 18:24, 10 November 2005 (UTC)
- re colors for other American langs: if we give Quechuan a separate color, what will justify not adding 100 more colors for the other families? I assumed that the reason that it had only one color was because maps of the language family distribution in South Am. were not exactly at a high level of accuracy & it would be too hard to differentiate the small families which would just be little specks on the map. Quechuan does have a lot speakers if you want to use that as a criterion for getting a color. The only families that come close to Quechuan are Tupian and Mayan.
- it is not clear what kind of criteria are used to display families (am i right? do the original authors state their ideas?) nor are any sources indicated (which makes me wonder if i must i should trust the map). so what is it going be?
- re Austronesian color: how about switching with Sino-Tibetan? (many pages are there?)
- That would be an attractive switch. I withdraw the notion on Quechua - being widely spoken is insufficient to warrant inclusion at the macro-family level. --April Arcus 02:34, 11 November 2005 (UTC)
- I belatedly repent. The map looks awful under this scheme. I'd like these switched back, on purely aesthetic grounds. --April Arcus 07:56, 8 December 2005 (UTC)
ok. so, i'll switch them until someone objects.
i'll looking into switching Nadene with Native American. – ishwar (speak) 03:51, 17 November 2005 (UTC)
- Um, is there a bot to go through all the pages and switch the colors for Austronesian and Sino-Tibetan? I for one sure don't wanna do it by hand. --User:Angr/talk 14:54, 17 November 2005 (UTC)
- Does anyone know how this could be made less painful? There was an idea above to replace the HTML color codes with templates. Where would we go to find someone who knows how to automate such a task? --April Arcus 00:24, 20 November 2005 (UTC)
- A bot would be able to do these switches less painfully, but you need the technical know-how, or some with it, to operat for you. I suggest that we complete the Austronesian/Sino-Tibetan change either by bot or by hand, but hold off any further change until a new feature has been built into {{language}}. I've been putting a lot of new features into the infobox recently, and it has been suggested that we stop defining the language family colour in each article and have them defined centrally instead. I'm working on a system that would replace |familycolor=yellow with |fam=Afro-Asiatic, then the colour equivalent yellow would be read centrally. If we want to change the colour of all infoboxes belonging to that family, we simply change it once, at a central point rather than in every article. This parameter would also make the new {{{fam1}}} redundant. Of course, a change-over period will be built in, so that the old colour definitions continue to work as the new definition is implemented. WHat do you think about this? --Gareth Hughes 13:52, 20 November 2005 (UTC)
- Please do not conflate the color entry with the family entry, though changing the name of the argument for familycolor might be a good idea. Lakota, for example should have |fam1=Siouan-Catawban but |familycolor=Native American. Unless you want to go through all 200+ Native American language families and assign them the same lightblue color. Incidentally, what do we do with Native American language isolates like Zuni? At the moment it's #dddddd for being a language isolate, but surely a case could be made for its being lightblue for being a Native American language too. --User:Angr/talk 14:58, 20 November 2005 (UTC)
- I'm still trying to work out which way round the defaults should be. I think that in many cases {{{fam}}} would duplicate the information in {{{fam1}}}, so it seems good practice not to require the latter. However, we could continue to use that latter parameter as an override in cases where the first parameter does not give sufficient information. This is what happens at the moment with {{{family}}}, the old parameter. --Gareth Hughes 15:57, 20 November 2005 (UTC)
I've been persuaded to use {{{familycolor}}} instead of introducing a new parameter. If you think that by typing |familycolor=gold in a {{language}} call makes it gold, you'd be wrong. It does actually turn out as gold, but it refers the call to the central array: {{language/familycolor}}. If you set |familycolor=brown, it'll turn out white now! The advantage of the array are:
| |||||||||||||||||||||||||||||||||||||
See also | Wikipedia:WikiProject Languages |
---|
- We can use language family names instead of colour names now. Please start using the family names instead of the colour names, as I don't want to be setting the array to pink=tomato unless we have to (as change is mid-way through, there's little that can be done).
- All colour changes are now made centrally: and edit to {{language/familycolor}} changes that colour in every instance.
The little quilt is at {{language/quilt}}. If you look at the source text, you'll see that it's set to auto-update to changes made in the arrays. This syntax could be used in other places that use these colours (like maps), so that they auto-update to changes in the array. --Gareth Hughes 13:31, 22 November 2005 (UTC)
- I grew up with maps showing the Indo-european languages in red. Bantu in blue. chinese in yellow. What is your experience, is there any standard? The green currently could be taken for grass and forest and the yellow for desert. It seems the author had the vegetation in mind. Can be regarded as benefitial or less so.
- If we change colors we should maybe interwiki coordinate. Tobias Conradi (Talk) 22:06, 23 November 2005 (UTC)
Great work on the familycolor array. I was going to suggest a mechanism to allow specifying logical (rather than physical) colours in the language template, but you've beaten me to it (and your mechanism is better than the one I was going to suggest). Martin.Budden 13:33, 26 November 2005 (UTC)
- I think there are two more colours that need defined: one each for Paleosiberian languages and creoles/pidgins. Neither of these can be adequately colour coded with the present colours, and neither group is genetic classification. I was toying with the idea of incorporating colours from both strata for creoles/pidgins, but it would be messy, and some have more than two strata. I would suggest using darkseagreen for Paleosiberian languages. This would fit the general green scheme for northern Asia. Finding a colour for creoles/pidgins is slightly more difficult. How would you feel about tan? --Gareth Hughes 13:58, 26 November 2005 (UTC)
- but don't allow usage of colorname outside the family-color-matrix. Tobias Conradi (Talk) 17:25, 26 November 2005 (UTC)
- Yep, I wasn't planning on allowing {{{familycolor}}} to be defined by the colour names of new colours, but only by the name of the classification. I think it would be right to allow either 'creole' or 'pidgin' for the latter, with each producing the same colour. I'll wait for a couple more comments before adding new colours though. --Gareth Hughes 21:32, 26 November 2005 (UTC)
- OK, I've switched on the two new colours as suggested, as no one has said anything. --Gareth Hughes 20:28, 29 November 2005 (UTC)
Original research/no cited sources in English dialect articles
I'm concerned about the large number of articles on dialects of English in which there are either no sources cited or only unscientific sources cited, or which seem to be written entirely based on original research (specifically, people with no linguistic training writing amateurishly and largely in stereotypes about the way they notice people talking around them). Some of the worst offenders are:
Some of these just need a little work on them to bring them up to snuff; others are probably AFD-worthy. Any suggestions on what we can do with all of these? --User:Angr/talk 18:21, 15 November 2005 (UTC)
- I think these articles are particularly vulnerable to this. Some time ago, I tried to improve the phonetics/phonology sections of some of articles about British dialects I'm familiar with (e.g. Yorkshire dialect and accent) by looking at the features claimed, trying to find sources, deleting those I couldn't find any sources for and converting those I could to IPA. I ended up using the British Library English Accents and Dialects collection a lot, and Wells's Accents of English is often useful. But there are still things on many of the pages in question I'm not particularly happy with, and unsourced and/or badly described things still get added.
- For some of the American articles, there's a lot of information in the draft chapters of Labov's Atlas of North American English which could be used, and in fact I suspect that this is the origin of some of the material and just hasn't been referenced. E.g. some of the stuff on Philadelphia accent looks like it was based on http://www.ling.upenn.edu/phono_atlas/Atlas_chapters/Ch17_2nd.rev.pdf and I think you could use that chapter to give Philadelphia English a decent article, at least as far as phonology is concerned.
- In some cases, I'd suggest redirects or mergers with sections of other pages. E.g. do we need both West Country dialects and the southern rural/West Country section of English English?
- Hello! At least for ones concerning Canadian English et al., there are numerous style and usage guides (that I'm in possession of and elsewhere) that can be used to either round out the relevant articles or to nix uncited/unverifiable contributions. An interesting discussion has arisen around the validity (or not) of creating an article about BC English, and I believe the outcome is self-evident. For this and others, perhaps the Oxford Guide to World English (by Tom MacArthur) can be of some help? Eh? :) E Pluribus Anthony 17:44, 20 November 2005 (UTC)
- I'm not sure how much help style and usage guides will be. Those are generally prescriptive, and an encyclopedia article needs to be descriptive. Ideally there should be published descriptive linguistic research on any dialect with its own Wikipedia article. --User:Angr/talk 18:25, 20 November 2005 (UTC)
- I think they can be of great help: common usage and style guides are generally rooted in authoritative, cited works (whether or not they're prescriptive), and merely including other works – without sufficient context – may be too cryptic for general users. I think a Melange of the two is better than the current state. E Pluribus Anthony 19:03, 20 November 2005 (UTC)
Okay, I've re-written Hayna Valley English based on data from PEAS and ANAE, though a lot is still unsourced. I've also tried to improve the encyclopedic tone of the article. Take a look and let me know what you think. --Angr (t·c) 07:09, 2 January 2006 (UTC)
Regions?
I've been writing a lot of infoboxes for languages but I still don't understand one thing: What exactly are regions? Are they meant to be geographical like Western Europe or administrative like Quebec? Aleksei 06:02, 25 November 2005 (UTC)
- IMO the usage as "Western Europe" is not good because
- in the template it comes after the countries
- in general this sence maybe needs not to be written, because states are mentioned, implying the region in the broader sence (for those readers that know where the states are situated)
- At the template talk page it was also suggested to drop "region". Tobias Conradi (Talk) 09:02, 25 November 2005 (UTC)
- I've brought this up a couple of times in the past (see Template talk:Language). The template is being revised at the moment so it is probably worth weighing in on that discussion. In my opinion, the "region" and "spoken in" both refer essentially to the geographical area where the language is mainly used, but "region" can be anything from a whole continent to a small village, whereas "spoken in" refers to the country. I think the one flexible geographical category would be enough. ntennis 09:31, 25 November 2005 (UTC)
- I agree with Ntennis. I've always understood 'region' to be a place to state more specifically where in the mentioned states the language is spoken (see for example its use at Nobiin language, Nafaanra language, Ogiek language). However, I don't see any good reasons against collapsing the two, especially since they are often partially redundant. — mark ✎ 10:16, 25 November 2005 (UTC)
- I think the original idea was to have {{{states}}} representing sovereign states in which the language is spoken, and {{{region}}} representing the areas within those states. This works very nicely for languages that are only really spoken in one part of one country. However, when you try using it for a language which spoken across a number of countries, it makes sense to turn {{{region}}} into a large international area. There are so many templates that leave {{{region}}} blank because there is nothing useful that can be added to what is given in {{{states}}}. I would make far more sense to have just one field for geographical distribution. I would suggest that we keep {{{region}}} as the parameter for this, as it is more non-specific than {{{states}}}. However, I think we should keep the left-column text 'Spoken in:' rather than 'Region:'. It would be fairly easy to build this in as an option (or rather place the current set up in a sub-template as an option, and build the single field into the template). --Gareth Hughes 14:17, 25 November 2005 (UTC)
- Sounds good to me. — mark ✎ 15:34, 25 November 2005 (UTC)
- OK, that's done. --Gareth Hughes 16:20, 25 November 2005 (UTC)
- I think the original idea was to have {{{states}}} representing sovereign states in which the language is spoken, and {{{region}}} representing the areas within those states. This works very nicely for languages that are only really spoken in one part of one country. However, when you try using it for a language which spoken across a number of countries, it makes sense to turn {{{region}}} into a large international area. There are so many templates that leave {{{region}}} blank because there is nothing useful that can be added to what is given in {{{states}}}. I would make far more sense to have just one field for geographical distribution. I would suggest that we keep {{{region}}} as the parameter for this, as it is more non-specific than {{{states}}}. However, I think we should keep the left-column text 'Spoken in:' rather than 'Region:'. It would be fairly easy to build this in as an option (or rather place the current set up in a sub-template as an option, and build the single field into the template). --Gareth Hughes 14:17, 25 November 2005 (UTC)
ISO 639-3
an easy look up for the "iso3" variable in the template is http://www.sil.org/iso639-3/codes.asp?order=name&name=name&letter=n
change the last letter in this url to what you need.
ISO 639-3 has codes for macrolanguages see for example http://www.sil.org/iso639-3/documentation.asp?id=ara click on 'scope: "macrolanguage"' to learn more.
So for Arabic language instead of offering 30 codes in the template it could be considered to use the macro-code. Tobias Conradi (Talk) 12:49, 25 November 2005 (UTC)
Hindi vs. Hindi language
Right now there is a vote to move Hindi to Hindi language. Some of us should get involved in the discussion and voting at Talk:Hindi. —Tox 00:03, 28 November 2005 (UTC)
Proto-Euphratean
I wonder if you could take a look at Proto-Euphratean. It has some style problems, but most importantly, it sounds too speculative and has no sources. I've already tagged it as unreferenced. Searching for "Proto-Euphratean" in the web gives me very few links, mostly directing to email conversations in specialized email lists, and some obscure personal pages. It sounds like a fringe theory to me. --Pablo D. Flores (Talk) 10:42, 15 December 2005 (UTC)
- I think it would be best to talk with John D. Croft about the page he created. I have heard some stuff like this about Sumerian, but this is not my field. The copy is a bit rough round the edges, but it lokks like the work of an adult who hasn't copied it straight out of a book. The user has made numerous useful edits around the subject, and does not appear to be pushing fringe theories. Another article he has started is proto-Afro-Asiatic, which I do think is POV: the entire article talks about the place of the language family within Nostratic. So, the Nostratic line comes over a bit too strongly throughout his edits, but still probably best to go gently. --Gareth Hughes 16:58, 15 December 2005 (UTC)
Hmong-Mien
What should we do with Hmong-Mien languages? I think only Iu Mien has the infobox at the moment, and it's using familycolor=Hmong-Mien, which renders as white. Should we have an extra colour for these languages, or should we use familycolor=Sino-Tibetan? The latter choice doesn't have to display that language family: it just gives the box the same colour as that used for those langauges. --Gareth Hughes 21:54, 23 December 2005 (UTC)
- I think it should have its own color, and that the infobox should be added to other Hmong-Mien languages like Hmong language. As to what the color should be, how about purple? It's not taken yet, and it's in the same part of the spectrum as the other Asian language families we have colors for. --Angr (t·c) 08:26, 24 December 2005 (UTC)
- Purple is a little dark, and so we would have to change the font colour to white: it's possible, but I would prefer not to do that. Lighter purple shades get too close to the colours for Australian and Papuan languages, so I've set it to a fairly bright red (#f03). I'm sure we could probably find a better colour though. --Gareth Hughes 21:49, 3 January 2006 (UTC)
- It looks good! Diolch i ti, a Gareth! --Angr (t·c) 22:07, 3 January 2006 (UTC)
Future of the template
The language template has to go through some changes to comply to WP:AUM. There is no clear way to do this. Netoholic has developed template:Infobox Language independantly and tried to add it to articles without discussion anywhere. There have been complaints that his template does not work and looks ugly. I am fed up with telling this guy that his approach is not wanted. Can we use this page to build a clear, quotable consensus against this approach? --Gareth Hughes 03:29, 6 January 2006 (UTC)
- I'm sure other people understand more about this than I do, but I thought the best way to avoid using meta-templates was simply to subst the ones we have inside the bigger one. I suppose that won't work here so simply for some reason? --Angr (tɔk) 06:19, 6 January 2006 (UTC)
- No, substituting them in won't work, the present template is somewhat dynamic (and overly so). It relies other templates to perform complex operations. In order to fully comply with WP:AUM, you need a template that doesn't include or require any other templates. That is what the new one is being designed to accomplish. Several articles (those languages starting with "C") have all been converted successfully, without losing any information, but Garzo is agressively reverting that progress. I am volunteering to help with this conversion until it's done, but these reverts are really just making extra rework for everyone. I welcome any feedback or requests to be placed here or on the template's talk page. At this point, one consequence I foresee is that we'll need to split up into three templates -- spoken, signed, and constructed. This isn't a big deal, since maintaining three templates shouldn't be a major problem. -- Netoholic @ 08:20, 6 January 2006 (UTC)
- Seriously, do we really need to quote anything to establish that we have one language template that is currently the standard? Isn't Netoholic still on some kind of probation on the explicit condition that he not pull these sort of stunts?
- Peter Isotalo 08:10, 6 January 2006 (UTC)
- Actually, I've been given reprieve for the express purpose of helping with this effort. I understand the "shock" of having your standard template re-invented, and I want to help ease that in whatever way I can. There may be some functions of the template that you're used to that won't function, but I don't think anything major will fail. Right now, you can see how many templates are being called each time an article is viewed by looking at a language article in edit mode. You'll see several templates at the bottom. All the ones with "Language/*", Qif, If defined, Bool*, and switch are involved in the old template. The new one does everything in one single template and greatly reduces the backend processing and database access needed to parse and present the articles. -- Netoholic @ 08:20, 6 January 2006 (UTC)
- After getting upset about various ll-templates and such, I recall having a conversation that IceKarma had with one or more developers relayed to me that stated that the extra burden brough on by templates of this kind are generally "neglibable".
- And the current template was, if I'm not mistaken, quite recently converted into the more advanced format. The design it has now has basically been the same for a year or so. And that includes colors. Why on earth didn't you just insist on the old format instead of pushing a completely new infobox that just steamrolls across old conventions? Just please calm down, try to build some consensus and compromise instead of going off on a anti-template-campaign.
- Peter Isotalo 08:44, 6 January 2006 (UTC)
- I know ways of producing a lot of the functionality, without using meta-templates. I'm not here to re-argue about the validity of WP:AUM... that page is policy by request of the Jamesday (a Foundation database developer) and has been tagged policy by the Arbitrators. I created this new template so that the migration could happen over time. It just isn't practical or necessary to try and revert the existing template back to any old format. What I'm here to do is listen to your project's needs, and provide solutions based on my knowledge. Help me to do that, please, without the accusatory or confrontational stance. I think templates are a great function, and I'm not anti-template. After all, I wrote the original version of Wikipedia:Infobox templates. -- Netoholic @ 08:57, 6 January 2006 (UTC)
- In what way is it less practical to revert the existing template to an older version than to introduce a completely new one? (Assuming that there is actually support for it.) And you really shouldn't be making complaints about the "accusatory or confrontational stance" of anyone when you're the one making seriously provocative and disruptive edits. If you're interested in listening and working in conjunction with other active editors, then stop trying to circumvent consensus in such a obvious manner. You've even opened up that trusty ol' can of worms that is color scheme squabbling.
- Peter Isotalo 11:09, 6 January 2006 (UTC)
- after Netoholic was reverted by several users and it was pointed out that his so called solution (rely on CSS) does not work properly, I regard his edits as strongly offensive. Garzo reverts do not consume extra time, but the hidden introduction of the template and anti discussion behavior of Netoholic consumes time. His personal template should be moved to his user space or to Template:Infobox Language new. Currently his template is blocking a move of the old template to the standard naming scheme for infoboxes. I tried to convince him to not to do this, but he prefers to block and suggests to use his version in the long run. But this would break all the edit history of the true Infobox. I am NOT against improvements that reduce serverload, but the brute force approach is really ugly. Please help to protect the old template and vote for a move Template:Language to Template:Infobox Language. And the private version of Netoholic to moved somewhere else. Tobias Conradi (Talk) 19:31, 6 January 2006 (UTC)
- I have no problem with either merging the histories at some future date, or just letting the histories sit hidden behind a redirect. All this talk of "true infobox" seems like ownership. -- Netoholic @ 23:03, 6 January 2006 (UTC)
- your behavior simply is ugly. to me all this talk with you seems like carry coals to Newcastle. you should be crowned King of Disruptive Behaviour Tobias Conradi (Talk) 03:05, 9 January 2006 (UTC)
- I have no problem with either merging the histories at some future date, or just letting the histories sit hidden behind a redirect. All this talk of "true infobox" seems like ownership. -- Netoholic @ 23:03, 6 January 2006 (UTC)
Bottom line. The current Template:language template is a convoluted meta-template and needs to be changed under the meta-templates policy. I have reduced the problem slightly by changing the way Template:Language/familycolor works (though I initially missed updating a few calls to it on talk pages - sorry) and there are other ways in which it's reliance on meta-templates could be reduced. However, I believe it would actually be easier to update the version Netoholic created to include the same functionality as the current version with NO meta-templates involved. Netoholic has reverted my changes in this regard, but examples can be seen at User:CBDunkerson/Sandbox2. I've only tested the new template with three examples there (boxes on the left are new template / on the right are current template) so many additional tweaks will likely be required, but I think it demonstrates that a single template (no forks) can still cover all the languages and make use of the color coding system. --CBD ☎ ✉ 13:14, 9 January 2006 (UTC)
- Netoholic has made it pretty clear that he doesn't want to work with others on this. It is clear that the rest of us are of the same mind as you on this. I think the improvements you have made are good. I think it would be good to move your version into somewhere central (like template:language/newdraft) and for us to test it thoroughly. So that the edit history of template:language be not lost, I suggest, when we are in agreement, that the new template be moved there. Then the whole thing can be moved to template:infobox language. --Gareth Hughes 13:42, 9 January 2006 (UTC)
- Ok, I've put a current working draft of the template at that location (Template:Language/newdraft) and started a discussion on what needs to be changed there. --CBD ☎ ✉ 14:07, 9 January 2006 (UTC)
- Uhm, hello? How about not moving any template anywhere and thereby keeping the same (shorter) template namespace we've used, like, forever?
- Peter Isotalo 15:21, 9 January 2006 (UTC)
- I think the proposed 'language > infobox language' name change is for consistency with other 'infobox' type templates. Not really my concern though... any name works for me. I'm just trying to get a working replacement for the current functionality before any of the conditional/boolean templates it relies on (Qif, Switch, Booleq, Boolor, et cetera) are deleted and the whole thing breaks. --CBD ☎ ✉ 17:12, 9 January 2006 (UTC)
Circumposition
Does the term actually exist? When I merged postposition and preposition into adposition, I ignored the entry circumposition, which gave a bad example in German and one I couldn't verify in Pushtu. Ruakh has brought to my attention an example of a putative circumposition in Kurdish, but it is questioned by reviewers. Should "circumposition" be mentioned at all, or is it just part of a a bad analysis. Please weigh in with any sources, info or suggestions at talk:adposition.
Peter Isotalo 09:03, 8 January 2006 (UTC)
The bad side of colors
The Template:Infobox Language I presented does work in that it displays all of the information that it should. The color is so engrained in the meta-template (in that the familycolor parameter is matched to a color) that there is simply no way to support that, in a reasonable way, in the new template. It comes down to the article level where, if you look at any language article, there is no "color" parameter. There is only "familycolor" which for most articles has the main language family, not the name of a color. There are only two solutions that come to mind - individual templates for each family (ugh, bad idea) or to hit every article and take familycolor and split that into "family" and a matching "color". That's the technical side of the reasoning.
On my view of the practical side, neither solution is appropriate and we should just use one template for spoken languages with one single color choice throughout. Using the family & color approach doesn't guarantee consistency because a drive-by author could change the color to anything they might like. The color also does not provide any "new" information. Would an average reader even realize what the colors meant or that they related to anything in particular? Would their first thought be that it relates to the Family or something else, like the "spoken in:" or "region"? Would an average reader see limegreen and know immediately that it's an Indo-European language? Can any of you even recite the various color-family relationships without looking?
On a more policy-driven side, the choice of which colors match to which language family is entirely our (Wikipedia's) creation. These colors are not official, but we've designed a complex structure around them. I'm sure in your circles that linguists dispute language families, but at least we can cite a source for using what we do in the genetic classification. We can't do the same for the colors, so on an article like Chuvash language, we really are taking a side in the dispute by so prominently displaying that color.
The genetic classification gives the language family already. The technical, practical, and other concerns about color make implementing that without meta-templates very hard/impossible/impractical, at least for now. I want to work with your group on getting beyond the meta-templates, but it can't happen right now with the colors. Maybe in the future, but we shouldn't wait. -- Netoholic @ 16:15, 9 January 2006 (UTC)
- Very funny: the colours are now in violation of Wikipedia:No original research! --Gareth Hughes 16:57, 9 January 2006 (UTC)
- In addition to being over-thought, arbitrary, unnecessary, ungainly, potentially POV (in cases where there the family is disputed), technically difficult to implement/maintain, ... Yes. I could also add that several of this project's color choices encroach on colors set aside for other Wikipedia:Infoboxs. -- Netoholic @ 17:25, 9 January 2006 (UTC)
- why split? familycolor is only for the purpose of display the color. For the family the "family" or since december or so fam1, fam2, fam3 are used. See Template_talk:Language
- a drive by author could not change it easily because he would have to edit the familycolor-array.
- I don't agree with Netoholic on the technical point. But I have a related question to his other arguments. Does anyone know a color standard? E.g. when I grew up I was to used to have the Indoeuropean languages in red-colors and chinese in yellow. I think color are helpful if used in maps and the colors in the articles provide links in our heads to the maps. Mostly I think this works with worldmaps, but if you have language map of papua you would probably not display 300 slightly different purple colors. Tobias Conradi (Talk) 17:18, 9 January 2006 (UTC)
- Because the "familycolor" parameter in the articles uses a language name, not a color.
- false, this is not a reason, but a desription of what is currently used. So, again: how is this a reason for splitting? Tobias Conradi (Talk) 17:57, 9 January 2006 (UTC)
- That array is a meta-template, that we should be removing from service.
- The only way of adding color information properly would be to add a "color=" parameter to every template call. As I said above, that is hard to maintain as any author could change that as they like. The notion of "standard" family colors is the flawed idea. -- Netoholic @ 17:25, 9 January 2006 (UTC)
- False. The familycolor array is not a meta-template. I converted it already. Nor do I think the change from the format {{Language/familycolor|Na-Dene}} to {{Lanuage/familycolor|if=|Na-Dene=1}} which this conversion introduced is an especially significant impediment to continued use. --CBD ☎ ✉ 17:50, 9 January 2006 (UTC)
- That syntax is unwieldy and is still using two templates where only one should be used. -- Netoholic @ 18:29, 9 January 2006 (UTC)
- The colors have been working very satisfactory for well over a year now, (so much for the arguments about them being too complicated). And if we can state that a language is considered Altaic in the infobox, then it's complete nonsense to claim that it's more misleading to assign an Altaic color. And as for reasoning to keep the colors: they add much welcome color to articles and they're a quick, efficient and non-distracting way of telling the reader the classification of the language.
- Peter Isotalo 04:49, 13 January 2006 (UTC)
- That's the problem... the colors can no longer work as they have. I need an answer from this group. Do we abandon the colors, for the many reasons I've given, or do we keep the colors, by putting explicit color information in every article, and accept all problems with consistency that I described. Those would be the only two options available because we must get rid of the template-within-template scheme. I am sorry about this, the colors were nice while they lasted, but if you want to keep them you have some work to do for the forseeable future. I do need an answer. -- Netoholic @ 06:54, 13 January 2006 (UTC)
- I really think you should take a break from this issue. By now you've presented most of your arguments and complaints at least twice. I think you have a better chance of getting someone to act on your concerns if you just stop nagging and making a fuss over really mundane issues. We're talking a few hundred articles tops. The combined mass of template fiddling and talkpage activity you're generating are probably putting more stress on the servers than the meta-templates ever have.
- Peter Isotalo 21:54, 15 January 2006 (UTC)
- That's the problem... the colors can no longer work as they have. I need an answer from this group. Do we abandon the colors, for the many reasons I've given, or do we keep the colors, by putting explicit color information in every article, and accept all problems with consistency that I described. Those would be the only two options available because we must get rid of the template-within-template scheme. I am sorry about this, the colors were nice while they lasted, but if you want to keep them you have some work to do for the forseeable future. I do need an answer. -- Netoholic @ 06:54, 13 January 2006 (UTC)
- That syntax is unwieldy and is still using two templates where only one should be used. -- Netoholic @ 18:29, 9 January 2006 (UTC)
- False. The familycolor array is not a meta-template. I converted it already. Nor do I think the change from the format {{Language/familycolor|Na-Dene}} to {{Lanuage/familycolor|if=|Na-Dene=1}} which this conversion introduced is an especially significant impediment to continued use. --CBD ☎ ✉ 17:50, 9 January 2006 (UTC)
Many of the difficulties around converting Template:Language into something manageable, but that doesn't use nested meta-templates, is that its function has to cover constructed languages. Your group has established specific row headings and content for conlangs. I'd like to propose that all of the contructed language be moved to this new template, because it is lighter and can be changed without impacting the spoken languages. Maintaining a consistent look between the templates should not be difficult, and in fact, splitting the signed languages into their own template would reap the same benefits. Please take a look at the example here and on Fasile perm link, and provide any feedback/requests on Template talk:Infobox Conlang. -- Netoholic @ 07:15, 12 January 2006 (UTC)
- I've removed the template from Fasile (talk · history · watch): tests should be in user space. Separating out types of language is not the best move, and is not necessary at the moment. --Gareth Hughes 10:52, 12 January 2006 (UTC)
- I've presented about a half-dozen arguments for splitting the templates. You've voiced your opinion, but not presented any reason that counters mine. By splitting the templates, we directly make designing the spoken languages template easier. I value your opinion, but you really need to present specific arguments. -- Netoholic @ 17:24, 12 January 2006 (UTC)
(moved from Template talk:Language)
- I've just got back and found a whole lot of articles with Net's template: removing it. --Gareth Hughes 22:30, 14 January 2006 (UTC)
- As an article is not the place to test a template, it has been removed from Fasile (talk · history · watch). In principle, separating out conlangs may be something that we need to do. However, that decision has to be made by consensus, and I think it would be fair to say that others would support me in saying that this is a step that we don't want to take right now. --Gareth Hughes 10:49, 12 January 2006 (UTC)
- The variant at Template:Language/newdraft handles both natural and constructed languages. --CBD ☎ ✉ 11:27, 12 January 2006 (UTC)
- It handles neither of them elegantly. Your version requires that a color specification be added to every article. If we use mine to migrate the conlangs, only the template name (and image= line, if any) is affected. -- Netoholic @ 17:24, 12 January 2006 (UTC)
- I hadn't implemented default colors for constructed and sign languages. Now I have. It handles both without any extra parameters being required... and allows use of the 'familycolor' system. Or just straight definition of colors in the template call (as you have advocated). No need for different templates for the different types of languages. Why fork when it can be done in one template? Yes, that template then becomes more involved, but the calls to it remain simple/consistent. --CBD ☎ ✉ 00:25, 13 January 2006 (UTC)
- It handles neither of them elegantly. Your version requires that a color specification be added to every article. If we use mine to migrate the conlangs, only the template name (and image= line, if any) is affected. -- Netoholic @ 17:24, 12 January 2006 (UTC)
- The variant at Template:Language/newdraft handles both natural and constructed languages. --CBD ☎ ✉ 11:27, 12 January 2006 (UTC)
BTW, as can be seen at Template talk:Language/newdraft, the alternate non-meta draft of this template now handles natural spoken, signed, and constructed languages. Both the template call and results are very close (and in many cases identical) to the current template. There are still details to iron out here and there (e.g. how to handle template:Language/genetic and sign-languages without a specified genetic origin), but it is in pretty close to 'finished' form. --CBD ☎ ✉ 01:37, 13 January 2006 (UTC)
- CBD! Thanks for your help! best regards Tobias Conradi (Talk) 03:58, 13 January 2006 (UTC)
- Your template is 3 times more bulky than needed. Comparing the rendered page size (not raw wikitext) of Template talk:Language/newdraft and Template talk:Infobox Conlang puts newdraft at about 42kB and Conlang at about 15.5kB (and that's with about .3kB in discussion-related text). This though is not even comparable to how terrible yours looks like under lynx, with confusing repetitious rows and headings. Mine is just much more lightweight and tailored to the specific present and future needs of constructed languages.
- Let me put this in perspective using some other templates that are very similar - those used for people. We have Template:Infobox Prime Minister and Template:Infobox President. These are very similar roles, so why so we split the usage? Ok, let's say we merge them. It takes a little trick coding, but it will work. So now we see that we have Template:Infobox Governor. OK, again very similar and it could technically work merged with the others. Well then we might as well merge Template:Infobox Senator and just make one template for all government office holders, right? Well heck, adding a few more hidden optional lines, we could merge in Template:Infobox Celebrity and Template:Infobox Philosopher too. I suppose we could eventually keep merging in more of these like Template:Infobox Wrestler into one-template-fits-all. Does anyone here think any of those steps makes sense? So why again are we keeping constructed and signed languages together with spoken languages in one template. Visually, each looks radically different, but with a few shared components that could easily be replicated. In the future, more tailored changes can be made without bringing in the possibility of impacting the other language styles. -- Netoholic @ 07:02, 13 January 2006 (UTC)
- Six of one / half dozen of the other to me. At the extremes this issue leads to either one template for everything or one template for each instance of anything (or no templates at all). Obviously the dividing line generally gets drawn somewhere in between where the users feel that the degree of similarity is greater than the degree of difference. My philosophy is to give people what they want / options to choose from. I've shown that it is possible to make them all one template with the same functionality as the current 'nested template' version. I really don't care whether people use that or go another way. That's not my decision to make / not my 'job' here. In my view, the ideal situation would be to first replicate the existing functionality, pass on an understanding of how the new logic works, and then let the community re-jigger it however they like before wide-scale conversion from the existing templates takes place.
- What you say about the Lynx browser is true except that it might be better stated that my added conditional variations make the template look even worse in Lynx than your original version does... which is pretty bad to begin with. There is a solution which makes it look just fine in Lynx, but someone has (until now) consistently argued that there aren't enough Lynx users to care whether we inconvenience them. Or to justify the great burden of four extra characters ('|if=') in the template calls. --CBD ☎ ✉ 11:24, 13 January 2006 (UTC)
- The Conlang template I designed actually has very few CSS-hidden optional fields, and looks damn good in lynx. I can post a screenshot, if you want. -- Netoholic @ 05:29, 14 January 2006 (UTC)
I imagine that template:Infobox Sign language will be new to you: that is, of course, because Netoholic decided to impose his own template once more. Same story... --Gareth Hughes 23:24, 16 January 2006 (UTC)
- I too am perplexed by Netoholic's seeming unwillingness to work with the other editors, while pursuing the admirable goal of reducing the pressure on overloaded servers that meta-templates contribute to. Netoholic's new sign language templates looked very nice in my usual browser (safari), but the original template looks much better in my text browser. Gareth, are you opposed to having seperate templates for sign languages? As an aside, it did occur to me that where spoken languages can have "regulated by", the sign language templates could have the "peak body" — the relevant deaf organisation that supports the sign language. Most sign languages have one of these. ntennis 02:07, 17 January 2006 (UTC)
- There are serious concerns about the accessability of his templates, which compound the fact that they are always implemented unilaterally, without the support of other editors. I am not against splitting off a template for sign languages, that's the way things used to be. I am against doing it if there is no obvious benefit to doing so. I feel much happier working with others to produce a template that will meet all of our needs and reduce pressure on the servers. --Gareth Hughes 12:07, 17 January 2006 (UTC)
- Template:Infobox Sign language and Template:Infobox Conlang, because they are tailored to the specific attributes of those languages, only very lightly uses CSS to hide some optional parameters. The output, even with CSS disabled, is generally quite good looking. -- Netoholic @ 22:04, 17 January 2006 (UTC)
- At the MediaWiki talk:Common.css#CSS hack reduces accessibility discussion on meta-template replacement in general I've suggested a possible compromise. If 'double transclusion' (template which calls a template which does not call any other templates) were allowed on some templates (as it currently is on hundreds) then it would be possible to have separate templates for natural, constructed, and sign languages but use exactly the same template name and parameters to call any of them. This would still vastly reduce the problems caused by meta-templates and indeed might be better for the servers than one big template to handle all conditions. It would also eliminate the problem of needing to add "|if=" to all template calls... because that could be done once in the top level template rather than in each article. The only problem I see with this approach is that it is a 'meta-template'... but only of the most minor and least disruptive sort. In some cases it would actually be less of a server drain than a single large/convoluted template. --CBD ☎ ✉ 12:24, 17 January 2006 (UTC)
I am happy to announce the following polls:
- Wikipedia:Templates for deletion#Infobox Language
- Wikipedia:Templates for deletion#Infobox Conlang
- Wikipedia:Templates for deletion#Infobox Sign language.
As I'm not looking forward to the next time Netoholic decides to spread these all over the article space, I thought we might as well vote them out of use. --Gareth Hughes 14:42, 24 January 2006 (UTC)
CSS hack reduces accessibility
I just learned about a CSS hack being added to a number of templates, including template:Infobox Language, to compensate for a changed policy on template transclusion. I understand that there is an alternative way of recoding these templates ("weeble method"), but the CSS hack is being implemented because it is slightly easier for editors. This hack injects junk code into the body of the page, then hides it from most visual browsers using CSS. This is already in use in several templates, and is being added to many more.
This makes Wikipedia less accessible for users of assistive technologies, like web page readers for the handicapped, and text readers. This is sloppy programming and bad practice from the point of view of web page accessibility, web page usability, and standards implementation. Wikipedia is an open encyclopedia; please lets not start treating the minority who has the most difficult time reading like second-class citizens. Main discussion on this is at Wikipedia talk:No meta-templates. Please make your opinion heard there. —Michael Z. 2006-01-16 19:02 Z
EVERYONE - in order to quash this ForestFire, please follow-up discussion at MediaWiki talk:Common.css#CSS hack reduces accessibility. -- Netoholic @ 19:15, 16 January 2006 (UTC)
Linguasphere codes
It has been mentioned before (by Angr or Mark Dingemanse) that we might think about using Linguasphere codes in language articles. The codes provide a more coherent classification system than that used by Ethnologue, but the latter have become more mainstream by their inclusion in the draft of ISO 639-3. The major drawback with Linguasphere codes is that they look like nonsense (e.g. Turoyo is 12-AAA-ae) unless you take time to learn how the system works (it's a bit like a library classification scheme). I've started referencing PDFs of the codes at user:garzo/lala#Linguasphere codes. If they are used, they probably should have a link to an explanation of how they work. They could either be included in the infobox or somewhere appropriate in the article. --Gareth Hughes 21:57, 18 January 2006 (UTC)
- It wasn't me, I've never even heard of them. --Angr (tɔk) 22:00, 18 January 2006 (UTC)
- It wasn't me either; I remember Mustafaa loosely suggesting something like it. I'm neither for nor against it; they might be of use in the feature but currently the ISO codes seem to suffice. — mark ✎ 18:00, 31 January 2006 (UTC)
- IMO they should be included. Garzo, if you already know something about the codes can you write about them, maybe at Linguasphere language code? 70 000 entries in their database - wao! Tobias Conradi (Talk) 05:26, 19 January 2006 (UTC)
- Sounds like code trivia to me. That Angr hasn't heard of them doesn't exactly make it seem less obscure. I think Ethnologue/ISO is enough.
- Peter Isotalo 16:14, 20 January 2006 (UTC)
Infobox for language families and groupings
Are we ready for an infobox for language families and groupings? I've seen a few places where template:language has been suggested for a group of languages, and one place (Gallo-Italic) where it is used. Obviously, in spite of the difficulty in distinguishing a language with many prominent dialects from a group of related languages, the infobox we have is designed for a relatively unique variety or homogeneous group of varieties. I propose a new infobox designed for classificatory groups of languages. Some of the Austronesian language groups have something a little like this already. I propose that we colour code it to match the language articles (i.e. use template:language/familycolor). I propose that we keep it simple and small: the main focus would be the genetic descent from larger groups, followed by immediate divisions of that group. The only other information I would propose would be geographical distribution and number of speakers of languages in that group (or information on the extinction of the group). Any thoughts? --Gareth Hughes 17:13, 31 January 2006 (UTC)
- I would use the same Infobox. Tobias Conradi (Talk) 17:28, 31 January 2006 (UTC)
- It's been suggested for the Gbe languages too. I have been working on Niger-Congo languages and several of its subfamilies (Volta-Congo, Bantoid, Kwa, etc.); while doing that I thought that some sort of 'navbox' would be nice, in order to be able to navigate through the various subgroupings while keeping track of the context (see Talk:Niger-Congo_languages#Navbox for what I drafted then). Although that's probably quite different from what Gareth is proposing here, I think it is important to capture the hierarchical nature of language families and not only some general facts about the grouping.
- Probably it would be possible to use very much the same infobox, like Tobias proposes. The main difference (apart from ditching language-specific information that's irrelevant to larger groupings) would be that the infobox should not only show higher levels in the phylo-genetic hierarchy, but also lower levels (and what about same-level groupings?). I.e. if you are at Volta-Congo, you should not only see that its parent is Atlantic-Congo, but also that it branches off into Senufo, Gur, Kru, etc; and of course the highest level (Niger-Congo) should be included as well. Whether to include siblings (in this case Ijoid, Dogon, and Atlantic is a separate question, but one that needs to be addressed, too.
- Lastly, especially in the case of phylo-genetic trees, some people might object that this is what the category system is for. — mark ✎ 17:56, 31 January 2006 (UTC)
- I was thinking of something a little smaller than your draft, Mark. I am proposing that only larger language groupings on the direct path to the relevant language grouping be listed (i.e. for a Bantoid language Benue-Congo would be listed, but not Adamawa-Ubangi; Volta-Congo would be listed, and its infobox would have its immediate descendants). I think that showing all higher branches would not be useful: just the path from 'top level'. The user can click back up the path to see the higher branches. Likewise, for lower branches, only the immediate branches from the group in question are needed. The user can click through these to see where they lead. Doing things in this way keeps the infobox small and allows it to be precise. The advantage of your design, Mark, is that it's a static infobox for the entire language family. As Tobias suggested, I think that the extant template:language is the model, but I propose a different template call so that language codes can be stripped out and room made for listing immedate descendents. --Gareth Hughes 18:31, 31 January 2006 (UTC)
- I think we largely agree. I should have been clearer; I didn't mean to propose that all higher levels and all lower levels be included, only the top level and the immediate ancestor and descendents of the group. Just like you were saying, actually. — mark ✎ 18:50, 31 January 2006 (UTC)
- I was thinking of something a little smaller than your draft, Mark. I am proposing that only larger language groupings on the direct path to the relevant language grouping be listed (i.e. for a Bantoid language Benue-Congo would be listed, but not Adamawa-Ubangi; Volta-Congo would be listed, and its infobox would have its immediate descendants). I think that showing all higher branches would not be useful: just the path from 'top level'. The user can click back up the path to see the higher branches. Likewise, for lower branches, only the immediate branches from the group in question are needed. The user can click through these to see where they lead. Doing things in this way keeps the infobox small and allows it to be precise. The advantage of your design, Mark, is that it's a static infobox for the entire language family. As Tobias suggested, I think that the extant template:language is the model, but I propose a different template call so that language codes can be stripped out and room made for listing immedate descendents. --Gareth Hughes 18:31, 31 January 2006 (UTC)
- OK, here's a draft form to have a look at. You can see the template text at user:garzo/Language family, and the template call is in the wikitext of this page. It is very much like template:language. I would like a few ideas about how to improve this. The template call is easy: have a go yourselves. --Gareth Hughes 23:46, 31 January 2006 (UTC)
- An open question... in the genetic classification, is it totally necessary to repeat the name of the language family again at the bottom of the chain? Beyond the slight amount of extra space it uses up, removing it would simplify the template code greatly. -- Netoholic @ 00:25, 1 February 2006 (UTC)
- OK, here's a draft form to have a look at. You can see the template text at user:garzo/Language family, and the template call is in the wikitext of this page. It is very much like template:language. I would like a few ideas about how to improve this. The template call is easy: have a go yourselves. --Gareth Hughes 23:46, 31 January 2006 (UTC)
- @garzo: it might be better to use 'groupname' instead of 'name', this giving the possibility to use the same template. Or if every group has children this can be the point for decision what not to show. What is better use children or a differing param for 'name'?
- use Linguasphere codes?
- what will happen at the top level? no further browsing upstream to find the other languages? top group languages of planet earth :-) - or hey, spoken languages / natural languages? so we clearly separate with computer and sign?
- @Neto: interesting idea. IMO current implementation gives a little bit more clarity.
Tobias Conradi (Talk) 05:35, 1 February 2006 (UTC)
- I was looking for a more elegant way to lead the descending groupings into the child groups, but I haven't thougt of a good way of doing that yet, and they appear in separate boxes. Having the name of the currently viewed group in the middle makes sense to me: it is repetitious, but it shows it as a child of the groups above it and parent of those below. I hadn't thought about using te Linguasphere codes here. It would be possible to show the code against each level in the infobox. However, that might make us feel tied to Linguasphere's system, which diverges in places from traditional classifications, and it might add another degree of complication. I believe that the top level should be the largest widely accepted language family. Thus, in this example Afro-Asiatic is widely accepted, and larger 'super-families' are fringe postulations. Putting anything other at the top would suggest a coherency of the world's languages that cannot be proven. In a few cases, we might want to use slightly less accepted families, like Altaic, or areal groupings like Caucasian, but I think we have to mark such clearly for what they are. --Gareth Hughes 11:24, 1 February 2006 (UTC)
- I see strong coherency for all spoken languages vs non spoken or computer languages. Tobias Conradi (Talk) 00:12, 3 February 2006 (UTC)
- On pages for the 'macro-families' you might do something like have the infobox header be, 'Dene-Caucasian (conjectured)' and then the suggested descendants. I agree that they should not be 'upward linked', e.g. the 'Na-Dene' infobox should not include 'Dene-Caucasian', but the reverse should be true. As to how to present 'downstream' genetic relationships... look at how the 'tree of life' people do it. For instance the Mammal page lists the sub-classes of the mammal 'class' and then the orders in each sub-class. We don't have the corresponding labels for each 'level', but the same principle could be used... list each sub-family and language in the family and (depending on size) possibly each sub-level of those. Maybe make families bold and individual languages italic in such a list. The way life-form lists work is actually just normal wiki-indent syntax with ':', '*', and '#'. The whole list could be done this way, but then it gets into lots of levels of indenting. --CBD ☎ ✉ 12:14, 1 February 2006 (UTC)
- I was looking for a more elegant way to lead the descending groupings into the child groups, but I haven't thougt of a good way of doing that yet, and they appear in separate boxes. Having the name of the currently viewed group in the middle makes sense to me: it is repetitious, but it shows it as a child of the groups above it and parent of those below. I hadn't thought about using te Linguasphere codes here. It would be possible to show the code against each level in the infobox. However, that might make us feel tied to Linguasphere's system, which diverges in places from traditional classifications, and it might add another degree of complication. I believe that the top level should be the largest widely accepted language family. Thus, in this example Afro-Asiatic is widely accepted, and larger 'super-families' are fringe postulations. Putting anything other at the top would suggest a coherency of the world's languages that cannot be proven. In a few cases, we might want to use slightly less accepted families, like Altaic, or areal groupings like Caucasian, but I think we have to mark such clearly for what they are. --Gareth Hughes 11:24, 1 February 2006 (UTC)
- I somehow missed CBD's post, and pressed on: not too far, though. Netoholic has helped straighten out a few bits of the template syntax, and it now works well, looks alright and does a decent job. I've moved the template out into the template namespace: it's at template:language family. I've included it in two articles: Northwest Semitic languages (as I was working on that) and Gallo-Italic (as that was using the other infobox). I don't propose to add it anywhere else as yet, until there is some support for this. Now that I've read CBD's post: proposed super-families could use the box; some, like Altaic, are more generally accepted, if not solid (I mean in comparison to Den-Cau and Nostratic). I propose that we link upwards to the largest generally accepted family, which would include the likes of Altaic (with a note of reservation), but not Nostratic. I would propose that downward links only show the immediate subdivisions of the family. For example, Indo-Iranian languages are quite easily subdivided, but if we listed every complicated branch below that level, the infobox would be huge. Therfore, I suggest that links up follow direct path to largest generally acceptable family, and links down list only immediate subdivisions. --Gareth Hughes 13:07, 2 February 2006 (UTC)
I've just been using simple pink boxes at Continental Celtic languages, Insular Celtic languages, Goidelic languages, and Brythonic languages. I lifted them from North Germanic languages, East Germanic languages, and West Germanic languages. Angr/talk 13:30, 2 February 2006 (UTC)
- I've seen those little pink boxes too. There are also little boxes like those that can be found in the Oceanic languages article. They all do the same kind of thing. Do you think we're ready for a standard infobox for this? --Gareth Hughes 14:46, 2 February 2006 (UTC)
- I don't see why not. Calculating the numbers of speakers of individual branches is going to be difficult though, especially for things like Austronesian and Bantu languages where so many people are bilingual or multilingual in closely related languages that you can't just add the numbers of the individual languages together, or you'll run the risk of counting large numbers of people twice. Angr/talk 15:26, 2 February 2006 (UTC)
- Now that really is a good suggestion: you are right that counting numbers of speakers will become impossible the larger the families get. I think the best thing is to remove that row of the template. --Gareth Hughes 15:32, 2 February 2006 (UTC)
- I don't see why not. Calculating the numbers of speakers of individual branches is going to be difficult though, especially for things like Austronesian and Bantu languages where so many people are bilingual or multilingual in closely related languages that you can't just add the numbers of the individual languages together, or you'll run the risk of counting large numbers of people twice. Angr/talk 15:26, 2 February 2006 (UTC)
Why doen't we use the same infobox as for languages? it has signers, constructed langs and it can have groupings/families too. Tobias Conradi (Talk) 00:08, 3 February 2006 (UTC)
The languages have the iso codes. why can't the families not use the Linguasphere codes? Tobias Conradi (Talk) 00:09, 3 February 2006 (UTC)
- Your draft looks good to me, Garzo. As for the Linguasphere codes, Tobias, I don't think they are as widely used as ISO codes (in fact I've never come across it in my own field, African languages), so I think it would be unnecessary to include them. — mark ✎ 15:42, 7 February 2006 (UTC)
- One more point: to keep consistency across templates, I think we ought to move this to Template:Infobox Language family before it's introduced. — mark ✎ 15:43, 7 February 2006 (UTC)
- I'm all for starting to use it! What are we waiting for? — mark ✎ 15:49, 7 February 2006 (UTC)
- OK, Mark, I'll move it Template:Infobox Language family, and we might as well start using it. --Gareth Hughes 16:06, 7 February 2006 (UTC)
- Okay, but those of us not versed in esoteric syntax need instructions on the talk page! Angr/talk 16:16, 7 February 2006 (UTC)
Some minimal instructions are up on the talk page, and a few editors seem to be using it (or is it just Mark, Angr and me?). Do you think we should place it at the top of articles as we do with Infobox Language? If so, do we want to have the option of strapping a map to the bottom of it too? I realise that, when we get to the top of the tree of language families, the infobox will default to printing the name of language family twice in bold. The way to get around this is by using the back-up {{{family}}} parameter. You could use a text something like "one of the world's major language families; although links with other families have been proposed, none of these has received mainstream acceptance". --Gareth Hughes 14:20, 11 February 2006 (UTC)
- A good idea, Gareth; and thanks for fixing it at Niger-Congo languages. — mark ✎ 17:33, 11 February 2006 (UTC)
- OK, Niger-Congo languages now has the map in infobox at the top. --Gareth Hughes 18:47, 11 February 2006 (UTC)
Alphabet info in languages infobox (bottom maybe?)
That would be great. Such as French Alphabet/Latin or Gothic Language Alphabet/Gothic, Arabic, etc, etc... http://en.wikipedia.org/wiki/Infobox#Languages Ksenon 05:41, 5 February 2006 (UTC)
- There has been a proposal to do something like this for a while. There seems to be some consensus for an optional line something like this, placed below 'genetic classification':
Writing systems | {{{script}}} |
--Gareth Hughes 14:44, 6 February 2006 (UTC)
Historical Languages and Categories
If an ancient language of one country (Lets say Country A) is not spoken now anywhere, not even in that specific country?? Do you think that language must be included in the Category:Languages of "Country A"? I will apreciate a lot any answer to me in my talk page, especially to those who belong to the Languages Wikiproject. User:KRBN 7 February 2006 (UTC)
Peer review requests
Currently, there are two language articles up for peer review: Nobiin language (request) and Welsh language (request). While Welsh did get some reviews, Nobiin I think suffers a bit from its relative obscurity (although it's not much smaller than Welsh in number of speakers). If you have the time, please consider reviewing! — mark ✎ 09:57, 8 February 2006 (UTC)
- Jamtlandic is up for PR as well. The view of non-Scandinavians would be nice.
- Peter Isotalo 16:51, 8 February 2006 (UTC)
Mandarin needs improvement
Mandarin (linguistics) has been nominated for removal as an FA and has so far one vote in favor of doing just so. I was the one who pointed out the discrepancy between its FA status and the actual quality, but I think this can be fixed rather easily. Please help out in any way you can if any of you feel up to it.
Peter Isotalo 07:23, 10 February 2006 (UTC)
Question
I've been a member of the Wiki community for some time now, and I still can't figure out which type of English (e.g. International, British, U.S.) is considered standard for use in Wikipedia. I would guess that it should be the international version, but the article seems to suggest that International English is a term used by most of the world to refer to Commonwealth English (i.e. British). What is the standard?? I just can't figure it out. Let me know on my talk page. Thanks. Fuzzform 19:50, 10 February 2006 (UTC)
- Answered on User talk:Fuzzform. Angr/talk 20:38, 10 February 2006 (UTC)
I wonder how many people are aware that there is a Portal:Language now since the end of December. I only recently discovered it, and only one user, JonMoore, has been active at all in maintaining it. There is also a Portal:Linguistics, which is still very much under construction. IMO we don't need both; Portal:Language can serve as a portal to linguistics as well. Angr/talk 10:17, 11 February 2006 (UTC)
- I totally agree with you: Portal:Language looks like a good start, and Portal:Linguistics should be merged in with it. Like you, I had no idea that either of these existed. Is Wikipedia now too big, or am just not reading the right memos? --Gareth Hughes 12:40, 11 February 2006 (UTC)
Requested merge
I have requested that the new British language (Celtic) article be merged into the Welsh language article. Contribute at Talk:Welsh language. --Mais oui! 11:02, 12 February 2006 (UTC)
Help improve sound symbolism
As an anonymous editor rightfully noted on Talk:Sound symbolism, 'this article is a mess (see further discussion there). I have remedied the most egregious errors, but the subject is worth a well-referenced and well-written article and for that, I thought, we have to turn to Wikiproject Languages. If you feel like diving into the literature on phonosemantics, phonaesthemes, ideophony, Japanese phenomimes and psychomimes and sound symbolism, it's all there waiting for you! — mark ✎ 19:37, 18 February 2006 (UTC)
I've tagged the list in Mutually intelligible languages as containing potential original research. Could someone please point to some reliable references dealing with this subject? Zeneize 20:55, 24 March 2006 (UTC)
- This is an irredeemable article. The concept of mutual intelligibility is inherently POV. — mark ✎ 20:58, 24 March 2006 (UTC)
- Aren't you being a bit harsh, Mark? I mean, it's very clear that, for example, Serbian and Croatian are mutually intelligible while German and English aren't. I think it's just a matter of keeping the info in the article fairly brief and set strict standards for inclusion.
- Peter Isotalo 11:16, 25 March 2006 (UTC)
(disputed)
At the moment, some articles have (disputed) in the classification section of their infobox, e.g. Chechen, Japanese. If we're going to be putting such families in the infobox (Template talk:Infobox language says we shouldn't), I think it would be a good idea to make it clearer that there's a lack of concensus in the linguistic community—at the moment it looks like it's referring to a Wikipedian's dispute à la Template:Disputed. --Ptcamn 12:32, 3 April 2006 (UTC)
- I think we shouldn't have them at all. For one thing, it isn't clear from the single word "disputed" what the dispute is about. For example, with Chechen, the dispute is about whether there is such a grouping as "North Caucasian languages" at all, whereas with Japanese, the dispute isn't about whether the grouping "Altaic languages" exists, but merely whether Japanese belongs to it. Angr (talk • contribs) 12:43, 3 April 2006 (UTC)
- I don't agree with Ptcamn. I think it's fairly obvious that it's not a Wikipedia-dispute simply because there's no link to any pages related to internal disputes. The argument might hold true for regular editors, but I doubt your average reader barely knows about any wikidisputes. Except for really controversial super-families, I don't see why we can't have somewhat disputed classifications in the infobox. If people want to know why they're disputed, they just have to click the link and read up on it. A "(disputed)" can even be a very good motivation for people to find out more.
- Peter Isotalo 17:18, 10 April 2006 (UTC)
Hausa characters
Just looking for some advice on the use of the IPA and unicode templates. At Hausa language#Writing system someone has just removed the IPA template from /r/ and added it to the orthographic letters Ɓɓ, Ɗɗ, Ƙƙ and Ƴƴ. I believe I've read that the IPA template should be used for all IPA characters, including basic ASCII ones, to give a standard appearance. (Can anyone point to a reference for that, please? I can't now find it.) Should it be used for the orthographic characters or not? Should the unicode template be used for those instead? Should the unicode template in fact be used for everything which isn't basic ASCII and isn't IPA, or only for certain things? Thanks for any advice. Gailtb 09:14, 10 April 2006 (UTC)
- I think it makes most sense to use {{IPA}} for, well, just IPA characters and no others. {{unicode}} should be used for other special characters encoded in other unicode ranges. — mark ✎ 10:21, 10 April 2006 (UTC)
- Does the problem with differing displays of simple IPA (/r, a, u/) compared to more specialized IPA really exist? I've never come across it myself. A screenshot would be nice.
- Peter Isotalo 17:08, 10 April 2006 (UTC)
Extended Grammars
I'm sure that English isn't the only language whose grammar can fill an entire textbook, so why not build on and expand the articles on the grammars of other languages? I've noticed that many of them have only one page for their entire grammars. Foxjwill 00:54, 17 April 2006 (UTC)
- I think you'll be interested in WP:LPOV. — mark ✎ 08:01, 17 April 2006 (UTC)
- I don't think Wikipedia is the proper place to write full-fledged grammars. The articles on that should be overviews, not attempts at near-complete descriptions. Why not start a Wikibook instead?
- Peter Isotalo 12:00, 17 April 2006 (UTC)
- Peter, I do agree with your point. I think it is important to fix the issue both ways: by making sure that our articles on grammatical categories and the like are not just about English or Indo-European (this is at the moment the primary target of WP:LPOV), and by providing our language articles with good sections on grammar (because an article on a language isn't complete without a solid section on its grammar). — mark ✎ 13:49, 17 April 2006 (UTC)
Arabic languages/dialects
The decision to subsume all Arabic languages and dialects under "varieties of Arabic" was IMO inadequate and inappropriate. Far from being clear, the distinction in some countries is regularly debated. See Egyptian Arabic and Talk:Egyptian Arabic as an example. Also, two varieties of Arabic, Maltese and Hassaniya, are officially recognized languages, therefore one article would not capture such nuances. Most Arabic vernacular articles that exist are in pretty bad shape and could actually use to be converted into professionally written linguistics-articles. The rest are either stubs (Iraqi Arabic is shocking, IMO, considering the current events) or they don't exist at all (Syrian Arabic)! I have broken down the list into the major branches of Arabic and included articles that have more substantial writing. — Zerida 07:54, 30 April 2006 (UTC)
- I haven't studied the subject, but are Maltese and Hassaniya really considered to be just Arabic dialects on any regular basis? I know that it's definetly not the case with Maltese.
- Peter Isotalo 13:08, 30 April 2006 (UTC)
- No, they're not actually, and I think that's precisely the point. Maltese is a diachronic development from Maghreb Arabic, yet Malta being a non-Muslim European country has had no trouble formalizing the language. While Islam and Arab nationalism nearly always play a role in the decision that all the Arabic vernaculars are "dialects" that are descended from Classical Arabic (not an accurate assumption for many), Hassaniya is an exception. It is recognized in its native Mauritania, a Muslim country, as an independent language and is also a national language of Mali. Yet, the article on Hassaniya IMO is written from a decidedly Arab POV! It starts with "Hassaniya is a Bedouin dialect derived from the Arabic dialect spoken by the Beni Hassān tribes..." No mention at all of the language's status and the double use of "dialect" in the sentence seems rather forced and awkward. Hassaniya looks to me as a sure candidate for conversion to the template. Also, I think the general treatment of the spoken "varieties" of Arabic verges on WP:LPOV. — Zerida 07:44, 1 May 2006 (UTC)
- This seems ot be an issue that concerns separate language articles, not the language project. The project has general guidelines, and there are almost always exceptions to them. Anyone reading the prescriptions here as a set of rules that have to be followed slavishly has misunderstood them entirely. The general structure of the language template is also mostly a recommendation, although a fairly flexible and a quite neutral one.
- I suggest you take matters into your own hands and attempt some rewrites. Good luck with neutralizing the article and don't forget to motivate your changes!
- Peter Isotalo 12:29, 1 May 2006 (UTC)
I want to clarify that the issue does not concern any one particular language, nor simply the NPOV-ness of the articles. As I mentioned before, there are articles that need inclusion because they don't exist or need substantial expansion. Varieties of Arabic, while excellent comparative linguistics, is not the solution. As to whether it concerns the project, I suppose it was made a project issue when the topic of Arabic languages/dialects was included under "Pages awaiting conversion to the template". Initially, they were broken down into each separate language until a decision was made that, in a nutshell, the issue was "too controversial" and the break-down was replaced with varieties of Arabic (discussion is in the archives.) This is what I disagree with. A project like this is in fact perfect for a linguistic topic that clearly gets little attention on Wikipedia. — Zerida 06:59, 2 May 2006 (UTC)
Hey, I didn't know if anyone here wanted to, but it would be nice to get some help for this portal, maintaining and such. Right now I just used previous featured content for the Language and topic of the month. Also, it would be nice to get some input on whether the incomplete Portal:Linguistics should be merged into it, maybe Portal:Language and linguistics? Please let me know. JonMoore 18:12, 18 May 2006 (UTC)
ISO 639 redirects
maybe have a look at Category:Redirects from ISO 639. Tobias Conradi (Talk) 11:07, 15 June 2006 (UTC)
Ashkun, Kamviri, Kati, Prasuni, Tregami, Waigali, (Nuristani languages)
This grouping does not agree with Richard Strand Nuristani classification:
Which one is now correct? I think ethnologue.com is a good idea / website, but they make also errors. --lorn10 16:11 20. June 2006 (CEST)
The time is running, if nobody says a clear logical fact / argument against the better organization from Richard Strand, I will overtake his systematic. This means, that the actual “Kamviri” and “Kata” (Kati) language would be summarized to “Kamkataviri” language. --lorn10 11:54, 29. June 2006 (CEST)
he has kamviri and katavari. if Kati is katavari then don't merge. Tobias Conradi (Talk) 21:18, 29 June 2006 (UTC)
Richard Strand's classification has only 5 main Nuristani language groups, if you look on his page, there are only 2 northern groups, kâmk'ata-viri (Kamviri, Kati) & vâsi-vari (Prasuni). Ethnologue uses 6 main and 3 northern Nuristani Groups:
At second, Richard Strand uses the much clearer and logical native language names, not the legacy descriptions from 1890. --lorn10 21:06, 30. June 2006 (CEST)
The migration to the new language names is now finished. --lorn10 12:35, 8. Juli 2006 (CEST)
Naming standard for language histories
I've added a guideline to the language template on naming language histories because of the somewhat odd tendency to give these articles the much bulkier name format "History of XXX language" rather than the more compact "History of XXX." The use of the former is especially superfluous when applied to articles like history of Latin and Esperanto.
Peter Isotalo 15:46, 15 July 2006 (UTC)
- Hmm... I rather like having History of the English language at that name though, rather than at History of English. Perhaps it's merely because the class I took at university was called History of the English Language and not History of English. (I took advantage of the fuller name to tell people, when they asked me where I was going, "I'm going to HEL!") User:Angr 19:00, 15 July 2006 (UTC)
- shouldnt the history article follow the language article name? Tobias Conradi (Talk) 11:18, 15 August 2006 (UTC)
German-American influence on General American
There's a dispute going on at Talk:General American about a paragraph asserting (without any sources to back it up) a connection between German Americans and the General American accent. It's turning into a revert war; outside opinions are welcome. User:Angr 14:46, 18 July 2006 (UTC)
Vulgar Latin is up for a featured article review. Detailed concerns may be found here. Please leave your comments and help us address and maintain this article's featured quality. Sandy 20:36, 13 August 2006 (UTC)
ISO 15924
Scripts can be coded with ISO 15924. To avoid confusion with ISO 639-3 language codes I also suggested to move some stuff in WP, "User cyr" to "User Cyrl":
On script articles the code maybe could be included as is the lang code on lang articles. Tobias Conradi (Talk) 11:23, 15 August 2006 (UTC)
Although I can't help regularly, I made a few suggestions for the section "Did you know?" at Portal:Language/Did you know/Nominate. If you agree, I can update that part of the portal. Ι have created and I am looking after the Portal:Language of the greek wikipedia (under the username "Valentin"). --Michkalas 16:35, 30 August 2006 (UTC) [Better to answer to the talkpage of the portal and let me know by leaving a message to my talkpage]