This is an archive of past discussions about Template:Routemap. 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.
@Sameboat: Can a way to centre maps using the CSS margin: auto; (without any label text on either side) be added to the module (or does one exist in the module already)? I'm not exactly very good at Lua coding, so I wouldn't really try to add something like that myself. Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 06:20, 13 September 2015 (UTC)
The |bg= parameter does not load well with {{BSsplit}}. When I safe subst{{BS}} templates on Template:IRT Eastern Parkway Line, I got empty space instead of background color, and the BS split was also removed when I tried to put that in simultaneously. I put bg-color in, but this happened because the bg-color wouldn't render on the same line as the bs-split. Is there a way to fix this? epic genius (talk) 02:16, 2 December 2015 (UTC)
I thought about it before, but my conclusion is that it's not worth to complicate the Lua code when this can be easily done by stacking the routemap templates in the same table. -- Sameboat - 同舟 (talk · contri.) 09:27, 19 March 2016 (UTC)
PS I meant that because Pldx1 didn't make /safesubst for some of the templates (and removed the substitution function from some of the actual BSn and BSn-2 templates) it wouldn't work without checking if the subpage exists. I would use his scripts (on WT:RDT, as you probably saw) to make the subpages, but I don't know how to run the scripts. Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 15:13, 4 June 2016 (UTC)
I have recently seen that on the various Routemaps I have edited and added the parameter convert, I have seen that the icons have become spaced out and now create horrible looking maps, such as here Template:Channel Tunnel Rail Link. Please could this be addressed so all maps with this parameter are fixed? Nathan A RF (talk) 18:53, 24 June 2016 (UTC)
Additionally, you may want to use {{BScvt}} instead, as it avoids having to use {{Convert}} as well as {{BSsplit}}. ("Convert" is not a parameter; it's a separate template to the RDT series.) Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 04:50, 25 June 2016 (UTC)
I know about {{BScvt}} and I update Routemaps with that referring to tunnel and bridge distances in yards, however I do use {{Convert}} as it shows miles and chains, widely used by British railways, rather than 0.93 miles for example, which is not used in the UK. {{BSsplit}} is used for other things in my opinion, but I will continue to use {{Convert}} for miles and chains. Nathan A RF (talk) 11:23, 25 June 2016 (UTC)
@Nathan A RF: I've added conversion functionality for miles and chains to BScvt (example: {{BScvt|56; 13|in=mi; ch}} →
Seems to have fixed it - I checked half a dozen articles in the category and they were OK, or OK after purging. The number in the category has already reduced by ~50, but it may take some time for it to return to normal with no articles.--JohnBlackburnewordsdeeds15:26, 31 July 2016 (UTC)
Collapsible replacement row background
@Sameboat: I still don't really know how this thing works. I'm trying to give the table cells which hold the collapsible replacement text cells the CSS width:100%;, but I'm not sure where this actually is in the module. (This would fix {{GZM RDT/5}}, as "Proposed extension" is wider than "Huangniubu".) Could you help with this if you have time? Thanks, Jc86035 (talk) Use {{re|Jc86035}} to reply to me13:34, 23 December 2016 (UTC)
I didn't actually take time to analyze YLSS's code but did a quick style value backtracking in Firefox page inspector for "vertical-align:middle;padding-left:3px;font-size:90" and ended up at "row-collapsible-right-button-fmt". Please test in testcase if my edit to sandbox works. -- Sameboat - 同舟 (talk · contri.) 16:19, 23 December 2016 (UTC)
@Sameboat: I was trying to solve something else, although that does help. I've tried editing the sandbox, but I don't really know how q.text_width is handled and it's not working. Jc86035 (talk) Use {{re|Jc86035}} to reply to me05:33, 24 December 2016 (UTC)
Add |inline={{#if:{{{inline|}}}|1}} to the diagram; and use {{SomeMap RDT|inline=1}} when transcluding into an Infobox (otherwise just the normal {{SomeMap RDT}} format). Useddenim (talk) 14:04, 5 January 2017 (UTC)
I can't seem to be able to use the parameter collapsible in my routemap properly, and there is no example in the Template data section. I tried with collapsible=yes and collapsible=on but I still can't make my routemap to be collapsed in the article by telling it to collapse=yes. How should I use collapsible? --Matija (talk) 13:36, 2 March 2017 (UTC)
@Matija: If you're using the template in an infobox, it should have the parameter |inline=yes. I've made the infobox's table cell collapsed. |collapse=yes should work properly. The template is collapsible by default, so you don't need to add |collapsible=yes. Jc86035 (talk) Use {{re|Jc86035}} to reply to me14:17, 2 March 2017 (UTC)
@Jc86035: Thanks for fixing it in the infobox. However, I'd also like to use it in EuroVelo where I'd like it to also be collapsed by default, but with the frame and all (and not inline). Any advice? --Matija (talk) 08:23, 3 March 2017 (UTC)
@Matija: Try using |inline={{#if:{{{inline|}}}|yes}} (along with |collapsed=yes) in the template. Then in the infobox you could use {{EuroVelo 6|inline=yes}}. Jc86035 (talk) Use {{re|Jc86035}} to reply to me08:40, 3 March 2017 (UTC)
@Jc86035: Well, it works now, thanks! Funny, when I first did it like this, the template appeared to be all inline (that's why I reverted the edit). I don't know how to explain that but the important thing is - it now works :) --Matija (talk) 10:09, 3 March 2017 (UTC)
@Sameboat: Would it be possible to change the text sidebars, so that the text for the leftmost/rightmost two cells is contained in divs instead of table cells, without messing up collapsible sections? (This is primarily to make diagrams narrower; it used to work with a hack using {{right}} in diagrams such as {{4 (New York City Subway service)}} but now doesn't for some reason. I tried manually adding float tags for Bowling Green station in that diagram.) Jc86035 (talk) Use {{re|Jc86035}} to reply to me09:02, 5 March 2017 (UTC)
@Sameboat: It seems to be solved if both the left side and the right side are divs with CSS float:[left/right];line-height:1.44 (with possible margins in the middle). I don't know how the code for |tw= and collapsible rows would be modified if this were to be added, though, or if the 6-value |tw= would still work afterwards. Jc86035 (talk) Use {{re|Jc86035}} to reply to me05:02, 6 March 2017 (UTC)
However, it seems as if there are still some problems getting it to look right, and fixing them is beyond my capabilities (I suspect that some of the here-deprecated versions are still supported over there). Would someone with those capabiities be so kind as to take a look at it and fix them? I'd appreciate it. Daniel Case (talk) 20:04, 9 May 2017 (UTC)
Typo
Should fix typo in module. default = '[[Cat1egory:Pages with errors of Module Routemap]]' should be
default = '[[Category:Pages with errors of Module Routemap]]'
Template-protected edit request on 23 September 2017
This edit request to Template:Routemap has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
I wish to acess the template editing page so I can translate this template to my language, we still use the old BS-map template and I'm trying to modernize a bit of the portuguese wikipedia.
Thank you. Ligaanet (talk) 18:54, 23 September 2017 (UTC)
Doesn't work because i don't have the right permissions: This page is currently protected so that only template editors and administrators can edit it. Is there a way i could get granted acess to it? Or maybe someone that has acess could simply copy it and send it to me? I don't know whats the actual "right way" to translate a template that is as important as that one. Thanks Ligaanet (talk) 05:33, 24 September 2017 (UTC)
I was able to bring it to the pt wiki, i asked for help from my side to gradually translate everything but the pt wiki bosses are unfortunately known for being a lil hostile. I simple made a few pages with the right templates and i hope they won't end up deleted because of some weird rule (believe it or not but the huge, days long work, i did across the Lisbon Metro pages - did the same at ptwiki and enwiki, just translated it from one another - got deleted from the ptwiki because for some reason we can't put the connected bus lines and all that because: "we ain't a travel agency" true moderator reply). Thanks for all your help here!Ligaanet (talk) 08:26, 24 September 2017 (UTC)
pass parameter to make collapsed outside infobox?
So at Transportation in Vancouver § Public transportation, I'm trying to get {{TransLink Major Route Diagram}} (which is not in an infobox) to start collapsed (because it's honking and dominates the page)... but only on that page. So I don't want to use |collapsed=<includeonly>yes</includeonly> in the template itself because that would make the template collapsed by default wherever it's included. I can't seem to figure out what parameter to pass to the call to {{TransLink Major Route Diagram}} to make that happen—what am I missing? Is it not possible without making "collapsed" the default state for all inclusions? —Joeyconnick (talk) 09:19, 1 January 2018 (UTC)
Oh cool... thanks! 👍 I'm still learning about templates and coding them, so I really appreciate the help! One more question... the second map (the "Legend") has this set: |map2-collapse=yes and I assume the intent (which I agree with) is for that part of the diagram to always start collapsed. But it doesn't. I can't find any documentation at {{Routemap}} that specifies adding multiple maps in one call to the template using |mapX...=... is it a case of the template failing as gracefully as it can but not quite working as I assume the original editors of the TransLink diagram intended? Or is it an incompatibility between what {{BS-map}} was able to do and what {{Routemap}} can, given this template used to be at: {{TransLink Major Route Diagram (pre-Evergreen with 97 B-Line)}} (long story as to why it was forked). —Joeyconnick (talk) 20:47, 1 January 2018 (UTC)
My error; I've fixed this (previously only map2-collapsed worked and not map2-collapse). There are a number of things which I should probably add to the documentation but haven't. Jc86035 (talk) 04:44, 2 January 2018 (UTC)
I noticed that when I try to link an icon that has more than one overlay, the link doesn't work (as shown in the box). How can this be fixed? epicgenius (talk) 19:57, 28 February 2018 (UTC)
@Epicgenius: It looks like no one ever added the functionality for this (Sameboat and YLSS wrote this part of code, I think). I don't know if I have time to add it, or to clean up the icon parameter coding, but maybe someone at WT:Lua could help. Jc86035 (talk) 07:42, 23 March 2018 (UTC)
Me neither! Which means this request is not ready to be made. So I'll leave it marked as answered until you have found someone to code it. — Martin (MSGJ · talk) 20:22, 20 March 2018 (UTC)
@Useddenim and MSGJ: For the text colour, I think it'd be easiest to just use |style=color: colour, since this is not really something that a lot of diagrams will need. I don't think changing the behaviour of |bg= is a good idea, since currently all |...1= parameters have aliases without 1 (e.g. |map1-collapsible= = |map-collapsible=). Just use all the parameters, or use |style=background: colour to change the background of the whole container table. Jc86035 (talk) 07:50, 23 March 2018 (UTC)
@Jc86035:|style=background: works (although without the elegance of {{{bg1}}} and {{{bg2}}}, because the padding has to be added manually); |style=color: doesn't. Useddenim (talk) 10:25, 26 March 2018 (UTC)
@Useddenim: It works for me (see diagram above); is there a part of the diagram table where it fails? (I'm ignoring the header text since if it were changed as well there might be contrast issues without a different colour for the header being explicitly specified.) Jc86035 (talk) 05:49, 23 April 2018 (UTC)
Not sure where we are with this or what the parameter even does but it appears clear it needs to be coded first, then a request can be done if needed, so marked as answered. Can request slave labour help at Wikipedia_talk:LuaGalobtter (pingó mió) 13:05, 30 March 2018 (UTC)
@RexxS: Sorry; I didn't realize which part of the code you were editing. I think it would be better to fix it in a way which doesn't break the table, for example by allowing the sidebar table cells to have rowspan (and then manually fixing a lot of diagrams). Jc86035 (talk) 10:13, 19 May 2018 (UTC)
As noted, I would like to make the template compliant with the guideline while avoiding gaps between images. Because of the way that rows are generated it would be a bit difficult to allow for rowspan, but it would probably be the best option. Jc86035 (talk) 10:27, 19 May 2018 (UTC)
I'm afraid you're mistaken about my change to Module:Routemap/sandbox. It does do something, so I've reverted you because you made the text non-complaint again. MOS:FONTSIZE is not negotiable. If you think the edit did nothing, please compare Template:Wherry Lines with Template:Wherry Lines/sandbox. I think you'll find the difference striking. As far as I can see, there is no problem with line heights in that template, although the first line in BSto could be rendered slightly smaller if problems occur. Just reduce the '105%' in line 1100. --RexxS (talk) 10:18, 19 May 2018 (UTC)
@RexxS: Sorry about that (I've replied at the template talk page). It would be visually disruptive to introduce gaps between the rows of images. Try looking at the template in the mobile skin. I do remember spending quite a while to make the template function properly and not look terrible in Minerva. Jc86035 (talk) 10:22, 19 May 2018 (UTC)
My last changes decreased the overall fontsize to 95% of page fontsize, then increased the smallest font up to 85% of page fontsize. Unfortunately that left both lines of BSto at the same font size. The Minerva skin still has a gap in the images at the ante-penultimate row. I don't think it's possible to get two rows of text using the Minerva skin into a height of 20px. I'll have a look at the images then. --RexxS (talk) 11:28, 19 May 2018 (UTC)
@RexxS: Oh, and it should also work in {{BS-map}} and {{BS-table}} diagrams, both of which are a bit broken, have different CSS and don't display correctly in Minerva at all. Also the PDF renderer.
I think it would be better to wait until any of the following happen: (a) TemplateStyles is enabled; (b) the other two diagram types are replaced entirely, which probably won't happen in a while; (c) someone figures out how to cleanly add rowspan to Module:Routemap table cells. Jc86035 (talk) 11:38, 19 May 2018 (UTC)
Well, in the meantime, if it's a choice between accessibility and aesthetics, then accessibility really has to take precedence. I'll ping @Redrose64: into this discussion, as he was the one who started me down this particular rabbit-hole. --RexxS (talk) 11:56, 19 May 2018 (UTC)
@RexxS: I'd always assumed that RDTs remained this way because it would be prohibitively difficult to make them usefully accessible to those with poor vision in any way. For example, the icons are currently displayed in triple-nested tables (one for each row, one for each diagram, one for each Routemap/BS-map) and overlaid above each other with position:absolute divs, and have no alt text, which means screen readers are completely out of the picture. I'm probably the only Lua-competent user around (Sameboat doesn't edit much any more), and I haven't had the time to write a module to generate alt text like {{BS-alt}} used to. There are almost 100,000 icons, so obviously the BS-alt switch parser function became impractical a while ago. The colors are also fairly difficult to distinguish: open and closed line colours (e.g. #BE2D2C and #D77F7E) have a 2.0 contrast ratio (test others). Right now, I still don't think making some of the text bigger is going to help in a particularly meaningful way, especially since the majority of the text is compliant with the guideline. Jc86035 (talk) 13:22, 19 May 2018 (UTC)
If something performs badly with a screen-reader, I don't accept that as a reason why it should also perform badly for all people with impaired vision. The discussions on text size at MOS were quite conclusive about the necessity to have a minimum acceptable size. That has nothing to do with screen readers and the problems of alt text. It's important to realise that poor colour contrast is improved by scaling up, so whatever contrast problems exist with 20px images can only be alleviated, not worsened, by moving to a larger image. --RexxS (talk) 13:53, 19 May 2018 (UTC)
Images
@Jc86035 and Redrose64: An experiment with font-size and line-height leads me to this:
First line of text
Second line of text
First line of text
Second line of text
First line of text
Second line of text
Because Minerva has a default font size of 16px, the minimum allowable fontsize is therefore 85% of 16px = 13.6px. Any line-height greater than 0.8 breaks the line in the table, so that's the best we can do if we want to preserve both the line continuity and comply with MOS:FONTSIZE. The question then is does that text look acceptable, or do we need more line height? If so, then the size of the images will have to be increased to keep the lines continuous. Once that decision is made, then we can look at sorting out the module and templates. Thoughts? --RexxS (talk) 12:41, 19 May 2018 (UTC)
@RexxS: I think for now the font size should be made larger if only one of the table cells contains text. A lot of BSicons have been drawn specifically so that they don't look pixelated at 20px height (i.e. most rectangular objects adhere to a 20-by-20 grid), so it would be somewhat annoying if we had to switch to e.g. 30px as everything would look very blurry on low-pixel-density screens. Jc86035 (talk) 13:11, 19 May 2018 (UTC)
@Jc86035: I'm not sure I understand you. We can't have font sizes less than 13.6px in Minerva because of MOS:FONTSIZE. There's clearly no problem when fitting just one line of text in to a 20px height, but keeping double lines of text at less than 85% of the page font size simply isn't an option. I can't understand why you think pixelation of larger images would happen because, as far as I can see, all of the BS icons available at c:BSicon/Catalogue are svg images, which scale up without pixelating. --RexxS (talk) 13:21, 19 May 2018 (UTC)
@RexxS: With the images rendered as PNGs, it does affect the display to some degree if objects don't correspond to pixels (especially at this resolution).
The software eventually renders the images as PNGs, but does its best to scale the SVGs up cleanly. SVG images that render well at 20px rarely render worse at 30px and I don't agree that we have to make special allowances for very low resolution displays; readers will expect them not to perform as well as high-res ones. Here are a couple of icons at 20px / 30px:
—
—
Do you know of a device that shows the second row worse than the first? It's a mistake to cram so much information into a box that it is unreadable, so if we are to have these sort of routemaps, then we have to have them large enough to read. --RexxS (talk) 13:46, 19 May 2018 (UTC)
@RexxS: I've tried using 28px in the module sandbox (the row height has to be a multiple of 4, because MediaWiki rounds image widths to the nearest integer and some icons have 1:4, 1:2, 3:4, 5:4, 3:2 and 7:4 aspect ratios). It doesn't look bad except for the text now being disproportionately small, but issues will definitely probably come up with parameter values which are in pixels, and maybe other things. (The module already converts |tw= values to ems from pixels; this will need to be fixed since it's basically another hack to make it not break in Minerva.)
@Jc86035: Looking at Template:Wherry Lines/sandbox and https://en.wikipedia.org/wiki/Template:Wherry_Lines/sandbox?useskin=minerva I must say I like them a lot. Everything is clearer for me; I especially find the text more obviously associated with the corresponding feature in the image. I think that basing it on 24px would be just about usable, but all of the text would need to be almost the same size, so it's less ideal. It needs testing in some real templates to see what problems (if any) will arise. You're right, of course, that the biggest obstacle will be folks who dislike any change, but you've done all you can to satisfy MOS:FONTSIZE, so you can be proud of your efforts. --RexxS (talk) 16:22, 19 May 2018 (UTC)
@RexxS: What's wrong with using a browser's (device's) zoom function to examine smaller text? One has to do that anyways to see fine detail in images on mobile devices. Useddenim (talk) 06:33, 27 May 2018 (UTC)
@Useddenim: For your comment about the ECML diagram, I actually used it as a test. The original was already quite long, but the test diagram taking up more space isn't necessarily a bad thing. (Even with the current templates and text sizes, a lot of diagrams don't really fit into the space in infoboxes.) A lot of people might not know that they can zoom in, especially on desktop browsers.
Changing to 24px might also allow some more flexibility in rendering diagonal parallel lines, since they are currently spaced at intervals of 1⁄3 along the icon edge. I don't know what 24px will look like, though. Jc86035's alternate account (talk) 09:21, 27 May 2018 (UTC)
Compared with Template:East Coast Main Line diagram it has exactly the same balance vis-a-vis lines to white space. The text is less cramped in the sandbox version, of course, as the 28px image version has more room for the double text lines (like "Waverley Route" | to "Brunstane"), but the sparsity of text in the leftmost column is identical in both cases. --RexxS (talk) 18:54, 27 May 2018 (UTC)
@Useddenim: In theory, we can say that both our BS icons (SVG files) and type (TTF, OTF) have a vectorial basis, and therefore this can all be scaled limitlessly (long time ago I tried to implement a zoom function in RDTs, by the way). In practice, and in my humble opinion, here expressed solely because I was pinged, MOS is crap. Tuvalkin (talk) 22:36, 28 May 2018 (UTC)
@Useddenim: Older folk and those who are visually impaired are only able to comfortably read a relatively smaller range of text sizes. So they will have already set resolution and browser zoom to whatever is most comfortable for them. It is disconcerting to have to keep on changing from one zoom to another just to be able to read some tiny text. When you restore your previous zoom to go back to reading normal text, you will often have lost your place in the article. Simply put, having text below about 85% of what is "normal" size will make the experience much less comfortable for a significant sector of our readership. --RexxS (talk) 09:48, 27 May 2018 (UTC)
OK then; first an explanation on why I have been quiet. As I remarked to RexxS more than a week ago (and demonstrated using a SMS text from my manager that conveniently arrived whilst we were talking), I'm working pretty much full time these days (week ending 27 May I clocked 45 hours) and have a serious watchlist backlog. Tomorrow (29 May) is my first free day since that SMS.
Now to what started this: it was my request to RexxS here. Put simply: I cannot read the two-line text in Template:Wherry Lines (except in one instance: Haddiscoe Junction). My eyesight is not brilliant: but I defy anybody to state that all of the two-line text is perfectly readable at normal zoom in MonoBook skin. Since this is an accessibility issue, it must be fixed - we have no choice in the matter. WCAG is not something that you can opt out of.
We need to increase the font size. Period. This causes other issues and for me the simplest next step is to eliminate two-line text and put it all on one line. This will of course increase the width of the RDT; but that in turn suggests that we should ask "do we really need all this text?" Originally, RDTs had station names and little else, we didn't dress them up unnecessarily. So let's cut the crap. --Redrose64 🌹 (talk) 20:15, 28 May 2018 (UTC)
@Redrose64: You're right; you are ranting. Also, your accusation of 'refactoring of somebody else's post' completely removes the context of my comment. And we really don't need a note from your boss excusing you from editing on Wikipedia; you're a responsible adult who can make his own decisions about what to do with your time. Good Night. Useddenim (talk) 20:34, 28 May 2018 (UTC)
This edit was in direct violation of WP:TPO which says "you should not break up another editor's text by interleaving your own replies to individual points".
Is it really wrong for me to explain my silence? Other people take wikibreaks for various reasons, many of them say why that is. --Redrose64 🌹 (talk) 20:50, 28 May 2018 (UTC)
@Redrose64 and Useddenim: I think increasing the image size in Routemap and BSpx to 24px or 28px, and then changing BSsplit etc. to use div/br tags and larger text, might be better than instantly eliminating the split rows entirely. Otherwise things like labels for objects split between two rows and multiple objects in the same row (e.g. (WBRÜCKE1-WBRÜCKE1)) might be broken. (Currently it is a bit difficult to change image size in {{Routemap}}. I or some other Lua-competent editor will have to fix that at some point.) Jc86035's alternate account (talk) 11:26, 29 May 2018 (UTC)
Also, there are text cells and images of text which we might want to make larger. (In making Routemap's text cells I tried to squeeze the font so a digit would fit onto the grey part of (cBS-), so the font size is half of the icon height and the characters are transformed to be 10% narrower than usual. This size is still larger than that of the characters in the images, which currently have an effective font size of about 8px.) If the font size of the text cells is kept at 50% of the height, then 28px icon height would be necessary to comply with MOS:FONTSIZE in Minerva (13.6) and Timeless (12.92), although for 24px we could ignore those skins because they aren't mentioned in the guideline change the line height and horizontal scaling of the text. Jc86035's alternate account (talk) 14:50, 29 May 2018 (UTC)
Using this template in another Wiki
I've done many edits using this template and find it very useful. I also edit Wikipedia in other languages and would like to use it there as well.
How can I use this template in another language? Is there a way to copy it?
@Chocom: Assuming you only want to add this to WMF wikis, you will need to import (ask an admin on your wiki) Module:Routemap and Template:Routemap at a minimum, although you will also need Module:Color contrast, Module:Navbar and Module:Arguments if they do not already exist. Importing is restricted on most wikis so you will want to ask an administrator to help you, although sometimes I just copy and paste the pages and link to the original page/revision in the edit summary text (as you should do when updating a page based on another wiki's version). You will probably want to import and translate the documentation pages but it is not strictly necessary. The Routemap module itself also has some text strings (in the i18n table at the top) like the "Legend" text which you should translate. (You don't need to translate the text after double hyphens, because those are hidden comments and should remain in English.) The other templates which rely on the module are listed in the module documentation, but you don't need to import them. There are also several templates in Template:Routemap/doc which other wikis probably don't have all of, and you might want to import those as well. Jc86035 (talk) 15:51, 4 July 2018 (UTC)
@Jc86035: Followed your advice and it looks like it's working nicely. Thanks! I still need to translate lots of the documentation and the legends, but that is a WIP. One thing I'm still stuck on, the V T E links at the top of the infobox, where are they defined? In my version the row is "deformed" (broken onto 3 rows, the brackets being one row above and below the letters) and I would also like to change them to the correct letters for this language. Any ideas? --Chocom (talk) 08:11, 5 July 2018 (UTC)
The v-t-e links are defined by the |navbar= parameter. This should normally be set to the pagename of the template - for example, in Template:Bakerloo line RDT we have |navbar=Bakerloo line RDT. If such a template is subsequently moved, the |navbar= param must be updated to suit, like this. --Redrose64 🌹 (talk) 10:59, 5 July 2018 (UTC)
@Redrose64: I don't think Chocom was asking about that. If you want to change how the navbar template looks you should probably edit Module:Navbar on the Hebrew Wikipedia. It has displayed badly for me on some browsers in the past; it's probably either an issue with the module not being updated (to match the English Wikipedia version) or an issue related to the switch from HTML Tidy to RemexHtml.
If you've run into issues with the right-to-left text, it's probably fairly complicated to change the template to a natural sort of order but you could try adding text direction attributes and see what happens. There's a Routemap on arwiki, I think, but it doesn't seem to have been modified. Jc86035 (talk) 11:32, 5 July 2018 (UTC)
@Redrose64:Thanks for the info. @Jc86035: It looks a bit more complicated than I want to deal with right now. For the moment I just removed the navbar parameter so it's not showing. Just wanted to say thanks for the help and support! On the Hebrew Wikipedia I've so far only received negative comments, they're discussing deletion of the work I've been doing in this area, based mainly on the fact that I don't have 1000s of posts like they do. Needless to say, I prefer editing here. --Chocom (talk) 11:48, 5 July 2018 (UTC)
Template-protected edit request on 28 July 2018
This edit request to Module:Routemap has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
I am trying to rewrite Template:Bridgewater Canal map, currently a BS map, as a Routemap. One of the problems with the existing version is that when you expand the collapsed sections, the alignment goes to pot.
I have a version at User:Murgatroyd49/sandbox2 that works for three out of the five collapsible sections. Currently the 2nd and third sections have the <collapsible> mark-up commented out and it works, if I uncomment either of those sections, the whole thing breaks again. What am I doing wrong? Murgatroyd49 (talk) 14:10, 14 July 2018 (UTC)
All of the sections (both collapsible and at least one segment of the main) must be exactly the same number of icons wide. It's been fixed. Useddenim (talk) 12:49, 28 July 2018 (UTC)
This edit request to Template:Routemap has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Please remove the line <noinclude>{{pp-protected|reason=1500+ transclusions|small=yes}}</noinclude>, since it is handled automatically by the documentation page.
@WMSR: I think it's technically possible if you pass the {{stl}} output through Module:Redirect, but I don't think you should bother. There are actually only 66 diagrams (out of several thousand) that use the !@ function in the first place. It'd be possible to modify Module:Adjacent stations to allow {{stl}} to output just the page title, but someone would need to write the code for that to happen. Jc86035 (talk) 16:14, 21 June 2019 (UTC)
For me, the top "commuter terminus" (when collapsed) and "River Boris" (when expanded) is a couple of pixels to the right compared to "station" and the bottom "commuter". If "commuter terminus" is replaced with shorter text, the top part is misaligned to the left, but only in collapsed state:
{{Routemap|map-title=Example 6.2: Only main text cell applied
|style=width:380px
|text-width=,120,,,120,
|map=
-startCollapsible
first terminus! !uKBHFa\\KBHFa~~regional terminus
River Boris! !uhKRZWae\WASSERq\hKRZWae~~bridge
-endCollapsible
station! !uINT\LDER\LSTR
second terminus! !uKBHFe\\KBHFe~~regional terminus
}}
Version with shorter text is aligned properly in expanded state. Checked in Firefox browser. Issue is present on all zoom levels between 100% and 200% for the first example, and on 100%–190% on the second example. —andrybak (talk) 19:25, 20 June 2019 (UTC)
My first test was on Firefox in Kubuntu. Firefox on Windows look more or less OK (only saw one issue on 90% zoom). Chrome on Windows looks fine on all zoom levels—it seems to employ a different strategy to zooming compared to Firefox. Will try to check on newer version of Firefox in Kubuntu later. —andrybak (talk) 10:29, 21 June 2019 (UTC)
@Andrybak: This is partially dependent on your browser's default fonts, because some fonts are wider than others. If your browser uses Helvetica, Arial, San Francisco, Roboto or Liberation Sans as the default sans-serif font, then the table should be wide enough (assuming the CSS works properly). However, if your browser uses Verdana or Bitstream Vera as the default sans-serif font, then it's possible that some diagrams will not be wide enough simply because >99% of users don't have this configuration and no one noticed.
You can usually fix this by changing |text-width= until the table cells are wide enough. However, I think it would be inadvisable to test this with any font wider than Bitstream Vera, since there's always going to be some other typeface that has wider characters, and the (fragile and slightly invalid) collapsible table structure necessitates fixed column widths. Jc86035 (talk) 16:02, 21 June 2019 (UTC)
Add DejaVu Sans to the list of bad fonts. Switching to Liberation Sans fixed the issue in Firefox in Kubuntu. Jc86035, thanks for clarifying! —andrybak (talk) 17:51, 21 June 2019 (UTC)
Text overlay
@Useddenim: Further to the revert, the reason overlay is needed a lot of the time is because the transform function applied makes some of the characters just slightly over 5px wide in Helvetica/Arial at that font size, which means that they'll often mess up the row unless they're put in an overlay cell. I do think this should probably be explained at some point in the documentation. (The way you added the overlay in the example diagram was also incorrect because you didn't add d on the bottom layer.) However, there are not a lot of sans-serif fonts where numerals are wider than they are tall, and most people should be seeing a fairly normal font as the default sans-serif font in their browser, so I don't think the example as it currently is should be problematic. Jc86035 (talk) 08:01, 10 August 2019 (UTC)
Collapse function does not appear to work on m.wikipedia
As of August 2019[update], RDTs that are set with collapse=yes (and do collapse in "normal" wikipedia) do not collapse when visited via m.wikipedia. (Compare, for example, https://en.m.wikipedia.org/wiki/West_Coast_Main_Line with https://en.wikipedia.org/wiki/West_Coast_Main_Line ). The effect of this fault is that visitors on mobile (cell-phone) can be confronted with pages and pages of detailed track layout and will probably turn away.
@John Maynard Friedman:All collapsing within the page content is disabled on mobile, because the relevant JavaScript is not loaded. (While the mobile site does collapse every level 2 section on the page, this is a separate function.) There's nothing we can really do about this unless there's a convincing case for enabling it across the board. Jc86035 (talk) 03:48, 19 August 2019 (UTC)
Because that would be yet another syntax to learn. It's bad enough with the two we have at present, one based on Wikimarkup, the other not. --Redrose64 🌹 (talk) 00:00, 25 November 2019 (UTC)
Documentation
I am finding this very difficult to learn. For starters, is there a complete (or largely complete) list of the icons somewhere? I'll probably have a bunch more questions. - Jmabel | Talk22:18, 8 August 2019 (UTC)
Thanks! Should I have been able to find those from the help text for the template? Because I sure didn't. - Jmabel | Talk22:27, 8 August 2019 (UTC)
I get some of this, but I still don't seem to have my head around it. Could someone take a look at User:Jmabel/sandbox? I think it should be clear what I'm trying to do, and where I'm failing. If someone could fix it, I'm sure I'd learn a lot from seeing the diff. - Jmabel | Talk22:56, 8 August 2019 (UTC)
@Jmabel: done, see Special:Diff/910000216. Firstly: give more room for junctions vertically. Example: for "Coal Creek" I moved BS2+r one row down, and simple STR acts like a vertical spacer, same thing for "Taylor". Second: don't try to remember codes. I just stare intently at Commons:BSicon/Catalogue until I see the icon I need. Navbox at the bottom can be especially useful, click through to subpages. Every time I edit route maps I need to re-learn how corners are numbered, for example. Third: the only tricky part is the three-way under "Black Diamond". At first, I tried using kABZg23, but I couldn't figure out icons for corners for right and left branches to Franklin and Bruce. So started looking at Commons:BSicon/Catalogue/junctions/3-way, where I found ABZg23 ("Branch straight, to corners 2 and 3"). The next row after that is very straightforward — it consists only of STR code icons (although some are overlapped using !~) with different modifiers. The particular versions of STR I found at Commons:BSicon/Catalogue/branchings. With regard to documentation of Template:Routemap — it needs a section about icon separators. Information about slash, tilde-tilde, exclamation mark-tilde (is this all of them?) is spread across several sections and is hard to find. —andrybak (talk) 01:01, 9 August 2019 (UTC)
@Andrybak: I would say remembering the codes (especially the simple ones) is definitely a good way of drawing diagrams if you already know all of the icon types, although I'm probably biased since I've uploaded and renamed quite a lot of BSicons.
I've added an overview section to the documentation, which hopefully helps. I've also realized that the collapsible section code is a bit hacky, which is why I've commented out part of the overview table. Jc86035 (talk) 01:42, 9 August 2019 (UTC)
@Jmabel: There should probably be a guideline written down somewhere for how to draw diagrams, but there isn't. Which sort of makes sense, since most of the complex diagrams have been drawn up by the same few users, but it's still kind of detrimental since we've probably discouraged a couple of new users by reverting them for not following various unwritten conventions (e.g. use {{Jct}} sparingly, omit level crossings for mainline railways).
While the current diagram would already be acceptable, there's probably a lot of missing detail that would be useful and there are some conventions that we'd need to follow. I think first you would have to decide whether you're drawing a service diagram (i.e. details like bridges and tunnels are omitted) or a line diagram (i.e. details like bridges and tunnels are shown).
Off the top of my head:
Since part or all of the railway has been closed, for a line diagram it would be best to show either (a) which parts of the railway still exist and which don't, by using (exSTR) icons instead of (STR) icons, or (b) which parts of the railway still existed at a particular point in time (or multiple points in time, if necessary, usually by using multiple maps in the same container).
(INT) is usually reserved for large or intermodal interchange stations. If you just want to indicate relatively important stations, you should probably use (BHF) and (HST).
If the railway has a main route – it seems to have one – then it would be better to indicate this by drawing the main route as a straight line through the whole diagram. Allowing it to curve out for branches is usually unnecessary unless the diagram is already really wide or there isn't a single "main" line at a certain point.
If you want to save space, you can often overlay icons over junctions (e.g. d!~KRWgl\d!~lHST\KRW+r or KRWgl!~lHST~L\KRW+r!~lHST~R) or use icons with stations on curves like (HST+4).
Also, these might be useful for your particular diagram. I haven't edited your sandbox but you should be able to just paste these in directly if desired. Jc86035 (talk) 02:23, 9 August 2019 (UTC)
The actual template name needs to be in |navbar= (sometimes it's the same as the header, but this is not usually the case). I've fixed it. Jc86035 (talk) 07:50, 12 August 2019 (UTC)
