Template talk:descendants tree

One of the shortcomings

 * Re "The template should collapse the descendants tree under certain circumstances, particularly when it's rather long. This helps with keeping an overview and avoids the descendant lists becoming too long on the transcluding page (particularly PIE).", shouldn't we use instead when it would become rather long? --kc_kennylau (talk) 04:04, 5 March 2017 (UTC)
 * The idea is to make unnecessary while still keeping the length manageable. —CodeCat 13:35, 5 March 2017 (UTC)
 * : In that case redirect to see desc if more than 10 lines? --kc_kennylau (talk) 15:05, 5 March 2017 (UTC)
 * Huh? —CodeCat 15:08, 5 March 2017 (UTC)
 * I'm actually really happy it doesn't collapse. I think there are some places works and others where  is the best choice. I prefer using  on PIE entries and for borrowing descendants. --Victar (talk) 01:56, 19 April 2017 (UTC)

Ideas and bug reports
et al, I have few ideas and bug reports: --Victar (talk) 00:45, 19 April 2017 (UTC)
 * Right now it's a bit annoying that if I want to list alternatives for an entry, I have to list them before the, as opposed to order of commonality, etc., as I normally would, i.e. . The solution that comes to mind is to have an altN parameter, i.e..
 * ✅: Sometimes I'd like to be able to add a qualifier after the on the same line, but instead it sends to the bottom of the list, i.e.  . It would be great if a q parameter could be added to accommodate this, i.e..
 * ✅: I'm wondering if it wouldn't be a good idea to include lead text with the language name, like we do with and, especially if we get the order issue resolved. I realize that would break all the current uses, but perhaps we could run a script first to add   them all. Alternatively, if we can't get the order issue resolved, maybe a   option would be better.
 * This is already mentioned on the template page, but we really need a working id parameter for entries with multiple descendant trees.
 * ✅: Descendant trees with columns, i.e., break , so that needs fixing as well, most easily by simply filtering them out.
 * How about programming the alternative forms into the descendant tree data module, so that when you type, it will automatically display the alternative forms and ? — Eru·tuon 04:44, 8 May 2017 (UTC)
 * Hmm... never mind. I was thinking of the other module that uses a data module listing the descendants. Since this grabs the forms from the entries, perhaps we could get the alternative forms from the Alternative forms section and display them somehow. — Eru·tuon 04:48, 8 May 2017 (UTC)
 * Could you point to an entry in which the problem related to alternative forms has cropped up? Are you referring to, or somewhere else? — Eru·tuon 06:12, 8 May 2017 (UTC)
 * I have plenty of examples, but to give a recent one, let's take 🇨🇬. In the descendant tree I have OF:
 * OF is the common form, but because I want to be able to use, I have to put it last. I'd like to be able to do this and have it work:
 * However I think I'm going to have to settle for this, which is not a bad solution, but it loses some of its flexibility:
 * --Victar (talk) 14:09, 8 May 2017 (UTC)
 * Ahh, that helps me understand. Well, I think a better solution would be to put both the alternative forms into the Alternative forms section of the Old French entry, and add a function to Module:descendants tree that grabs the alternative forms. Then, if you type, it would display the alternative forms and  along with . — Eru·tuon 14:25, 8 May 2017 (UTC)
 * , that's a great idea I hadn't even thought of! Wanna help me code it? =) --Victar (talk) 15:16, 8 May 2017 (UTC)
 * I'm working on it now... It's kind of complicated, so my code might not even work. Take a look after I save it. — Eru·tuon 15:18, 8 May 2017 (UTC)
 * Awesome! Yeah, you can probably just do a straight-up copy-paste of, have it look for  instead, and some tweaks to the parsing code. --Victar (talk) 15:25, 8 May 2017 (UTC)
 * I got it to work in the main module! I tested the example at Template:desctree/testcases and the example on the template page, and they both look good. — Eru·tuon 15:37, 8 May 2017 (UTC)
 * The only caveat is that Alternative forms sections using instead of  will have to be corrected before the module can parse them. — Eru·tuon 15:42, 8 May 2017 (UTC)
 * Hey, that's great! I knew it wouldn't be too hard. I was only vaguely aware of, so I'm happy to use it more often, though, why it wasn't named , I have no clue. Would it be possible to run a bot script on all existing entries to add 1 so we don't have duplicate alternates listed before we clean-up and 1 to disable the language name prefix I'm adding, so they aren't doubled? --Victar (talk) 15:53, 8 May 2017 (UTC)
 * I think there won't be duplicate alternative forms, because till now it has not been possible to show them while using, which was one of the reasons why you started this thread. But the 1 would be a good idea. The language name should be added by rather than having to be typed out. — Eru·tuon 16:43, 8 May 2017 (UTC)
 * Cool, well if you or someone else can run that bot, I'll add my changes from . --Victar (talk) 17:02, 8 May 2017 (UTC)
 * I don't have a bot, but might be able to help. — Eru·tuon 22:04, 8 May 2017 (UTC)
 * Could you explain explicitly what you want done? DTLHS (talk) 22:27, 8 May 2017 (UTC)
 * Search for all usages of and add 1 to them all. Thanks for any help! --Victar (talk) 22:35, 8 May 2017 (UTC)
 * Done. DTLHS (talk) 23:10, 8 May 2017 (UTC)
 * Thanks a ton! edits made. --Victar (talk) 23:21, 8 May 2017 (UTC)
 * Search for all usages of and add 1 to them all. Thanks for any help! --Victar (talk) 22:35, 8 May 2017 (UTC)
 * Done. DTLHS (talk) 23:10, 8 May 2017 (UTC)
 * Thanks a ton! edits made. --Victar (talk) 23:21, 8 May 2017 (UTC)

