Module talk:etymology

Linking

@Daniel Carrero This edit causes uninformative errors such as in entries such as Belize. Checking for term or display text or transliteration before trying to generate a link prevented the module error. — Eru·tuon 17:55, 13 March 2017 (UTC)

Please check Belize again. I did a null edit on it, and the entry looks fine now. --Daniel Carrero (talk) 17:56, 13 March 2017 (UTC)

Oh, you're right. Huh. I wonder what the problem was. — Eru·tuon 18:01, 13 March 2017 (UTC)

Admittedly, it seems that in the middle of my edits, I made some mistake which caused a temporary module error on that entry. But whatever it was, I believe the module is good now. As you may already know, before the null edit, the entry was using a slightly older version of the module. The description of Category:Pages with module errors also advises doing a null edit to see if the error is still there. --Daniel Carrero (talk) 18:09, 13 March 2017 (UTC)

Maybe setting term to - when the code is for a family was what solved the problem. Without that, the module would try to create a link for a nil term and try to call a nonexistent lang:getScripts() method on a language family object. Not sure how the old version of the module handled this situation. — Eru·tuon 18:20, 13 March 2017 (UTC)

Taking term in {{desc}}

There are cases when we know a language has meddled in derivation but the the term is uncertain, such as in κολικός. --Z 08:30, 7 May 2017 (UTC)

Name of {{desc}}

Many usages are for terms that are borrowed not inherited, so it would be used as {{desc|bor=1}}, can we make this "desc|bor=1" any shorter? --Z 08:32, 7 May 2017 (UTC)

@ZxxZxxZ: Why? It's already pretty short.

I suppose there would be two possibilities: coming up with a new template name, and using a numbered parameter. I have no idea what the template name could be, but the next available numbered parameter is |6=. Using a numbered parameter would mean, in the case of {{desc|ar|قَوْلَنْج|bor=1}}, that the code would be {{desc|ar|قَوْلَنْج||||bor}}. A lot of empty parameters, which are best avoided. (Perhaps some parameters could be eliminated: translation is unlikely ever to be used.)

Actually, a third possibility would be making borrowing the default, and hence using a parameter |inh=1 to turn on the "inherited" behavior. Not sure if that's desirable. Is inheritance or borrowing the more common type of derivation indicated by {{desc}}? (Calquing is pretty obviously the least common.) How would we determine which type of derivation occurs most often in Descendants sections, since the template isn't used very widely yet? — Eru·tuon 09:38, 7 May 2017 (UTC)

Did you consider creating a new template? e.g. {{bor}} --Z 09:43, 7 May 2017 (UTC)

Creating a new template is one of the three options I mentioned. {{bor}} is already used. — Eru·tuon 20:16, 7 May 2017 (UTC)

Another problem in Ῥώμη#Descendants: Classical Syriac is borrowing a term, but the arrow should be placed before "Aramaic:" (similar siuation for Hindustani). --Z 14:24, 7 May 2017 (UTC)

(diff) Our common practice has been putting the arrow before "Aramaic" (etc.), which is more accurate. In some cases like Reconstruction:Median/ganzabara- it becomes more problematic, where Classical Hebrew borrows from an undetermined Aramaic language. --Z 12:01, 8 May 2017 (UTC)

@ZxxZxxZ: I've cleaned up the descendents list. I don't see any problem here. --Victar (talk) 14:10, 18 June 2018 (UTC)

Multiple genders

Since I'm still blocked from editing modules (@Chuck Entz), @Erutuon, can you please add |gN= support for multiple genders to {{desc}}? Many thanks. -- Skiulinamo (talk) 06:16, 17 September 2022 (UTC)

Update re etym-only languages

@Benwing2 Just flagging this as an FYI: the language ancestor check has been updated to handle the new type of etym-only languages, and I’ve refined the logic along the same lines as what we had before: languages can inherit from any ancestor, as well as any child etym-only lang of those ancestors, even if the ancestor is an etym-only lang. For example, Romance languages can inherit from any etym-only child of Latin, as they have Latin as an ancestor. On the other hand, Tajik has Classical Persian as an ancestor (which is an etym-only child of Persian). As such, Tajik can only inherit from Classical Persian or its children, but not from Persian itself (or its other children).

