From Wikimedia Commons, the free media repository
Jump to: navigation, search
See also: Talk:BSicon/Renaming/SPL,
Talk:BSicon/Renaming/k and

Suffix reuse[edit]

@Useddenim, Tuvalkin, C21H22N2O2, Newfraferz87:   (RP4r),   (RP2r) and   (RP1r) (roundabouts) are currently blocking page moves for   (RP4rf),   (RP2rf) and   (RP1rf) (90° curves). I did not notice this so all of the others have been renamed (I used pywikibot so they were all done in one go). Should the roundabouts be renamed? Jc86035 (talk) 15:59, 12 September 2017 (UTC)

Symbol strong support vote.svg Strong support Which suffix would be well for them? rb? -- C21H22N2O2 /talk/lab/de/en 16:23, 12 September 2017 (UTC)
  • @C21H22N2O2: Just b would work (I think two letters is unnecessary). Jc86035 (talk) 16:26, 12 September 2017 (UTC)
  • Civilspanaren used r (from "roundabout"?) back when these road icons were meant to be something different than just a new “set light-grey-with-white-lane-lines”, but now it really needs to be changed. Too bad that o and x have already meanings, and b is not really free for use, although it is a prefix. Now, some ideas:
d + STRrg
BSicon d.svg
d + KSTRe
BSicon d.svg
d + STRlf
BSicon d.svg
d + KSTRa
BSicon d.svg
BSicon .svg BSicon .svg
d + RP2rns
BSicon d.svg
  • Thinking in broader terms, though, what we have here is a kind of crossing/merging of genric “lines” not unlike what we name as, say,   (ABZ),   (WSL), or   (ÜST). This suggests that what we need here is not a new suffix, but a new root name!
  • (Of course that would clash with current naming of these road icons, where, according to the original naming idea, the root ID determines the type of road while prefixes and sufixes denote geometry and topology. So, either we keep these road icon names as a separate paradigm, or we homogenize them all. The series   (SKRZ-G) shows that a hybrid naming scheme, if properly implemented, can be successful, however.)
  • If we think that it would be useful to have this geometry/topology in a single icon for any regular line/track icon, not only for these road oddities, (see diagram) then we should find a new root ID for these icons.
