Talk:BSicon/Renaming/Archive 7

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

CPIC

see also: User:Circeus/BSicon renaming/Stations#Cross-platform interchange

Finally received my file mover right so I can be more active in renaming BSicons. The CPIC set is one of my early BSicon mayhem which confused many users about the subjective left/right direction. (Speaking of which, I'm not convinced of transverse terminus like   (KBHFl)) The easiest way (to me) to fix it is to rename the ROOT altogether so there is no conflict of L/R of the same ROOT. I'm not happy with "CPIC" also because the uppercase "i" looks unnecessarily like the lowercase "L" and it contains 4 letters. The candidates for the new ROOT include "CPT" (cross-platform transfer), "LST" (level station) and "LTS" (level transfer station, less confusion with   (DST) or   (HST)). And then the ROOT prefix K for terminus will also apply to the new ROOT. -- Sameboat - 同舟 (talk) 02:56, 6 March 2014 (UTC)

CPT. It’s the closest to CPIC, so the least-disruptive change. Useddenim (talk) 04:31, 6 March 2014 (UTC)
If you really want to rename that set, then I suggest that you use a root modifier, not a separate root. Because we have not only   (CPICl), but also   (KINTCPICla),   (CPICAl),   (CPICCCla) and maybe others. Indeed I wanted to create   (uextKINTCPICACCla), just for lulz.✓ done it. Notce that it's not CPIC+ACC, but CPICA+CC. 09:12, 6 March 2014 (UTC) So maybe it would be better to have   (CPICl) renamed to BHF+Cl or something like that. And don't forget about   (CPICpasso),   (CPIClf) etc. YLSS (talk) 08:43, 6 March 2014 (UTC)
I prefer a new suffix rather than expanding the ROOT modifier. Maybe   (CPICl) → BHFpl, "p" for "platform". -- Sameboat - 同舟 (talk) 09:27, 6 March 2014 (UTC)
I would suggest a capital P suffix, just to get away from the lower case {X}p prefix. Useddenim (talk) 00:55, 7 March 2014 (UTC)
That is exactly why I suggested a root prefix: having a suffix that applies to another special suffix (-l applying to -p instead of anything on the root) seems like a recipe for disaster when the current special case is prefixes that do double-duty as suffixes. Yes, we'll eventually run into issues anyway (we always do...), but let's try pushing that as far further down the line as we can, shall we not? Circeus (talk) 23:42, 19 March 2014 (UTC)

Dammcut

I'd like to propose bringing damm and cut in line with their more common relatives ("h" and "t") using by using a prefix. It makes perfect sense to me that the elevated and tunnel versions of   (STR) are   (hSTR) and   (tSTR), but it is completely lost on me why this doesn't apply to the dammcut set: we have   (DAMM) and   (CUT). Some icons, such as   (DBHF), already use a prefix to denote a DAMM or CUT version of the base icon. In this particular case, however, the prefix is capitalized, where in the "h" and "t" sets the prefix is lowercase. Out in Junctionland things get outrageous. The established convention of   (ABZlf) has this as a counterpart:   (CUTgl). It doesn't even use the same ROOT.   (DABZlf) is the only one that follows a coherent pattern.

I'd like to see some standardization here. As far as I'm aware, we're not currently using "d" (stupid half width icons) and "c" (#!*@ quarter width icons)Useddenim (talk) 00:29, 8 April 2014 (UTC) as prefixes, so fixing this should be pretty straightforward. (Unless someone objects.)

  •   (DAMM) →   (DSTR)
  •   (CUTlf) →   (cSTRlf)
  •   (DAMMa) →   (DSTRa)
  •   (CUTgl) →   (cABZlf)
  •   (CBHF) →   (cBHF) And so on...

Thoughts? Lost on Belmont (talk) 23:49, 7 April 2014 (UTC)

D and C prefixes. Useddenim (talk) 00:29, 8 April 2014 (UTC)
Hmmm... I'll accept "D" for DAMM because of the half width icons (as seen in my proposed naming scheme). There are too many to bother changing at this point, but it looks like there are only 28 quarter width icons total and those 28 span 4 different sets (base, u, purple, and formation/legende/whatever). Wouldn't it make more sense to move those to "C" prefix and give the CUT icons (since there are already a greater number in the base set alone) the more appropriate "c"? And why "d" and "c" for half and quarter width icons anyway (other than they come after a and b)? They don't seem to have any German rational that I (via Google translate) can find. Wouldn't "V" or "Q" (Quarter/Quartal) as a prefix make more sense? (I know "v" is already in use for some icons and "q" is as a suffix.) Lost on Belmont (talk) 01:03, 8 April 2014 (UTC)
According to en:WP:Route diagram template/Catalog of pictograms, the c prefix is from schmal/compact. Also, see the discussion above: #The "C" root prefix. Useddenim (talk) 03:35, 8 April 2014 (UTC)
Renaming the existent 31 icons with "c" and "cd" prefixes would require renaming   (c) and   (cd) as well (and also the new   (leer+c),   (leer+d) and   (leer+cd)Useddenim (talk) 11:22, 8 April 2014 (UTC)) – and these have become a staple means of building a diagram and are widely used across en.wp, fr.wp, no.wp, it.wp and others. If you are willing to single-handedly carry out that renaming – well, why not... I do not cling to "c" for quarter for any philosophical reasons, but I don't have a desire either to start another wave of renaming just to free it.
There is indeed some confusion with the usage of lower-case prefixes and upper-case root modifiers (e.g.   (tBHF) vs.   (LBHF) vs.   (lBHF)), and tracks in cuts and dams indeed look more like they would require lower-case prefixes similar to   (hSTR). But I can't come up with any appropriate ones, so I would suggest satisfying ourselves with capital "C" and "D" – that battle is lost...
That said, Circeus once proposed using "E" prefix for dams, IIUC because he needed "D" for diagonal tracks. The latter idea did not take root except for arrows, so we may continue with "D" for dams – or not?
WRT suffixes: no, we certainly should not rename these icons to "lf", "rg" etc. I have regular pangs to rename   (ABZlf) and others to either ABZgl or STRgl, just because that pattern is pretty universal now and I always swear that I have to type "rg" instead of "g+l". So if you're up to renaming   (CUTlf) and   (CUTgl), then better to   (CSTRl) and   (CSTRgl)/  (CABZgl)...
Incidentally, I may note that Useddenim chose to name   (CUTq+l) not in line with   (ABZql), but in line with the philosophy of rotating our POV if we have a track across, which is lost to us... I understand his motives, but... I would still prefer them to be named in parallel to standard tracks. (Usage is very low, so there's no reason not to change the suffixes when they are renamed from CUT to CABZ.Useddenim (talk) 11:22, 8 April 2014 (UTC)) See also this discussion, where it was settled to use   (SHI4g+lq) for similar shifts. YLSS (talk) 10:49, 8 April 2014 (UTC)
I knew as soon as I put an ABZ up there I was opening up a can of worms. I have no particular preference for rf, lg, n+i, 6%l, or whatever as far as that goes because it seems to be that there are multiple conventions going on for naming such figures and I generally have no idea what they mean. (And by the time I do figure those out, they seem to have been superseded by six new conventions!) As long as junctions are some kind of an ABZ with a suffix that somebody understands, that will be best.
As much as I detest it on a purely conceptual level (but... logic!) I'll go with "C" and "D" for prefixes.
Further examination has brought this to my attention. Should   (DAMMa) become   (DSTRa) (matching   (hSTRa) by concept) or   (DSTRag) (matching   (hSTRag) by geometry)? Lost on Belmont (talk) 12:50, 8 April 2014 (UTC)
(Thanks for noticing, I forgot that moment!) With cuts, yes, I have uploaded   (lCUTa) some time ago precisely because it is sometimes beneficial to have a cut starting midway (so that one can construct  )(upd) -- Tuválkin ✉ 01:10, 23 December 2014 (UTC), so yes,   (CUTa) should better be renamed to   (CSTRag). With dams, I honestly don't know... If we're striving for consistency, then yes, it should better be   (DSTRag), and some other icon should be uploaded where a dam would start more abruptly from the midpoint. YLSS (talk) 15:56, 8 April 2014 (UTC) It seems that Useddenim agrees ;) Now we have   (DSTRa) &   (DSTRe). YLSS (talk) 06:53, 9 April 2014 (UTC)

So I've started moving the DAMMs to DSTRs, but I may have acted a bit too soon. I moved DAMM-Le to   (DSTR-Lef) and DAMM-La to   (DSTR-Lag) as I figured this would be the proper notation. However looking at   (hWBRÜCKEa-R) I'm beginning to wonder if I should have moved these to DSTRef-L and DSTRag-L. Because of this I've held off on doing the R versions of these. Which way is correct? Lost on Belmont (talk) 02:48, 12 April 2014 (UTC)

Lately we've been using -La order, so you did everything right. I guess the last time this was discussed was here. YLSS (talk) 09:16, 12 April 2014 (UTC)


So we've got   (DAMMc2) which would seem to be renamed lDSTRc2 since it doesn't display any line color as part of it. But I keep looking at this thing and it seems like there's something wrong with that. At one time I thought I knew what that problem was... but now I cannot remember. What should this be called?

Also, I'm coming up to the parallel icons such as   (evDAMM) et al. Should I just change the DAMMs and CUTs to DSTRs and CSTRs or is there another system that should be employed? Lost on Belmont (talk) 23:45, 4 May 2014 (UTC)

Name collision: BHFlf/HSTlf etc.

Yesterday I needed a stop on a curve, coloured like   (eHST), so I created   (eHSTrf) taking the naming from   (HSTrf) and   (exHSTrf). I then created   (eHSTlf)   (eHSTlg)   (eHSTrg) to complete the set for the colour/shape. Looking to fill in some of the other gaps (different colour permutations, different types of station), I find that if I change HST to BHF, I don't get a bigger spot, but a different shape entirely:   (eBHFlf)   (eBHFlg)   (eBHFrf)   (eBHFrg). --Redrose64 (talk; at English Wikipedia) 14:55, 25 April 2014 (UTC)

That’s because things like   (STRrg) are showing what’s an obsolete name — should be   (STR+l), but nobody wants to go around changing their massive usage. Othe icons should however use the correct, current nomenclature: In this case, "rg" means right side, going backwards, and that's exactly what is shown in   (BHFrg). A station on a line curved as   (STRrg) should be named   (BHF+l). -- Tuválkin ✉ 16:57, 25 April 2014 (UTC)
Besides, the entire combination combination is improper begin with. Eventually these will become   (BHF-Rf) etc. per the slowly spreading hyphenated R/F for halved features. Circeus (talk) 18:04, 25 April 2014 (UTC)
Huh,   (BHF-R) vs.   (BHF-Rf)? Not good... You once wrote about "-R" vs. "R" (with or without a hyphen), maybe it's not too late?.. YLSS (talk) 18:22, 25 April 2014 (UTC)
Yes. Looking back, I have no idea when   (BHF-R) started to happen (weren't they BHFR etc?). I had intended for the hyphenated form to be "half feature" and regular to be "continuing" feature. Circeus (talk) 00:36, 1 May 2014 (UTC)
(ec) I would say that this is one of the most difficult questions in the BSworld ;) Like Tuválkin said, it would indeed be better to rename   (HSTlg) to HST+r (I regularly have to cool myself down in order to get my hands off   (STRlg)). However, that would necessitate renaming   (HSTlf) to HSTl – but lo! that naming pattern is already in use, and no less than for two (slightly different) concepts:   (BHFl) &   (lHSTl), and the existent   (HSTu) consequently also pretends to occupy HSTl... Seeing that there is also   (HST-L), I don't think we have any suffixes left to choose from... On the other hand, the matter of   (BHFlf) vs.   (BHFlg) should also be sorted out, just because they both use "l" but have the station on different sides of the track... And also, the "f" suffix may mean "shifted forward", like in   (lHSTf) (not a very good name, I admit). I have no ideas how untangle this Gordian knot. YLSS (talk) 18:19, 25 April 2014 (UTC)
The half circles (  (lHSTl) and co) case should probably be shifted to a new root name entirely to solve the problem. Note the presence of   (lACC-R) and   (lACC-L). Circeus (talk) 00:36, 1 May 2014 (UTC)

Road crossings

Moved to Talk:BSicon/Renaming/Roads#Road crossings

BHFCC redux

I wanted to rename   (S+BHFCCqa) to the more modern pattern S+BHFCCaq, and at some later moment to do the same with   (BHFCCqa), but then I thought... Since the whole business of   (utvSTRag) –   (utvSTRa) –   (utvSTRaf) /   (utvSTRagq) –   (utvSTRaq) –   (utvSTRafq) is pretty established now, and since   (tBHFa) was introduced last time, possibly we should get rid of the CC suffix? Like that:

  •   (tBHFCCa) →   (tBHFag)
  •   (tBHFa) ==   (tBHFa)
  •   (BHFCCe) →   (tBHFaf)
  •   (BHFCCa) →   (tBHFeg)
  •   (tBHFe) ==   (tBHFe)
  •   (tBHFCCe) →   (tBHFef)
  •   (tBHFCCqa) →   (tBHFagq)
  • +   (tBHFaq)
  •   (BHFCCqe) →   (tBHFafq)
  •   (BHFCCqa) →   (tBHFegq)
  • +   (tBHFeq)
  •   (tBHFCCqe) →   (tBHFefq)

I know that this would mean renaming once again the same old files, but still... Opinions? YLSS (talk) 18:00, 6 September 2014 (UTC)
Added: Forgot these (cf.   (CSTRae) &   (tdSTRaeq)):

  •   (BHFCC) →   (tBHFea)
  •   (tBHFCC) →   (tBHFae)
  •   (BHFCCq) →   (tBHFeaq)
  •   (tBHFCCq) →   (tBHFaeq)
I like it! Useddenim (talk) 20:19, 8 September 2014 (UTC)
I like it too! -- Tuválkin ✉ 17:05, 26 September 2014 (UTC)

So... I have renamed all S-Hahn icons (  (tS+BHFagq),   (tSBHFaeq),   (tSHSTefq)) and all BST icons (  (tBSTea)), which was simple: only two uses for all of them. But then I came across the first stump:   (dKBSTCCa). How should the terminal stations be named within this scheme? For example,   (KBHFCCe). Strictly speaking, we need two "e" suffixes here: one two represent the fact that the track ends, and another to represent the fact that the line stops being a tunnel one. So the most precise name would be tKBHFeeg. But is it possible to contract this to tKBHFeg? Tuvalkin has quite opportunely uploaded   (uextKBHFef), which sounds quite weird (not to mention that it's a DST, not BHF):   (uextDSTef) ←→   (uextKDSTef) ←→   (uextKDSTe). The precise name in this case should probably be uextKDSTaef, but... I don't know... P.S. Tuválkin has previously decided that   (uxpBHFf) should be occupied by a station shifted forward. In case of BHFs & DSTs, I would say there is no difference how an icon   can be named, u-BHF or uBHFf; but in case of HSTs & BSTs, there is: u-HST would be  , while uHSTf would show the stop right next to lower edge. So, possibly, tKBHFeg would rather mean a   (tKBHFe) shifted backward... YLSS (talk) 16:27, 1 October 2014 (UTC)

k

separated to Talk:BSicon/Renaming/k

Mixed junctions

moved from Talk:BSicon/Obsolete and deletions#unconsistently named icons in the list above
  •   (uABZgmr)
  •   (umABZlg)
  •   (umABZlf)

Should follow a unique naming scheme! a×pdeHello! 10:29, 31 October 2014 (UTC)

Ah, I haven't made this public yet, as I'm still unsure with this... The issue is that the established naming patterns do not allow for the "u" tracks being shown above "bahn" tracks. (Axpde, please don't start telling that they should always be below, we're past that, and we need both options.) Some time ago Vanisaac uploaded   (umABZlg1) &   (umABZrg1), under those cryptic names because   (umABZlg) &   (umABZrg) were occupied by different versions (which, incidentally, do not go in line with   (umABZrf)). At that moment, I renamed his files to   (uSTR+STRlg) &   (uSTR+STRrg), which are correct, but quite long... So recently I started experimenting with a different approach. I was always against the "m"/"um" scheme because of it's lack of symmetry (and also because of the implied "preference" for the "bahn" set, which isn't good from the algorithmic point of view). My suggestion is:
  • The main prefix shows the colour of the top line, regardless of whether it's straight or curving (we lack any other way of showing the "topness");
  • The "m" pre-suffix (before "l"/"r" or before "g"/"q") shows that the respective part of the icon is of a different colour than expected:
  (ABZgmr)   (uABZgmr)   (ABZmgr)   (uABZmgr)
As yet, I have only employed this scheme with several files that had some otherwise outdated names:
  (tABZqml)   (utABZqml)   (uABZgmr)   (uABZmgr)   (ueABZg+ml)   (uABZqr+xmr)   (uexABZmg+l)   (uexABZr+mr)
I'm not sure whether it should better be   (tABZqml) or tABZqul, and likewise   ABZmgl or ABZugl... How does this sound overall? YLSS (talk) 11:34, 31 October 2014 (UTC)
P.S. @Axpde: While we've on the topic, could you perform this? YLSS (talk) 11:51, 31 October 2014 (UTC)
first request was already is now done, conc. the other one is two thirds done but I have a question left. Greets a×pdeHello! 18:15, 31 October 2014 (UTC)
Thanks ;) (Replied here, 'cause it's an "insider" topic.) Axpde, I'm not asking you to add xBUE to Bilderkatalog or to use it at de.wp. A file (incl. BSicon) can exist at Commons without being a representation of a real-life object, however abstract. With BSicons, yes, we have established some rules that all icons are expected to fit (at least more or less), although those rules tend to ceaselessly expand... xBUE fits those pattern pretty well. And don't forget that there is overlaying, and that a file may become usable together with another one. WRT the present one: there may be slight differences of interpretation at different projects, and   (exSTR) may be used for a line that is no longer in passenger service, but is still used for freight; or for a line that de facto is no longer employed in any way, or only as a backup, but the tracks are still in place, and the road vehicles are prescribed to cross the rail line with a halt or at a "flashing yellow" light. Real-life example: [1]. YLSS (talk) 19:45, 31 October 2014 (UTC)
Not sure whether those icons are really needed, but here you are:   (xBUE),   (xBUEq),   (uxBUE),   (uxBUEq) ... a×pdeHello! 08:55, 1 November 2014 (UTC)
Thanks again, but see the notes at Category:Icons for railway descriptions/crossing road/level crossings and File talk:BSicon STR+lBUEq.svg. @Tuvalkin: I didn't pay attention to the "l" in your   (STR+lBUEq) and left it out in   (exSTRq+BUE)... But I'm not sure whether it's needed or not; cf.   (SPLa+vBHF), not SPLa+lvBHF. YLSS (talk) 16:16, 1 November 2014 (UTC)
I don't think the l prefix is needed within a compound icon, only for a single stand-alone symbol. Useddenim (talk) 13:24, 2 November 2014 (UTC)

