Template talk:descendants tree
One of the shortcomings
@CodeCat: 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 {{see desc}} instead when it would become rather long? --kc_kennylau (talk) 04:04, 5 March 2017 (UTC)
- The idea is to make
{{see desc}}unnecessary while still keeping the length manageable. —CodeCat 13:35, 5 March 2017 (UTC)- @CodeCat: In that case redirect to see desc if more than 10 lines? --kc_kennylau (talk) 15:05, 5 March 2017 (UTC)
- I'm actually really happy it doesn't collapse. I think there are some places
{{desctree}}works and others where{{see desc}}is the best choice. I prefer using{{see desc}}on PIE entries and for borrowing descendants. --Victar (talk) 01:56, 19 April 2017 (UTC)
Ideas and bug reports
@CodeCat, Erutuon et al, I have few ideas and bug reports:
Right now it's a bit annoying that if I want to list alternatives for an entry, I have to list them before the{{desctree}}, as opposed to order of commonality, etc., as I normally would, i.e.Latin:. The solution that comes to mind is to have an{{l|la|elmus}},{{l|la|hermus}},{{desctree|la|helmus}}|altN=parameter, i.e.Latin:.{{desctree|la|helmus|alt1=elmus|alt2=hermus}}
Done: Sometimes I'd like to be able to add a qualifier after the {{desctree}}on the same line, but instead it sends to the bottom of the list, i.e.Vulgar Latin:. It would be great if a{{desctree|la|*scuma}}{{q|merger with Latin spūma}}|q=parameter could be added to accommodate this, i.e.Vulgar Latin:.{{desctree|la|*scuma|q=merger with Latin{{l|la|spūma}}}}- Done: I'm wondering if it wouldn't be a good idea to include lead text with the language name, like we do with
{{cog}}and{{desc}}, 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|notext=1them all. Alternatively, if we can't get the order issue resolved, maybe a|text=1option 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. - Done: Descendant trees with columns, i.e.
{{top2}}, break{{desctree}}, so that needs fixing as well, most easily by simply filtering them out.
--Victar (talk) 00:45, 19 April 2017 (UTC)
- How about programming the alternative forms into the descendant tree data module, so that when you type
{{desctree|la|helmus}}, it will automatically display the alternative forms{{l|la|hermus}}and{{l|la|elmus}}? — 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)
- How about programming the alternative forms into the descendant tree data module, so that when you type
- @Victar: Could you point to an entry in which the problem related to alternative forms has cropped up? Are you referring to *helm, or somewhere else? — Eru·tuon 06:12, 8 May 2017 (UTC)
- @Erutuon: I have plenty of examples, but to give a recent one, let's take Medieval Latin raubō. In the descendant tree I have OF:
*{{desc|fro|robber}},{{l|fro|robier}},{{desctree|fro|rober}}- OF rober is the common form, but because I want to be able to use
{{desctree}}, I have to put it last. I'd like to be able to do this and have it work: *{{desctree|fro|rober}},{{l|fro|robber}},{{l|fro|robier}}- 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:
*{{desctree|fro|rober|t2=robber|t3=robier}}- --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
{{desctree|fro|rober}}, it would display the alternative forms robber and robier along with rober. — Eru·tuon 14:25, 8 May 2017 (UTC)- @Erutuon:, that's a great idea I hadn't even thought of! Wanna help me code it? =) --Victar (talk) 15:16, 8 May 2017 (UTC)
- @Victar: 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)
- @Erutuon: Awesome! Yeah, you can probably just do a straight-up copy-paste of
{{Module:descendants tree}}, have it look for====Alternative forms===instead, and some tweaks to the parsing code. --Victar (talk) 15:25, 8 May 2017 (UTC)- @Victar: 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
{{l}}instead of{{alter}}will have to be corrected before the module can parse them. — Eru·tuon 15:42, 8 May 2017 (UTC)- @Erutuon: Hey, that's great! I knew it wouldn't be too hard. I was only vaguely aware of
{{alter}}, so I'm happy to use it more often, though, why it wasn't named{{alt}}, I have no clue. Would it be possible to run a bot script on all existing{{desctree}}entries to add|noalt=1so we don't have duplicate alternates listed before we clean-up and|notext=1to disable the language name prefix I'm adding, so they aren't doubled? --Victar (talk) 15:53, 8 May 2017 (UTC)- @Victar: I think there won't be duplicate alternative forms, because till now it has not been possible to show them while using
{{desctree}}, which was one of the reasons why you started this thread. But the|notext=1would be a good idea. The language name should be added by{{desctree}}rather than having to be typed out. — Eru·tuon 16:43, 8 May 2017 (UTC)- @Erutuon: Cool, well if you or someone else can run that bot, I'll add my changes from
{{desctree2}}. --Victar (talk) 17:02, 8 May 2017 (UTC)- @Victar: I don't have a bot, but @DTLHS 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)
- @DTLHS: Search for all usages of
{{desctree}}and add|notext=1to them all. Thanks for any help! --Victar (talk) 22:35, 8 May 2017 (UTC)- Done. DTLHS (talk) 23:10, 8 May 2017 (UTC)
- @DTLHS: Thanks a ton! @Erutuon edits made. --Victar (talk) 23:21, 8 May 2017 (UTC)
- Done. DTLHS (talk) 23:10, 8 May 2017 (UTC)
- @DTLHS: Search for all usages of
- Could you explain explicitly what you want done? DTLHS (talk) 22:27, 8 May 2017 (UTC)
- @Victar: I don't have a bot, but @DTLHS might be able to help. — Eru·tuon 22:04, 8 May 2017 (UTC)
- @Erutuon: Cool, well if you or someone else can run that bot, I'll add my changes from
- @Victar: I think there won't be duplicate alternative forms, because till now it has not been possible to show them while using
- @Erutuon: Hey, that's great! I knew it wouldn't be too hard. I was only vaguely aware of
- @Erutuon: Awesome! Yeah, you can probably just do a straight-up copy-paste of
- @Victar: 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)
- @Erutuon:, that's a great idea I hadn't even thought of! Wanna help me code it? =) --Victar (talk) 15:16, 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
@DTLHS: Now, would you be willing to run another set of edits removing the canonical_name: before {{desctree}}, and the |notext=1? — Eru·tuon 00:03, 9 May 2017 (UTC)
- @Erutuon, could you have a look *barō? 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)
- @Victar It's not cache, because it remains when I edit the page. Yeah, it's a nesting issue, because baro uses
{{desctree}}. It didn't crop up before? — Eru·tuon 00:20, 9 May 2017 (UTC)- @Erutuon: No, no previous nesting issues. Must be due to some changes on my end. --Victar (talk) 00:25, 9 May 2017 (UTC)
- @Victar: I found and reintroduced the code that allowed
{{desctree}}to be replaced with{{#invoke:descendants tree/templates|show}}in Module:descendants tree. — Eru·tuon 00:28, 9 May 2017 (UTC)
- @Victar: I found and reintroduced the code that allowed
- @Erutuon: Hah, I see you pasted in the fix before I could. Guess I mistakenly removed that. --Victar (talk) 00:29, 9 May 2017 (UTC)
- @Erutuon: No, no previous nesting issues. Must be due to some changes on my end. --Victar (talk) 00:25, 9 May 2017 (UTC)
- @Victar It's not cache, because it remains when I edit the page. Yeah, it's a nesting issue, because baro uses
- 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)
- @DTLHS: Yeah, plus we need to adjust the order, which update fixed. Thanks again! --Victar (talk) 00:52, 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)
- I'm a bit puzzled why this solution was taken. An alternative could have been to make
{{desctree}}only show descendants, and not show the link, leaving that to{{l}}. 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){{desc|fro|rober}},{{l|fro|robber}},{{l|fro|robier}}{{desctree|fro|rober}}- 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)
- @CodeCat: Don't be such a sour-sport just because we changed your module. You can always use
|notext=1and you can create|noalts=to add your variants separate form what's in{{alter}}. 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,
{{desc}}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
{{desc}}. --Victar (talk) 14:23, 9 May 2017 (UTC)
- I think you may be alone in that opinion. People seem to have taken a keen shining to
- 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,
- @CodeCat: Don't be such a sour-sport just because we changed your module. You can always use
- 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)
Sense ids
===Alternative forms===
===Etymology===
===POS===
{{temp|senseid}}
or
===Alternative forms===
===Etymology 1===
====POS====
{{temp|senseid}}
or
===Etymology===
===POS===
{{temp|senseid}}
====Alternative forms====
@Erutuon, 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 {{senseid|fro|ugly}}. --Victar (talk) 06:25, 14 May 2017 (UTC)
- @Erutuon, JohnC5: 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)- @Victar: 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)
- @Erutuon: 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)- @Victar: 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)
- @Erutuon: Yeah, so I thought
content = mw.ustring.gsub( content, "^.*{{senseid|" .. lang:getCode() .. "|" .. id .. "}}(.*)", "%1")would do the trick, but apparently not. --Victar (talk) 21:56, 10 June 2017 (UTC) - @Erutuon: It looks like what's happening the
whilebelow 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)
- @Erutuon: Yeah, so I thought
- @Victar: 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)
- @Erutuon: Maybe you're thinking about
- @Victar: 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)
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 *ĉarHád-. --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}}. @Erutuon, JohnC5 can we start moving forward with some of these changes? --Victar (talk) 12:07, 7 June 2017 (UTC)- @Victar: So, I'm fine with adding
{{{qN}}}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
|qn=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)- @Erutuon, JohnC5: 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. @Erutuon, 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)- @Victar: 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)
- @Erutuon, JohnC5: I'd definitely want to eventually do away with current
- 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
{{alter}}is because currently Module:descendants tree only fetches the content of one{{alter}}... 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 @Erutuon. --Victar (talk) 20:58, 7 June 2017 (UTC)
- @Victar: So, I'm fine with adding
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?
@Erutuon, Victar: Hello. Could we consider making it collapsible?
Though useful, I find it distracting to have all the descendants of Proto-Slavic *blъxà on the Proto-Indo-European *plúsis 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 {{see desc}}, 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)
- @AryamanA, 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)
- @Per utramque cavernam: 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)
- @Per utramque cavernam: 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
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)
- @Gormflaith: 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)- @Victar: 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 {{l|enm|wyrm}} is treated as ]). Thanks, – Julia ☺ • formerly Gormflaith • 14:35, 7 June 2018 (UTC)
- @Julia: 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)- @Victar: But shouldn't it link to wyrm#Middle_English? If I put
{{l|de|catfish}}on catfish, it'll show up as catfish (I'm assuming you have orange links on) rather than catfish – Julia ☺ • formerly Gormflaith • 15:09, 7 June 2018 (UTC)- @Julia: 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)
- @Victar: But shouldn't it link to wyrm#Middle_English? If I put
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 *weraldiz. 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
|noalts=1already 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 Latin sabbatum,
|noalts=1has to be added in the entry for Old Galician-Portuguese sabado. — Eru·tuon 01:54, 21 February 2019 (UTC)- Ah, that works. Thanks! — Mnemosientje (t · c) 09:09, 21 February 2019 (UTC)
- The parameter
Something is broken..
{{desctree|osx|bilīvan}} 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:-
*Old Saxon: <span class="Latn" lang="osx">]</span>, <span class="Latn" lang="osx">]</span>, <span class="Latn" lang="osx">]</span>, <span class="Latn" lang="osx">]</span> <ul> <li>Middle Low German: <span class="Latn" lang="gml">]</span> <ul> <li>Low German: <span class="Latn" lang="nds">]</span> <ul><!--Suprious UL generated here --> <ul> <li>Plautdietsch: <span class="Latn" lang="pdt">]</span></li> </ul> </li> </ul> </li> <li><span title="borrowed">? </span>Faroese: <span class="Latn" lang="fo">]</span></li> <li><span title="borrowed">? </span>Icelandic: <span class="Latn" lang="is">]</span></li> <li><span title="borrowed">? </span>Norwegian: <span class="Latn" lang="nb">]</span>, <span class="Latn" lang="nb">]</span></li> <li><span title="borrowed">? </span>Swedish: <span class="Latn" lang="sv">]</span>, <span class="Latn" lang="sv">]</span></li> <li><span title="borrowed">? </span>Danish: <span class="Latn" lang="da">] </span>/li> </ul> </li></ul><-- Suprious list termination generated here... -->
Which has at least 2 point where spurious tags are seemingly generated.
- There was an error 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 {{desctree}} 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 {{desctree}} 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 {{desctree}}? {{desc}} would be a lot less resource intensive then and produce the same result. Adding {{desctree}} 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)