-- Tuválkin 18:37, 12 September 2017 (UTC)
What about using D as a suffix (RP#D a/e/l/r), for the (visual) similarity to   (DST)? Useddenim (talk) 19:15, 12 September 2017 (UTC)
The root structure is fine, but why not RP#RB? -- C21H22N2O2 /talk/lab/de/en 19:47, 12 September 2017 (UTC)
@C21H22N2O2: I would avoid using both capital B and capital R due to   (RB) (as with RA, D, E, G, M, P, R and Y). One letter might be fine. Jc86035 (talk) 02:58, 13 September 2017 (UTC)
@Useddenim: I'd use d since it's unused and not a valid suffix without +. D is a suffix already   (DKRZD), so it should probably be avoided here. If there's no objection I'll rename them at some point. Jc86035 (talk) 08:07, 1 October 2017 (UTC)
@Jc86035: RP#d would be fine. Useddenim (talk) 11:28, 1 October 2017 (UTC)
  • My opinion is that you can change to any suffix that suits, just it works with other icons. --Civilspanaren (talk) 07:13, 18 September 2017 (UTC)

Cutting to tunnel transitions[edit]

@Useddenim, Tuvalkin: I have renamed most of the *CC icons (the enwiki catalogue needs updating), but I didn't realize that the CBHFCC icons would be problematic since e.g.   (tCSTRa) shows the end of a tunnel, as opposed to   (htSTRa) showing the start of one.

  • Should   (tCSTRea)/  (tCSTRae) (plus variants) be renamed to teCSTRa/taCSTRe (or tCaSTRe/tCeSTRa)? The usage of ae and ea, of course, conflicts with   (tSTRea) and similar.
  • None of the CBHFCC icons are actually in use, having been created randomly by 京市. Should they be re-renamed from *eaq to *aeq, or should I just upload the correct shape (with the cutting on both sides) without renaming them?
  •   (uextCSTRea-Rq) and others uploaded by Xeror are out of sync with the other tunnel portals uploaded by Useddenim. Should they be re-renamed from *eaq to *aeq as well?

Jc86035 (talk) 07:42, 1 October 2017 (UTC)


@Useddenim: Since there's no WDOCKS-L, shouldn't   (WDOCKS-Le) etc. be named based on   (WDOCKSe) and therefore be WDOCKSe-R [right side], like   (lhSTRe-R)? Jc86035 (talk) 11:22, 8 October 2017 (UTC)

Yes. Useddenim (talk) 10:05, 9 October 2017 (UTC)
✓ Done Jc86035 (talk) 12:38, 9 October 2017 (UTC)


@Useddenim, Tuvalkin, Axpde, Vunz: Since there are now a bunch of weirdly named WSLs uploaded by 蘭斯特 like   (WSLr+l+l), and since the existing system is also a bit inconsistent, should the WSL naming conventions be changed? Jc86035 (talk) 12:37, 9 November 2017 (UTC)

Current Proposed (Jc86035) Proposed (Axpde)
  (WSLg+l) etc. ✓ Fine ✓OK
  (WSLe) etc. ✓ Fine ✓OK
  (WSLr+r) etc.   (WSLeq) (based on   (vWSLeq)) ✓OK
  (WSLqr) etc.   (WSLglq) ✓OK
  (WSLq+r) etc.   (WSLgrq) ✓OK
  (WSLql) etc.   (WSLg+lq) ✓OK
  (WSLq+l) etc.   (WSLg+rq) ✓OK
  (WSLr) etc.   (WSLlq) ✓OK
  (WSLa+l) etc.
  (WSLel) etc.
  (WSLl) (after targets are renamed and replaced)
  (WSLr+l+l) etc.   (WSLge) (based on   (vWSLge))   (WSLge)
  (eWSLgcc) etc.   (exWSLga)   (exWSLga)
  (uWSfd) etc.   (uWSLgaq)   (uWSLql+l)
  • I introduced most of those icons and named them very consistently! No need to rename them at all! a×pdeHello! 12:51, 9 November 2017 (UTC)
@Axpde: We can't use …ql+l for   (uWSfd), because following   (uexWSLg+lr), either that would be one loop on each side, or it would be impossible to have an unfilled   (uexWWPr)canal icons are exempt from logic at this point in time because of the naming conflict. If we use q as a 90° anticlockwise rotation of the whole icon, then we may as well rename all the others to use q that way where logical and appropriate. Jc86035 (talk) 15:19, 9 November 2017 (UTC)
  • Symbol strong support vote.svg Strong support, the proposed names are compatible with the current system, so I wonder why they aren't named like this. -- C21H22N2O2 /talk/lab/de/en 13:04, 9 November 2017 (UTC)
  • Symbol keep vote.svg Agree,Sorry,I don't notice the rules,other like there also,I agree to rename this.~Zh-N、En-2 蘭斯特 (talk) 13:44, 9 November 2017 (UTC)
  • Symbol strong support vote.svg Strong support Good proposal. Vunz (talk) 14:09, 9 November 2017 (UTC)
  • Symbol support vote.svg Support: Good to see q used in this simple and productive manner. -- Tuválkin 16:20, 9 November 2017 (UTC)
  • Symbol strong support vote.svg Strong support Why can't we have this kind of consensus all the time? Useddenim (talk) 19:21, 9 November 2017 (UTC)

@Useddenim, Tuvalkin, Vunz, C21H22N2O2, 蘭斯特: ✓ Done (renamed 81 files; others will follow after replacement). Further to the above, could we rename the double-width WSLs as well? (I'm not entirely sure that the existing vWSLg(+)?[lr] files are named correctly – I would have swapped l and r in the names – but they make sense. It's possible to round-robin-swap the file names and have them automatically replaced by JJMC89 bot now, though, so it's not an issue if they should be changed as well.) Jc86035 (talk) 12:02, 25 November 2017 (UTC)

Current Proposed Notes
  (bvWSL-BS2+r) etc. bvvWSLg+l (or bvvWSLg+r) like   (vWSLg+l)
  (uebSHI2+r+WSLe) uebvvWSLgr (or …gl) like   (evWSLgr)
  (bvWSL-BS2lxr) etc. bvvWSLgrxl (or …lxr) like   (vWSLgr) + (xvWSLgl)
@Jc86035: Wouldn't the bvvWSL icons look something like   (bvvWSLe), or does the bvv prefix signify something different than double-width; parallel line; parallel line? Useddenim (talk) 22:28, 25 November 2017 (UTC)
@Useddenim: I think that icon would have bvvv, per   (vSPLa) ≈ vvSTRa. I had thought bvvvWSLe would just be the outer loop, but adding inner loops where possible also makes sense. (Do you think the icons should have l/r swapped or are they fine?) Jc86035 (talk) 04:42, 26 November 2017 (UTC)

Junction icons[edit]

@Axpde: 45° junctions follow the same conventions as those with the point of the junction at f or g, just not in the way that you think they do. Jc86035 (talk) 06:42, 25 November 2017 (UTC)

  (ABZr+12)   (ABZ23)   (ABZl+34)   (ABZ+14)
  (ABZr+1f)   (ABZr+2g)   (ABZ2r)   (ABZ3l)   (ABZl+3g)   (ABZl+4f)   (ABZ+4l)   (ABZ+1r)
  (ABZr+1g)   (ABZr+2f)   (ABZ2l)   (ABZ3r)   (ABZl+3f)   (ABZl+4g)   (ABZ+4r)   (ABZ+1l)
  (ABZ3+1g)   (ABZ4+2f)   (ABZ4+2l)   (ABZ1+3r)   (ABZ1+3f)   (ABZ2+4g)   (ABZ2+4r)   (ABZ3+1l)
  (ABZ4+fl)   (ABZ1+fr)   (ABZ2+gr)   (ABZ3+gl)


@Useddenim, Tuvalkin: Assuming that the BS2 shift icons will eventually be renamed, how should   (BS2rxl) and   (eBS2lxc) be renamed based on the existing SHI syntax? Would there have to be +c2 and +c3x2/+xc2, making them inconsistent with   (eBS2l) (which would be xSHI2l)? Would we replace the c suffix? Jc86035 (talk) 08:37, 29 November 2017 (UTC)

  •   (BS2rxl)SHI2rxl+c2 and   (eBS2lxc)xSHI2l+xc3. These icons have three features (the shift(s) + 2 corners), so of course they're not going to be consistent with the simpler icons. Useddenim (talk) 11:27, 29 November 2017 (UTC)

@Epicgenius: Other than this one, the most recent discussion is here. All the elevated icons have already been renamed (most recently by me). The only pertinent concern is the German Wikipedia's Bilderkatalog, which appears to be universally seen as a design guideline (i.e. avoid bells and whistles like CONTs, 3-curves and parallel lines) but is stated to be a list of the (only) BSicons allowed in dewiki diagrams. Since it doesn't include any shifts other than the BS2 icons, the SHI1–4 icons aren't seen as canonical, and no one has ever renamed any of the BS2 icons because SHI2 is an ugly English-based root with a false suffix or something like that (I don't really remember at this point). However, I don't know if this really matters any more, since there have been so many Bilderkatalog icons which have been renamed without asking dewiki users (e.g.   (ABZgl),   (KDSTeq)). I first asked about the BS2–SHI2 discrepancy in September 2015, and the renaming was first proposed at Talk:BSicon/Renaming/SPL a few years earlier. Jc86035 (talk) 10:01, 17 February 2018 (UTC)

@Jc86035: It's not “an ugly English-based root”, as German uses the same sound in „Verschiebung”. Useddenim (talk) 04:51, 20 February 2018 (UTC)
@Useddenim: Thanks; I didn't know that (or maybe I forgot about it). Jc86035 (talk) 05:00, 20 February 2018 (UTC)
@Jc86035: Thanks for the link. On a slightly unrelated note, you said the Bilderkatalog contains "a list of the (only) BSicons allowed in dewiki diagrams". Does that mean icons not on the Bilderkatalog can't get used at dewiki? Was there a discussion there? epicgenius (talk) 01:18, 18 February 2018 (UTC)
@Epicgenius: I suppose it's just the way it's always been (I haven't bothered reading their talk page archives to find out), and it was probably quite sensible in the old days when the naming rules were less internally consistent and icons were more often uploaded with wonky geometry (though I wasn't around then). The Bilderkatalog is often ignored, sometimes so that conveniences like   (dSTRl+4h) can be used (since there still isn't an overlay function, it's not possible to have something like c!~v-SHI2r\STRl); sometimes to use KRW and kSTR icons; sometimes because editors have copied diagrams from other Wikipedias. Apparently there have been a bunch of conservative users who have refused anything like the addition of overlay (and, of course, the abolition of the Bilderkatalog) for years. Most of the time diagrams do look consistent, though. Jc86035 (talk) 07:53, 18 February 2018 (UTC)


@Useddenim, Tuvalkin: There is still some inconsistency in how SKRZs are named; could we fix that? Jc86035 (talk) 03:26, 3 December 2017 (UTC)

Current Proposed Notes
  (SKRZ-Buq) etc. ✓ Fine
  (SKRZ3+1-Bu) etc. ✓ Fine
  (SKRZ-G4hq2+4) etc. ✓ Fine (or SKRZq-G4h2+4)
  (SKRZ-G43+1o2+4) etc. SKRX-G4o If KRX is picked then a rotated version would probably be SKRX-G4oq
SKRX is much neater than SKRZ2+4…3+1, but otherwise seems like a good idea. Useddenim (talk) 12:18, 3 December 2017 (UTC)
@Useddenim: I've corrected the rest of the proposal because I mixed up the primary/secondary convention. I think the last icon is probably the only one that needs renaming at present. Jc86035 (talk) 13:31, 3 December 2017 (UTC)

✓ Done (renamed the latter icon). Jc86035 (talk) 14:02, 24 December 2017 (UTC)


@Useddenim, Tuvalkin: Should   (hWSTR) etc. be renamed to treat W as "this track is water" rather than "this track crosses water" (i.e. to KRZW;   (WBRÜCKE2) would probably become KRZWo2 or 2KRZWo or something similar)? This would reconcile the railway icons' naming with that of the water junctions like   (WABZgl). This was originally advocated by YLSS in 2014, though I didn't think it made sense until renaming   (kWKRZq+4u) in October. Jc86035 (talk) 14:02, 24 December 2017 (UTC)

  • Looks like a good idea. -- Tuválkin 16:00, 25 December 2017 (UTC)
  • Okay; but, we can't use 2 as a suffix because of the potential conflicts with   (STR2), etc. Useddenim (talk) 14:25, 26 December 2017 (UTC)
    @Useddenim: We could use it as a prefix (as with 1 for BRÜCKE1 etc.); incidentally I was thinking of making 4HUB (from 45°, 4 corners) icons for aligning HUBaq, HUB2 etc. with   (BHF2) etc.. Jc86035 (talk) 08:57, 27 December 2017 (UTC)
    @Jc86035: Wouldn't HUB2+g be a better name for the   (BHF2) overlay (similar to   (CONT2+g)? Useddenim (talk) 14:19, 27 December 2017 (UTC)
    @Useddenim: No, I meant like a   (HUB2) or   (HUBaq) where the HUB fits correctly with a   (BHF+1). I’ve seen some fudging of station positions in diagrams like w:en:Template:WMATA Blue Line where a 3HUB-G2 (or similar name) would be needed to fit 3ACCr+1 in the HUB properly. Jc86035 (talk) 15:21, 27 December 2017 (UTC)

Prefix order[edit]

@Useddenim, Tuvalkin: Does k go before [o/]c/d/b[/s/w]/v   (kvSTR+1) or after   (dkSTRc1)?

Furthermore, is it logically consistent for C, D and 3 to be "root modifiers" while other similar suffixes are placed before c, d and v (in particular 3, which isn't a capital letter)? Though vCSTR might look slightly better than CvSTR, and this doesn't really matter. Jc86035 (talk) 12:48, 27 December 2017 (UTC)

  • Definitely, q should come before anything else, I think. As for for the rest, I think you’re right, in all accounts (incl. that this doesn’t matter much). -- Tuválkin 16:44, 30 December 2017 (UTC)

Using tildes[edit]

Useddenim, are we doing this now? It seems sensible, although edge cases could conflict with the !~ used in {{Routemap}}. Jc86035 (talk) 13:11, 31 December 2017 (UTC)

Not all icons affected listed in table
Current Proposed
  (dBHF~L fuchsia) dBHF~R fuchsia to synchronize with other icons, since this is the right half
  (STR-R) STR~R (or vv--STR)
  (dSTR-R) dSTR~R or dv-STR
  (lhSTR-R) ✓ Okay
  (KRZo-R) ✓ Okay
  (lBHFf) lBHF~F
  (lvBHFf) lvBHF~f small f meaning quarter of an icon, possibly combining?
  (lvBHFgg) lvBHF~G
  (lBHFgq) lBHF~R or lBHF~Gq both names would work but since there's no line I think we would choose the shorter one?
  (dKBHF~Leq lime) dBHF~Fq lime or dBHF~fq lime
  (exKBHF~F brown) exBHF~f- brown or exBHF~F- brown with parallel lines syntax? not sure
  (mKBHF2 u~steel) ✓ Okay (or umKBHF2 ~steel)
  (mBSHI2l u~purple) umvBHFSHI2l- ~purple or mvBHFSHI2l- u~purple based on BHFABZ
  (SHI1+r+BHF) BHFSHI1+r to avoid ambiguous nesting of + combining two roots within parallel lines syntax
  (BHF yellow-blue) mBHF yellow~blue
  (BHF black-halforange) mBHFe black~orange+black
  (mbSHI4l exmaroon~ochre) embvvSHI4l-- maroon~ochre inconsistent with ex-primary object being xROOT, but per   (emvSTR), unless we want to change those as well
do we really want this? the colour contrast is extremely low and it's difficult to tell that the track has two colours
  (mBSHI2r fuchsia~exmaroon) mv-BHFSHI2r fuchsia~ex·maroon with interpunct/middot (alternately apostrophe?) or mv-BHFSHI2r fuchsia~exmaroon without interpunct
  (BHFlf) BHFf~l or BHFf-l or ~BHFf? we can't use ~L or -L
I'm fine with any renaming that synchronizes things. I just needed some titles that would fit within the existing naming and not cause conflicts or usurp a more conventional design. There shouldn't be a problem with the !~ overlay, as I can't think of any design that would begin with a ~. Move as you see fit. @Tuvalkin:? Useddenim (talk) 14:41, 31 December 2017 (UTC)
@Useddenim: I've added some more entries to the table, since I wrote the above while you were uploading files. Are those fine as well?
  1. The issue with the double-width icon is the thing about the primary/secondary convention and the colours not matching:   (xmABZgl) vs   (xmvSTR). There aren't any practical issues with keeping it the way it is, especially since the set~set/set+set thing currently matches the left-to-right direction of the parallel lines and that would have to be changed as well if xmv were to be swapped with emv, but it's still keeping me up at night somewhat of an annoyance which could be fixed in a few hundred semi-automatic page moves and redirect deletions.
  2. How do we deal with, say, a BHF with ex·u~pink or ex·u~f? Do all parts always have to be put after the icon? Would we use uex~pink or exu~pink or ex·u~pink or umROOT ex~pink? Would we just have a tilde after a [bahn]~u icon since it could use the um prefix?
  3. Would you treat ~F as forward to the icon edge or forward half an icon? Would it be different for parallel lines, as f currently is? Would ~f be correct or would it be better to use some sort of combining parallel lines syntax?
  4. Couldn't we use dv-BHF instead of dBHF~R? I think it's somewhat unnecessary to use a new suffix for something that can be done just with parallel lines syntax and this batch of renaming would be a good time to switch icons over to use v and vv for that.   (exKBHF~F brown) could be renamed to be fm[K]BHFea ex·brown+ (like   (mKBHFea), which might not need the K) and the rest of the station added.
  5. Do we indicate triple colours with two tildes? Do we add a double m prefix? Should they exist (low colour contrast, etc.)?
Jc86035 (talk) 15:27, 31 December 2017 (UTC)

We could fix the (u)mv problem for once and for all by eliminating the m prefix:

  (mvSTR)  (vSTR ~u)   (umvSTR)  (vSTR u~)

and then have all colour combinations follow on from there. Useddenim (talk) 21:05, 31 December 2017 (UTC)

Something else to throw in to the mix:   (TBHF)  (BKRZ), using B (and I for INT) as an icon modifier for ABZ/WYE, KRZ/KRX, SHI, etc. Useddenim (talk) 20:57, 31 December 2017 (UTC)

@Useddenim: I think if we were to remove m from parallel lines (which I think we shouldn't, since it's quite convenient, we'd still be using e and x anyway, and it would be inconsistent with using it for junctions) it would be better with dashes, since a tilde would imply that both lines were striped as in   (vxSTRe) (which would probably become vSHI1l ~ex-SHI1r ex~ or something like that; is m necessary?).
I am against using B as a prefix just because it's convenient, since B could mean BHF or BST, and A for ACC and D for DST would conflict with the existing A and D prefixes. We can afford to add two more letters to a few icon names. Jc86035 (talk) 05:21, 1 January 2018 (UTC)
Well, it was a thought… Useddenim (talk) 16:41, 1 January 2018 (UTC)

Another CPIC renaming scheme[edit]

Since the last one was more than a year ago, I'd like to propose that all CPICs become XBHF, all CPICAs become XACC, and so on. There are currently no BSicon roots (or BSicons) beginning with uppercase X. (Alternately uppercase I could be used.)

  •   (heCPICl)hXBHF-Le
  •   (CPICAa)XACC-Rq
  •   (CPICKl)KXBHF-Feq
  •   (utCPICCCle)utXBHF-Lef
  •   (xCPICma)KXBHF-Mxa
  •   (CPICqq)XPT*
  •   (CPIClg)XPT+r*
  •   (CPICdd)XPTe*
  •   (CPICpassu)STR+XPTq*
  •   (uexCPICpasso)XPTq+uexSTR*
  •   (CPTa)TXPTa

XBHF etc. would use standard -L/-M/-R/q/xa/xe suffixes instead of the current l/m/r/(a and e)/(x prefix + a)/(x prefix + e).   (tCPICCCle) would probably become tXBHFCC-Le or something like that until we decide on how to rename the KBHFCC icons. Jc86035 (talk) 10:19, 9 January 2018 (UTC)

* It just so happens that   (CPICqq) is about the same width as   (BSm), so PT could be reused if we want to rename the platforms as well. Jc86035 (talk) 10:19, 9 January 2018 (UTC)

  • I do like this idea. Seems to be the way to go, and the current state of affairs is a mess. -- Tuválkin 07:07, 10 January 2018 (UTC)
  • As the one who started the CPIC mess, I approve these changes. -- Sameboat - 同舟 (talk · contri.) 03:03, 11 January 2018 (UTC)

Multi-part icon names[edit]

I just renamed   (mvÜST-ÜST yellow+sky) to   (vÜST yellow-ÜST sky) based on   (vSTR saffron-ENDEe azure) and   (vfmKRZu-umKRZu). Issues:

  1.   (vSTR+4-STR azure) causes a naming conflict, since this would also be a valid name for   (vSTR+4-) +   (v-STR azure). Solutions include naming that hypothetical icon vSTR+4 -STR azure (with a space to indicate the default set), naming the hypothetical icon vSTR+4-STR +azure (this would affect the other aforementioned icons), naming the existing icon vSTR+4 azure-STR azure (this would probably affect   (uvSTR+4-STR) as well), naming the hypothetical icon vSTR+4-(STR azure), or naming the existing icon (vSTR+4-STR) azure. I would prefer the first of those, especially as there would be many valid and equally arbitrary ways to place brackets.
  2. Does   (vSTR+GRZq azure) need to have azure before +GRZq (per the above, since it doesn't apply to the GRZ part), or should it stay as it is (per   (SKRZ-Ao denim))? I would prefer the former since it's syntactically different because of the +, although there's   (SPLa+vBHF) (which I think would be named BHFSPLa per § Using tildes).
  3.   (SPLe+vCPICl), if renamed to XBHF-LSPLe per § Using tildes and Another CPIC renaming scheme, could be interpreted as parallel lines syntax, and could be interpreted as being one side of SPLe if renamed to XBHFSPL-Le. Maybe XBHF-L'SPLe?

Jc86035 (talk) 07:20, 13 January 2018 (UTC)

  • Concerning issue 1, I think that   (vSTR+4-STR azure) does not cause a naming conflict: According to what we’ve been renaming multi-color multi-line icons, the compound BSicon .svgBSicon v-STR azure.svgBSicon vSTR+4-.svg  should be named mvSTR+4-STR +azure, while, say, BSicon .svgBSicon v-STR.svgBSicon vSTR+4- azure.svg  should be named mvSTR+4-STR azure+.
Concerning issue 2, no: GRZ’s color is inherent and azure does’t apply to it.
-- Tuválkin 23:43, 14 January 2018 (UTC)
  • @Tuvalkin: Concerning 1, this still crops up in cases where m isn't used like   (veBHF-uBHF) (and veBHF-BHF azure would result in a conflict). I'm not sure if   (vSTR saffron-ENDEe azure) is correct now but I think it probably is since I moved it back after moving it to   (mvSTR-ENDEe saffron+azure) last year (I don't remember why). Concerning 2, shouldn't the + indicate that all affixes need to be applied twice if applicable to both parts (e.g.   (fvHST-+fexv-HST), where f is applied twice)? Jc86035 (talk) 05:58, 15 January 2018 (UTC)
  • In cases such as   the m preffix always should be used, even in icons such as  , the latter with appended color names, separated by a space and connected by a +. Disjunct color names are only to be used when an icon name is made up of two fully independent names, separated by a +; this kind of names should be used only when there is no better alternative; for the cases above, we have:
icon perfect acceptable wrong
  not possible mveBHF-L-BHF-R
  mvSTR-ENDEe saffron+azure vSTR- saffron+v-ENDEe azure vSTR saffron-ENDEe azure
  not possible fvHST-+fexv-HST
  not possible fvHST-L-+fexvHST-R fvHST-exHST
This (the part concerning colors, not the double station name issue) is not my own suggestion or opinion right now, it is what we decided upon back when the “other colors” mess was clared. (And, yes, all this would be much simpler if my suggestion of using brackets and not spaces for color names had been approved back then: I told you all so.) -- Tuválkin 05:26, 22 January 2018 (UTC)
@Tuvalkin: Would   (vumKRZu-fmKRZu) with red (driver's right), blue (driver's left) and green (across) be mvmKRZu-mKRZu red+green+blue+green? Does it need an m before the v? (I think the mv… a+b structure is good, though it seems a bit awkward to scale it to the various valid and possible edge cases like these hypothetical ones.) Jc86035 (talk) 09:53, 28 January 2018 (UTC)
I agree with both your name suggestion and with your assessment of it — but after all it’s expectable and even virtuous to have awkward names for awkward icons: Anything else would mean that the naming systemn doesn’t meet the needs. -- Tuválkin 13:30, 28 January 2018 (UTC)
@Tuvalkin: In the table, couldn't the last two be fvHST-exHST (after replacing current uses) and fvHST-L-exHST-R?
If the aforementioned four-colour name is correct, then   (vumKRZu-fmKRZu) would become ufvmKRZu-mKRZu (this would probably be correct per   (ugKRZo))? Or would it be mvmKRZu-mKRZu u++g+ (this would probably also be correct per   (ABZr+mr +f))?
Concerning (2),   (WGRZ) does sort of imply that we could change the GRZ colour, so it might be better to use + unambiguously, to replicate an overlay of the adjoining parts (STR azure!~GRZq = STR azure+GRZq). Jc86035 (talk) 15:00, 28 January 2018 (UTC)
  • (1) And obviously with horizontal lines we would have uBHFq-eBHFq and BHFq-eBHFq azure causing conflicts. I think the best ways to resolve these, if any, would also help in fixing the double parallel lines issue. Jc86035 (talk) 09:43, 15 January 2018 (UTC)


Current Proposed
  (lINT1) etc.   (lINT-1)
  (lINT2+4) etc.   (lINT-24)
  (lINT-1) etc.   (lvINTf1) or   (lvINTc1)?
if lvINTc1
  (lINTc1) etc.   (lv-INTg) or   (lv-(INT-))?
  (lINTc3) etc.   (lvINTf-) or   (lv(-INT)-)?
  (lINTf1) etc.   (lINTc1)
corner 3 connection
from   (lINTf2)
to   (lINT2+4)
corner 1 connection
from   (lINTf2)
to   (lINT2+4)
  (lvINTlq)/rq   (lvINTffq)/ggq

@Useddenim, Tuvalkin: The dash in   (lINT-2) indicates that it should be an INT from middle to corner 2, but that icon is   (lINT2), which is probably incorrectly named since it should be something similar to   (lhBHF2) (with only the circle and not the formations).

  (lINT-1) connects to   (vSTRc1) and not   (STRc1), so I would probably rename it to lvINTf1 or lvINTc1 to indicate what it actually could be used for (the only use of the icons is here, which should actually use   (exlINTf2) and connecting icons). Using the latter name would make more sense but it would be inconsistent with   (lINTc1) and we would have to rename those to something else. I suppose using f and g makes sense per   (v-STRrf) and   (lvBHFf). Jc86035 (talk) 09:10, 14 January 2018 (UTC)

  • I agree with the renaming principle: Stations should not be named as if they were lines. Besides, INs should be named using the same principles as BHF, right? (As for the details, I don’t have any insights to share right now; will revisit later if necessary.) -- Tuválkin 23:31, 14 January 2018 (UTC)


  1. Should the M prefix be added to all existing icons like   (hSTRc1) (with mask), per   (hSTR+hc1) (no mask) and   (hkSTRc1) (no mask)? About 22 + 54 diagrams out of 139 (54.7%; including user pages) on enwiki might have uses that require masking.
  2. If those icons are renamed, should icons without masks be uploaded under their current titles?
  3. Should the l prefix be added to all icons like BSicon .svgBSicon BS.svgBSicon MSTR2.svg (MSTR2) , per   (hMSTR) and   (lhMSTR)?

Jc86035 (talk) 10:13, 21 January 2018 (UTC)

Perhaps the solution would be to fix the icons that have embedded masking, and the create stand-alone mask icons (which would then no longer have a need for the l prefix). Useddenim (talk) 13:34, 21 January 2018 (UTC)
If you're referring to the elevated corner icons, I think it would be better to have JJMC89 bot manually replace all uses of the originals after uploading the new icons with masking, and only then re-upload the original icons without masking. What do you mean by "which would then no longer have a need for the l prefix"? (For what it's worth,   (lhSTRc1) doesn't have masking.) Jc86035 (talk) 13:42, 21 January 2018 (UTC)

Parallel lines – one side[edit]

Should icons like   (vSTR2-R) and   (vSPL1+r-L-L) also have their -L and -R suffixes changed, per STR-L  (STR~L)? I think using -l and -r, :l and :r, or :L and :R would work. -f and -g, or ~f and ~g, could also be used for the current "move the primary object along the line" uses of f and g; e.g.   (tSTR2ef)tSTR2e-f (and one of the unused pairs, or ~l and ~r, could also be used for icons like   (BHFlf)). We could also start using more Unicode characters, though this might not be desirable and would probably be unnecessary. Jc86035 (talk) 10:53, 28 January 2018 (UTC)

  • I’m waiting to see concerning the tilde matter, but colons (:) cannot be used in filenames. -- Tuválkin 13:27, 28 January 2018 (UTC)
  • Symbol keep vote.svg Agree with Tuválkin. Useddenim (talk) 18:39, 28 January 2018 (UTC)


What are the rules for using the tilde suffixes, anyway? I'm having trouble figuring out exactly how they're supposed to work. I've renamed most of the -L/-R transform icons to ~L and ~R, except for some of the half-width icons (to parallel lines) and the ones where -L or -R might be incorrect (like   (vSTR-L), which I moved to   (vvSTR-STR-) – would it be more correct to name it vvSTR~L or something like that?). Do the ~L/~R/~F/~G suffixes always move an object to the icon edge (or the edge of the parallel lines syntax border)? Would   (dBHF~R) be different to dv-BHF, the latter of which might presumably have the small station circle of   (dBHF)? Jc86035 (talk) 11:04, 28 January 2018 (UTC)

I've also just realized that ~L and ~R currently contradict the ~F uses (as well as the directions of the +L, +R, +F and +G transforms), and that it might be better to move all of them back and then swap them. I'm reverting the ~L and ~R moves for now. Should they be swapped (i.e.   (STR-L) would become STR~R)? Jc86035 (talk) 11:39, 28 January 2018 (UTC)
I don't know that we formulated any rules for the use of ~ in icon names. I just used it (in files like   (exdpBHF~R ruby) and   (mv-BHFSHI2r~exBHFSHI2r fuchsia~maroon)) because I needed a name that wouldn't conflict with anything else. However, I do like the idea of defining it as move an object to the edge, and restricting -L/-R/-M to connecting to left/right/middle. Useddenim (talk) 16:57, 28 January 2018 (UTC)
If ~ is defined as “against an edge”, then it does make sense to use it as the divider between that halves of bi-coloured icons. Useddenim (talk) 18:51, 28 January 2018 (UTC)
Whatever is decided, the icons in Category:Icons for railway descriptions/half width/parallel lines/stations and stops/BHF/halved should probably also be included. Useddenim (talk) 18:51, 28 January 2018 (UTC)


@Useddenim, Tuvalkin: Since this is more easily doable with pywikibot now, could SKRZ-G1/G2/G4/GD be renamed to SKRZ-P1/P2/P4/D for consistency with the original roots? This could avoid issues/confusion arising from somewhat ambiguous names like SKRZ-G2+4. Jc86035 (talk) 16:18, 9 February 2018 (UTC)

  • Sounds reasonable to me, as I can't think of any objections. Useddenim (talk) 20:29, 11 February 2018 (UTC)
  • If «there are a few icons which need to be added to the catalogue pages», then the catalogue pages do not suffice. Besides, this catalog, “unofficial” as it is, is much more readable and compact. I’ll try to keep it current. -- Tuválkin 15:59, 12 February 2018 (UTC)

RP2 divided curves[edit]

Can the following files can be renamed, consistent with railway and other road curves? Would this be the correct convention?

  •   (vRP2rg) to   (vRP2+l), like   (STRrg) to   (STR+l)
  •   (vRP2lg) to   (vRP2+r), etc.
  •   (vRP2rf) to   (vRP2r)
  •   (vRP2lf) to   (vRP2l)
  •   (v-RP2rg) to   (v-RP2+l)
  •   (v-RP2lg) to   (v-RP2+r)
  •   (v-RP2rf) to   (v-RP2r)
  •   (v-RP2lf) to   (v-RP2l)
  •   (vRP2rg-) to   (vRP2+l-)
  •   (vRP2lg-) to   (vRP2+r-)
  •   (vRP2rf-) to   (vRP2r-)
  •   (vRP2lf-) to   (vRP2l-)

epicgenius (talk) 03:00, 18 February 2018 (UTC)

@Epicgenius: Yes, except   (v-RP2rg) etc. should be v-RP2+lf like   (v-STR+lf). (Most of the other road curves, incidentally, are consistent, except for those which weren't moved because of icons like   (RP2r), which should have been renamed but no one's bothered to yet. Probably RP2d or something, per this discussion.) Jc86035 (talk) 07:59, 18 February 2018 (UTC)
@Jc86035: I'm confused. So should   (v-RP2rg) go to   (v-RP2+lf), or   (v-RP2+l)? Like this:
  •   (v-RP2rg) to   (v-RP2+lf)
  •   (v-RP2lg) to   (v-RP2+rg)
  •   (v-RP2rf) stays the same
  •   (v-RP2lf) to   (v-RP2lg)
  •   (vRP2rg-) to   (vRP2+rf-)
  •   (vRP2lg-) to   (vRP2+lg-)
  •   (vRP2rf-) stays the same
  •   (vRP2lf-) to   (vRP2lg-)
Then an admin will need to move two of these, because the file names are already occupied. epicgenius (talk) 14:52, 18 February 2018 (UTC)
@Epicgenius: Probably, yes. JJMC89 bot replaces redirect usage so after a day or two it should be possible to delete the two redirects. I'll move the four other files. Jc86035 (talk) 15:00, 18 February 2018 (UTC)


@Useddenim, Tuvalkin: Could   (uCROSS),   (gSKRZ-YuEnd) and other similar icons be converted into a standard set of crossings? I would probably assign a suffix to indicate that a line has a break, perhaps uCROSS → ugKRZB (or another suffix).

The issue of assigning more capital prefixes and suffixes is that at some point they'll end up conflicting with roots (there's already DST = embankment + road crossing railway, although this doesn't exist and should be extremely rare), so it could be time to expand into Unicode. Jc86035 (talk) 11:15, 25 February 2018 (UTC)

@Jc86035, Bob1960evens, Zin92::
  • Converting: I’m all for homogenizing the filenames, but it’s better to first ascertain what are these icons being used for. If it’s mere crossing and the gap is only a visual aid, then they should be redrawn to match all the standard crossings like   (mKRZo), or even   (mKRZ), and renamed trivially. If the gap is meaningful (filled up canal with road running across), then a renaming is in order but also a homogenous redrawing. (For the latter I suggest something like BSicon .svgBSicon STRq.svgBSicon lENDEf.svgBSicon lENDEg.svg , which doesn’t include the crossed line — reducing the number of needed icons.)
  • Renaming: I agree with adding an uppercase prefix or suffix. The ambiguity issue raised above can be solved (or significantly reduced) if all icon roots are made of exactly three letters (not two, not four). Unicode (meaning non-ASCII Unicode) is a possibility, but seeing how people still have difficulties with "Ü" as if this was the 1970s, we should be wise to avoid more of these.
-- Tuválkin 12:48, 25 February 2018 (UTC)
@Tuvalkin: I agree with your points, though an issue with using lENDEf/g might be if two of the icons are used in a row. Renaming CONT, ENDE, SHI(1–4), etc. might be seen as unnecessary but since almost no one took notice of the proposed wide-ranging CPIC renaming above (and I advertised it in multiple locations on enwiki), it might not really be an issue. Jc86035 (talk) 05:28, 26 February 2018 (UTC)