Template talk:etyl/archive 1

Idiosyncratic categorisations
This is looking promising, we may need to retain some of the older style templates for some of the more idiosyncratic categorisations.--Williamsayers79 23:56, 11 February 2008 (UTC)


 * Like what? Seems to me that the etymologies should follow our language divisions.  Either we should have a language template, or the language should go under .  Atelaes 05:12, 12 February 2008 (UTC)


 * Like for those of New Latin, Vulgar Latin, Old Latin.. that don't have specific ISO codes but are very important to distinguish, or macrolanguage families like Germanic or Slavic. Although for some of those there are even ISO codes reserved, like sla. These are useful when a borrowing is very old, and you cannot source it to a specific language/dialect with confidence, so this family-style templates are the only option. --Ivan Štambuk 19:08, 12 February 2008 (UTC)


 * Ah. I suppose language families could be useful.  As for the Latins, I think that if they're distinct enough to distinguish in etymologies, they should be distinguished in language divisions.  As I understand it, EncycloPetey and Ruakh are working on that very thing.  Atelaes 20:24, 12 February 2008 (UTC)


 * I tried this with lang=Kongo, "kr", which has a WP template "Lang-kr". It seemed to call a WP template "lang:kr". Experiment at Pongo or nguba. DCDuring TALK 15:45, 19 April 2008 (UTC)


 * Yeah, the problem was simply that we didn't have . Now, we do. :-) —Ruakh TALK 19:26, 19 April 2008 (UTC)

Another example is Canadian French, which has no specific ISO code, but is sometimes cited in references. I'm sure there are many more examples which aren't considered a distinct language, but can benefit from such a regional qualifier. I'd like to have a  parameter, so I can link to French, but have the displayed link contain the noun Canadian French, not the awkwardly-split Canadian French. —Michael Z. 2008-05-06 17:02 z 


 * I think I can work something out for that. Give me a day or two and I'll try and program it in.  -Atelaes λάλει ἐμοί 23:36, 6 May 2008 (UTC)