Now, would you be willing to run another set of edits removing the  before, and the 1? — Eru·tuon 00:03, 9 May 2017 (UTC)
 * , could you have a look ? It looks like a nesting issue, or is it just old cache that hasn't worked it's way through? --Victar (talk) 00:05, 9 May 2017 (UTC)
 * It's not cache, because it remains when I edit the page. Yeah, it's a nesting issue, because uses . It didn't crop up before? — Eru·tuon 00:20, 9 May 2017 (UTC)
 * No, no previous nesting issues. Must be due to some changes on my end. --Victar (talk) 00:25, 9 May 2017 (UTC)
 * I found and reintroduced the code that allowed to be replaced with  in Module:descendants tree. — Eru·tuon 00:28, 9 May 2017 (UTC)
 * Hah, I see you pasted in the fix before I could. Guess I mistakenly removed that. --Victar (talk) 00:29, 9 May 2017 (UTC)
 * I think this should be done by hand. I found many cases where the template is not on its own line. DTLHS (talk) 00:29, 9 May 2017 (UTC)
 * In addition, some pages use the code "la" but have the text Late Latin, so I would be removing that information if I removed the text. DTLHS (talk) 00:31, 9 May 2017 (UTC)
 * Yeah, plus we need to adjust the order, which update fixed. Thanks again! --Victar (talk) 00:52, 9 May 2017 (UTC)
 * I'm a bit puzzled why this solution was taken. An alternative could have been to make only show descendants, and not show the link, leaving that to . Then you'd be free to position it wherever you like. —CodeCat 01:45, 9 May 2017 (UTC)
 * strikes me as a pretty sloppy solution. Pulling from the alternative forms section is far more elegant IMO. --Victar (talk) 01:52, 9 May 2017 (UTC)
 * Until it doesn't work. There may be too many alternative forms, or there may be minor spelling variants that are not worth putting into a descendants section. That kind of judgement would formerly be done by editors, now that control is taken away. I don't think I'll be using the new desctree template, I liked it in its original form, before it did all these weird things and before it included the language name. —CodeCat 13:41, 9 May 2017 (UTC)
 * Don't be such a sour-sport just because we changed your module. You can always use 1 and you can create noalts to add your variants separate form what's in . The control is still in the editor's hands. --Victar (talk) 14:14, 9 May 2017 (UTC)
 * I'm not upset with people changing modules I created, as long as the changes are actually good. I don't think these are good. As I said, it should be made so that it showed only the descendants, allowing editors to remain free in how the descendants are shown. Also, is a pain for editors who want to edit existing descendants section, so integrating it into this template is also bad. —CodeCat 14:20, 9 May 2017 (UTC)
 * I think you may be alone in that opinion. People seem to have taken a keen shining to . --Victar (talk) 14:23, 9 May 2017 (UTC)

POS
or

POS
or

