This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
I am converting a Familytree into chart. There was a tile in the tree that did not exist in Chart. It was "K" which is documented in the section in template:familytree/doc called Misc.
Familytree:
Misc.:
T
G
X
K
k
U
It is easy to pick up on failed conversions that return letters such as "K" because it shows up clearly. It is more difficult to spot changes such as "k" which changes the shape but does not fail.
Here is a table of all the ASCII characters and how they appear as tiles.
For ones with a one to one mapping
For no Familytree or Chart tiles
For no Familytree tile but a Chart tile.
For a Familytree tile but no Chart tile, however an alternative Chart tile
For a Familytree tile but no Chart tile
For a Familytree tile with a different Chart tile, but a different Chart position with the correct tile
Is it possible to get this set added to Chart (as perhaps a third set) because without them it makes automating tree conversions involving any of them difficult?
Thanks for that. I'm pinging the authors of that page (The Mol Man and Jackmcbarn) for advise and help. -- PBS (talk) 09:04, 24 April 2015 (UTC)
This is a table is constructed from the "Mixed" on the talk page but with tiles from {{Familytree}} (in blue) which do not appear to exist in {{Chart}}:
Hi. Using this Template to do family trees, I noticed that the charts are displayed differently in Chrome and Firefox/IE. Chrome tend to break the rows (lines) in an undesirable places. This example is a screenshot from Chrome (wich is bad), and this is from Firefox (the proper way of displaying). I don’t know if it is only a Template issue or only a Chrome’s one, but I wish to fix it. Or can someone explain to me if I’m doing something wrong? I’m using <br /> to break the rows. This is the chart from the pictures. I know that this seems trivial, but these broken rows are making the text more difficult to read. Generally speaking, in Chrome the boxes looks bigger than in Firefox or IE --Daduxing (talk) 11:23, 7 February 2016 (UTC)
Man, I hate these charts. Have you tried {{nbsp}}, {{wbr}} and {{nowrap}}, Daduxing? ‑‑YodinT 15:57, 7 February 2016 (UTC)
Hi. I used {{nowrap}} parameter at some points (and it's working), but it would be ,,painful" to add it to the past charts. --Daduxing (talk) 18:31, 7 February 2016 (UTC)
This is a flaw (not even an actual bug, so it's unlikely to be "fixed") in the way Chrome renders tables, combined with the way this template abuses table syntax to display a chart. I would personally like to see a better chart-creation tool, using modern html & css, but in the medium-term, there's not likely to be a way to improve this. In the short-term, would WP:AWB help? ‑‑YodinT 18:52, 7 February 2016 (UTC)
I see. Thank you. It is a good ideea to use AutoWikiBrowser --Daduxing (talk) 19:13, 7 February 2016 (UTC)
Problem with a chart
Can anyone show me how to fix this chart?
Family of Tree chart/Archive 2
Name1
Name2
Name3
Name4
Name5
Name6
Name7
Name8
Name9
See how "Name8" is out of kilter? Why is that? How do I fix it?--Brianann MacAmhlaidh (talk) 00:24, 12 April 2016 (UTC)
Done it. Add a (or more) | at the end of the row. Especially at the longest. --Daduxing (talk) 04:54, 12 April 2016 (UTC)
Can {{chart}} accept a name parameter so you can breakdown a tree and call another tree instead? — Preceding unsigned comment added by 112.201.134.144 (talk) 17:01, 19 June 2016 (UTC)
Not sure what you mean, can you give an example? ‑‑YodinT 10:49, 21 June 2016 (UTC)
Can anyone understand why an extra | (a space and a pipe sign) on the line between the 1st and 2nd Baronets in the right-hand column moves, not only that specific vertical connecting line, but also the lines above and below, so they're no longer centered on the boxes?
@HandsomeFella: for me, the vertical line is on the right of the right-hand column on both of them, and should be in the middle, so removing the extra unnecessary spaces (and moving the right-hand column closer to the rest of the chart) gives:
Not completely sure why the missing cell would cause it to collapse in that way, though probably because of the way tables are rendered, with empty cells being condensed more than cells with a vertical line through them (and the edges of tables seem to get especially crushed). That said, this kind of unpredictable behaviour is another example of why these charts should really be rendered with css rather bodged as tables! ‑‑YodinT 10:50, 24 June 2016 (UTC)
Solid lines vs. dashes?
When should you use dashes instead of solid lines?--Launchballer 09:15, 7 June 2016 (UTC)
It depends on the context, there are no set rules to make sure dashes etc. are used in the same way. Do you have a specific example in mind Launchballer? ‑‑YodinT 14:36, 26 June 2016 (UTC)
There is an issue about how this charts are displayed on mobile devices. As you can see from the pictures (Example 1; Example 2) there is an extra line outside the boxes in Firefox and on the ' line in Chrome. Some years ago there was a similar (resolved) problem. (you can see it here)--Daduxing (talk) 10:49, 2 May 2018 (UTC)
Suggestion
Wouldn't be better if we had the default wideness of the boxes' borders at 1px instead of 2px? The present default wideness is too thick and it's distracting the attention from the un-bolded text. A more thinner border looks better. --Daduxing (talk) 10:22, 6 May 2018 (UTC)
Connecting lines
What can be done with the following issue.
I noticed that the connecting lines are not perpendicular on the middle of the boxes, tending to move toward left or right, if the boxes are not vertically aligned (See here) or if the size of the boxes is different. Note that the the middle of the box is where the # is placed.
If I insert some line breaks to try to make the boxes relatively equal the problem is not completely resolved, and on other big charts isn't a solution at all.
Is there a way make the lines to be on the middle of the boxes, when the boxes are not vertically aligned, and without having the boxes deformed? I'm using Chrome. I see that Firesox also has this issue but is somehow better then with Chrome. --Daduxing (talk) 18:26, 4 December 2018 (UTC)
I think, without being certain, that this is the same regardless of which browser you are using. I also think this is because each box is made up by three horizontal "units", each of which has the width of the widest "unit" in that vertical row. The vertical line connects to the center of the middle "unit" of the box. If there are boxes that don't align in the sense that the left-most "unit" of a box aligns with that of another box above (or below), but rather to its middle or right-most "unit" (or even to a gap between boxes), boxes that don't align will consist of three "units" of different size. And if it's the left-most and the right-most "units" that are not of the same size, then this will inevitably occur.
Let's take the two boxes in the lower left in your example above, Philip and Charles. The right-most third of Philip's box aligns with Charles' left-most third, with the middle part relatively thin, and leaving the remaining third part of both boxes with a different size than the opposite part of the same box. Hope this makes at least some sense.
I have never seen this happen to boxes that align, so I think this is the reason.
@Daduxing: the reason the connecting line was not connecting to the center of the two boxes in the upper right-hand corner was that a pipe sign and a space was missing. Fixed that for you. I don't know the reason, but I know the cure.
Thank you HandsomeFella. Beats me, I can't see any difference. I think that we really need a more dedicated tool for those family trees without using the table syntax. There is space for improvement the graphic aspect of the charts. But besides PBS I don't see too many programmers being interested in family trees. --Daduxing (talk) 13:38, 5 December 2018 (UTC)
If you compare the two talkpage versions side-by-side, I think you can see the difference. I'm speaking of the Charles of Valois and Philip VI boxes. In this version, one can clearly see that the connecting line does not align to the # in Charles of Valois' box. HandsomeFella (talk) 16:34, 5 December 2018 (UTC)
What does a dotted line stand for?
Hello. I wanted to make a family tree in the sandbox, but I am not so sure which lines should I use. Correct me if I am mistaken. Solid lines mean that these people are related. Dashed lines mean that these people aren't related. So what do the dotted lines mean? And which lines do I use if I don't know the exact parents, grandparents etc. but I know that this person is a descendant of another person? --Shader301202 (talk) 14:24, 18 July 2017 (UTC)
In the initial example given, a dotted line signifies a marriage. That being said, there's no firm rule about whether solid or dashed lines should be used. Banaticus (talk) 18:48, 20 February 2018 (UTC)
@John Maynard Friedman: there is no set convention across Wikipedia, so dotted or dashed lines could be used to show children born out of wedlock if necessary. One suggestion below was to include a key or legend to tell readers what different styles of lines mean. ‑‑YodinT 18:18, 4 January 2019 (UTC)
Adding "legend" or clarification in the bottom of the chart
What is the best way to add a legend or clarification to the bottom of the chart? e.g. the chart in Cleopatra. Sometimes, it's helpful to clarify the difference between dashed vs solid vs dotted line. HaEr48 (talk) 05:55, 26 December 2018 (UTC)
Yes please. Especially given the pharoahs' tendency towards incestuous marriages, we really do need to know when solid line => blood relative (how related? sibling? parent? cousin?). See also above my query on recognised children of unmarried parents.
IMO, this should be a standard function of the template, editors ought not to be able to just make it up without guidance. --John Maynard Friedman (talk) 13:44, 5 January 2019 (UTC)
Requested move 24 February 2019
The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this section.
– Module and template should have the same name, but I'm not sure whether "chart" or "TreeChart" is best. {{3x|p}}ery (talk) 15:47, 24 February 2019 (UTC) --Relisting.SITH(talk) 21:50, 6 March 2019 (UTC)
Given that modules can't be moved without disruption and/or a lot of unnecessary work, I'd say what's moved should be the template. Dekimasuよ! 19:02, 24 February 2019 (UTC)
If that's really the case, then good. I am not sure how long the changes take to propagate. My general point is just that I think we should avoid moving modules unless absolutely necessary since redirects can't be left behind, and in many cases we (or I, as a prospective closer of the move discussion, in any case) find it difficult to assess how much collateral damage there will be. In general I'm still of the opinion that module move discussions might be better held outside the RM process. Would the proposed move of the adjacent stations module be able to proceed as smoothly? Dekimasuよ! 21:55, 24 February 2019 (UTC)
I think TreeChart – "chart" is too generic. There are all kinds of charts I can't use this for. ErikHaugen (talk | contribs) 17:45, 6 March 2019 (UTC)
Support{{Tree chart}} and Module:Tree chart with an ensuing quick fix in this template. (are we thinking to rename the pages on Wikibooks?). And Dekimasu, I'm curious about why a redirect cannot (or should not) be left behind from a module page move. The module namespace does have redirects that seem to always be subpages, usually /doc pages, and I wonder if there is some software glitch that specifically makes us avoid making module basepage redirects? Paine Ellsworth, ed. put'r there 23:03, 6 March 2019 (UTC)
Looking at it more closely, it must have something to do with the way a module is called, by use of the #invoke parser function, that precludes usage of a redirect. Paine Ellsworth, ed. put'r there 23:44, 6 March 2019 (UTC)
This request for help from administrators has been answered. If you need more help or have additional questions, please reapply the {{admin help}} template, or contact the responding user(s) directly on their own user talk page.
Didn't realise these were template-protected, please can an admin or template editor implement the consensus above? SITH(talk) 13:30, 16 March 2019 (UTC)
Done. Please re-read the documentation and let me know if I missed any now-outdated {{chart}} references. Cheers! Reaper Eternal (talk) 16:59, 16 March 2019 (UTC)
The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.
Familytree.js doesn't work anymore
The Familytree.js tool does not recognize the new name/parameters of this template ({{Tree chart/start|), and so it does not work anymore. Could someone tweak it? It would also be great if there would be some improvements to it. --Daduxing (talk) 06:22, 17 April 2019 (UTC)
planning a chart
I've been having a great time learning to use this function -- aside from which I'm a very visual thinker and it is much more useful for me to SEE the relationship rather than read about it. But for as much as I try to pre-plan, things end up being trial and error... adding and subtracting tiles in order to have things match up. I suspect that I am missing something very simple, and I would appreciate any information related to charting the chart before you type the chart. Thanks!!! PurpleChez (talk) 15:46, 12 April 2019 (UTC)
@PurpleChez: Unfortunately, the code is normally pretty messy – I don't think you're doing anything wrong, it's all about trial and error! The only trick is to make sure all the tiles (spaces and connecting lines) are the same width (2 characters, including the | character), and that the boxes are all three times this (6 characters including the |). Here's the example from the template page to show what I mean (see how the empty cells are all one space, and the named boxes are spaced to make them all 5 characters + | ) :
{{Tree chart/start|align=center|summary=An example family tree}}
{{Tree chart| | | |GrMa |~|y|~| GRP | |GrMa=Grandma|GRP=Grandpa}}
{{Tree chart| | | | | | | |)|-|-|-|.| }}
{{Tree chart| | | MOM |y| DAD | |DAISY|MOM=Mom|DAD=Dad|DAISY=[[Aunt Daisy]]}}
{{Tree chart| |,|-|-|-|+|-|-|-|.| | | }}
{{Tree chart| JOE | | ME | | SIS | | |JOE=My brother Joe|ME='''Me!'''|SIS=My little sister}}
{{Tree chart/end}}
Do you have a draft, or specific example you want help with? ‑‑YodinT 17:06, 15 April 2019 (UTC)
many thanks!!! I agree with your trial and error observation PurpleChez (talk) 15:20, 16 April 2019 (UTC)
Hi@Yodin and Daduxing: many thanks both for the swift replies! I thought this page might be a bit quiet, but I'm glad it's not the case—or perhaps everyone understands family trees better than me! :)
Yodin, this is the table in question; and, coincidentally, Daduxing has hit the nail on the head. Maud, on the righthandside was married three times, first to William (on her left) and then to Thos and bussy respectively. Who wuld that lay out, do you think? ——SerialNumber54129 10:17, 9 October 2019 (UTC)
I've made an example edit, following the House of Capet in the link Daduxing gave – not beautiful, but seems to get the idea across I hope? What do you think Serial Number 54129? ‑‑YodinT 10:32, 9 October 2019 (UTC)
@T, brilliant, that's exactly the thing I was after (I don't think it looks bad at all!). Just one thing; you couldn't move the double marriage you just inserted down a generation, to Maud, dau. of Phili Nevil? She was the energetic one :) ——SerialNumber54129 11:01, 9 October 2019 (UTC)
@Serial Number 54129: how about that? :) ‑‑YodinT 11:19, 9 October 2019 (UTC) EDIT: Wait, still not right, one second! ‑‑YodinT 11:20, 9 October 2019 (UTC) EDIT2: Should be right now I hope! ‑‑YodinT 11:23, 9 October 2019 (UTC)
@Yodin: That's great, it works a treat! Many thanks! ——SerialNumber54129 11:30, 9 October 2019 (UTC)
Glad to help. :) ‑‑YodinT 11:34, 9 October 2019 (UTC)
Template-protected edit request on 26 October 2019
Not done for now: please establish a consensus for this alteration before using the {{edit template-protected}} template. Given the suggested use, please find a consensus that WP:COLOR has been appropriately accounted for and that colors are desired. Izno (talk) 17:32, 26 October 2019 (UTC)
Color option for connecting lines
To editors The Mol, Man, Jackmcbarn and PBS: Kindly add the Color option for the connecting lines. In the Module:Tree chart/data, the present color is limited to black due to the below lines.
local SLD = '1px solid black'
local DSH = '1px dashed black'
local DOT = '1px dotted black'
, which results in limiting the no. of relations possible in a chart only to three. Please do the changes for the Tree chart to add color option for each type of line, and carry the value to the Module:Tree chart/data to represent different kind of relations.
(harith·discuss) 09:44, 26 October 2019 (UTC)
If this is implemented, MOS:COLOR must be kept in mind, for accessibility. – Jonesey95 (talk) 15:00, 26 October 2019 (UTC)
"and for those of you who are watching in black and white, the pink is next to the green."(Ted Lowe). If this is to be implemented then before it is care must be taken to include documentation covering WP:COLOR. user:harithvh (harith) did you considered this issue before makig the request? If so how will colourblind people be able to distinguish lines? -- PBS (talk) 16:40, 17 December 2019 (UTC)
Sure, the color-blind people will not properly see it, but it’s a good suggestion anyway. Nevertheless there are improvements that we can make like the possibility to make more than one connecting line to the right/left of the boxes (like here) or to make it on the top/bottom of the boxes without deforming the box/chart. --Daduxing (talk) 18:14, 7 January 2020 (UTC)
Familytree.js script deleted
I’m surprised to see that the familytree.js script was deleted without a proper debate on the subject. That was a valuable tool to make the family trees because it was far more easier to create complex charts with it than it is with the present temple. Shouldn't we have a reevaluation of the decision taken? That script shouldn't have been deleted --Daduxing (talk) 18:14, 7 January 2020 (UTC)
HiDaduxing, I'd be happy to back you up if you want to file an undeletion request at WP:IANB (could maybe be moved to your user pages to protect if from being deleted again in the future?). ‑‑YodinT 21:15, 8 January 2020 (UTC)
HiYodin. Done it. Thank you for suggestion. --Daduxing (talk) 12:02, 9 January 2020 (UTC)
Is it possible (and if so, where!) to put a citation inside the chart? ——SN54129 14:42, 6 April 2020 (UTC)
@Serial Number 54129: If I have understood your question, in short yes, anywhere within the text that you substitute for box names. For example {{tree chart |boxwc|boxwc=Box with citation<ref>{{cite web |url=http://en.wikipedia.org/wiki/Template_talk:Tree_chart#References_within_the_chart |title=References within the chart |last=54129 |first=Serial Number |date=2020}}</ref>}} which produces with suitable start and end templates:
The last column comes out very narrow in {{tree chart}} but works well with {{family tree}}. See for example Kiszka family and the old version (note far right column with "Janusz Kiszka"). Also could not get the far right column to align with the relationship lines in Manvydas family (old edit), but they work beautifully when switched to {{family tree}}. Any clues? I am nowhere near technical enough to figure out what's going on. Thanks, Renata (talk) 06:02, 6 March 2020 (UTC)
I'd noticed this annoying bug before, would be good to fix it if possible! An initial look at the code shows that {{family tree}} has a span within a div in each td cell element, while {{tree chart}} misses these out and puts the data straight into each td cell. I haven't got into Lua scripting yet (not sure if/how sandboxes work with Lua template modules), but it should be possible to test this out adding these divs and spans in Tree Chart and see if that fixes it. ‑‑YodinT 12:05, 7 March 2020 (UTC)
The issue is fixed by adding some pipes | | | at the end of the longest row. [See here]. As for the second point, yeah, they created another mess with no easy fix mainly because the syntax is different. You can't merge something that it is different. --Daduxing (talk) 11:31, 14 April 2020 (UTC)
Tango Mike Bravo In the Duke of Clarence#Family Tree case the boxes should be vertically aligned and also add more pipes at the end of the longest row. --Daduxing (talk) 14:46, 14 April 2020 (UTC)
@Daduzing: I have tried as you suggested with mixed results. The overall layout is better, but the first column of boxes is squashed. I tried adding extra pipes to one of the longest lines (lines have one, two or three boxes, all the longest lines have 3 boxes), adding extra pipes at the start of every line and finally extra pipes on all lines, so that all lines are the same length. None of these totally fixed the problem. It is the latter, with extra pipes at the start and end of every line and all lines equal length, that I have published at Duke of Clarence#Family Tree. Any suggestions? If you want please see if you can improve the layout. Tango Mike Bravo (talk) 16:08, 14 April 2020 (UTC)
Tango Mike Bravo The box is taking the shape of the text (long text or short text) and affects the all column. You must either make a shorter per row text, using the <br> or force the text to remain unsplit by using the {{nowrap| }} template. I used them both. --Daduxing (talk) 17:32, 14 April 2020 (UTC)
BTW, the familytree.js script is not working again. There are times when it appears only after refreshing the page some couple of times. --Daduxing (talk) 17:50, 14 April 2020 (UTC)
@Daduzing: Thank you for looking at this. Is this summary accurate/sufficient? Problems with narrow boxes can be overcome by 1. ensuring all boxes are vertically aligned; 2. setting the minimum width of a narrow column by using the {{nowrap| }} template; and 3. reducing the line width in columns that are too wide by the use of <br>. Tango Mike Bravo (talk) 18:42, 14 April 2020 (UTC)