Regional language tags
Or is there a sensible way to create, allowing use of to link and categorize to French language, but with the link text Canadian French? —Michael Z. 2008-05-06 22:56 z 


 * I introduced, but I'm reminded that it's not a good idea to multiply the number of language templates by the number of regions. Quoting from WT:BP:


 * {{blockquote|text=We have language code templates for the exact set of languages we use as L2 headers. Creating templates like this for an entirely open ended set of regional dialect (e.g. hundreds of thousands in potential) would be an absolute disaster area. Canadian French is a context label {{temp|Canada|lang=fr}} on definitions. In etymologies, we are always going to need descriptive qualifiers, it is not possible to just add code after code. etyl should be used if and only if the language is accepted as an L2 header and thus is coded. If you simply must use etyl for everything, forcing them into it, then etyl needs a qualifier parameter ({etyl|fr|Canadian}} or some such syntax). (The point made above about sync'ing L2 languages with Ety languages is valid, as long as one keeps in mind that one is syncing L2 languages (with code templates) with a small subset of the huge number of dialects and variants in Etys. Robert Ullmann 14:04, 12 August 2008 (UTC)}}


 * How about the idea of adding a  parameter to the template, to preserve the information when my dictionary reference says “from Canadian French?” —Michael Z. 2008-08-12 15:47 z 


 * Take a look at my failed proposal at User_talk:Robert_Ullmann. Thus far, we have not yet managed to get around the technical aspects of the thing.  But, if you have any bright ideas, I would love to hear them, as I would like to get etyl to differentiate dialects (which is, I think, a more flexible approach than regions).  -Atelaes λάλει ἐμοί 06:10, 13 August 2008 (UTC)


 * It looks like these issues bear further discussion. I'd still like to use purely regional tagging to reproduce a dictionary's notation of something like “Canadian French”, without having to delve into the question of what is a dialect, and hopefully without going through the additional administrative hassle of creating and approving private-use language codes.  Anyway, there's some discussion about this at WT:RFDO.  If that peters out, then I may post a revised proposal to the Beep Parlour. —Michael Z. 2008-08-13 22:46 z 

Limitations
Isn't the whole idea to replace the type template? Well, there is not applicable replacement for this within the scheme, because, even though the Low German article lists "nds" as the ISO 639-3 code, applying this as dyne creates a non-standard category (Low Saxon). Also, I attempted to add a Frisian etymology, but ended up with West Frisian to the exclusion of East Frisian, while my source doesn't distinguish and only mentions Frisian (as I'm sure a lot of dictionaries would). __meco 08:07, 9 May 2008 (UTC)


 * The issue here is that etyl is dependent upon the ISO templates. Now, my Germanic languages are not really up to snuff, but the Wikipedia article seems to indicate that Low German and Low Saxon are different names for the same thing.  If that's the case, then we should probably be referring to that language consistently throughout Wiktionary (we might want to get Widsith in on this).  As for Frisian, it does illustrate a limitation with etyl, which is that it can't do language families, only languages.  The decision was made to treat Frisian as a language family, not a language (and Snakestuben has been doing some excellent work on making this transition).  You may want to ask their opinion on that particular etymology, they may have some useful input.  I'm sorry that I can't offer anything else.  -Atelaes λάλει ἐμοί 08:52, 9 May 2008 (UTC)


 * 1) In many circles (including ISO codes) Low German and Low Saxon are the same thing. "Saxon" has always designated a "low German" branch in any case.
 * 2) It is unfortunate (in my opinion) that ISO call the language Low Saxon, when my impression is that most other sources use the term "Low German".
 * 3) Either term can easily be viewed as being a whole language family rather than a single language. In the Netherlands, several Low German dialects each have official language status.  This is very confusing.
 * 4) The further back you go the more confusing it is. Normally the exemplary proto-low German language is called Old Saxon and the exemplary proto-high German language is called Old High German, but in reality there was a bewildering variety of dialects, especially on the low German side of things.
 * 5) I think what we've done with Frisian is basically a good thing and my reading of the specific problem mentioned above is just that Meco's source is not specific enough, which is more a failing of theirs than of ours.
 * 6) User:Ivan Štambuk might have more to say on all this. My head hurts now.  Widsith 09:26, 9 May 2008 (UTC)
 * Then how do I treat the source which specifies Frisian origin? I mean, do I simply ignore it? That does not seem to constitute an appropriate solution as I'm sure there's a full spectrum variation with respect to degree of specificity from the plethora of sources we may choose from. Also, I would think that any option should eventually be doable with the etyl template alone so we need not have two different templates for the same job. __meco 10:02, 9 May 2008 (UTC)


 * Usually "Frisian" really means "West Frisian"(just like they say Frysk: in West Frisian, but "West Frisian" is a bit more than just "frysk" in English), but there are also distinct languages (not dialects, they are not mutually intelligible) of Saterland Frisian and North Frisian. On Wiktionary these are all treated separate (as they should be). I can imagine that some source would call the word "Frisian" if it's the same in all Frisian languages. Can you state which particular word and it's Frisian source is in question? --Ivan Štambuk 16:29, 9 May 2008 (UTC)


 * Today, Frisian is the language of Friesland, West Frisian. "Back then" when there was such a place as Frisia, Frisian means Frisian (extinct). Yeah, that's astonishingly unhelpful.


 * So, well, how about this for a rule of thumb? For language evolution purposes, if context gives no indication otherwise, then: If it's both in the etymology section, and it's talking about ancient past, Frisian means Old Frisian. (Subject to caveat below.) If it's talking about very recent history, or it's in the related words/cognates section, Frisian means West Frisian. ;-) If it's a proper name, look it up. (And if it's talking about a horse, then it's either a bunch of rooted spears or spikes, or a misspelling of Friesian. Sorry... )


 * In the (extremely unlikely I image) event that a cognate is either of the other two languages, it should say so. (Or any of the other three. I can't imagine any English language source would differentiate that, but now you've seen it. Plus for all I know, some of you may use non-English references, too. If you really want to get into what I imagine is probably akin to a Nynorsk/whatever-it-is type distinction for a language spoken by 10.000 people, let me know. I can't imagine you do.)


 * The caveat mentioned in paragraph 2? Just checking against this wikipedia article, if it's talking 16th century-ish, the proper term in an etymology discussion might be Middle Frisian. I wouldn't want to make that call. Maybe you knowledgeable types have a feel for whether the time periods might parallel, in a highly standardised fashion, Old and Middle English. If they do, then my gut feeling/reasonably confident guess is that taxonomy would port over.


 * If that's not the case, I can't competently opine. Talk to somebody who knows something. Maybe the Frisian Academy no, West Frisian Academy yuck! Fryske Akademy or this guy. (One thing all the Frisian lands have in common--more than their fair share of rather odd, but charmingly so, men.)


 * Mind you, this is just language; not history, which I imagine is quite more complicated, and I haven't pondered that. Snakesteuben 06:44, 10 May 2008 (UTC)


 * Here you go. The relevant time period for Middle Frisian is 1550-1800. (Google is your friend...) If unknown, just say "Old Frisian." Everybody (well, you know what I mean) will know what you're talking about, and you'll already be more specific than 80-90% of the references out there. ;-) Winter (Username:Snakesteuben 08:03, 10 May 2008 (UTC))