If anybody is interested, I have implemented this scheme with mixed uw-junctions, see the chart. YLSS (talk) 18:57, 11 March 2015 (UTC)

back utSTR

I don't know if anybody has seen it, but I just caught this bugger   (back utSTR) which, of course, doesn't follow naming conventions at all. Also appears to be a narrow icon, and, as a subway, is virtually impossible to see properly at 20x20. Thoughts? Lost on Belmont (talk) 23:24, 1 November 2014 (UTC)

See Talk:BSicon/New icons and icon requests#"Background". I suggest that we just don't touch that abhorrence. It's impossible to track them as they are used as a background image via CSS-class. I hope they'll be gone if I ever finish Routemap... YLSS (talk) 09:10, 2 November 2014 (UTC)

bvWSL-BS2lr et al.

See also Talk:BSicon/Icon geometry and SVG code neatness#bvWSL-BS2lr et al.

I was just about to upload the blue (set u) version of all these icons, but I realized that there is no “v” (parallel lines) component to them. Since   (bSHI2lr) seems to be non-controversial, can we rename   (bSHI2lr+WSL), etc.? Useddenim (talk) 02:32, 4 November 2014 (UTC)

  (bSHI2lr+WSLa), I think. Although there would be some weirdness comparing to   (WSLa) – but wait, there is already one with   (vWSLa)... YLSS (talk) 18:30, 4 November 2014 (UTC)