I haven’t yet converted any of the ancestral_to_parent langs, which means that that check will need to remain for the time being. Currently, if you set (e.g.) Old Latin as the ancestor of Latin, it causes Module:family tree to go into an infinite loop, which breaks every instance (as it always iterates through every language). Once that’s been updated, we can remove it. Theknightwho (talk) 11:03, 1 April 2023 (UTC)

@Theknightwho Thanks for the update. Benwing2 (talk) 17:21, 1 April 2023 (UTC)

@Benwing2 I'm actually rethinking whether this logic makes sense, as it prevents us from setting (e.g.) Vulgar Latin as the proto-language of Romance languages, as that would cause every instance of a Romance language inheriting from la to throw an error (as only Vulgar, Classical or Old Latin would work). However, we still don't want Tajik to be able to inherit from fa (instead of Classical Persian). I had a chat with @Allahverdi Verdizade about this on Discord, and I think it makes sense to have the test be:

1. If a language has an etym-only language as an ancestor, it can inherit from that language's etym-only children (as currently), as well as its parent(s). It cannot, however, inherit from any sibling etym-only languages. This prevents things like Italian inheriting from New Latin, which is currently (wrongly) permitted.
2. Inheritance from the parent is excluded if the etym-only ancestor is ancestral to its parent. This would catch the Tajik/Classical Persian example. I don't think there's anything analogous with Latin, but if we had another language with Old Latin as its ancestor, it seems right that simple la inheritance should be excluded.

Making this change would open the door to being more specific about ancestry in a lot of cases, without forcing users to go into that level of detail on every entry - which feels like a fair compromise. Theknightwho (talk) 17:32, 3 April 2023 (UTC)

@Theknightwho I think this makes sense :) I haven't worked through some of the specific examples but maybe we actually need to specify what can inherit from what in more detail, e.g. in general all Romance languages can inherit from Vulgar Latin and Late Latin (and Old Latin of course) but not Ecclesiastical Latin, Medieval Latin or New Latin, and I don't see how we can avoid specifying this explicitly somehow or other. Maybe we need a separate "can_inherit_from" tree and specify it for Proto-Romance as having Late Latin and Vulgar Latin in it. Benwing2 (talk) 18:41, 3 April 2023 (UTC)

@Benwing2 So I think it should work if we just set la-vul as the protolang of Romance, because the ancestry chain is already set up for the various etym-only langs of Latin: it goes Old Latin > Classical Latin > Vulgar Latin, so those three will work. However, the tree also has Classical Latin > Late Latin > [the rest], which means they should be excluded. The new model means we can basically treat them like conventional languages for the purposes of ancestry, which is useful. The important thing is distinguishing between ancestors/descendants and parents/children, as the latter is analogous to superfamilies and subfamilies. At the moment, all the etym-only langs of Latin are direct children of la, but there are also cases like Middle Japanese being an etym-only lang of Japanese, but we also have Early and Late MJ, too, which should obviously be children of MJ.

Btw, I have a feeling that setting VL as the protolang of Romance is likely to need discussion first, as I know it's not univesally accepted (because VL is so nebulous) - but it is useful to illustrate the point. You mention LL being an ancestor as well, which already complicates it! Theknightwho (talk) 18:52, 3 April 2023 (UTC)

@Theknightwho Ultimately there's no way to avoid modeling a proper inheritance tree that doesn't care whether a given node in the tree is regular or etym-only, I think. Benwing2 (talk) 18:59, 3 April 2023 (UTC)

@Benwing2 I agree. The problem that I'm unsure how to solve is how we deal with nested etym-only families. For example, do we set the ancestor of Japanese as Middle Japanese or Late Middle Japanese? Probably the latter, but then how do we show this on Module:family tree? Theknightwho (talk) 19:23, 3 April 2023 (UTC)

@Theknightwho It should be Late Middle Japanese, and I wouldn't worry too much how we show it. E.g. we can always show etym languages in one color and regular languages in another color, or something. Benwing2 (talk) 19:34, 3 April 2023 (UTC)