Alternative forms
, so, any idea how to start with getting id to work? For instances, I need to grab the descendants under Etymology 2 on this page through. --Victar (talk) 06:25, 14 May 2017 (UTC)
 * : I'm trying to get id to work by simply filtering out all content before the matching occurrence of senseid. Doesn't seem to be playing nicely though. --Victar (talk) 17:39, 10 June 2017 (UTC)
 * It's not that simple. Sense ids are typically in POS sections, and alternative forms sections are either before or after them. When they're before, they're either at the same section level as or one level higher than the POS section, but when they're after, they will be at one level lower. See the outlines I added in the box above. — Eru·tuon 17:53, 10 June 2017 (UTC)
 * Maybe you're thinking about termetym. For desctree it doesn't matter because senseid will always be above its respective descendant tree. --Victar (talk) 21:05, 10 June 2017 (UTC)
 * Oh, I see. Yeah. I would grab content between the header after the sense id and the next header that is one level higher. — Eru·tuon 21:47, 10 June 2017 (UTC)
 * Yeah, so I thought  would do the trick, but apparently not. --Victar (talk) 21:56, 10 June 2017 (UTC)
 * It looks like what's happening the  below is expecting the whole page content but is freaking out when it can't find it; it being the language header. --Victar (talk) 01:36, 12 June 2017 (UTC)

Adding qualifier
It's a good idea to fetch and show the qualifier when showing an alternative form, for example for Middle Persian we add the script / language variant as qualifier, e.g. in. --Z 06:06, 7 June 2017 (UTC)
 * I agree, but first some changes need to be made to alter, primarily allowing qualifiers for each entry, instead of all of them. If not, we need to stop using alter in tandem with desctree and desc. can we start moving forward with some of these changes? --Victar (talk) 12:07, 7 June 2017 (UTC)
 * So, I'm fine with adding params to alter. To be clear though, we're not talking about merging across dialects, correct? — JohnC5 15:55, 7 June 2017 (UTC)
 * I'm fine with q n being added, but not with the old parameter format being removed, as that would be a dramatic change and would require a lot of work, and I'm not sure it's necessary. — Eru·tuon 17:23, 7 June 2017 (UTC)
 * I'd definitely want to eventually do away with current 4 mechanism, but I'd be happy to start with just adding qN for now., The amount of work an improvement would take is irrelevant if there are people like myself who are willing to do it. =) --Victar (talk) 18:53, 7 June 2017 (UTC)
 * Okay, so the amount of work isn't really a sufficient reason. It could be done by bot anyway. — Eru·tuon 19:22, 7 June 2017 (UTC)
 * Also, I suspect that Module:descendants tree can be made to recognize the existing qualifier format. — Eru·tuon 20:19, 7 June 2017 (UTC)
 * It occurs to me that another reason you want to change is because currently Module:descendants tree only fetches the content of one ... that is a design flaw that should be fixed. I'll work on it at Module:descendants tree/sandbox. — Eru·tuon 20:41, 7 June 2017 (UTC)
 * Exactly. They're all the puzzle pieces I'm trying to jam together with a hammer. Thanks . --Victar (talk) 20:58, 7 June 2017 (UTC)

Edit links for subpages
Can a feature be added so that an edit link is shown to the right of a term if its descendants are listed on another page? A user should be able to click this link to edit the tree, without having to figure out what content is on which page. The edit link should be right aligned or not, depending on whether the user has this preference set for regular edit links. —CodeCat 22:27, 14 August 2017 (UTC)
 * So, for instance, provide an edit link for Reconstruction:Proto-Brythonic/sɨx in siccus, or edit links for Reconstruction:Old Dutch/hagal and hagel in Reconstruction:Proto-Germanic/haglaz? That would be useful. Currently, it's kind of annoying to browse the various pages and find which of them contains which content.
 * And would it be an edit link for the section or for the whole page? Depending on the size of the page, the latter could be unhelpful. — Eru·tuon 23:46, 14 August 2017 (UTC)
 * Section, preferably. —CodeCat 14:12, 16 August 2017 (UTC)

Collapsible?

 * Hello. Could we consider making it collapsible?

Though useful, I find it distracting to have all the descendants of 🇨🇬 on the 🇨🇬 entry.

I think by making it collapsible (similarly to how Module:family tree behaves), we would get the best of both worlds: the cleanliness of, and the practicality of having all the descendants on a single page. --Per utramque cavernam (talk) 12:41, 13 March 2018 (UTC)
 * Sorry, I see this has been suggested above, and that you (Victar) don't think it's a good idea. Too bad. --Per utramque cavernam (talk) 12:44, 13 March 2018 (UTC)
 * , I see you've edited that entry; what's your take on this? --Per utramque cavernam (talk) 14:09, 13 March 2018 (UTC)
 * Yeah, I wouldn't support this. --Victar (talk) 15:09, 13 March 2018 (UTC)
 * I don't know if it's a good idea, but I agree that some people might want to see all the descendants on one page. But I prefer see desc. —AryamanA (मुझसे बात करें • योगदान) 16:04, 13 March 2018 (UTC)