Personally I don't think that "SHI" is a proper root-ID (reminds me of SHIt evertime I read it ;-) but I have to admit that "BS2" is missleading nowadays (as "2" indicates usually the lower right corner, as introduced by ... myself :-\
Maybe the "v" is missleading as well, it usually indicates two lines on one icon width.
So I think you're right, YLSS,   (bSHI2lr+WSLa) sounds reasonable to me! I'd like to do the rename myself, ok? Greets a×pdeHello! 09:17, 8 November 2014 (UTC)
Knock yerself out! BTW, we were well into the renaming/reorganizing/recategorizing process when we realized that all those shift icons really should have had a SH1/SH2/SH3/SH4 root (no letter “I”). Useddenim (talk) 18:07, 8 November 2014 (UTC)
Lemme guess: SH1 means shift by 1x 250px, SH2 means shift by 2x 250px, SH3 → 3x 250px, SH4 → 4x 250px?
So it should be   (bSH2lr+WSLa)?
On the other hand, 1~4 has two different meanings, 1st through 4th quadrant corner or shift by x-times 250px ... :(
No better ideas? a×pdeHello! 09:37, 9 November 2014 (UTC)
SHI1n means shift by n × 125px. No confusion with corners, as numbers in SHIn can be taken to be a part of the root. (Speaking algorithmically, if 1~4 directly follows "SHI", then it pertains to that shift; otherwise, it means a corner.) That's why it was realised that it could have been better to keep the root to three symbols: SHn. But by now, IMHO saving a single character is not worth all the trouble of re-renaming. YLSS (talk) 10:06, 9 November 2014 (UTC)
BTW: Useddenim has already outlined his naming scheme at en:Wikipedia:Route diagram template/Catalog of pictograms/broad icons. However, I have some doubts about   (uebSHI2lr+WSLa) and similar; possibly they should better be ubSHI2lr+exWSLa... YLSS (talk) 10:11, 9 November 2014 (UTC)
I did think about   (uebSHI2lr+WSLa) vs. ubSHI2lr+exWSLa (and   (uebSHI2l+WSLa) vs. ubSHI2l+exWSLa etc.), but decided that the former made for prettier catalog pages. Useddenim (talk) 12:18, 9 November 2014 (UTC)
Last Q: Shall I proceed with ...
  •   (bSH2lr+WSLa) or
  •   (bSHI2lr+WSLa) ?
I'd prefer the first name (for really shitty reasons ;-) a×pdeHello! 18:05, 13 November 2014 (UTC)
Well, yah, I like SH2 better than SHI2, but unless you're intending to rename all the SHI# icons, I'd stick with the established   (bSHI2lr+WSLa). Useddenim (talk) 19:13, 13 November 2014 (UTC)

BSicon exLLSTR2+4a
exLLSTRc1 LLSTR2+4e
LLSTR2+4
LLSTR2+4a exLLSTRc3 c

I'm not sure this icon is named correctly, as it has an LSTR dot at one end, but an LLSTR dot at the other. Thoughts? Useddenim (talk) 01:54, 27 December 2014 (UTC)

Looks correct:   (exLLSTR2+4a) starts with a regular lücke-start dot and ends with a mid-lücke dot, that’s what the code name LL…a means. -- Tuválkin ✉ 03:36, 27 December 2014 (UTC)
I guess the original files are Tuválkin's   (uexLLSTR3+1a) &   (uexLLSTR3+1e). I explained the names to myself like this: it's a start of a continuous LLSTR line (before it was a plain STR line). YLSS (talk) 10:11, 27 December 2014 (UTC)

GRENZE vs ZOLL

moved from User talk:YLSS#GRENZE vs ZOLL

Hello! I just noticed this, and the others like it. I need you to reconsider. The original problem, way back 3 yrs ago or more, was the uttem impossibility of convincing Axpde and the Guardians of the Bilderkatalog that the GRENZE family needed change. After much strife it was decided to leave GRENZE alone and work on two separate sets of icons: GRZ and ZOLL: These are completely independent of the Bilderkatalog and can be dealt with normally by all of us, concerning their naming and design. Please consider renaming   (xtZOLL) back to   (xtGRENZE) (and the other such renamings), allowing the uploading of a new   (xtZOLL) (etc) designed as  (lZOLL※ extSTR) . -- Tuválkin ✉ 20:13, 13 January 2015 (UTC)

Well, I see two separate issues here: naming & design. The latter let's discuss at Talk:BSicon/Icon geometry and SVG code neatness#ZOLL.
With respect to naming, I don't think there is a reason to panic. In the last three years, quite a lot has happened. (I have joined the project, mwah ha ha!) I think there is no need to worry about anybody's being inconvincible: either we have to try reasoning with him or her once again, or if that still doesn't help and the voice of the community is against the wishes of an individual, we can always request the help of other admins. (You may have witnessed the epopee with   (ENDEl) vs.   (ENDEaq), now hidden in deleted revisions, but still noticeable here). So, if we agree that:
  1. GRENZE is a bit too long for a root;
  2. That the icons   and   are too different to be united under the same root, regardless of the relatedness of their meaning;
  3. That such signs as   are generally used for some kind of halt at a border, such as customs, so Zoll is an appropriate word for it,
then we should better organise a smooth transition from the older naming system to the newer one. That essentially includes preserving the original design of   (GRENZE) as an older version of   (ZOLL), and uploading a modern version of   (tZOLL) (if we agree on that!) on top of the older one. YLSS (talk) 21:53, 13 January 2015 (UTC)

Monodirectional icons

So we have   (STRl),   (uSTRl),   (STRr), and   (uSTRr), and everyone is a part of a happy monodirectional family. But then we have the "h" icons which are pointing in the opposite direction   (hSTRl),   (uhSTRl)   (hSTRr) and   (uhSTRr). If we decide not to abandon this naming scheme for something like   (STRfq), et al., which scheme is correct? I've recently uploaded a number of "colored" elevated icons which use the current scheme of "l" meaning right and "r" meaning left (from the viewer's perspective) hence   (hSTRl violet). Recently, however, we got   (hSTRl pink), which follows the elevated version. I was just going to bulldoze through the elevated icons, swapping them around to make them match the non elevated versions, but I figured I'd bring it up here first. Thoughts? Lost on  Belmont 3200N1000W  (talk) 01:08, 21 February 2015 (UTC)

They should be named consistently with   Icons for railway descriptions/arrow, which is much bigger set than Icons for railway descriptions/direction. Useddenim (talk) 10:29, 21 February 2015 (UTC)
I  agree. -- Tuválkin ✉ 13:02, 21 February 2015 (UTC)
That category is not a good example, as it isn't totally consistent within itself and does not follow some patterns established in the last couple of years, so it also needs quite a lot of renaming... YLSS (talk) 14:23, 22 February 2015 (UTC)
Just scroll to #vSTR above. Of course they should be renamed STRfq etc., but I haven't bothered with that because I'm still not sure that STRf is safe... YLSS (talk) 14:23, 22 February 2015 (UTC)

BSicon hKRZr+lr black+pink+green+orange.svg

  (hKRZr+lr black+pink+green+orange) – this has got to be breaking all sorts of naming conventions… AlgaeGraphix (talk) 11:45, 25 February 2015 (UTC)

Yeah, I would like very much to get it deleted... Just like   (mhABZgr+r black+green+orange)... The latter wouldn't be too hard to replace with overlays: File:BSicon STRlg orange.svg (lhJCTgq※ STRrf black※ tSTR orange※ STR green※ STRlg orange) , but the former...   (KRZ+r orange) +   (KRZr pink) +   (KRZ+l black) +   (STR green) +   (tSTR pink) +   (lhKRZlr+lr)? YLSS (talk) 12:18, 25 February 2015 (UTC)
I’d use overlaying if I ever wanted to produce this kind of result for sure, but neither filename seem to be against convention to me… -- Tuválkin ✉ 17:04, 25 February 2015 (UTC)
ORLY? I don't think we ever considered producing a convention about a line of one colour being overlaid with a tunnel line of another colour.That is, of completely the same shape. 06:57, 26 February 2015 (UTC) Or about the order of colour listing WRT several branches and/or levels. YLSS (talk) 17:37, 25 February 2015 (UTC)
I thought two-colour icon names were for:
  • a single line branching
  • two lines crossing
  • a parallel line icon
Useddenim (talk) 19:40, 25 February 2015 (UTC)
The names quoted above (which I’d never use myself, I repeat) are «not against» the convention for multiple color icons, named with an "+", which we more or less standardized back in 2013. They do depart from its scope (which is pretty much the whole history of BSicons, anyway), but don’t break its principles, as the order of the color names seem to reflect the stacking of the colors in the icon itself. (I didn’t check in detail, though: These are eyesores I’d never use; actually I dont think that “other color” icons should be used for almost anything apart from stylized diagrams shouing only halts and interchanges. Unless they are used to convey gauge or voltage, but that’s another matter altogether.) -- Tuválkin ✉ 00:07, 26 February 2015 (UTC)

The point is moot now since the icons in question have been simplified and renamed. But that's three brain farts in a rather short amount of time, so I guess I'll be taking a break from BSicons for a while. Lost on  Belmont 3200N1000W  (talk) 14:38, 28 February 2015 (UTC)

Three? I count zero so far — but who’s counting? -- Tuválkin ✉ 14:49, 28 February 2015 (UTC)
Too bad it's been deleted–it was so baroque that I think it should have been preserved for posterity. AlgaeGraphix (talk) 20:59, 1 March 2015 (UTC)
Yeah, I also sometimes mourn over such things... Bunnzeechen Streck um X no lénks.svg, all the previous avatars of RBo. But let our hearts rejoice with the thought that we're endowed with the (nearly) complete palette of tACC3+1 for eternity! YLSS (talk) 22:15, 1 March 2015 (UTC)
It is preserved, here. --Redrose64 (talk; at English Wikipedia) 17:25, 13 March 2015 (UTC)