A couple weeks ago I answered the question, "What does the widely used but imprecise shorthand 'Frisian' mean in dictionaries and other references in the most common contexts?"

Please select whichever follow-up is appropriate.
 * 1) I'm sorry I inferred the wrong question. Can you clarify what you wanted to know?
 * 2) I'm sorry my answer wasn't as useful as I had hoped. I gave it a fair bit of thought, and I really do want to be helpful. Did you find something in particular confusing? If so, what? Do you have more questions about something I said? Do you believe or suspect something might be misleading or inaccurate?
 * 3) You're welcome.

Snakesteuben 18:20, 29 May 2008 (UTC)

Latin and Medieval Latin
Doesn't work with Medieval Latin derivations. __meco 01:40, 13 May 2008 (UTC)


 * That's because Medieval Latin is just temporal designation, not a real separate language. Use instead. BTW, what is that Frisian word you were wondering about in the section above? --Ivan Štambuk 02:06, 13 May 2008 (UTC)


 * The Norwegian word is dyne. The dictionary didn't say what Frisian word, it wasn't even sure whether it was a Frisian or a Low German derivative. __meco 06:43, 13 May 2008 (UTC)

There is a proposal to add Wiktionary-specific language codes for languages, language families, etc that don't have ISO codes, so that they can used with templates like this. See Languages without ISO codes, where the discussion is linked. Thryduulf 10:36, 13 May 2008 (UTC)

lang=
Would it be possible for someone who knows how to change this template so the second parameter can be called positionally (as now) or with "lang=" as is standard for other templates? e.g. allow and  for fr:Latin derivations. Thanks, Thryduulf 10:43, 17 August 2008 (UTC)


 * That would be pretty simple — just replace  with   and   with   — but are we sure we want to do it? This is already a fairly confusing template in that it takes two ISO language codes; I think it might create further confusion if we added a secondary equivalent way to supply one of those (keeping in mind that as long as both approaches exist, both will be used, and editors will need to understand both). —Ruakh TALK 15:06, 17 August 2008 (UTC)


 * Yes, I agree with Ruakh. I think it a bad idea to make one of them use a lang call.  The problem is that both parameters are lang calls, but if one of them can call it by name, I think everyone will just get more confused.  I think it best to simply leave them both as numbered parameters.  -Atelaes λάλει ἐμοί 17:17, 17 August 2008 (UTC)

Translingual
Not only does this template not categorize words derived frem Translingual ones, it doesn't categorize Translingual words derived from other languages. We have a category for Translingual words from Latin (and there are a lot of them), so why won't the template handle this? Are we stuck with using instead? --EncycloPetey 23:22, 27 August 2008 (UTC)


 * Ummm....I thought that translingual terms were specifically not categorized, which is why etyl does not categorize them. That was supposed to be an extra feature.  Now, I'm seeing a few entries at Category:mul:Latin derivations, but not very many.  If we're going to start categorizing them, etyl is certainly capable of doing so (I'd just need to remove a bit of code).  However, I'm sure I'm not the only one who thought that translingual words were not supposed to be categorized, so I think you'd better start a BP discussion before we go ahead with this.  I'd probably support such a move, by the way.  -Atelaes λάλει ἐμοί 18:37, 28 August 2008 (UTC)


 * Why indeed. DCDuring TALK * Holiday Greetings! 12:49, 3 January 2010 (UTC)

Etymological languages
Issue: (as discussed above and elsewhere) We want etymologies to refer to regional languages, periods, and groupings that do not correspond to ISO-coded languages and our L2 headers.

For example, Canadian French, Late Latin, Germanic (meaning the language group, not Proto-Germanic).

Note that these cannot be simply linked to "w:(language name) language"; the link for Late Latin is Vulgar Latin, others may want to link to sections, etc.

Suppose we do this:

The first parameter to {etyl} may be:


 * 1) an ety-specific name or abbreviation ("Late Latin" or "LL")
 * 2) the name of the language ("French")
 * 3) the language code ("fr")

The template doesn't need the code itself for the first parameter. (The second parameter is always a code, but since it must also always be in our ISO/L2 set, that isn't an issue.)

(2) and (3) can be handled by using instead of. People can then simply wrap the language name in {etyl} if they don't know the code (and we can always convert these by minor magic if we really don't want them):, which will work just like. (I had to look up that code ;-)

