Template talk:Routebox2

From Wikivoyage
Jump to navigation Jump to search

New template: Template:Routebox2[edit]

Swept in from the pub

New template time again, but here it is.

For a long time, not being able to use Templates in routeboxes has been quite a problem. Given that we're shifting from images for roads and transports, to templates in particular note {{rint}} and the future RINTroad, it kinda sucks for routebox to not be able to accept templates. So here it is. Used it on the French Wikivoyage (infact I made a similar template there before coming and making the same here), and used the concept of voy:fr:Modèle:Routes and made this templates.

I'm still in the proposal of creating the documentation, but it's half done. This template can accept images if needed, just now the usual way of adding an image ([[File:qwerty|20px]] ) instead of the former way of using routebox.

Any feedback for this template is greatly appreciated :). SHB2000 (talk | contribs | meta.wikimedia) 13:50, 21 September 2021 (UTC)[reply]

  • Oppose: I'll be ignoring the preparation for RINTroad, which, as I detailed below, will not be done in the foreseeable future, nor is in any way, shape or form cleared for introduction to begin with. This template, as I understand it, builds off of the longer-existing idea of allowing route marker templates to be used in Routeboxes instead of purely images. There are some problems with this method of achieving this though:
Routebox2 allows only for the inclusion of templates, and is therefore not backwards compatible with {{Routebox}}. Since the introduction of templates into routeboxes will most certainly be slow and gradual in nature, you will eventually end up with two routeboxes, as neither can support a combination of images and templates, which I likely won't have to say is far from ideal. Meanwhile, Routebox uses a subtemplate ({{Routebox/row}}) for every image inclusion. The better way would be to allow for a switch between /row (image-mode) and a template mode (which would be Routebox/tl or something along those lines) within Routebox through a parameter, let's name that parameter "mode" for now. "mode" can be set to two, or if the need arises later, possibly more values: "image"/"img" or "template"/"tl". To allow for backwards compatibility out of the box, "image" needs to be the default option. By adding a line such as |mode3=template, you could make the third listing in the Routebox use a template rather than an image. This wouldn't break with the current workings of Routebox and leaves us from having two competing versions with the exact same goal.
This template, quite literally called Routebox2 should, if anything, work off of what exists as Routebox(1). Starting from scratch and introducing this as a stand-alone template will do nothing but complicate its introduction. Outside of that, I am still in favour of working templates (specifically RINT, as metro and tramlines labels are scarcely available on Commons) into Routeboxes in a way that does not disrupt the current usage of Routebox, which is already present on a whopping forty percent of articles.
-- Wauteurz (talk) 21:22, 30 September 2021 (UTC)[reply]

Improving icon legibility[edit]

Routes via the Afsluitdijk (current size)
AmsterdamHoorn W  A7  /  N7  E  SneekGroningenWeener
Cadzand-BadDen Helder SW  Kustroute  NE  HarlingenBad Nieuweschans
AmsterdamEnkhuizen   Zuiderzeeroute    HindeloopenAmsterdam


Routes via the Afsluitdijk (larger labels)
AmsterdamHoorn W  A7  /  N7  E  SneekGroningenWeener
Cadzand-BadDen Helder SW  Kustroute  NE  HarlingenBad Nieuweschans
AmsterdamEnkhuizen   Zuiderzeeroute    HindeloopenAmsterdam

Something I'm noticing is that icons in Routebox2 appear very small to the point of having a questionable legibility. This is due to {{RbE}} using a font-size:70%, which then gets topped by a font-size:smaller courtesy of Routebox2, for a grand total of about 50% of the normal font size, which altogether, makes the labels tricky to make out, or near-impossible when the labels aren't using the most legible colours. RbE needs to be so small because its main use is to generate labels that are intended to appear within articles, like {{Rail-interchange}} and its derivatives, and thus cannot be so big to where they would distract from the article. For Routeboxes though, I don't see that being as much of a problem, and if anything, I'd assume we'd want to have the label clearly legible.

@SHB2000: Do you mind if I modify Routebox2 somewhat to counteract this, and to possibly simplify its CSS somewhat? I'm thinking the centre column for Routebox2 can easily be scaled up without it making much of a change to the template overall, as visible in the example on the right. It applies font-size:smaller to the entirety of the box, then gives the label +120%, for a total of about 90% the font size in comparison to the rest of each Routebox line.
Wauteurz (talk) 16:08, 14 August 2023 (UTC)[reply]

Yeah, that works; thanks for the modifications! --SHB2000 (talk | contribs | meta) 21:31, 14 August 2023 (UTC)[reply]
No worries! I've just published my modifications. Everything should still work the way it did, but in case it doesn't, feel free to ping me :) Wauteurz (talk) 08:59, 15 August 2023 (UTC)[reply]
Awesome – I just had a look at Canberra/Civic#Go next, and I have to say, it looks much more readable. --SHB2000 (talk | contribs | meta) 09:47, 15 August 2023 (UTC)[reply]
I would agree. I did notice that the labels have more vacant space above them than below them though. It's only about a pixel and a half, but it's still off-center. I did add a vertical-align: middle to the styleset, but it wasn't the solution I was hoping it'd be. I suspect the vertical misalignment is a trade-off that comes from downsizing the text. Since it doesn't affect the usability of the template though, I'm not sure it's really essential to fix. Also, I did just spot that the header text got downsized too, so I'll fix that right now. After that, I think we're properly done.
On another note, I have to say the template works out better than I expected it to two years ago and I might have been overly sceptical then. I might go as far as to pick up RINTroad's development and use it alongside Routebox2 on some Dutch/Luxembourgish articles, but I'll slide onto your talkpage about that later since it does affect other templates of yours like {{AUR}}. Wauteurz (talk) 10:20, 15 August 2023 (UTC)[reply]
Funnily enough, the main reason why I created this was not to handle templates (though that was the problem with {{routebox}} that needed to be addressed), but to resolve the issues with Australian route markers and c:COM:TOO Australia (I still find it hard how route markers are copyrightable, but it is what it is).
Another possible improvement that could be addressed is backwards-compatibility (as you mentioned two years ago), but that will require a lot more effort and maintenance. --SHB2000 (talk | contribs | meta) 11:38, 15 August 2023 (UTC)[reply]
It'd be a hassle to implement that backwards compatibility, though honestly, there's nothing wrong with maintaining two styles of routebox aside from visual appearance to the reader. So long as routeboxes are replaced region-by-region, I don't think that that has to be called an issue though.
I see two ways in which backwards compatibility can be applied if we ever do get serious about implementing it:
  • On label-level: Have a toggle between a "new" and "old" version for each label line, with old being default and using {{Routebox}}'s parameters. New just prints the label-line as it does in Rb2 currently.
  • Template-wide: Have a single toggle between versions for the entire template; which would mean the template has to contain two routeboxes: Rb2, and an adapted Rb2 that uses Rb1's parameters.
Nether is perfect, but I think there's potential in that first option. It'd have the added benefit of being able to replace labels as they get added into templates like RINT, RINTroad and EUCR, CCR, etc. too. But like I said, if Rb2 is implemented region-by-region, I don't think that backwards compatibility is needed per se, as Rb2 can technically use images, but needs a bit of a work-around for it...
Wauteurz (talk) 12:01, 15 August 2023 (UTC)[reply]