CPICArr vs CPICAKr

I was working on some icons to fill in some of the gaps in the interchange icons and noticed an inconsistency in some names. For the non-accessible CPIC icons, they are named   (exCPICKl) and   (exCPICKr), but the lone equivalent accessible icon is   (exCPICArr). Should   (exCPICArr) and its future siblings be renamed to   (exCPICAKr)? -- Imperator3733 (talk) 02:31, 1 April 2015 (UTC)

Nope, they should be renamed to something different, but I don't know to what. Something with "K" prefix. WRT suffixes, I don't know. See also #CPIC above. In short: leave it as it is for now. And honestly, I don't see a need to fill in those gaps. There is little chance these icons will ever be used... YLSS (talk) 07:08, 1 April 2015 (UTC)
Okay, after reading the discussions at #CPIC and Talk:BSicon/Icon geometry and SVG code neatness#exACC, as well as User:Circeus's renaming proposals, I created a couple prototype icons that I think would have a bit more use:   (KCPICAal__beta) and   (uKCPICAal__beta). Although, now I'm thinking there needs to be a 'q' suffix in there as well... -- Imperator3733 (talk) 02:50, 2 April 2015 (UTC)
Personally, I think the entire CPIC set should be deleted, in favour of   (BHF-L) etc. icons. Useddenim (talk) 23:13, 2 April 2015 (UTC)
Hehehe, have you ever chanced to read this discussion from 2007? Judging by the revision history of   (CPICl), it was decided that its (present) design is better than the (present) design of   (BHF-L). However, with the temporary files unavailable, only Sameboat can cast light onto that... YLSS (talk) 23:54, 2 April 2015 (UTC)
Yes, these definitely need -q's somewhere. Circeus (talk) 03:14, 14 April 2015 (UTC)

HUBs

It's been a while since we've gone on a mass renaming binge, so, submitted for your consideration (apologies to Rod Serling):

Start/end
HUB16 →   (HUBaf-R) HUB36 →   (HUBaf) HUB17 →   (HUBaf-L)
HUB81 →   (HUBa)
HUB24 →   (HUB-R) HUB26 →   (HUB) HUB22 →   (HUB-L)
HUB83 →   (HUBe)
HUB19 →   (HUBeg-R) HUB38 →   (HUBeg) HUB18 →   (HUBeg-L)
Across
HUB06 →   (HUBaqf-L) HUB39 →   (HUBaqf)
HUB09 →   (HUBaqf-R)
HUB84 →   (HUBaq)
HUB23 →   (HUBq-R) HUB25 →   (HUBq) HUB21 →   (HUBq-L)
HUB82 →   (HUBeq)
HUB37 →   (HUBeqg) HUB07 →   (HUBeqg-L)
HUB08 →   (HUBeqg-R)
Turns
HUB14 →   (HUBlf-R) HUB62 →   (HUBlf) HUB32 →   (HUBlf-L)
HUB31 →   (HUBrf-R) HUB61 →   (HUBrf) HUB13 →   (HUBrf-L)
HUB34 →   (HUBlg-R) HUB64 →   (HUBlg) HUB12 →   (HUBlg-L)
HUB11 →   (HUBrg-R) HUB63 →   (HUBrg) HUB33 →   (HUBrg-L)
HUB60 →   (HUBl-R) HUB77 →   (HUBl)
HUB76 →   (HUBr) HUB59 →   (HUBr-L)
HUB79 →   (HUB+r) HUB75 →   (HUB+r-L)
HUB70 →   (HUB+l-R) HUB78 →   (HUB+l)
Cross
HUB68 →   (HUBx-2) HUB41 →   (HUBxq-L) HUB65 →   (HUBx-3)
HUB44 →   (HUBx-R) HUB69 →   (HUBx) HUB42 →   (HUBx-L)
HUB67 →   (HUBx-1) HUB43 →   (HUBxq-R) HUB66 →   (HUBx-4)
HUB45 →   (HUBx-13) HUB46 →   (HUBx-24)
Tees
HUB54 →   (HUBtf-2) HUB74 →   (HUBtf) HUB57 →   (HUBtf-3)
HUB55 →   (HUBtg-1) HUB72 →   (HUBtg) HUB52 →   (HUBtg-4)
HUB53 →   (HUBtl-1) HUB73 →   (HUBtl) HUB56 →   (HUBtl-2)
HUB58 →   (HUBtr-4) HUB71 →   (HUBtr) HUB51 →   (HUBtr-3)
Shifts
HUB87 →   (HUBsl-R) HUB97 →   (HUBsl) HUB48 →   (HUBsl-L)
HUB47 →   (HUBsr-R) HUB96 →   (HUBsr) HUB86 →   (HUBsr-L)
HUB50 →   (HUBs+r-R) HUB99 →   (HUBs+r) HUB89 →   (HUBs+r-L)
HUB88 →   (HUBs+l-R) HUB98 →   (HUBs+l) HUB49 →   (HUBs+l-L)
HUB91 →   (HUBsc2) HUB92 →   (HUBsc3)
HUB94 →   (HUBsc1) HUB93 →   (HUBsc4)
Diagonal
HUB80 →   (HUB2) HUB85 →   (HUB3)
HUB95 →   (HUB1) HUB90 →   (HUB4)
HUB28 →   (HUBc2) HUB29 →   (HUBc3)
HUB27 →   (HUBc1) HUB30 →   (HUBc4)
HUB15 →   (HUB2+4) HUB20 →   (HUB3+1)
 
Miscellaneous
HUB0 →   (MHUB)
HUB01 →   (lHUB)
HUB02 → HUB?

Some thoughts about the new names:

  • Start/end, Turns, Diagonal - standard suffixes
  • Cross - x suffix
  • Tees - t suffix
  • Shifts - s suffix
  • HUB02 - no ideas
I know that this would be introducing (yet more) non-standard suffixes, but the HUB icons always have been a world unto themselves. Useddenim (talk) 21:27, 3 July 2015 (UTC)
Maybe HUB02 could be   (vHUB), it being possibly intended to give a better fit to things like   (vDST-BHF)? This solution would make naming simple for any other HUB icon with this kind of squarer tips (not that I defend the use of this alternate shape, though!). -- Tuválkin ✉ ✇ 15:16, 4 July 2015 (UTC)
Um, I realized that I have no idea why I created HUB02. Should its few uses be replaced with   (HUB01)? Useddenim (talk) 17:21, 4 July 2015 (UTC)
I would say that’s the best idea, as the initiator of one of its 4 distinct uses:
-- Tuválkin ✉ ✇ 20:47, 4 July 2015 (UTC)
Done & deleted. Useddenim (talk) 19:16, 7 July 2015 (UTC)
Too bad. I was going to suggest HUB02 → HUBtoo :p Lost on  Belmont 3200N1000W  (talk) 00:01, 8 July 2015 (UTC)
I think I know why you created it, Useddenim: Its tighter corners match the curves of things like   (HUB32). -- Tuválkin ✉ ✇ 02:20, 8 July 2015 (UTC)

Well, since no-one seems to have any objections, and the HUB02 issue has been solved, I guess it’s renamin’ time! Useddenim (talk) 01:37, 14 July 2015 (UTC)

Done. Useddenim (talk) 00:20, 18 July 2015 (UTC)

HUB# → new name

  • 0   (MHUB)
  • 01   (lHUB)
  • 02 deleted
  • 06   (HUBaqf-L)
  • 07   (HUBeqg-L)
  • 08   (HUBeqg-R)
  • 09   (HUBaqf-R)
  • 11   (HUBrg-R)
  • 12   (HUBlg-L)
  • 13   (HUBrf-L)
  • 14   (HUBlf-R)
  • 15   (HUB2+4)
  • 16   (HUBaf-R)
  • 17   (HUBaf-L)
  • 18   (HUBeg-L)
  • 19   (HUBeg-R)
  • 20   (HUB3+1)
  • 21   (HUBq-L)
  • 22   (HUB-L)
  • 22clo   (HUBsc4)
  • 22clu   (HUBsc3)
  • 22lf   (HUBs+r-L)
  • 22rg   (HUBsr-L)
  • 23   (HUBq-R)
  • 24   (HUB-R)
  • 24cro   (HUBsc1)
  • 24cru   (HUBsc2)
  • 24lg   (HUBsl-R)
  • 24rf   (HUBs+l-R)
  • 25   (HUBq)
  • 26   (HUB)
  • 26lf   (HUBs+r)
  • 26lg   (HUBsl)
  • 26rf   (HUBs+l)
  • 26rg   (HUBsr)
  • 27   (HUBc1)
  • 28   (HUBc2)
  • 29   (HUBc3)
  • 30   (HUBc4)
  • 31   (HUBrf-R)
  • 32   (HUBlf-L)
  • 33   (HUBrg-L)
  • 34   (HUBlg-R)
  • 36   (HUBaf)
  • 37   (HUBeqg)
  • 38   (HUBeg)
  • 39   (HUBaqf)
  • 41   (HUBxq-L)
  • 42   (HUBx-L)
  • 43   (HUBxq-R)
  • 44   (HUBx-R)
  • 45   (HUBx-13)
  • 46   (HUBx-24)
  • 47   (HUBsr-R)
  • 48   (HUBsl-L)
  • 49   (HUBs+l-L)
  • 50   (HUBs+r-R)
  • 51   (HUBtr-3)
  • 52   (HUBtg-4)
  • 53   (HUBtl-1)
  • 54   (HUBtf-2)
  • 55   (HUBtg-1)
  • 56   (HUBtl-2)
  • 57   (HUBtf-3)
  • 58   (HUBtr-4)
  • 59   (HUBr-L)
  • 60   (HUBl-R)
  • 61   (HUBrf)
  • 62   (HUBlf)
  • 63   (HUBrg)
  • 64   (HUBlg)
  • 65   (HUBx-3)
  • 66   (HUBx-4)
  • 67   (HUBx-1)
  • 68   (HUBx-2)
  • 69   (HUBx)
  • 70   (HUB+l-R)
  • 71   (HUBtr)
  • 72   (HUBtg)
  • 73   (HUBtl)
  • 74   (HUBtf)
  • 75   (HUB+r-L)
  • 76   (HUBr)
  • 77   (HUBl)
  • 78   (HUB+l)
  • 79   (HUB+r)
  • 80   (HUB2)
  • 81   (HUBa)
  • 82   (HUBeq)
  • 83   (HUBe)
  • 84   (HUBaq)
  • 85   (HUB3)
  • 86   (HUBsr-L)
  • 87   (HUBsl-R)
  • 88   (HUBs+l-R)
  • 89   (HUBs+r-L)
  • 90   (HUB4)
  • 91   (HUBsc2)
  • 92   (HUBsc3)
  • 93   (HUBsc4)
  • 94   (HUBsc1)
  • 95   (HUB1)
  • 96   (HUBsr)
  • 97   (HUBsl)
  • 98   (HUBs+l)
  • 99   (HUBs+r)