(1) is handled by a set of templates used only by etyl&mdash;see and &mdash;that provide the link and the name as needed. Redirects are useful here if we want to use abbreviations as well (probably), or to converge two variant names for the same thing. (e.g. "etyl:Vulgar Latin" might redirect to this as well) The entry is then categorized in "Category:(language name) derivations" as specified in the template, i.e. the template can display a link different from the category. (It could display "Late Latin", link to "w:Vulgar Latin", and cat in "Latin derivations", although in this particular case the latter isn't wanted, we do use Category:Late Latin derivations.)

That gives us an open set of abbreviations, distinct from the language codes. The abbreviations should always be capitalized and not use hyphens, so they don't look like, and are not confused with, the ISO codes.

Further: a language or variant name that people use, but that isn't defined, will work (case 2) and can then have an etyl: template added later that will pick up the existing entries. (And "whatlinkshere" for a non-existing etyl: template does work.)

AF can then convert all of the existing templates to case (1) or (3). Robert Ullmann 09:34, 9 September 2008 (UTC)


 * If you can make that work it sounds like a good idea. My only concern is that opening the second parameter to non-coded languages allows for incorrect names and categories to be created.  For example, someone enters "Romany" and it doesn't get linked, so they create a category (not realizing that "Romani" is our standard spelling).  This isn't a purely academic issue, as we already have this problem with our regional templates. --EncycloPetey 20:46, 9 September 2008 (UTC)


 * note the opposite problem: they don't know a code for Romani, don't know our canonical name, so just get f**king annoyed and either leave the information out or abandon the wikt altogether. Better to accept it; we can, and should, always hunt exceptions and learn from them. Meanwhile, it is likely in a lot of cases to work. Robert Ullmann 01:41, 10 September 2008 (UTC)


 * Agree with EP's concern about etyl accepting plain-text. A huge part of the point of taking templated parameters is to introduce conformity.  However, I very much like your trick with .  I am still a bit confused about the mechanics underlying it.  It seems to me like the very thing that I was trying (but failed) to accomplish with the dialect templates.  I am still of the opinion that this would work better if we make these sorts of things work with a few different templates, instead of just, and I see no reason why we could not do so.  There are a few other places where we would need these, such as , , , and a few others which are escaping my notice.  The code I'm seeing looks like it could fit into these without any problems, but, as I said previously, I'm not fully understanding the mechanics here.  Robert, would you be willing to shed some light on this?  Anyway, this would allow us to create specific standards on how we want to break down languages into dialects, as we need to in some situations.  I have no problem with naming these things in a way which makes them clearly distinct from lang codes, perhaps  could be moved to , or something.  -Atelaes λάλει ἐμοί 00:59, 10 September 2008 (UTC)


 * Okay, I'm going to do a fast "take" on this at 4AM... Naming things (this is "Late Latin") is a very different exercise from coding things. Saying we will essentially define "Late Latin" with some template that specifies the Wikipedia link and the name used to categorize them is easy (and easily changed). Coding, like "la-dial-vul", requires careful, precise definition of each code, its relationship to other codes, etc.


 * Think about it this way: we've named 600+ context categories, without too much work.


 * ISO has coded several thousand languages with the careful work of several thousands of people, spending tens of thousands of man-hours, spanning more than three decades.


 * get it? We can name the dialects, regions, periods, etc; and fix confusions, mistakes, and so on, (including EP's cases, note that and  both already exist :-) coding is out of the question. It is critical that these (1) not look like codes and (2) not be overloaded by other uses (a, context, etc). Just names for things referred to in Etymologies. And we can redirect  to . Robert Ullmann 01:23, 10 September 2008 (UTC)


 * Perhaps this is just my lack of background in programming, but I'm not seeing the gagantuan leap between, say, LL. and la-dial-vul. They're both an abbreviation for a classification that we determined.  In both cases, it's not like we just make it up, but rather we follow standard academic conventions.  Yes, your point is not unfounded that SIL has spent a great deal more manpower (with better qualified people to boot) on their language codes than we could ever hope to put into dialect codes, but I fail to see how that means we shouldn't try.  As for overloading, I think that your example template already contains all, or nearly all, the information that we'd need to implement my idea.  -Atelaes λάλει ἐμοί 04:00, 10 September 2008 (UTC)


 * I agree with Atelaes. One result of ISO, SIL, and W3C's careful work has been the development of a system that anyone can use to tag dialects, including the magic x subtag to separate public parts from private parts. (However, I can't say that I object to human-oriented names like "Late Latin". Any of the options will require that editors learn our naming or coding idiosyncrasies, and the "use names as codes" approach seems the easiest.) —Ruakh TALK 15:18, 10 September 2008 (UTC)

This all sounds good, and I'm personally not too worried about the difference between"LL" and "la-dial-vul", just that whatever we agree on should be noted at Wiktionary::Etymology/language templates so that there is a single place to look up all the codes.

Regarding uses in other templates, could we not create or whatever using the same mechanism? If we want to combine them later, that should be no more difficult for AF than what it is currently doing with L. and F. to etyl|la and etyl|fr etc. Thryduulf 12:12, 10 September 2008 (UTC)


 * Well, for one thing there isn't a one-to-one correspondence between language/dialect and geographic variation in pronunciation. "Late Latin" is a particular period in the chronology of the language, and it doesn't have a particular "accent", since it lies on the cusp of all the various modern Romance languages splitting off.  To express it by analogy, I don't think I could say this word or that word entered Portuguese from "General American English" or from "Geordie" or from "New Zealand English", so I wouldn't ever use those as etymological categories, but I would use all three for accent categories, and many more besides.  Even if these did happen to be both accent and etymological sources, the categories we would want to put words into differs enormously between the two.  When such an item appears in an Etymology, we want it to appear as the name of the category, as in "French derivations" or "Spanish derivations".  When it appears in  we want to mark it as a regionalism, as in "Nicaraguan Spanish" or "Brazilian Portuguese".  So, those templates are doing entirely different things for entirely different reasons. --EncycloPetey 16:33, 10 September 2008 (UTC)


 * Yes, (and a lot clearer than my 4AM comments ;-) etymology sources, accents, dialects, and languages (e.g. what we use at L2) are different things. There are some relationships, but trying to force coding that people will then attempt to use with {a}, or (G- forbid) {context} is not going to make sense, or work.


 * If Late Latin (which is a new term to me; I know Vulgar Latin, didn't know this apparent synonym) is give something that looks like a language code ("la-dial-vul") people will persist in trying to trying to use it everywhere with "lang=", which will almost always be wrong. But then they will go create the categories to "fix" it. (And note Atelaes is one of these, who, supra, said he would like to see them work with {a}, {context}, etc. ;-) There is a difference between names (and abbreviations of names) and codes. These are only names of etymological sources, not codes for dialects.


 * (also keep in mind that ISO/FDIS 639-6 has 30,000 dialect codes, and is due out shortly (months). Trying to code them now just means replacing them all in a fairly short period of time)


 * The proposal here is simply to name some of the useful etymological sources to connect them to the correct WP link and the correct xxx derivations category: would link to Canadian French (not "Canadian French language", which is a redirect to "Quebec French" ;-), and categorize in French derivations. We are not naming or coding dialects, accents, or languages except when they are already ISO/L2 coded languages. To continue this example, "Canadian French" is not a dialect, it is a group of dialects and language variants, Québécois and a dozen others. (You going to code dialect groups? ;-) The {a} template uses/would use "Québécois", "Newfoundland", etc. The {context} template uses "fr". This is a different class of names. Robert Ullmann


 * Since I seem to be fairly alone here, I'll let it go. Just for clarification, you misunderstood what I meant about context.  I didn't intend these as lang= parts of context, but the context itself.  So, for example, if a word only existed in Late Latin, and not in classical, then a context tag could be used to note this.  -Atelaes λάλει ἐμοί 19:18, 10 September 2008 (UTC)


 * Ah, that makes a lot more sense! Sorry to misinterpret. Should add to {etyl} so the above works, and we can look at it? (ATM, the mechanism probably isn't clear. (There is an odd case from what I said above: we don't really need or want {etyl:Romani}, it is an ordinary language with code. So if we had {etyl:Romany}, what would it do? It can't just redirect ;-) Robert Ullmann 19:23, 10 September 2008 (UTC)

source=destination
Should we put the entire transcluded part of this template inside of

or is that not worth worrying about?—msh210 ℠ 19:44, 22 September 2008 (UTC)


 * For those of us who are not au fait with the complexities of #if templates, what would this actually do, and other than increased processing overhead (how much?) what would be the costs and benefits of doing it? Thryduulf 20:07, 22 September 2008 (UTC)
 * It would (unless I've done it wrong) cause nothing to appear in the entry, and no category to be added, either, if the two languages listed (the source and the destination) are the same. It would add overhead, of course, and I have no way of knowing how much, though others will (chime in any time, folks). It would cause "from English foo" (on an English page) to appear as "from foo" which is I think what we want. I don't know how widespread "from English foo" is, but I've seen it myself a few times.—msh210 ℠ 20:35, 22 September 2008 (UTC)

Accomodating language families
Re: WT:BP#ISO 639-5, I've made a version of this template (at ) that handles language family templates found at the etyl: prefix (Robert reminded me that fam is an existing language code, so using that as a prefix could be a problem). It is being used now at cola with the code. Besides looking for the code with a prefix, the new version also appends "... languages" instead of "... language" to the language name for constructing the wikipedia link. If it looks fine, I'll roll that version into the main template here. --Bequw → ¢ • τ 05:45, 8 February 2009 (UTC)
 * This new template works under the assumption that there is no collision between the 3-letter -3 and the 3-letter -5 code? --Ivan Štambuk 06:59, 8 February 2009 (UTC)
 * There isn't. 639-5 was designed to use the same "pool" of 3-letter codes as 639-3, so there won't be a problem with that.
 * OK, no problem then; I interpreted your statement of "disjoint set of codes.." as if using separate namespace of codes for -5 (based on collective codes for -3 but independently expanding). --Ivan Štambuk 20:26, 8 February 2009 (UTC)
 * I like it in general, but I'm not 100% happy about using the etyl: prefix in a way that only works for language groups, since nothing in the prefix suggests that that's what it's for. Ideally should support other kinds of non-languages, such as "Late Latin" or "Canadian French", but as you can imagine, neither Late Latin languages nor Canadian French languages has a Wikipedia article. (I have some thoughts on other approaches, but you probably have a better idea of how you'd want to do it, so I'll hold those back unless you want them.) —Ruakh TALK 23:59, 9 February 2009 (UTC)


 * Implemented, with Ruakh's suggestions. --Bequw → ¢ • τ 07:16, 14 February 2009 (UTC)
 * Could you please update the documentation on new features? Many thanks. --Ivan Štambuk 08:20, 14 February 2009 (UTC)


 * Thanks! :-)  —Ruakh TALK 02:19, 16 February 2009 (UTC)

title= paramater
I was thinking if the title= parameter could be added to this template that would provide alternative display (like title= in, or alt= in ), in order to accommodate the fact that there are several different phases of what Wiktionary treats as one language, all of which are treated under one L2 section. E.g. for Ancient Greek (Classical vs. Byzantine), Latin (Classical vs Late Latin), and probably a few others as well (these two being the most prominent ones).

These periods often diverge in pronunciation of what would otherwise be identically spelled words, but words usually get borrowed by pronunciation not by spelling, hence the more precise diachronic marker would greatly add in value.

Also, this would induce secondary categorization, similar to what is doing now generating not "xx:Latin derivations" but "xx:Late Latin derivations". Not sure for the Greek though. --Ivan Štambuk 00:40, 15 February 2009 (UTC)


 * I might be misunderstanding your idea, but it seems like this is covered by the just-added support for templates named {&#x7B;etyl:…&#x7D;} . For Classical Greek, for example, we can create either (or, I don't know which approach is better), with the content Classical Greek . Then  (or ) would evaluate to Classical Greek . —Ruakh TALK 02:55, 16 February 2009 (UTC)


 * Well, that would work for Late Latin and similar cases, where the categorisation is matched by the altname, but not for Greek where everything from Homeric to Late Byzantine is covered with the same L2 but the underlying phonology has changed immensely so more precise temporal marker would be very much welcomed. So far one'd have to use e.g. "from Byzantine ".., which would yield "from Byzantine Ancient Greek" (which looks weird), and I was thinking of adding direct support like "from ".. , which would retain "xx:Ancient Greek" categorisation but display alternative name and link to different WP article (Medieval Greek in this case). --Ivan Štambuk 03:59, 16 February 2009 (UTC)


 * Yeah, already supports that; it calls the {&#x7B;etyl:…&#x7D;} template three times, once with argument disp (to get "Byzantine Greek"), once with argument cat (to get "Ancient Greek"), and once with argument pedia (to get "Medieval Greek" — or just "Byzantine Greek" again, since Byzantine Greek is a redirect to the right place; and personally, I think it's better to link, whenever possible, to the same thing we're displaying). So the template's content could be  instead of Byzantine Greek . This way, it's easy to standardize; a single {&#x7B;etyl:…&#x7D;} template holds all the information about how we want to handle Byzantine Greek derivations, and editors don't need to worry about it too much. —Ruakh TALK 01:34, 18 February 2009 (UTC)


 * Oh, I see some of those parameters you mention in the code, but none in the documentation. If it's not documented - it doesn't exist. --Ivan Štambuk 02:01, 18 February 2009 (UTC)


 * I don't disagree, but the documentation here is directed at "normal" editors — people editing pages. For people creating {&#x7B;etyl:…&#x7D;} templates, I think Template:etyl?action=edit is fairly O.K. documentation. Unlike many of our templates, it's pretty straightforward. (I'd never expect "normal" editors to look at template source-code, but I don't think it's nuts to think that an editor creating one ParserFunctions-using template can read another one.) But again, I don't disagree with you: if you want to add developer documentation, that would be great. :-D  —Ruakh <i >TALK</i > 20:14, 18 February 2009 (UTC)


 * "Use the source, Luke" approach doesn't really work with one of the ugliest programming languages ever invented :) I actually did glanced upon Bequws's diff, and noticed the newly-added support for ISO 639-5 codes, but have somehow missed these other news goodies. Immediately after I asked him to update the docs, which he did, and the newly-updated docs did not make mention of any of the stuff you describe, so there was no way for me (or anyone else not inspecting the code, and given the recent discussions that would be at least one more editor) to know that the support for 3 additional parameters was there. Keeping documentation in sync with with the production code is one of the basic tenets of software engineering, as is illustrated by the If it's not documented, it doesn't exist maxim. --Ivan Štambuk 21:29, 18 February 2009 (UTC)


 * :-)  —Ruakh <i >TALK</i > 21:37, 18 February 2009 (UTC)

Incompatible dual purposes of etyl?
It seems that etyl has two purposes. The primary being to standardize language names in etymologies including making a nice link to a Wikipedia article. The secondary being to automatically add the page to a category.

But the categorization seems overzealous. It always adds adds to a category which says the current term is derived from the mentioned term. This is far from being always the case. So what is the correct procedure when a mentioned term is not a direct ancestor? Should etyl be avoided all together or is there a parameter I'm missing or is it time to add some new parameters? For an example see this edit: &mdash; hippietrail 23:44, 15 February 2009 (UTC)
 * Read the docs: use "-" as a second parameter. --Ivan Štambuk 00:02, 16 February 2009 (UTC)

Adding a sort key
Could a sort key be added to ? While English doesn't really need it, Catalan sure could, especially Category:ca:Latin derivations which has 18 out of its 282 current entries missorted. I imagine other languages with diacritics could use it as well. Carolina wren 05:12, 25 March 2009 (UTC)


 * Done. -Atelaes λάλει ἐμοί 05:40, 25 March 2009 (UTC)


 * Thanks for the . Carolina wren 05:53, 25 March 2009 (UTC)

Non-linking some languages.
There are some editors who aren't using for languages where the Wikipedia-link seems unnecessary. (I mean, how useful is a link to English language?) I see three ways to address this:


 * 1) We can berate the editors in question. A good thrashing should put them right. ;-)
 * 2) When  exists, the template can check if  is the empty string, and if so, not linkify. (Then we could create  and have it return the empty string when 1=pedia .)
 * 3) When  does not exist, the template can check if  and  are identical, and if so, not linkify. (That is, it would check to see if  is a link, under the assumption that if we don't linkify it in translation tables, then we don't need to linkify it in etymologies.)

My preference is to do all of the above.

—Ruakh <i >TALK</i > 16:25, 8 January 2010 (UTC)


 * Too much use of resources required for the technical options. More economical: berating + stronger sanctions, leading to public (or at least well publicized) corporal punishment (eg. waterboarding). DCDuring TALK 17:16, 8 January 2010 (UTC)


 * Do you mean, too much use of technical resources? Or too much use of human resources? Because the former isn't really our concern (within reason, anyway), and it seems like corporal punishment would require even more of the latter …
 * So in all seriousness, are you saying that you don't support changes 2&3?
 * —Ruakh <i >TALK</i > 15:36, 9 January 2010 (UTC)
 * I am increasingly bothered by sluggish performance, not all of which I can lay at the feet of (idiom, non-idiomatic metaphor) my ISP. I don't know the nature of the resource-consumption, download-time, and latency trade-offs for this, nor how they affect non-editing vs. editing users. What is the actual harm caused by having a blue-link for English? Is it aesthetic? Is it performance? How often do users click on the language links in the Etymology section? How often by mistake? Is it possible to have hover-activated boxes that contain links to WP language articles that consume less resources and meet the aesthetic or other objections to the existing arrangement? DCDuring TALK 16:31, 9 January 2010 (UTC)


 * Any of the technical solutions sound fine. I think it's only 1 or 2 conditions per instance, which doesn't seem that much for the server (but someone w/ more knowledge please correct me). And berating users seems like it would take more human-time. --Bequw → ¢ • τ 17:13, 9 January 2010 (UTC)


 * So, uh, what's the conclusion? Can I go ahead with nos. 2 and 3? —Ruakh <i >TALK</i > 01:16, 4 February 2010 (UTC)


 * Not to answer your question (that is, I'm not saying what the conclusion, but merely what my own opinion is): I like option 3. I like something like option 2: perhaps check whether is defined as empty in etyl:en, and not link; otherwise link to  if  is defined. (How do we currently specify, in the etyl: templates, WP articles other than the displayed text? Do we?) &#x200b;— msh210 ℠ 16:48, 4 February 2010 (UTC)


 * (for example) calls three times: once as  (to get the language-name to display), once as  (to get the name of the Wikipedia article to link to), and once as  (to get the language-name that goes in the category name). In each case,  is expected to return a plaintext string; it is  that handles all wikisyntax, including linking to Wikipedia. In the general case, an etyl: template that wanted to display, link, and categorize in three different ways could be coded as  . But most such templates use the same text for all three, so don't need to bother with the switch. —Ruakh <i >TALK</i > 17:17, 4 February 2010 (UTC)
 * Oh, thanks for the explanation. Then, yes, I support option 2 as you stated it in the first place. &#x200b;— msh210 ℠ 17:22, 4 February 2010 (UTC)


 * O.K., I've done nos. 2 and 3. Note that they'll take a while to clear the job queue. —Ruakh <i >TALK</i > 17:20, 8 February 2010 (UTC)

We do need some form of link for el, since "Greek" is often mistakenly used to mean "Ancient Greek" (grc) in the etymology section. Most people don't realize the ISO codes are different.

BTW; the change to ought to be noted at news for editors by someone who can concisely explain the change. I was a little surprised at first when common languages were no longer linked from in the etymology sections. --EncycloPetey 03:24, 10 February 2010 (UTC)


 * Re: el : what we really need is for that one to say "Modern Greek". Unfortunately, due to an AutoFormat error a while back, the great majority of entries using actually mean Ancient Greek, so I don't think we can make the change until they're fixed. (Currently the wiki-text is technically wrong, and the content is inconsistent; but if we changed the text and/or restored the link, then our content would be actually wrong.) There are definitely steps that we could take in the meantime, but when I proposed them, a few editors claimed that they were the ones working on fixing these, and they objected to any sort of interim fix. So, whatever. If you want to propose something new, be my guest. :-)
 * Re: News for editors: Good idea, thanks. Done.
 * —Ruakh <i >TALK</i > 12:54, 10 February 2010 (UTC)

Why link to Wikipedia instead of <name-of-language>#Proper_noun ? That entry can then have a linkbox to the WP article. --Jerome Potts 22:44, 23 December 2010 (UTC)

Language links
Re: above, would it be possible to have a preference to link all languages using etyl? Nadando 06:18, 17 February 2010 (UTC)


 * Good idea. In the case of the languages that aren't linked here because they aren't linked in translations tables, this is definitely possible; we just need to wrap the language-name in some sort of hook for JavaScript to search for — something like &lt;span class="etyl"&gt;English&lt;/span&gt;, say. (I'm thinking we can provide the hook whether or not the name is linkified; the JavaScript can distinguish that easily.) In the case of languages that aren't linked here because their {&#x7B;etyl: foo &#x7D;} templates don't specify a Wikipedia article to link to, we can still do this, but there's no guarantee there'll be an actual article at the other end of the link. But for right now, there aren't any {&#x7B;etyl: foo &#x7D;} templates that do that, and I don't expect that that will be common, anyway.
 * (Personally, I don't think I want such links, but I would like to customize the styling of these language names: I find it disconcerting that it's no longer obvious whether an entry is using . A JavaScript-hook such as I describe would double, conveniently enough, as a CSS-hook.)
 * —Ruakh <i >TALK</i > 16:21, 17 February 2010 (UTC)


 * ✅ since no one objected. It's the "Always linkify language-names in etymologies" pref at Preferences. The JavaScript for it is at User:Ruakh/WiktEtylAlwaysLink.js; feel free to make improvements. —Ruakh <i >TALK</i > 01:24, 22 February 2010 (UTC)


 * Thank you so much. Nadando 02:04, 22 February 2010 (UTC)


 * Why did i find it in only the per-browser preferences, and not in "My preferences" ? --Jerome Potts 22:39, 23 December 2010 (UTC)