Category talk:English words derived from New Latin languages

From Wiktionary, the free dictionary
Jump to navigation Jump to search

The following discussion has been moved from Wiktionary:Requests for moves, mergers and splits.

This discussion is no longer live and is left here as an archive. Please do not modify this conversation, but feel free to discuss its conclusions.


This automatically generated category name seems wrong. Shouldn't it be Category:English words derived from New Latin. Or isn't the fiction of a single New Latin good enough? This is a very well populated category and would be even better populated if all medical and legal Latin terms used in English had proper etymologies that reflected the nature of the word formation process. OTOH, recognizing the Translingual nature of many of these terms would some reduce category membership, I think. DCDuring TALK 01:42, 23 June 2011 (UTC)[reply]

The problem arises because the template has no way of knowing whether it's a family or a language. I proposed to add a subtemplate called type in a recent vote to handle this, but it was rejected. Until a proper solution can be found I don't think we can fix this. —CodeCat 11:25, 23 June 2011 (UTC)[reply]
The category mentioned in the title ("Category:English words derived from New Latin languages") never existed, but another category ("Category:English terms derived from New Latin languages") existed and got deleted.
The template can know whether a code is of a family. --Daniel 17:07, 23 June 2011 (UTC)[reply]
How can it know that, exactly? —CodeCat 17:14, 23 June 2011 (UTC)[reply]
If {{family}} lists all the family codes, and only family codes, and returns some text only when a family code is given, then {{#if:{{family|{{{code}}}}}|TRUE|FALSE}} returns TRUE when {{{code}}} is a family code, and returns FALSE otherwise. --Daniel 17:20, 23 June 2011 (UTC)[reply]
But it doesn't work for {{etyl|ine}}, because Indo-European doesn't belong to a family. —CodeCat 17:21, 23 June 2011 (UTC)[reply]
What I said is true. If {{family}} fails just because its list of families is incomplete, we just have to complete it. I added "ine" there. --Daniel 17:28, 23 June 2011 (UTC)[reply]
But your fix has broken Category:English terms derived from Indo-European languages. And this seems like a temporary fix at best to me in any case. Beside, I think there are other codes that would fit better in this case, maybe {{etyl:qfa-und}} for undetermined, since we simply don't know the further classification. —CodeCat 17:35, 23 June 2011 (UTC)[reply]
I don't mind using {{etyl:qfa-und}} for that purpose. And how exactly my fix has broken that category? --Daniel 17:41, 23 June 2011 (UTC)[reply]
{{derivcatboiler}} assumes that if {{family}} doesn't return anything, the family is a top-level family and doesn't try to categorise it any further. But now that it does return something, it tries to categorise it into a superfamily. —CodeCat 17:43, 23 June 2011 (UTC)[reply]
If these kinds of problem can't be anticipated reliably and fixed quickly and if the whole endeavor can't be done without making Wiktionary as a whole a playpen, could the categories at least be hidden until the problems are mostly resolved? An abundance of redlinks and bizarrely named categories is not what we need to be displaying to users. DCDuring TALK 17:45, 23 June 2011 (UTC)[reply]
It seems to me that by trying to fix one problem in a bad way we're just creating more problems that need to be fixed in a bad way, too. I would prefer it if there were some unique way to find out if a template is a language family or not. Either a subtemplate such as /type or a switch template like {{codetype}} could work. —CodeCat 17:52, 23 June 2011 (UTC)[reply]

(unindenting) "{{derivcatboiler}} assumes that if {{family}} doesn't return anything," already demonstrates how {{family}} is used to determine whether a code is of a family. I suggest adapting {{derivcatboiler}} to look for "qfa-und" instead of looking for emptiness. --Daniel 18:00, 23 June 2011 (UTC)[reply]

I've made some changes to {{derivcatboiler/ALL}}, it should work now. —CodeCat 18:58, 23 June 2011 (UTC)[reply]
{{derivcatboiler}} still generates the error warning. See Category:English terms derived from Late Latin. DCDuring TALK 19:28, 23 June 2011 (UTC)[reply]
That's just because you used it with something that is neither a language nor a family. --Daniel 19:38, 23 June 2011 (UTC)[reply]
I was just interested in having a useful category, more useful than the monster category of Latin derivations. The lack of proper templates or language names is a technical problem that needs a technical solution or else we have the tail trying to wag the dog again. DCDuring TALK 19:59, 23 June 2011 (UTC)[reply]
I've fixed the template and now the categories themselves work too. But I think it might be better to create proper codes for these, such as {{la-old}}, {{la-vul}}, {{la-lat}}, {{la-med}} and {{la-new}}. —CodeCat 19:44, 23 June 2011 (UTC)[reply]
There may also be a code needed for "Ecclesiastical Latin" [{{la-ecc}}?] for entries so labeled in Webster 1913. Is "la-old" supposed to replace {{la}} or is it supposed to be for pre-classical Latin? I haven't seen, say, {{OL.}} in use. DCDuring TALK 19:54, 23 June 2011 (UTC)[reply]
These templates are prefixed with etyl: right now, the name is {{etyl:OL.}}. Old Latin is the form of Latin before the time of Caesar, I think, especually during the time when Latin was still confined to Italy. —CodeCat 19:57, 23 June 2011 (UTC)[reply]
Thanks. Please let me know when there are further changes. I assume that the old {{VL.}}, {{NL.}}, and similar still work in the individual entry etymology sections. DCDuring TALK 20:04, 23 June 2011 (UTC)[reply]
The problem here is that {{etyl}} is trying to figure out when it should add "languages" to the category name, when the individual {{etyl:foo}} templates should be handling that. The whole point of them is to give {{etyl}} the three things it needs: the category name, the display name, and the Wikipedia article. —RuakhTALK 21:00, 23 June 2011 (UTC)[reply]
And this is what the /type subtemplate was supposed to solve. It would have allowed templates to easily find out what kind of code something is - whether it's a family, a code that should only be used for etymologies, a code that should only be used for appendixes, a normal language, and so on. But now that that proposal failed with no consensus, I'm not sure what other options there are. —CodeCat 21:05, 23 June 2011 (UTC)[reply]
I don't think you understood my comment. :-/   We don't need /type to solve this, because {{etyl}} was already set up to let the {{etyl:foo}} templates solve it. That is the whole reason they exist. They just need to map cat to (for example) Slavic languages now. —RuakhTALK 22:04, 23 June 2011 (UTC)[reply]
But those features aren't documented anywhere, I didn't know they existed. And even so, the derivation boilerplate template does more with the templates than just generate a name. It also needs to know whether to categorise the category "Terms derived from xxx" in "xxx etymologies" (if it's a language) or "xxx languages" (if it's a family). —CodeCat 22:07, 23 June 2011 (UTC)[reply]
Re: Your first sentence: Even so, that is the entire purpose of those templates. (And I don't think you should be making major changes to {{etyl}} without understanding how it works . . .) The reason it's not documented is that those templates as a whole are not yet documented (though some individual ones are). Feel free to add such documentation, perhaps at Template:etyl/doc#Implementation. Re: your second and third sentences: I think that there should be separate boilerplate templates for those two cases. The category-name is different, the supercategory is different, the category text should be different; there's no reason that we should ask a template to autodetect something that is known beforehand, that cannot change, and that has such pervasive effects. —RuakhTALK 22:21, 23 June 2011 (UTC)[reply]

Why are people still discussing how to make autodetection of families possible like we can't do that easily yet? Just use {{family}}. CodeCat knows how to do that. Any other ideas are just alternative ways to solve a problem that doesn't exist anymore. --Daniel 22:27, 23 June 2011 (UTC)[reply]

For the record — in this case, {{family}} was actually the "alternative way[] to solve a problem that d[id]n't exist" to begin with. —RuakhTALK 12:47, 5 July 2011 (UTC)[reply]
Ruakh, there were many layers of problems and their solutions. When the problem discussed above didn't exist, a bigger problem, with a much more cumbersome solution, was taking its place:
--Daniel 18:51, 5 July 2011 (UTC)[reply]