Missing numbers were never used.

New names for BS_SL etc
Current
name		 Standard
pre-/suffix		 Similar
to
  (BS SL)
  (BS SR)		 §-L
§-R		   (STR-L)
  (STR-R)
  (BS SL white)
  (BS SR white)
  (BS S2m)
  (BS S3m)		 v§-
v-§		   (vSTR-)
  (v-STR)

where the § placeholder needs to be replaced by a proper root. The idea of using /// had occured to me, but I'm sure that would cause all sorts of problems. Also,   (BS S2m) and   (BS S3m) are not aligned to the standard 125/375 grid. Useddenim (talk) 11:40, 5 August 2015 (UTC)

@Useddenim: The "2" and "3" in   (BS S2m) and   (BS S3m) are for "second quarter" and "third quarter" (from left); "m" for "middle of quarter". (Side note—it would be great if we could have platforms in the same positions for single parallel lines.) This was so that in the demonstration in the TfD on enwiki they were aligned exactly in the middle of the side platforms. I would have added more of them but there just aren't any use cases in the diagrams I've converted so far. Would   (BS SM) be just §? Jc86035 (talk • contributions • uploads) 15:52, 5 August 2015 (UTC)
§ is just a placeholder until we settle on a proper root. It's not the easiest character to produce: ⌥ Opt+6 on a Mac; I have no idea how to enter it on a PC (let-alone with foreign-language keyboards). Useddenim (talk) 18:35, 5 August 2015 (UTC)
@Useddenim: The numeric character representation of § is § and so under Windows, this character may be entered as Alt+0+1+6+7, note that Alt+1+6+7 doesn't work as intended. --Redrose64 (talk; at English Wikipedia) 12:21, 6 August 2015 (UTC)
Most Latin-script keyboard layouts in widespread use carry a "§" key, I think. See wp:en "en:§". -- Tuválkin ✉ ✇ 15:57, 6 August 2015 (UTC)
@Tuvalkin: AZERTY-layout keyboards, as used in France, yes; but not QWERTY-layout keyboards as used in the UK and USA. --Redrose64 (talk; at English Wikipedia) 16:26, 9 August 2015 (UTC)
@Redrose64: , the QWERTY-layout that’s most widespread in Portugal (meaning: you need to visit a museums to see anything else), created around 1993, was based on the US layout (the old AT PC keyboard) and includes the "§" symbol in the AltGr+4 (or ⌥+4) position. (Maybe yours does something like this, too?) -- Tuválkin ✉ ✇ 17:59, 9 August 2015 (UTC)
On the UK layout QWERTY keyboard, AltGr+4 is the € symbol. None of the other numbers do anything with AltGr. --Redrose64 (talk; at English Wikipedia) 17:59, 10 August 2015 (UTC)
Why not just go the simple route with BSS et al.? Lost on  Belmont 3200N1000W  (talk) 01:11, 6 August 2015 (UTC)
As in BS Striped? Useddenim (talk) 12:09, 8 August 2015 (UTC)
I was thinking BS Split but striped works too. Lost on  Belmont 3200N1000W  (talk) 14:37, 16 August 2015 (UTC)
We could use   (SEP) or similar as a root, given that we don't seem to have any other separators (except for   (GRZ)). Jc86035 (talk • contributions • uploads) 10:21, 6 August 2015 (UTC)
I like SEP — we haev simply too many roots IDs that include or resemble BS. -- Tuválkin ✉ ✇ 22:35, 24 September 2015 (UTC)

Potential problem?

Compare   (WBRÜCKE3+1) and   (WBRÜCKE3+1u) with   (KRXu) and   (KRZ3+1u). Discuss. AlgaeGraphix (talk) 00:23, 7 August 2015 (UTC)

Um, yes. I do believe that WBRÜCKE3+1 should actually be   (WKRX3+1). (Am I correct in assuming that the "o" suffix is implicit for water crossings?) Useddenim (talk) 20:28, 8 August 2015 (UTC)

Platforms

Is there a reason why   (v-BS) and   (vBS-) (and others in Category:Icons for railway descriptions/legende/platform) use the "v" (parallel lines) prefix? Should they, or their 90°-rotated versions (  (-BS),   (BS-)), use the "q" suffix? Jc86035 (talk • contributions • uploads) 09:13, 10 August 2015 (UTC)

They use "v" because they are meant to be paired:  (v-BS※ vSTR-) . (As for rotated vFOO-BAR being FOO-BAR instead of vFOO-BARq is i.m.h.o. a harebrained choice, which I understand but I don’t agree with, but one whose discussion doesn’t belong under platforms, but somewhere else.) -- Tuválkin ✉ ✇ 12:04, 11 August 2015 (UTC)

