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


@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)



(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)

Axpde, I have not reverted you, but I would like you to move   (hWSTR) to   (hKRZW) again and keep it there until you have managed to overturn the consensus above that the W prefix should be used consistently. The file move was discussed here (with that exact file as an example). Don't revert a single file move just to make a point; I moved every file whose name contained "WSTR", and if you want to disagree you are very much welcome to ask about it here instead of clicking revert and not bothering to deal with any of the other similar files that I moved. I am currently aware that I made some errors in this process, like moving   (hWSTRq) to   (hKRZWq) instead of the shorter   (WKRZh), but my main account is "on a wikibreak" (i.e. I locked myself out of it) so I am technically unable to move any files right now.

KRZ means "crossing of to TRACKS", it has every been so and there is no need to overturn a consensus!
It wasn't YOU who invented this system so please don't change things which are contrary to the inventors system! a×pdeHello! 12:56, 2 June 2018 (UTC)
@Axpde: The BSicons cannot be owned by anyone (since they are, after all, hosted on a publicly editable wiki), so gatekeeping the system to those who were around in the mid-2000s would be pointless. As far as I am aware the "system" was created after consensus on 30 September 2006 by Bernina (please correct me if I'm wrong); even icons uploaded on that day have been renamed. In any case, I am the uploader of three-quarters of the BSicons that currently exist and uploaded my first in 2013, and have made more than ten thousand file moves, so you cannot say I did not have a part in it. It's true that many of them are differently coloured copies of icons that previously existed, but even then I have uploaded and redesigned thousands of others.
„Kreuzung“ bedeutet "crossing", richtig?
KRZ has been repurposed for roads (as SKRZ) and for paths (as fKRZ), so it clearly isn't limited to tracks.   (SKRZ-Bu) existed in 2007 as AKRZ-UKu. Jc86035's alternate account (talk) 13:46, 2 June 2018 (UTC)

@Tuvalkin, Useddenim: The errors mentioned are in the titles of these 19 files. I would prefer not to move them to titles which use "l" and "r" somewhat ambiguously, but the current convention, per   (KRZhl), seems to be to ignore that. Jc86035's alternate account (talk) 09:12, 2 June 2018 (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)

@Tuvalkin, Sameboat: ✓ 


(about 511 icons renamed). Outstanding issues include suffix order of -L/-R/-F/-G vs. a/e (I think it would be more correct to swap the suffix order for all of the terminal station icons) and whether   (exXBHFSHI1lr-M) needs to have an extra e/x in the middle (I don't think so, since it would be confusing and this particular icon can be split into parallel lines, but others may think it needs to). Jc86035 (talk) 10:23, 28 April 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 lENDE@F.svgBSicon lENDE@G.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)
  • Used in a row, good point. It would look bad, indeed. -- Tuválkin 02:51, 9 April 2018 (UTC)
current suggested
  (uCROSS)   (umgGAP)
  (gSKRZ-YuEnd)   (gGAPSRYq)
  • Okay, both have been redrawn. Lets go back to a renaming discussion: I think we can agree that this kind of crossing (or rather, a non-crossing!) is distinctive enough to have its own iconID. While akin to bridges and regular crossings (and even though it’s likely that there will be a much smaller number of icons involved here), in this feature the “broken” line should be always secondary, so there’s synonimity issues concerning u/o vs. -/q. For the icon ID I suggest GAP, a nice descriptive 3-letter word, even if it’s not German. -- Tuválkin 15:32, 29 April 2018 (UTC)
current suggested
  (uCROSS)   (gGAPq+uSTR)
  (gSKRZ-YuEnd)   (gGAP+RYq)
  • New idea: The gap is the feature, and it can even be standalone — compare   (GAP) and   (GAPq). An unbroken line may go through the gap as an overlaid   (STRq) (or   (STR)), either in a diagram or as a new icon — see the 2nd table. -- Tuválkin 16:10, 29 April 2018 (UTC)
  • No need for a “GAX”, either… -- Tuválkin 16:10, 29 April 2018 (UTC)
@Tuvalkin: ENDEea (from   (tSTRea) = tSTReg + tSTRaf; ENDEea would be equivalent to ENDEe@G + ENDEa@F under new schema)? Jc86035 (talk) 17:19, 29 April 2018 (UTC)

Beta what?[edit]

@Jc86035: I came across   (hvSTR3- β) and   (hv-STR+1 β), wich were moved from the more usual   (hvSTR3-) and   (hv-STR+1) two years ago; the redirects were deleted recently. What’s this? -- Tuválkin 20:08, 6 April 2018 (UTC)

I say "Just move them back". Useddenim (talk) 11:57, 7 April 2018 (UTC)
@Useddenim, Tuvalkin: This was because of   (hv-STR3 β), which I renamed last September so I could upload   (hv-STR3). Since the geometry type is probably never going to be used (predating YLSS's 2014 geometry change), and the filenames were both valid under the current naming conventions, I moved the other two as well in case someone wants to upload the icons. In the current naming scheme the icons for the curve in the ptwiki diagram would probably be hvSTR3, hvSTR3+L, hvSTR3+R, hvSTR+1, hvSTR+1+L, hvSTR+1+R, and two masks. Jc86035's alternate account (talk) 13:13, 7 April 2018 (UTC)
@Jc86035 (1): Thanks for explaining. Lets rename those icons properly, then? The fact that they are used in a diagram should be proof that they are needed. -- Tuválkin 02:49, 9 April 2018 (UTC)
@Tuvalkin: It turns out that with the proposed/de facto use of ~L and ~R (see #Suffixes and #Tildes) they all have perfectly valid names under the current system, so I've renamed all of them. They still need to be reuploaded (for narrow formations and 117.85px parallel lines spacing). Jc86035 (talk) 12:06, 29 April 2018 (UTC)


@Useddenim, Tuvalkin, Sameboat, Lost on Belmont, Newfraferz87: @Axpde, C21H22N2O2: I spent some time thinking about how to separate the various meanings of L, R, F and G suffixes, and this is what I came up with. It's not perfect, and the suffixes could be changed to clearer or more readable ones, but I think it's better than the somewhat arbitrary mess that we currently have. There are almost 100,000 BSicons now (of which almost all have fairly simple names and are validly named to be consistent with current naming conventions), and the current system does limit us in terms of the combinations of features that an icon can have, and how specific the suffixes can be. This would solve various issues, such as   (hSTR-R) vs.   (uhSHI1+l-R), and the myriad naming issues in finding a good name for   (uhBHFrf) which is consistent with other icons.

  • l, r: curves (STRl)
  • f, g: forward and backward arrow indicators (STRf)
  • L, R, F, G: reserved for prefixes
  • +L, +R, +F, +G: full transform of the icon boundaries in the respective direction (hvSTRa+L) [No pattern] [NOT AFFECTED BY PARALLEL LINES SYNTAX]
  • +l, +r, +f, +g: line connecting from respective direction (STR+l) [Pattern: +lf]
  • ~L, ~R, ~F, ~G: transform all objects from centre of icon to respective icon boundary (lBHF~F, currently lBHFf) [Pattern: ~LF] [NOT AFFECTED BY PARALLEL LINES SYNTAX]
  • ~l, ~r, ~f, ~g: only this side of the primary object(s) is shown (vSTR2~l, currently vSTR2-L / utvSTRa@g~g, currently utlvSTRag) [Pattern: ~lf (¾) or ~l~f (¼)]
    • A halved track is STR~ or ~STR. Somehow, this magically avoids naming conflicts.
  • @L, @R, @F, @G: transform secondary object(s) in respective direction relative to the line or other primary object (lvINT@F-, currently lvINT~f-) [Pattern: @LF]
  • @l, @r, @f, @g: transform auxiliary object(s) in respective direction relative to the line or other primary object (tSTR2a@f, currently tSTR2af / tBHFa@f, currently tBHFaf) [Pattern: @lf]
  • -L, -R, -F, -G: secondary object connection in respective direction (BHF-L) [Pattern: -LF]
  • -l, -r, -f, -g: auxiliary object connection in respective direction (tSTRa-l, currently tSTRal) [Pattern: -lf]
  • (L), (R), (F), (G): only this side of the secondary object(s) is shown (BHF(L)f, currently BHFlf / KRZo(L), currently KRZo-L) [Pattern: (LF) (¾) or (L)(F) (¼)]
  • (l), (r), (f), (g): only this side of the auxiliary object(s) is shown (lhSTR(l), currently lhSTR-L) [Pattern: (lf) (¾) or (l)(f) (¼)]

A somewhat related issue is that icons like   (KBHF-La) would probably appear to have an incorrect suffix order, especially after renaming a bunch of others, and might need to be renamed to KBHFa-L. Maybe this should be done. I'm not sure. Thoughts? Jc86035 (talk) 06:29, 27 April 2018 (UTC)

  • I'm strictly against those "~" or "@" suffixes, because the icon names should be understandable by general public! The names have become incomprehensible enough, so please no more confusion :-( a×pdeHello! 08:44, 28 April 2018 (UTC)
And Your example   (KBHF-La) should indeed be KBHFa-L :-) a×pdeHello! 08:45, 28 April 2018 (UTC)
  • @Axpde: Do you have any better suffix suggestions? There are already icons using ~L and ~R suffixes, and I don't see how they are less comprehensible than -L or -R. I suppose we could use suffixes like .L/.R or ,l/,r instead? Jc86035 (talk) 09:25, 28 April 2018 (UTC)
  • I’m still processing all this, but I like it so far, very much. -- Tuválkin 13:57, 29 April 2018 (UTC)
L R F G l r f g (none)

not used

l/r: curves   (STRl)

regular icons

f/g: directionals   (STRf)
+ transforms icon in direction   (hvSTRa+L) connects from direction   (STR+l)

not used

~ transform objects from centre to boundary   (lBHF~F) half of primary object   (vSTR2~l)
halved track   (uSTR~)
@ transforms secondary in direction wrt line/primary   (lvINT@F-) transforms auxiliary in direction wrt line/primary   (tSTR2a@f)

not used

- secondary connects in direction   (BHF-L) auxiliary connects in direction   (tSTRa-l) single parallel line   (vSTR-)
( ) only part of secondary shown   (BHF(L)f)
only part of auxiliary shown   (lhSTR(l))

not used

Useddenim (talk) 01:37, 30 April 2018 (UTC)

@Useddenim: By "halved track" I meant something like half of   (mSTR yellow~exteal), specifically for situations like   (uehbnvÜSTl) where currently the narrow track has to shift back to the centre even though the icon is paired with   (uehbnvSHI4gr). Now I'm not sure whether this means objects on the track would be halved [edit: they probably wouldn't, since this schema also includes suffixes for that purpose]. Jc86035's alternate account (talk) 15:02, 2 May 2018 (UTC)
Wouldn't ICON~nothing mean “halved icon”, as in   (uBHF~)? Useddenim (talk) 17:48, 3 May 2018 (UTC)
@Useddenim: I thought it would work like that at first, but we might also want to have, for example, a station centred on the half of the line, and it wouldn't make sense for ~HST on its own in a diagram to have half of a station circle; or we might want to extend the system logically for e.g. mINT u~grey~orange with the lines being 150px wide in total (allowing this would in turn require something like a mSHI.2+r u~grey to shift the driver's rightmost two lines back to the middle, and then we would probably have to extend SHI to diagonals). Jc86035's alternate account (talk) 08:15, 4 May 2018 (UTC)

45° junctions[edit]

@Useddenim, Tuvalkin, Epicgenius, Axpde:

Current Proposed
  (ABZq+1) etc. ABZq1
  (ABZq3) etc. ABZq+3

Can we do this? This is primarily because

  • +1 currently doesn't indicate which side of the icon the line from the corner goes to, but +1 in   (ABZg+1) does;
  • ABZg1 is currently a valid name and would be   (STR1) +   (STR), whereas ABZq1 is currently undefined, and if it were made to be   (STRl+1) +   (STRq) the logic wouldn't make much sense (since it would still be coming from the back of the icon).

It's also fairly clear now that

  • the naming rules for 90° ABZs are separate (i.e. g+4/q+4 curves are different; g+r/q+r curves are the same, so logic would be inconsistent anyway) and can be ignored for this;
  • "q" specifically means "rotated 90° anticlockwise" per   (STRfq), so it would be fairly logical to allow +3 to be used here to mean "[down the line, which is now towards the left] from 3".

Jc86035 (talk) 10:50, 29 April 2018 (UTC)

  • I fully Symbol keep vote.svg  agree , both with the proposed renamings and with the underlying argument. -- Tuválkin 13:53, 29 April 2018 (UTC)
  • I also Symbol keep vote.svg  agree . Are we changing the names for   (ABZq+4) and   (ABZq2)? I should think not - if the rotation is 90 degrees counterclockwise, then the "front" of the   (STRq) is on the left - but I want to know anyway. epicgenius (talk) 14:16, 29 April 2018 (UTC)
    @Epicgenius: No; those would be unchanged under the proposed logic. Jc86035 (talk) 14:20, 29 April 2018 (UTC)
    @Jc86035: Thanks. epicgenius (talk) 14:21, 29 April 2018 (UTC)
  • Symbol keep vote.svg  agreed Vunz (talk) 13:20, 30 April 2018 (UTC)
  • Symbol keep vote.svg  Mild agree . However, just make sure there isn't a repeat of the CONTl/CONTr debacle. Useddenim (talk) 23:33, 29 April 2018 (UTC)
  • Symbol delete vote.svg  Disagree The icons are perpectly named!   (ABZq+1) means track running across (q) and from corner 1 (+1). Your silly "rule" to rotate BSicons in a certain direction makes them uncomprehensible! Please stop your trials to fix things which aren't broken! a×pdeHello! 15:35, 30 April 2018 (UTC)
    @Axpde: How can you say they're already perfectly named? In the context I agree they're not problematic right now (if that's what you mean), but there's no harm in making the names better. There's obviously work to be done even on the ABZ root, given that there are still zigzag and wye icons which are named idiosyncratically.   (ABZ3+1lr) is fairly obviously wrong, since that name for an icon created now would be BSicon .svgBSicon STR3+r.svgBSicon ABZ3+1l.svg . Changing the way that the "q" suffix is defined here is something that would help us in renaming those icons and creating new ones which aren't limited by the current system (for example, that zigzag icon might be called ABZ(3+1)l+r or ABZl3+1r or ABXql+r, and this would build upon the redefinition of "q"). Jc86035's alternate account (talk) 11:30, 2 May 2018 (UTC)
    Didn't claim all BSicons are perfektly named,   (ABZ3+1lr) shoulde be   (ABZr3+1l)! a×pdeHello! 14:30, 2 May 2018 (UTC)



Jc86035 (talk) 11:35, 20 May 2018 (UTC)


@Useddenim, Tuvalkin, Vunz, Epicgenius: Since the duplicates in this category have two different and currently valid naming schemas:

Current Proposed
  (vÜWBl) ✓
  (vÜWBr) ✓
  (exvÜWBg+l) exvÜWBr+r
  (exvÜWBg+r) exvÜWBl+l
  (exvÜWBgl) exvÜWBl+r
  (exvÜWBgr) exvÜWBr+l
  (vÜWBol+lr) vÜWBl+lr
  (vÜWBor+lr) vÜWBr+lr
  (uvÜWBol+lr) uvÜWBl+lr
  (uvÜWBor+lr) uvÜWBr+lr
Crosses over to left
Crosses over to right
No lines through   (vÜWBl)   (vÜWBr)
Left line through +l   (vÜWBl+l)   (vÜWBr+l)
Right line through +r   (vÜWBl+r)   (vÜWBr+r)
Both lines through +lr   (vÜWBl+lr)   (vÜWBr+lr)

The icons are still restricted by the naming pattern to down the page/across the page orientations, although I don't think this is too much of an issue right now. Jc86035 (talk) 12:53, 19 May 2018 (UTC)

  • What’s the problem with across-oriented versions of these?
e.g.:   (vÜWBol+r)  q̿    (vÜWBol+rq)
No problem! -- Tuválkin 00:44, 21 May 2018 (UTC)
@Tuvalkin: I was referring to using 45° and other curves. Jc86035 (talk) 04:54, 21 May 2018 (UTC)
  • Aha, gotcha. We’re cool, then. -- Tuválkin 12:59, 2 June 2018 (UTC)



Jc86035 (talk) 12:11, 17 June 2018 (UTC)

Fill icons[edit]

So I just uploaded   (FILL2),   (FILL3), and   (FILL4) (complementing   (FILL)) so that there will be more fill icons. They are based off Wikipedia templates en:w:Template:Maybe, en:w:Template:Yes, and en:w:Template:Operational respectively. Is there a particular naming convention I should have followed? epicgenius (talk) 20:03, 26 May 2018 (UTC)

  • I would have gone with   (FILLy),   (FILLg),   (FILLb) and   (FILLr) (as with coloured roads). Useddenim (talk) 06:37, 27 May 2018 (UTC)
  • @Epicgenius: But why? -- Tuválkin 12:59, 2 June 2018 (UTC)
    • @Tuvalkin: I needed more than one fill icon for en:Template:NYP track map. However, the map no longer uses these icons. Jc86035 updated the local Routemap template so that individual cells may have background colors. epicgenius (talk) 14:45, 2 June 2018 (UTC)
      • (To clarify, I added this functionality about two years ago, although the documentation does not currently make it obvious that the functionality exists, as there is no example diagram which contains the cell formatting. Jc86035's alternate account (talk) 17:14, 2 June 2018 (UTC))


@Useddenim, Tuvalkin:

  1. Since we now have an established model for referring to secondary and auxiliary objects, I thought it might be useful to expand it. Apostrophes (and maybe quote marks) could be used as "prime" marks for icons with more than one auxiliary object, to indicate that a prefix or suffix referring to an auxiliary object refers to the second or third auxiliary object.
    • For example, to fix the suffix ambiguity of using l and r to indicate bridge start/end as well as curves in crossings, treating the two formations as separate objects,   (hSKRZ-G2hlu) could be renamed hSKRZ-G2hua' (not sure about the suffix order right now; I changed it to this ordering from an incorrect ordering because it would alleviate the aforementioned issue). This is not particularly intuitive, but   (KRZhl) would then be just   (KRZha) since there is only one bridge to which a can be applied (it can't be used for the tracks since the K suffix would be needed for it to indicate the start of a track).
    • This could also be used in other icons where there are multiple formations or structures.
    •   (hdKRZ) and   (dKRZmu) should be consistently named. Perhaps a suffix could be applied to indicate that the bridge formation is narrow. n' is a possibility (n on its own would refer to the line across – it's the secondary object, but I don't know if that matters).
  2.   (ABZ3+1lr) and similar icons have a nonstandard naming structure right now. Maybe the grave accent ` (or some other character like the comma) could be used as a separator between regular positional suffixes (e.g. 3+1 in   (STR3+1)) and specific positional suffixes (e.g. +l in   (WSL+l)).
    • ABZ3+1`r+l (or ABZ3+1,r+l), for the aforementioned ABZ3+1lr, would indicate 3+1 to be the "main track", and r and +l to be "curve from back [1] to r" and "curve to front [3] from l".
    • vÜWB2+r`l+r (or vÜWB2+r,l+r), obviously a hypothetical example, would indicate 2 and r to be the tracks' end and start points, with l+r being similar to the curves in   (vÜWBl+r). The real icon would pose some very odd geometry issues, but SHI and ÜST icons could definitely benefit from this.
  3. Currently exSTRq-BHFq is ambiguous. Using the grave accent (or some other character like the comma) in front of prefixes which are used before d's position, to separate the prefixes where d would be, could be a solution to the ambiguity.
    • extBHFq-BHFq indicates that both stations are out of use.
    • t`exBHFq-BHFq (or t,exBHFq-BHFq) would indicate only the upper station to be out of use. (This doesn't necessarily have to be done, but the suffixes being out of order might not be a very clear signifier.)
    • ex`tBHFq-BHFq (or ex,tBHFq-BHFq) would indicate the upper line to be in tunnel.
    • tBHFq-exBHFq indicates that the lower station is out of use, and that both lines are in tunnel.
    • `tBHFq-exBHFq (or ,tBHFq-exBHFq) would indicate the lower line to be out of use, and the upper line to be in tunnel.
  4. Things that have nothing to do with renaming:
    • How are tunnels affected by the ~L/~R/~F/~G suffixes? Are the dashes transformed, or do they line up correctly? A set of misaligned dashes (with connecting icons) would actually be somewhat useful, because then we would be able to have a   (tdSTRq) that doesn't make diagrams look weird.
    • There should be a standardized way to draw unpaired tunnel dashes, like those in   (utPSLa). It would be much easier to keep tSTR~ undefined, really, because having it opens the door to icons like tSHI.01l~ (or something like that) where the line moves from 220px to 225px, and would probably lead to a very unnecessary rabbit hole. However, it would be useful for the "track change" icons, so I would keep the connecting parts at 220px/280px but have the rest of the points at their positions in the at-grade icons.

(Please reply using the indents :#, ::#, …, if using lists within the reply.) Jc86035's alternate account (talk) 11:12, 2 June 2018 (UTC)

  • You’re supposed to be on a break, man!… Okay, I’m “processing” it in the back of my mind. Will comment later. Busy now. -- Tuválkin 13:15, 2 June 2018 (UTC)
    I'd written out most of the ideas beforehand, although it took me longer than I expected to formulate them into coherent and understandable English. Jc86035's alternate account (talk) 14:03, 2 June 2018 (UTC)