parameter suggestion
Would a ref parameter similar to q be a good idea? So the refs can be in a natural position, rather than having to go before the descendant or after the entire tree. Sorry if there's already a way to do this and I just don't know how. Example of the problem here (I know this tree is incorrect; I fixed it in the next edit). – Gormflaith (talk) 17:56, 15 May 2018 (UTC)
 * If the descendent has an entry, the reference belongs on the entry page, not in the descendents list, so there really is no need. --Victar (talk) 19:32, 15 May 2018 (UTC)
 * Also, in your example, it really should be using see desc. --Victar (talk) 19:41, 15 May 2018 (UTC)
 * Alright, thanks. – Gormflaith (talk) 20:22, 15 May 2018 (UTC)

Links for alt forms
Sorry to be asking another question. Anyways, is there an easy fix for this? (the Middle English descendant enm is treated as ). Thanks, – Julia ☺ • formerly Gormflaith • 14:35, 7 June 2018 (UTC)
 * No, that's purposefully built into link so you don't have links to the same page you're on. --Victar (talk) 15:03, 7 June 2018 (UTC)
 * But shouldn't it link to wyrm? If I put de on catfish, it'll show up as (I'm assuming you have orange links on) rather than catfish – Julia ☺ • formerly Gormflaith • 15:09, 7 June 2018 (UTC)
 * You're welcome to bring that up on Template talk:link, but this module and template has no control over that. --Victar (talk) 15:14, 7 June 2018 (UTC)

Suppressing alt forms?
Old and Middle English terms tend to have a lot of alt forms, which the template currently automatically includes and which imo clutters the Proto-Germanic pages a bit, e.g. at. Would it be possible to include a parameter which suppresses the inclusion of alt forms? — Mnemosientje (t · c) 11:50, 22 December 2018 (UTC)
 * The same problem affects Portuguese descendant lists. Sabbatum lists a bunch of obsolete Portuguese spellings, which is irrelevant to anyone trying to learn about the development of the Latin term. — Ungoliant (falai) 01:26, 21 February 2019 (UTC)
 * The parameter 1 already exists and I added it to the documentation page.
 * The parameter only suppresses alternative forms for the top level in the resulting tree. So to hide the Portuguese alternative forms in the entry for, 1 has to be added in the entry for . — Eru·tuon 01:54, 21 February 2019 (UTC)
 * Ah, that works. Thanks! — Mnemosientje (t · c) 09:09, 21 February 2019 (UTC)

Something is broken..
causes suprious tag generation at the end of the list. What's gone wrong on this invocation only?

ShakespeareFan00 (talk) 17:51, 23 December 2018 (UTC)


 * Prettified what seems to be generated for this is:-

biliban , bilivian , bilibian  Middle Low German: blîven  Low German: blieven   Plautdietsch: bliewen       ? Faroese: blíva   ? Icelandic: blífa  <li> ? Norwegian: blive , bli </li> <li> ? Swedish: bliva , bli </li> <li> ? Danish: blive	 /li> </ul> </li></ul><-- Suprious list termination generated here... -->
 * Old Saxon: bilivan ,

Which has at least 2 point where spurious tags are seemingly generated.
 * There was in the Old Saxon entry for bliven. With this template, always look at the pages that it's transcluding from. — Eru·tuon 22:22, 23 December 2018 (UTC)

Show an error when there are multiple descendants sections
Right now, when there are multiple descendants sections, the template silently chooses the first one, regardless of whether that is correct or not. The same also happens when there is only one descendants section at the time is added to a page, but someone else later adds a second one above the first. That will then silently break the descendant tree of the page transcluding it, since it will now choose the first (wrong) section instead of the second (right) one. The person editing the other page can not be expected to be aware of this; they are just adding another POS with descendants after all, and there is no notification of any problem this causes. It would be a good idea, and lead to less errors, if the template produced an error when there is ambiguity, rather than silently doing the wrong thing.

Perhaps a related issue as well, is that the template does not complain at all when the language section is missing from the page, but does complain when the language is added but without the descendants. This means that the addition of a language section can suddenly trigger an error in the descendants of another page, even though nothing is actually wrong. The template should treat lack of the language the same as lack of the descendants section within the language: either both should produce an error, or neither should. I'd prefer an error in this case, because if there are no descendants to show, why are you using ? would be a lot less resource intensive then and produce the same result. Adding to other pages should be done once a descendants section is added (and likely by the same editor). —Rua (mew) 21:28, 26 March 2019 (UTC)