Module talk:family tree

@-sche, I know you love fiddling around with the language phylogeny as much as I do. I just wanted to inform you that Kenny's module is up an running again, with improvements! —JohnC5 07:02, 20 November 2017 (UTC)Reply

@JohnC5, Erutuon: That's a very interesting module. Do you plan to make it a public good? Also, I'm no expert, but I can see some ways in which the Romance taxonomy could be improved. --Per utramque cavernam (talk) 21:29, 30 December 2017 (UTC)Reply

@Per utramque cavernam: I was going to suggest copying the module to Module:family tree, but there's already a module there (though it may not work correctly anymore). — Eru·tuon 21:53, 30 December 2017 (UTC)Reply

@Erutuon: If we could get a drop down on the langcat pages with this in it, it would be magical. —*i̯óh₁nC 22:02, 30 December 2017 (UTC)Reply

@JohnC5: I really like that idea. It would be pretty easy to add, aside from the collapsibility part.

It would add a considerable amount of memory to every language category: 20 megabytes or so. I wonder what it would be like if the table from which the tree is generated were saved in a data module. It would have to be updated regularly, like Module:languages/code to canonical name and Module:languages/canonical names, which would be somewhat troublesome. — Eru·tuon 22:41, 30 December 2017 (UTC)Reply

@Erutuon: Are there any other memory requirements for langcat pages besides the langcatboiler? I'm not sure adding 20 MB would be too much of a problem. CAT:English language only uses about 6.5 MB. Also, I would prefer that only the outermost div should be collapsed by default—all the internal ones would be uncollapsed. Then again, it would be easier just to pass in a parameter to the module saying whether to collapse or uncollapse everything. —*i̯óh₁nC 05:08, 31 December 2017 (UTC)Reply

@JohnC5: I don't know of anything else memory-heavy in langcats. Maybe the memory usage wouldn't be a problem. I just like to optimize. And it might be interesting to see what a data module would look like. I agree that the inner tables shouldn't be collapsed; it would be quite annoying if we had to click many different times to view the whole table. Then again, some of the tables would be huge and it might be helpful to be able to get an overview of one level of the tree. An idea: additional buttons for expanding or collapsing particular levels of the tree. (That would require a new JavaScript function, and some way to select each level of the tree.) Then, for instance, you could expand the table for Proto-Indo-European and click a button to hide all but the first level of descent (Proto-Albanian, Proto-Anatolian, ...). — Eru·tuon 05:44, 31 December 2017 (UTC)Reply

@Erutuon: That bonus JS would be up to you; my JS is waaaay too rusty. I almost proposed removing the collapsable tables inside the tree as the lines look much better without the padding on all the internal tables (i.e. the lines join up correctly). —*i̯óh₁nC 06:39, 31 December 2017 (UTC)Reply

@Erutuon, nudge. —*i̯óh₁nC 19:51, 12 January 2018 (UTC)Reply

@JohnC5: Well... how to proceed? The module should probably be moved to an official name. Module:family tree is a good name, but it's used; or maybe it could be moved to make room for this one, since it doesn't work. — Eru·tuon 22:56, 12 January 2018 (UTC)Reply

@Erutuon: I'd say move it. It hasn't been significantly edited in several years, and I don't think Kephir will come to object any time soon. —*i̯óh₁nC 00:15, 13 January 2018 (UTC)Reply

What was Kephir's code supposed to do? --Per utramque cavernam (talk) 12:33, 13 January 2018 (UTC)Reply

@Per utramque cavernam: It looks like it made a nested bulleted list of language descent. — Eru·tuon 20:50, 20 January 2018 (UTC)Reply

Just came to say this is cool. --Victar (talk) 23:18, 28 January 2018 (UTC)Reply