Also, do some of the platform icons need to be prefixed with leer+ (while   (BSl),   (BSm),   (BSr) and   (BSq) aren't)? Jc86035 (talk • contributions • uploads) 09:33, 10 August 2015 (UTC)

OK, now that I've fixed the HUB icons, I'll take a look at the platforms. Useddenim (talk) 16:20, 10 August 2015 (UTC)
Good — it is sorely needed. As one 1st step, lets get rid of the atypically 2-lettered and easily confusable "BS" and bring back "PLT" or "PTF" or something more distinct, please! -- Tuválkin ✉ ✇ 12:04, 11 August 2015 (UTC)

Superfluous compass arrows

Is there a need to have two sets of compass arrows (  (mapNORTH000deg) and   (numN000))? Should one set be replaced with the other? (IMHO the   (numN000) set looks better, and the other set needs to have the arrow size fixed.) Jc86035 (talk • contributions • uploads) 09:42, 10 August 2015 (UTC)

I didn't realize the (mapNORTH icons were still around. The numNs were created as replacements, so feel free to nominate the former for deletion. Useddenim (talk) 16:22, 10 August 2015 (UTC)
@Useddenim: I have nominated the icon set for deletion here. Jc86035 (talk • contributions • uploads) 14:14, 11 August 2015 (UTC)

PNG detected among SVGs!

File:ExKBHFe-exBHF.png needs to be put out of its misery… -- Tuválkin ✉ ✇ 21:04, 13 November 2015 (UTC)

I tried… Useddenim (talk) 01:52, 18 November 2015 (UTC)

files I uploaded

Is there anything wrong with the naming of   (umHST3+1uhc3) or   (umHST3uh)? (The parser function is because I'm currently waiting for the latter to be moved from …hu.svg to …uh.svg.) Jc86035 (talk • contributions • uploads) 10:00, 3 June 2016 (UTC)

(pinging Tuvalkin, Useddenim, Lost on Belmont, YLSS) or   (uABZrgg) (naming pattern from   (uABZg+1f) and   (uABZg+1g))? Jc86035 (talk • contributions • uploads) 10:23, 3 June 2016 (UTC)

"ÜW" in Luecke corners

(Pinging Useddenim, Lost on Belmont, Tuvalkin) The icons in Category:Icons for railway descriptions/uw/luecke/corner (e.g.   (LLÜWc1)) seem not to have been renamed along with their non-corner counterparts (e.g.   (LLSTR3+1)) and their non-Lücke counterparts (  (STRc1)). Should those 16 corner icons be renamed to LLSTRcn? Jc86035 (talk • contributions • uploads) 14:36, 2 June 2016 (UTC)

In short: yes. Probably just one of those things that no one got around to. Lost on  Belmont 3200N1000W  (talk) 02:00, 3 June 2016 (UTC)
@Lost on Belmont: Thanks; files have been renamed. Jc86035 (talk • contributions • uploads) 13:45, 12 June 2016 (UTC)

Suffix: "uh" vs. "hu"

(ping: Useddenim, YLSS, Belmont, Tuvalkin, Sameboat) A few days ago I moved   (STR+1uh),   (STR3uh),   (STR2uh) and   (STR+4uh) to STR[…]hu (unfortunately without asking anyone), because I thought the suffix was incorrect.[1] (I also uploaded   (umSTR+1hu),   (umSTR3hu) and HST variants.)

Later this week I requested to move all of them back to […]uh again (as well asking to rename   (STR2uhv+4) and   (STR2uh+4) to STR2+4uhvc4 and STR2+4uhc4 respectively because I thought there was ambiguity;[2] I also uploaded   (STR3+1uhc3) with u, m and umHST variants). However, all the requested moves for the files not uploaded by me (except, oddly,   (STR3uh), which was moved back by Wieralee along with my own uploads) were declined by Davey2010 due to "not complying with the renaming guidelines" (probably the Files should NOT be renamed only because the new name looks a bit better part).

Should these files use the uh suffix or the hu suffix; and should   (STR2uh+4) and   (STR2uhv+4) be moved to make their filenames less ambiguous? Thanks, Jc86035 (talk • contributions • uploads) 14:56, 4 June 2016 (UTC)

But, do not blame Davey, please. In cases when sb is requesting for rename of files not uploaded by him -- the filemover has always a doubt: is it proper? can I trust this requester? does he know what he's doing? is it a vandalism? The filemover is not omniscient. When he saw you can be mistaken again, he has declined.
Renaming of the file is not a safe operation: we have many files which disappeared after renaming, so it should be done in exceptional situations only. You can't shutter there and back again and again.
Discuss the "uh" and "hu" suffixex with other BSicon contributors, please and make a serious, discussed requests then.
Yours, Wieralee (talk) 15:33, 4 June 2016 (UTC)
  • When I first saw these (the first time round) I never understood the point to these and quite honestly I still don't ("STR2uh+4" means absolutely nothing to me and I simply see it as a bunch of random letters), Anyway I declined them this time because I thought it was stupid to go from renaming from one name to another and then decide "oh no I prefer the other one" or "oh my bad the other one's correct" as then once renamed you then could've renamed again and someone unaware may of again renamed it .... You should make sure you're completely correct the first time around, If an admin wants to move them back I have no objections. –Davey2010Talk 18:06, 4 June 2016 (UTC)

References

  1. ↑ I thought this because in Category:Icons for railway descriptions/set mixed/elevated/crossing, a lot of the icons are suffixed with hu. I'm not sure if this means something else.
  2. ↑ The file names could be construed as meaning that the bridges go over corner 2 and not corner 4.

In this case, the correct suffix is uh. BSicon names are parsed from the root outwards, so using the example of STR+4uhvc4 we have STR+4 line from corner 4; u crossing under; h an elevated line; v which is parallel; c4 in corner 4. The hu suffix describes an elevated line that passes under something else, such as   (uehKRZhu), which is an elevated metro line crossing under another elevated metro line that is out of use.
@Wieralee and Davey2010: For future reference, an introduction to BSicon naming is at en:Wikipedia:Route diagram template/Catalog of pictograms. (But no one is expecting you to become instant experts on the subject.) Useddenim (talk) 22:27, 4 June 2016 (UTC)

Useddenim - Ah brilliant thank you - I'll check it out later,
Jc86035 - I've reverted myself on those I've declined - If I've missed any just rollback the declines,
I apologize for the declining aswell - Meh we all make mistakes, ANyway thanks, –Davey2010Talk 22:52, 4 June 2016 (UTC)

Icons from viaduct to tunnel

(Pinging: Useddenim · YLSS · Lost on Belmont · Newfraferz87 · Tuvalkin · Sameboat) Should the icons using hTUNNEL and hTNL as part of their name (except for   (uhTUNNEL1),   (hTUNNEL2) and variations) be renamed to use htSTR (like how the   (TUNNELa),   (TUNNELe) set of icons were renamed to   (tSTRa),   (tSTRe))? (In addition, should   (uhtdSTRq) be renamed to uhtdSTRaq to fit with   (utdSTRaq), and   (uhdTUNNELru) to uhtdSTReq?) Jc86035 (talk • contributions • uploads) 09:58, 12 June 2016 (UTC)

If we are using "h" before "t", would that warrant a renaming of   (thSTR) and   (uthSTR)? Or do we consider those as a separate group?   ~ Newfitz Yo! 13:17, 16 June 2016 (UTC)
@Newfraferz87: Probably separate group, given   (htSTRe) (tunnel → viaduct) ≠ thSTRe (covered viaduct → ground?). Jc86035 (talk • contributions • uploads) 14:07, 16 June 2016 (UTC)

Separators

(pinging Xeror, Useddenim, Lost on Belmont) Could we change the BS S root to something more regular like SEP (English / German: Separator)? I think it's actually the only root which currently contains a space.

Old name New name
  (BS S2m) replace: cdSEP (change width to 3⁄4) and   (c)
  (BS S3m) replace:   (c) and cdSEP (change width to 3⁄4)
  (BS SM) SEP
  (BS SMq) SEPq
  (BS SL) SEP-R
  (BS SR) SEP-L
  (BS SL white) SEP-R white
  (BS SR white) SEP-L white

Jc86035 (talk • contributions • uploads) 12:28, 29 July 2016 (UTC)

Weirdly named icon

I'd move   (tdKRZW) to tdWSTR, but unfortunately that's a redirect (to tdKRZW) already. Is the correct procedure to CSD the redirect? Jc86035 (talk • contributions • uploads) 09:11, 1 August 2016 (UTC)

Surprisingly the move was performed by YLSS per this reasoning. -- Sameboat - 同舟 (talk · contri.) 11:03, 1 August 2016 (UTC)
@Sameboat: It seems pointless to use KRZ, given that a crossing is automatically implied by the W prefix. Jc86035 (talk • contributions • uploads) 11:14, 1 August 2016 (UTC)
As a filemover myself the system prevents me from moving file to the established redirect. The redirect page has to be deleted by someone with admin privilege first... -- Sameboat - 同舟 (talk · contri.) 11:43, 1 August 2016 (UTC)
@Sameboat: I've nominated the redirect for speedy deletion. Jc86035 (talk • contributions • uploads) 12:44, 1 August 2016 (UTC)

Museum

@Useddenim, Axpde, Tuvalkin, and Sameboat: your thoughts? "MSTR" conflicts with things like   (lhMSTR), so…

Current Proposed Final decision*
  (MBAHN) lMUSEUM   (lDAMPF)
  (exMBAHN) exlMUSEUM   (exlDAMPF)
  (MSTR) MUSEUM   (DAMPF)
  (eMSTR) eMUSEUM   (eDAMPF)
  (xMSTR) xMUSEUM   (xDAMPF)
  (exMSTR) exMUSEUM   (exDAMPF)
  (uMSTR) uMUSEUM   (uDAMPF)
  (ueMSTR) ueMUSEUM   (ueDAMPF)
  (uxMSTR) uxMUSEUM   (uxDAMPF)
  (uexMSTR) uexMUSEUM   (uexDAMPF)
(*) Column added on 15:47, 9 December 2016 (UTC).

(Naming based on that of   (TRAJEKT) series; there's probably something better, maybe based on   (BHF+BUE)-style naming.) Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me 14:02, 25 October 2016 (UTC)

  • Ok, "M" stands for "MASK". And I doubt that we need more MUSEUM icons than those listed above. IMHO your proposal sounds well, esp. when compared to those TRAJEKT icons! a×pdeHello! 14:11, 25 October 2016 (UTC)
  • I propose(d) the new name DAMPF, which is German for "steam". I don’t think it’s a good idea to refer to these icons as museums, as they are typically used to denote heritage railways (or even plain denotative steam traction, in historical diagrams), and these doesn’t always coincide with rail museums (in diagrams about Portuguese rail lines we’ve been using   (ARCH) for rail museums instead, also identified and linked in text, as none of those “museums” has any functioning ride on track, and some aren’t even connected to the rail network). -- Tuválkin ✉ ✇ 15:59, 25 October 2016 (UTC)
  •   (MBAHN)   →   (lDAMPF)
  •   (MSTR)    →   (DAMPF)
  •   (BOOT)    →   (lBOOT)
  •   (TRAJEKT) →   (BOOT)
-- Tuválkin ✉ ✇ 16:12, 25 October 2016 (UTC)

Files have been renamed. Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me 13:33, 4 December 2016 (UTC)

Another candidate for the Hall of Shame

  (uddexSTR legende) Let’s parse the name, just for fun:

u metro/light rail/canal
d moved down (deprecated in favour of f prefix; and it isn’t)
d half-width (it isn’t)
ex out of use (should be first prefix)
l legende
STR STRetch/STRaight (it isn’t)

Based on   (uexDOCKf)  (uexDOCKg)  (uDOCKl)  (uDOCKr), I think the renaming should be:

  •   (uddlSTR) →‎ ulDOCK
  •   (uddexlSTR) →‎ uexlDOCK

Useddenim (talk) 17:06, 30 October 2016 (UTC)

@Useddenim:   (uddSTR)? Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me 05:02, 31 October 2016 (UTC)
@Jc86035:   (uddSTR) →‎ uDOCKae. Useddenim (talk) 13:10, 27 November 2016 (UTC)
@Useddenim: Sounds good. Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me 13:32, 27 November 2016 (UTC)

Elevated formation naming (continued)

The below is a correction of my own mistake last year – I accidentally swapped left and right for these icons. It shouldn't be too difficult to replace their usage, since they're only in use on a few pages.

Icon Proposed name
  (hvSTR+La) hvSTR+Ra
  (hvSTR+Ra) hvSTR+La
  (hvSTR+Lag) hvSTR+Rag
  (hvSTR+Rag) hvSTR+Lag
  (hvSTR+Le) hvSTR+Re
  (hvSTR+Re) hvSTR+Le
  (hvSTR+Lef) hvSTR+Ref
  (hvSTR+Ref) hvSTR+Lef

—Jc86035 (talk • contributions • uploads) 10:39, 5 August 2016 (UTC)

✓ Done Never mind. Fixed by uploading over existing files Jc86035 (talk) Use {{ping|Jc86035}}
to reply to me 14:53, 23 September 2016 (UTC)

Elevated formation naming

I've just uploaded   (dleer+h-L),   (dleer+h-R),   (leer+h-L) and   (leer+h-R), but I'm not really sure what they should be called (especially for the half-width ones). Are there better names for these icons (and is leer+ necessary)? The rest of Category:Icons for railway descriptions/formations/elevated/parallel could use some cleaning-up; most of the icons don't align properly with regular formations, and the newly-uploaded   (lhvSKRZ-DOCKSl),   (lhdvSTRlre) and similar use a different naming scheme. Jc86035 (talk • contributions • uploads) 15:06, 11 August 2015 (UTC)

As the person who uploaded the icons you mentioned in your note, I used what I thought were appropriate naming conventions at the time based on some of the icons already there. The view I see here would be that   (leer) is a sort of invalid base to use in icon naming, considering it is not all-caps or (again, in my view) really necessary in the case of most icons and can be represented with   (lhv...)" instead. Fukuokakyushu2012 (talk) 20:21, 15 September 2015 (UTC)

@Fukuokakyushu2012: I've renamed the icons I uploaded using the lh prefix. Since it would probably be quite disruptive to just go and rename all the elevated formation icons which don't use the lh prefix, I've made a table with renaming suggestions:

Current icon name Proposed icon name Notes Done
  (leer+h-L)   (lhvSTRl) ✓[OK]
  (leer+h-R)   (lhvSTRr) ✓[OK]
  (dleer+h-L)   (lhdSTRl) ✓[OK]
  (dleer+h-L)   (lhdSTRr) ✓[OK]
  (hleer)   (lhSTR) is already in use. This icon has a mask.
  (hleerq)   (lhSTRq) is already in use. This icon has a mask.
  (hNUL-Rf) ??? Needs narrow formations
  (hNUL-Lg) ??? Needs narrow formations
  (hLGD-La) ??? Needs narrow formations
  (hLGD-Le) ??? Needs narrow formations
  (hLGD-Ma) ??? Needs narrow formations
  (hLGD-Me) ??? Needs narrow formations
  (hLGD-Ra) ??? Needs narrow formations
  (hLGD-Re) ??? Needs narrow formations
  (hLGD-La) ??? Needs narrow formations
  (hNULc14) lhTEEc14
  (hNULc1) lhTEEc1
  (hNULc2) lhTEEc2
  (hNULc3) lhTEEc3
  (hNULc4) lhTEEc4
  (hkABZq1) lhkABZq1 Needs narrow formations
  (hkABZq1a) lhkABZq1a Needs narrow formations
  (hkABZq1e) lhkABZq1e Needs narrow formations
  (hkABZq2) lhkABZq2 Needs narrow formations
  (hkABZq2a) lhkABZq2a Needs narrow formations
  (hkABZq2e) lhkABZq2e Needs narrow formations
  (hkABZq3) lhkABZq3 Needs narrow formations
  (hkABZq3a) lhkABZq3a Needs narrow formations
  (hkABZq3e) lhkABZq3e Needs narrow formations
  (hkABZq4) lhkABZq4 Needs narrow formations
  (hkABZq4a) lhkABZq4a Needs narrow formations
  (hkABZq4e) lhkABZq4e Needs narrow formations
  (hvkSTR2+R) lhvkSTR2+R
  (vhkABZc2hq) lhvkSTR2+Rq?
  (vhkABZc3h) ???
  (chLGD-Lm) lhcSTRl Needs narrow formations; move line to x=125 and add lhcSTRr (not created yet) in diagrams. Use limited, could be deprecated
  (d+h) Deprecate and replace
  (d+hl) Replace with   (lhdSTRl) (with   (lhdSTRr) or   (lhvSTRr) to right)
  (d+hr) Replace with   (lhvSTRr) (with   (lhdSTRl) or   (lhvSTRl) to left)
  (leer+h) lhvSTRm or lhvSTR-M
  (leer+hCONTfl) lhvCONTfl Needs narrow formations; move line to x=500 and add lhvCONTfr to right in diagrams
  (leer+hCONTfr) lhvCONTfr Needs narrow formations; move line to x=0 and add lhvCONTfl to left in diagrams
  (leer+hl) Replace with   (lhvSTRl) (with   (lhvSTRr) to right)
  (leer+hr) Replace with   (lhvSTRr) (with   (lhvSTRl) to left)
  (leer+hlr) Replace with   (lhvSTR) (with   (lhvSTRr) and   (lhvSTRl) to left and right respectively)
  (leer+hq) lhvSTRmq or lhvSTR-Mq Needs narrow formations
  (leer+hlq)
  (leer+ha)		 lhvSTRlq Duplicates, merge. Needs narrow formations; move line to y=0 and add lhvSTRrq to top in diagrams
  (leer+hrq)
  (leer+he)		 lhvSTRrq Duplicates, merge. Needs narrow formations; move line to y=500 and add lhvSTRlq to bottom in diagrams
  (vhLGD-La) lhvSTRlag (or lhvSTRag+L; see below) Needs narrow formations; move line to x=500 and add lhvSTRag or similar (not created yet) to right
  (vhLGD-Ra) lhvSTRrag (or lhvSTRag+R; see below) Needs narrow formations; move line to x=0 and add lhvSTRag or similar (not created yet) to left
  (vhLGD-Le) lhvSTRlef (or lhvSTRef+L; see below) Needs narrow formations; move line to x=500 and add lhvSTRef or similar (not created yet) to right
  (vhLGD-Re) lhvSTRref (or lhvSTRef+R; see below) Needs narrow formations; move line to x=0 and add lhvSTRef or similar (not created yet) to left
  (vhLGD-MLa) lhvSTR-Mlag (or lhvSTRlag; see below) Needs narrow formations
  (vhLGD-MRa) lhvSTR-Mrag (or lhvSTRrag; see below) Needs narrow formations
  (vhLGD-MLe) lhvSTR-Mlef (or lhvSTRlef; see below) Needs narrow formations
  (vhLGD-MRe) lhvSTR-Mref (or lhvSTRref; see below) Needs narrow formations
  (hSHI1r+R) lhSHI1r+R
  (hSHI2l+L) lhSHI2l+L
  (hSHI2l+R) lhSHI2l+R
  (hSHI2r+L) lhSHI2r+L
  (hSHI2r+R) lhSHI2r+R

Also, some of the parallel elevated bridge formations, like   (lhvSTRra) and   (lhdSTRlre), could be renamed with plus signs to lhvSTRa+R and lhdSTRe+LR, which could simplify the naming scheme and avoid awkward names like lhvSTR-Mlef. Jc86035 (talk • contributions • uploads) 11:01, 16 September 2015 (UTC)

Pinging Useddenim, Tuvalkin, YLSS, AlgaeGraphix and Lost on Belmont. Thoughts? Jc86035 (talk • contributions • uploads) 11:06, 16 September 2015 (UTC)
Additionally, should (for example)   (lhvSTRl) be lhvSTR-L or lhvSTR+L? Jc86035 (talk • contributions • uploads) 11:20, 16 September 2015 (UTC)

As you've noted, the hleers are different from lhSTRs in that   (hleer) has a background mask, so the two icons are different and should not be merged. I was always under the (probably incorrect) impression that "hleer" icons were supposed to be reserved for elevated icons with some kind of a mask. Then again, we currently have a "MASK" root, so if those two need to be renamed perhaps something along the lines of lhMASK and lhMASKq?

Additionally, I don't like the proposed lhTEEc# names, since these icons aren't specific to tee icons. The were originally used for hKRZ icons and now Useddenim has been adding them to the "empty" corners of standard junctions. Not sure what, if anything, would be a better name.

At first I agreed with your proposal for the k corner pieces, but after thinking about it, I say leave them as they are. Yes, they don't contain any of the actual line in them, but that's the nature of the k curves. These icons aren't a version of the corner minus the line, they are the elevated corner pieces themselves and, as such, should not contain the "l" prefix. Lost on  Belmont 3200N1000W  (talk) 13:42, 16 September 2015 (UTC)

@Lost on Belmont: I agree with you on the idea that hleer and lhSTR should not be merged, as well as the MASK proposal, and have integrated those into the below table. However, although I think the use of TEE is unnecessary and can easily be superseded by openings in the KRZ slots, I couldn't think of any other good way to indicate specific corners. If you or anyone else have ideas for an alternative, that would be greatly appreciated.

@Jc86035: I made my own tweaks where I thought appropriate, and hopefully you can tell me where I should change what I wrote. When rewriting the table, I figured consistency between namings were important where possible.

Current icon name Proposed icon name Notes Done
  (hleer)   (lhMASK)   (lhSTR) is already in use, using Lost on Belmont's suggestion. ✓[OK]
  (hleerq)   (lhMASKq)   (lhSTRq) is already in use, using Lost on Belmont's suggestion. ✓[OK]
  (hNUL-Rf)   (lhSTR-Ra) Needs narrow formations; uploaded as   (lhSTR+Raf) ✓[OK]
  (hNUL-Lg)   (lhSTR-Le) Needs narrow formations; uploaded as   (lhSTR+Leg) ✓[OK]
  (hLGD-La)   (elhKRZ-La) Needs narrow formations; I put a prefixal "e" here to distinguish it from a possible more complete icon with a "barrier" formation running against the potential   (KRZ) trackage (similar to the late   (eGRENZE), which used "e" to represent a downgraded status). Obsolete notices placed on these icons, not widely used. ✓[OK]
  (hLGD-Le)   (elhKRZ-Le) ✓[OK]
  (hLGD-Ma)   (elhKRZa) ✓[OK]
  (hLGD-Me)   (elhKRZe) ✓[OK]
  (hLGD-Ra)   (elhKRZ-Ra) ✓[OK]
  (hLGD-Re)   (elhKRZ-Re) ✓[OK]
  (hNULc14)   (lhKRZc14) Change in naming only! ✓[OK]
  (hNULc1)   (lhKRZc1) ✓[OK]
  (hNULc2)   (lhKRZc2) ✓[OK]
  (hNULc3)   (lhKRZc3) ✓[OK]
  (hNULc4)   (lhKRZc4) ✓[OK]
  (hkABZq1)   (hkABZq1) Needs narrow formations; no change in naming ✓[OK]
  (hkABZq1a)   (hkABZq1a) ✓[OK]
  (hkABZq1e)   (hkABZq1e) ✓[OK]
  (hkABZq2)   (hkABZq2) ✓[OK]
  (hkABZq2a)   (hkABZq2a) ✓[OK]
  (hkABZq2e)   (hkABZq2e) ✓[OK]
  (hkABZq3)   (hkABZq3) ✓[OK]
  (hkABZq3a)   (hkABZq3a) ✓[OK]
  (hkABZq3e)   (hkABZq3e) ✓[OK]
  (hkABZq4)   (hkABZq4) ✓[OK]
  (hkABZq4a)   (hkABZq4a) ✓[OK]
  (hkABZq4e)   (hkABZq4e) ✓[OK]
  (hvkSTR2+R)   (hvkSTR2+R) Change in naming only! ✓[OK]
  (vhkABZc2hq)   (hvkSTR2+Rq) ✓[OK]
  (vhkABZc3h)   (hvkSTR3+R) ✓[OK]
  (chLGD-Lm)   (lhcSTR-L) Needs narrow formations; move line to x=125 and create   (lhcSTR-R)
  (d+h)   (lhdSTR) Needs narrow formations
  (d+hl)   (lhdSTR-L) Delete file, use code for usage duplicate
  (lhdSTRl) Change in naming only!
  (d+hr)   (lhdSTR-R) Delete file, use code for usage duplicate
  (lhdSTRr) Change in naming only!
  (leer+h)   (lhvSTR-M) Change in naming only! ✓[OK]
  (lhvSTRl)   (lhvSTR-L) ✓[OK]
  (lhvSTRr)   (lhvSTR-R) ✓[OK]
  (lhdSTRlra)   (hdSTR+LRa) ✓[OK]
  (lhdSTRlre)   (hdSTR+LRe) ✓[OK]
  (lhvSTRla)   (hvSTR+La) ✓[OK]
  (lhvSTRle)   (hvSTR+Le) ✓[OK]
  (lhvSTRra)   (hvSTR+Ra) ✓[OK]
  (lhvSTRre)   (hvSTR+Re) ✓[OK]
  (lhvSKRZ-DOCKSl)   (lhvSTR+L-WDOCKSm) ✓[OK]
  (lhvSKRZ-DOCKSr)   (lhvSTR+R-WDOCKSm) ✓[OK]
  (lhdvSKRZ-DOCKSlr)   (lhdSTR+LR-DOCKSm) ✓[OK]
  (leer+hCONTfl)   (lhvCONT-Lf) Needs narrow formations; move line to x=500 and x=0, respectively, and create   (lhvCONTf)
  (leer+hCONTfr)   (lhvCONT-Rf)
  (lhCONT+f-L)   (lhCONT-L+f) Prefix order; other elevated formations have -R or -L before other suffixes. ✓[OK]
  (lhCONT+f-R)   (lhCONT-R+f) ✓[OK]
  (lhCONTf-L)   (lhCONT-Lf) ✓[OK]
  (lhCONTf-R)   (lhCONT-Rf) ✓[OK]
  (lhCONT+g-L)   (lhCONT-L+g) ✓[OK]
  (lhCONT+g-R)   (lhCONT-R+g) ✓[OK]
  (lhCONTg-L)   (lhCONT-Lg) ✓[OK]
  (lhCONTg-R)   (lhCONT-Rg) ✓[OK]
  (lhCONT+f-Lq)   (lhCONT-L+fq) ✓[OK]
  (lhCONT+f-Rq)   (lhCONT-R+fq) ✓[OK]
  (lhCONTf-Lq)   (lhCONT-Lfq) ✓[OK]
  (lhCONTf-Rq)   (lhCONT-Rfq) ✓[OK]
  (lhCONT+g-Lq)   (lhCONT-L+gq) ✓[OK]
  (lhCONT+g-Rq)   (lhCONT-R+gq) ✓[OK]
  (lhCONTg-Lq)   (lhCONT-Lgq) ✓[OK]
  (lhCONTg-Rq)   (lhCONT-Rgq) ✓[OK]
  (leer+hl) Redirect to   (lhvSTR-L) (and add   (lhvSTR-R) to left)
  (leer+hr) Redirect to   (lhvSTR-R) (and add   (lhvSTR-L) to right)
  (leer+hlr) Redirect to   (lhvSTR) (and add   (lhvSTR-R) and   (lhvSTR-L) to left and right respectively)
  (leer+hq)   (lhvSTR-Mq) Needs narrow formations Fixing
  (leer+hlq)
  (leer+ha)		   (lhvSTR-Lq) Duplicates, merge. Needs narrow formations; move line to y=0 and y=500, respectively, and create   (lhvSTRq) Fixing
  (leer+hrq)
  (leer+he)		   (lhvSTR-Rq) Fixing
  (vhLGD-La)   (hvSTR+Lag) Needs narrow formations; move line to x=500 and add   (lhvSTRag) or similar (not created yet) to right Fixing
  (vhLGD-Ra)   (hvSTR+Rag) Needs narrow formations; move line to x=0 and add   (lhvSTRag) or similar (not created yet) to left Fixing
  (vhLGD-Le)   (hvSTR+Lef) Needs narrow formations; move line to x=500 and add   (lhvSTRef) or similar (not created yet) to right Fixing
  (vhLGD-Re)   (hvSTR+Ref) Needs narrow formations; move line to x=0 and add   (lhvSTRef) or similar (not created yet) to left Fixing
  (vhLGD-MLa)   (lhvSTR-Mlag) Needs narrow formations
  (vhLGD-MRa)   (lhvSTR-Mrag) Needs narrow formations
  (vhLGD-MLe)   (lhvSTR-Mlef) Needs narrow formations
  (vhLGD-MRe)   (lhvSTR-Mref) Needs narrow formations

Please tell me if anything should be added to or changed on the list. Fukuokakyushu2012 (talk) 22:56, 16 September 2015 (UTC)

I edited the table to fix some errors and improve clarity. If no one else objects, I will start filing moving requests soon. Fukuokakyushu2012 (talk) 12:27, 17 September 2015 (UTC)
@Fukuokakyushu2012 and Lost on Belmont: I think it would probably be better to suffix some of the icons (including some already renamed or recently uploaded) with -R or -L instead of with r or l (for example, lhvSTR-L instead of   (lhvSTRl), elhKRZ-Le instead of elhKRZle, and so on), to be consistent with already-uploaded icons (  (lhSTR-Lef), so lhvSTR-Lef and not lhvSTRlef). For parallel line bridge endings where the end is off the side, we could use +R (e.g. lhvSTR+La instead of   (lhvSTRla)). Jc86035 (talk • contributions • uploads) 14:31, 17 September 2015 (UTC)
I understand, and I must agree with you on the -R idea, but so far I haven't been able to find any icons with the +R suffix. For the sake of consistency within this set, I think your first suggestion of -R would be a better move. Fukuokakyushu2012 (talk) 19:13, 17 September 2015 (UTC)
@Jc86035: Table changed to match your suggestions as well. Especially for the m's, I just realized that could potentially conflict with the mixed icons. I think though that the suffixes -M and -LR should be left out for most icons with formations on both sides, as often that could just be represented with no -R suffix. This excludes, of course, -M-suffixed BSicons. Fukuokakyushu2012 (talk) 01:24, 18 September 2015 (UTC)
@Fukuokakyushu2012: I think it's better if you use the +R and +L suffixes (even though they aren't on the suffixes list, probably because the older parallel bridge formations were entirely on one icon square), because otherwise you would end up having conflicting names (unless you use the +1 type of suffix to indicate which corner it's pointing to). I've also corrected the names for the lhvSTR-Mla series to lhvSTR-Mlag, etc., because if you don't have g (top; backwards) or f (bottom; forwards) it indicates the bridge ends in the middle of the icon. Jc86035 (talk • contributions • uploads) 09:59, 18 September 2015 (UTC)
@Jc86035: OK, thank you for making your point clear and sorry it is taking so long for for me to understand your point. I would still, in the applicable cases, would still rather use +l as opposed to +L, not so much because of personal preference, but I am just worried someone might make a fuss about it later and have it changed to something else anyway. Fukuokakyushu2012 (talk) 10:42, 18 September 2015 (UTC)

@Fukuokakyushu2012: Updated the table to have the +l and +r suffixes (and also added some continuation icons that probably have the wrong prefix order). Does anyone else have any objections to the proposed naming scheme? Jc86035 (talk • contributions • uploads) 05:19, 19 September 2015 (UTC)

Gave the icons with +r and +l the capitalized +R and +L suffixes (currently used on six icons), since although they wouldn't cause any naming conflicts if they used +r and +l, the uncapitalized suffixes are used for entirely different things. Jc86035 (talk • contributions • uploads) 12:09, 19 September 2015 (UTC)

@Fukuokakyushu2012: Can we move the files now? Jc86035 (talk • contributions • uploads) 11:11, 24 September 2015 (UTC)
@Jc86035: Yes, how should we divide them (so we aren't stepping on each others feet)? Should I just start at one end of the table? I suppose we should start first with those that only need to be renamed, then work through those that also need narrow formations. Fukuokakyushu2012 (talk) 23:10, 24 September 2015 (UTC)
Final changes made to table. Fukuokakyushu2012 (talk) 01:14, 25 September 2015 (UTC)
@Fukuokakyushu2012: I could do everything from   (leer+hCONTfl) down, plus the half-width icons except   (lhdvSKRZ-DOCKSlr); this would split the table exactly 40-40. One thing about the water formations though – should they use SKRZ? I would think that lhvSTR-L+WDOCKSm File:BSicon lhvSTRl.svg (lhvSTRl※ WDOCKSm)  (for the first one in the table) would be better. Jc86035 (talk • contributions • uploads) 13:52, 25 September 2015 (UTC)
That seems good, but earlier today (UTC), I

already requested renaming for 8 BSicons (lhCONT-L+f to lhCONT-Rg), so you can do what remains on that side will I do the top as you suggested. As for   (lhdvSKRZ-DOCKSlr), I was considering   (dDOCKSm) to be a crossing path (for what I was using, yes, but in general, definitely not), which was why I used the base SKRZ. I understand what you pointed out and think that is better, so I will rename that in compliance with your suggestion. Fukuokakyushu2012 (talk) 19:38, 25 September 2015 (UTC)

I regretted having removed the "Done" column, so I have restored it. I removed it originally to improve clarity of the table, but that is quite insignificant in comparison to retaining records as to what's been completed. Fukuokakyushu2012 (talk) 19:38, 25 September 2015 (UTC)

@Fukuokakyushu2012: One more thing – since the +L and +R icons can't actually have track in them maybe they shouldn't have the l prefix? Jc86035 (talk • contributions • uploads) 08:04, 26 September 2015 (UTC)
@Jc86035: Come to think of it, yes; that would keep these icons consistent with Lost on Belmont's idea. I will keep that in mind when I rename   (hvSTR+Le) and its immediate sister icons. Fukuokakyushu2012 (talk) 12:07, 26 September 2015 (UTC)
@Jc86035: Uh-oh. Take a look at this and this. Fukuokakyushu2012 (talk) 10:34, 28 September 2015 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Talk:BSicon/Renaming/Archive_7&oldid=835513984"