@JohnC5 Any idea why Emilian is excluded from {{#invoke:User:JohnC5/Sandbox2|show|la|yes}}? —Mahāgaja (formerly Angr) · talk 11:47, 19 February 2018 (UTC)Reply

@Mahagaja: I haven't the faintest notion. It looks from a coding standpoint like anything else. @Erutuon, any ideas? —*i̯óh₁n̥C 12:32, 19 February 2018 (UTC)Reply

@JohnC5: No idea. I'll have to do some debugging to figure it out. — Eru·tuon 22:33, 19 February 2018 (UTC)Reply

@JohnC5, Erutuon: Ladin (lld) is missing as well. —Mahāgaja (formerly Angr) · talk 13:40, 22 February 2018 (UTC)Reply

Ladin is there now, because I made a new subfamily for Rhaeto-Romance languages. —Mahāgaja (formerly Angr) · talk 14:00, 22 February 2018 (UTC)Reply

And Emilian is there now too, even though I haven't put it in a new family or anything. Weird. —Mahāgaja (formerly Angr) · talk 14:18, 22 February 2018 (UTC)Reply

But Sicilian is gone. Curiouser and curiouser. —Mahāgaja (formerly Angr) · talk 15:12, 22 February 2018 (UTC)Reply

@Mahagaja: Fixed! It had to do with items being removed in the wrong order when the parent → children map was converted to a tree. — Eru·tuon 19:40, 22 February 2018 (UTC)Reply

@JohnC5, Erutuon: Excellent! Thanks! And is it deliberate that creoles and pidgins are excluded? For example, Bislama and several other English-based creoles have English listed as an ancestor, but they're not listed at {{#invoke:family tree|show|ang|yes}}. Is that because their language family is listed as "creole or pidgin" and not as "Germanic"? —Mahāgaja (formerly Angr) · talk 20:51, 22 February 2018 (UTC)Reply

@Mahagaja: It is, but it can be changed. (See the line that mentions qfa-not, which Module:families/data lists "creole or pidgin" as a subfamily of.) Should I add a switch that turns on creoles and pidgins, or creoles, pidgins, and languages of undetermined family? 21:09, 22 February 2018 (UTC) — This unsigned comment was added by Erutuon (talk • contribs).

Are there any languages of undetermined family, other than creoles and pidgins, that have ancestors? And what about sign languages? They do group into families such as the French Sign Language family, which American Sign Language belongs to. —Mahāgaja (formerly Angr) · talk 21:54, 22 February 2018 (UTC)Reply

Seems to have gotten broken. Just throws a module error now. —Mahāgaja (formerly Angr) · talk 14:12, 3 March 2018 (UTC)Reply

@Mahagaja: I guess it was because a family mentioned in a language data module wasn't found in Module:families/data. Fixed. — Eru·tuon 20:12, 3 March 2018 (UTC)Reply

The complete tree at Module:family tree/documentation isn't showing up. —Suzukaze-c◇◇ 05:25, 21 February 2019 (UTC)Reply

Fixed-but-not-fixed, by not providing the complete tree. —Suzukaze-c◇◇ 05:16, 4 March 2019 (UTC)Reply

Maybe someday I will replicate Wiktionary's module structure on my computer and generate the table without any template include limits and post it... — Eru·tuon 05:19, 4 March 2019 (UTC)Reply

@Erutuon, right now, it seems only parent nodes have etym-only languages listed in the tree. Would be it possible to have child nodes also display etym-only languages below them? Case in point, User:Victar/Sandbox5 only shows the codes below ira-shr-pro, but none of the codes below sgh are being displayed. --Victar (talk) 02:22, 16 July 2018 (UTC)Reply

@Victar: Maybe. I haven't figured out how to do it yet, though. — Eru·tuon 22:01, 18 July 2018 (UTC)Reply

@Erutuon, well, here's to hoping! --Victar (talk) 23:08, 18 July 2018 (UTC)Reply

Languages with no specified family can't make main category pages (see subcategories of Category:Pages with module errors); the error message points back to this module. @Erutuon. Julia ☺ ☆ 17:13, 12 March 2019 (UTC)Reply

@Julia: Fixed. — Eru·tuon 19:49, 12 March 2019 (UTC)Reply

@Victar: The idea of using inconsistent font sizes for a monospaced font mildly upsets me. I'm frankly not sure what you mean by "the codes are too large now and overlapping". What does it look like for you? —Suzukaze-c◇◇ 02:58, 16 March 2019 (UTC)Reply

@Suzukaze-c: This is what your code looks like, https://pasteboard.co/I5CNenF.png, and this is what it should look like, https://pasteboard.co/I5CNQBN.png. --{{victar|talk}} 03:12, 16 March 2019 (UTC)Reply

Ah, I see. I did want to keep the icons small, but I also wanted to have them be 2 characters wide. I couldn't figure out how to do both. The former is more important; I'll give up on the latter. Is it better now? —Suzukaze-c◇◇ 03:29, 16 March 2019 (UTC)Reply

OK, so I changed the em to % that matches the original. Let me know if that still works for your monospace issue. --{{victar|talk}} 04:19, 16 March 2019 (UTC)Reply

Mm, font-size: 90%; means that the font-size for the box-drawing characters is different from the font-size for the languages, which results in a slight misalignment between different levels of the tree. em and % is not actually important here. —Suzukaze-c◇◇ 04:22, 16 March 2019 (UTC)Reply

Ah, I see what you're getting at now. How slight are we talking about here? --{{victar|talk}} 05:13, 16 March 2019 (UTC)Reply

Slight 🤷 1/2 of a character? I really think the easiest solution is removing font-size: 90%; (and perhaps adjusting font-size: 140%;). —Suzukaze-c◇◇ 05:26, 16 March 2019 (UTC)Reply

Working on a solution. --{{victar|talk}} 06:24, 16 March 2019 (UTC)Reply

Wonder if anything can fix the tiny gaps between line drawing characters that I see on my screen. But those might just be rendering artifacts. — Eru·tuon 06:43, 16 March 2019 (UTC)Reply

@Victar: Perhaps I should have asked this question earlier as well: What's wrong with having the font-size be uniform for all elements? —Suzukaze-c◇◇ 07:02, 16 March 2019 (UTC)Reply

The reason the branch lines font size is larger is so the level spacing can be increased, but then the title size needs to stay the same. Thanks for Erutuon enclosing the branch lines in a span, I took the sizing from the other end. Does that work better at all? If not, I'll need to play around with transform: scaleY(N) --{{victar|talk}} 07:08, 16 March 2019 (UTC)Reply

@Victar: Module:family tree/sandbox? It's still not completely aligned for me… I suspect that this sort of micro-adjustment depends very much on the font you use. What's wrong with line-height? If it has to do with how the box-drawing characters (don't) connect between lines/rows, I don't think it can be helped (or one could use a font with very tall box-drawing glyphs?). When I forked the module, I also thought about replacing the box-drawing characters with CSS :before stuff, because I had the same thoughts, but I couldn't figure it out. Thinking about it again, perhaps something could be done with background-image. At any rate, I really think that the only way to keep everything aligned is to have one uniform font size… —Suzukaze-c◇◇ 04:25, 17 March 2019 (UTC)Reply

If you want to try creating a fork with some of your ideas, that would be awesome, but I don't support changing the font size for an issue I don't even notice. --{{victar|talk}} 04:37, 17 March 2019 (UTC)Reply

Eh, it seems like we value different things, and that there is no one solution. 🤷 —Suzukaze-c◇◇ 04:49, 17 March 2019 (UTC)Reply

You probably can override the CSS in your common.css at least... — Eru·tuon 04:51, 17 March 2019 (UTC)Reply

I used the Stylus browser extension before directly editing Module:family tree/style.css. 🤷 —Suzukaze-c◇◇ 04:53, 17 March 2019 (UTC)Reply

(Heh, I use that as well...) — Eru·tuon 04:57, 17 March 2019 (UTC)Reply

Mm, I have a solution for my problem now: Don't use monospaced fonts for the language text 🤷 I still don't think the font-size of monospaced text should be touched, though. —Suzukaze-c◇◇ 05:01, 17 March 2019 (UTC)Reply

I think it would be a good idea to have an override option for generating family trees, however I'm not sure exactly how it would be implemented. If you look at Category:Proto-Bantu language, you can see that the family tree there is an alphabetical list of individual Bantu languages, except for Nguni and Sotho-Tswana. This is just because there are no family codes for other subfamilies, and there isn't really need for them. So it would be nice to override this to show all the subfamilies in a structured tree. Another advantage to this is that it would be easy to change if there are new developments in language classification (Bantu language classification is complex and constantly developing). If anyone has any ideas on how to implement this, let me know. Smashhoof (talk) 22:19, 6 May 2019 (UTC)Reply

If a tree can be stratified, family codes should be created. --{{victar|talk}} 08:53, 7 May 2019 (UTC)Reply

The Prakrit languages have incomplete or empty trees, despite being the ancestors of dozens of languages in the Module:languages data. psu and inc-ash are missing big chunks, and pka, elu-prk, inc-mgd, and pmh are empty. I think the Sauraseni Prakrit family not including all descendants of the Sauraseni Prakrit language could be a problem but that's just a guess. Julia ☺ ☆ 22:08, 22 May 2019 (UTC)Reply

@Julia: I'm not very familiar with the structure of the Indo-Aryan language family and I need some examples to figure out why languages or languages families are being put where they are. Which languages or language families should be shown underneath the Prakrit languages but aren't, for instance under Sauraseni Prakrit (psu)? — Eru·tuon 22:29, 22 May 2019 (UTC)Reply

@Erutuon: You can compare this module's trees to ones at मनुष्य#Descendants and Reconstruction:Proto-Indo-Iranian/pratʰamás and see a lot of missing pieces. (I made them using this module when it wasn't broken as a reference). I'm looking at the tree for inc-pro and it's not reflective of the data. For instance, omr's ancestor at Module:languages/data3/o is pmh, but in this module's tree it's inc-pro. Julia ☺ ☆ 23:01, 22 May 2019 (UTC)Reply

@Julia: Well, as you suggested above, it looks like the reason why Gujarati (gu) for instance isn't under Sauraseni Prakrit is that its family code is inc (Indo-Aryan) rather than inc-psu (Sauraseni Prakrit), as shown here:

m = {
	"Gujarati",
	"Q5137",
	"inc",
	scripts = {"Gujr"},
	ancestors = {"inc-mgu"},
	translit_module = "gu-translit",
}

Fixing the family code will put Gujarati under Sauraseni Prakrit at least, which is a little better, but it should be under Old Gujarati (inc-ogu).

Actually, Module:family tree/nested data/sandbox has a bunch of improvements that fix Sauraseni Prakrit's tree even with no changes to the data. I've merged those changes. — Eru·tuon 23:31, 22 May 2019 (UTC)Reply

@Erutuon: Everything looks in order now; thanks for fixing it! Julia ☺ ☆ 00:45, 23 May 2019 (UTC)Reply

@Theknightwho I've seen that you've changed "etymology language" to "variety" to avoid Wiktionary-only jargon. I don't think that these two terms are synonymous since "variety" can basically be used to describe any language version, but "etymology language" refers to languages that only occur in etymologies on Wiktionary. Yes, it's Wiktionary-only jargon, but that's not a problem because the term describes something that's only relevant on Wiktionary. Tc14Hd (aka Marc) (talk) 03:08, 6 October 2024 (UTC)Reply

@Tc14Hd They aren't just restricted to etymology sections, which is another major reason why we are moving away from that terminology. Theknightwho (talk) 03:13, 6 October 2024 (UTC)Reply

Oh, okay. Btw, I just changed the tooltip message to "Variety" since it still said "Etymology language". The names of some variables still contain "etymology language", they might have to be changed too. Tc14Hd (aka Marc) (talk) 11:54, 6 October 2024 (UTC)Reply

@Tc14Hd Thanks, and yes, you're right. To give some futher context as to why this is happening: the line between language and "etymonology-only" language (i.e. variety) has become increasingly blurred from both directions over time: e.g. Classical Persian (a variety of Persian) has its own transliteration scheme and is one of several varieties that gets added to translation tables, while Chinese, Arabic, Norwegian and Low German (each treated as languages) have varieties that are themselves treated as full languages for most (if not all) purposes. The underlying issue is that "language" has traditionally been Wiktionary jargon for "lect that has its own entries on Wiktionary", which is too simplistic and doesn't always align with the ordinary definition of "language".

There is one other major issue with the tree that still needs to be solved, which is that it doesn't distinguish between "A is a variety of B" and "A is a descendant of B", which has led to all sorts of crap being added to the data when editors have conflated the two things in the language data in an attempt to make the tree look correct. One obvious example of where these don't align is Old Latin, which we treat as ancestral to Latin while also being a variety of it; the tree has no way to show both of those things at the same time. Theknightwho (talk) 12:16, 6 October 2024 (UTC)Reply