Talk:BSicon/Renaming/Archive 6

Category:BSicon/New icons

DePiep has added some new icons that bear examining:

Existing	Suggested	Comments
(ANCHOR)	(ANK000)	from DE:ANKer (close to EN:ANChor)
(ANCHOR030deg)	(ANK030)
(ANCHOR330deg)	(ANK330)
(DIRECTIONyellow000deg)	(DELg)	from DELta, based on the greek letter Δ Cp. these. -- Tuválkin ✉ 18:06, 31 December 2012 (UTC) And also this and its l/r/d/u and u/ug variants. -- Tuválkin ✉ 15:41, 7 January 2013 (UTC)
(DIRECTIONyellow090deg)	(DELl)
(DIRECTIONyellow180deg)	(DELf)
(DIRECTIONyellow270deg)	(DELr)
(uxFEEDERqla)	(WFEEDERqlg)	incorrect prefix and suffix Both "FEED" and "FEEDER" are in use: cf. this (and cp. w/ this). -- Tuválkin ✉ 18:06, 31 December 2012 (UTC) Name revised & files moved. Useddenim (talk) 13:20, 23 May 2013 (UTC)
(uxFEEDERqra)	(WFEEDERqrg)
(uPANAMACANAL-BASINSl)	???	verbose, overly-exact, and incorrect u prefix Cp. w/ "RESV" and "RESR" incl. here. -- Tuválkin ✉ 18:06, 31 December 2012 (UTC)
(uPANAMACANAL-BASINSr)	???
(mapNORTH000deg)	(numN000)	not consistent with each other; superior versions already exist Vd. this. -- Tuválkin ✉ 18:06, 31 December 2012 (UTC)
(mapNORTH045deg)	(numN045)
(mapNORTH315deg)	(numN315)
(SUMMITl)	(lGIPl)	Legende icon that should renamed, along with   (STRSUMMITl) et al.; either to EN:SUMmit or DE:GIPfel (see below)
(SUMMITr)	(lGIPr)
(uexWATERSHEDv)	(WGRZ) no suffix	could be part of the   (GRENZE2) family, with uex prefix for      colour (see below)
(uexWATERSHEDh)	(WGRZq) q suffix
(LMROAD)	OK	however, the entire set of road icon names needs to examined cf.  (AKRZu) cf.  (uAKRZu) cf.  (MWWBRÜCKE1q)
(LMROADq)	OK
(LRAILBRIDGEq)	(ALKRZu)
(LWATERBRIDGEq)	(uALKRZu)
(LWBRÜCKEq)	(WALKRZuq)

Useddenim (talk) 16:07, 31 December 2012 (UTC)

I went ahead and renamed the lücke motorway bridges, but suddenly it struck me that   (WALKRZu) is not a good name, as water doesn’t take precedence over much anything, not even — this icon name thus needing to include a "q": It should be   (WALKRZuq) instead, as in  (MWWBRÜCKE1q1) vs.  (NWBRÜCKE), leaving the name   (WALKRZu) forFile:BSicon LMROAD.svg (LMROAD※ lMBRÜCKE※ WASSERq) — opinions? -- Tuválkin ✉ 19:14, 4 January 2013 (UTC)

 Done -- Tuválkin ✉ 21:30, 22 February 2013 (UTC)

Change proposals are nonsense. Icon nams say what it is. "direction" into 'delta' (for the figure you reason, really?). -DePiep (talk) 23:53, 14 March 2013 (UTC)

There is an established way to indicate direction in BSicons, which is the use of chevron arrows, such as  (STRf) or  (lvNULgq). You decided to go ahead and create your own style for the Panama Canal diagram. Useddenim was polite enough to try and find a way big yellow triangles could be fit into the BSicon system. Usually this kind of new ideas is simply discarded and its use dully replaced with more usual icons. -- Tuválkin ✉ 05:30, 15 March 2013 (UTC)

Changing "mapNORTH000deg" (good description I did!) into "numN000" is being illiterate. -DePiep (talk) 23:53, 14 March 2013 (UTC)

Adding comment on a subject away from the location of its ongoing discussion without even a link to it is maybe also being illiterate (or deceitful, and naive at that). Here’s where I explain to you why I think  (numN000) etc. are better names than the ones you used, considering other litteral icons in existence — which you may have not known when you devised the names   (mapNORTH000deg) etc. I purposefully created a new set, instead of renaming yours, out of respect for other people’s work and to invite discussion on the subject. You chose personal attacks instead, first with snark and misplaced smugness, now with a petty tantrum.

File:BSicon mapNORTH000deg.svg	File:BSicon mapNORTH045deg.svg	File:BSicon mapNORTH315deg.svg

Yet, one only has to compare our respective SVG skills to know who’s best described as illiterate — why, you couldn’t even get them three icons to show the windrose in the same size? «Awww, XML is hard!» -- Tuválkin ✉ 05:30, 15 March 2013 (UTC)

This list is clearly based on who added icons (me), not on their intrinsic value. If you have personal bias, better leave Wikipedia. -DePiep (talk) 04:17, 15 March 2013 (UTC)

There is a clear, well-established nomenclature for BSicon naming. I suggest that you follow it, instead of picking excessively-long names based on what you think the icon can (only) be used for. As for "intrinsic value", if an overly-complicated icon has only a single use, I think the answer is self-evident… Useddenim (talk) 04:45, 15 March 2013 (UTC)
P.S. Don‘t let the door hit you on the way out.

This list tried to deal with a series of more or less problematic icons which were uploaded at the same time and into the same (atypical) category, to be used in the same single diagram. That they were contributed by one same user is immaterial and any suggestion of personal bias or antipathy is ludicrous. Indeed, some of these icons were dully integrated in the system, others are oddballs still needing attention, others are good new ideas and welcomed as such. That’s all there is to be said. -- Tuválkin ✉ 05:30, 15 March 2013 (UTC)

Watershed

Instead of "GRENZE" with the "ex" suffix for the current   (uexWATERSHEDv) icons (suggested above), I suggest the "W" prefix instead, for semantics; it could be used with or without "ex" suffix, if non-current watershed boundaries are ever necessary.-- Tuválkin ✉ 16:14, 7 January 2013 (UTC)

 Done:  (WGRZ) and  (WGRZq). -- Tuválkin ✉ 19:36, 23 February 2013 (UTC)

BHF AUSW

Unless anyone has objections, I will be renaming the  (BHF AUSW) (Bahnhof Ausweiche) group to (PBHF). Useddenim (talk) 15:29, 14 March 2013 (UTC)

Cool. (What does the "P" stand for?) You should rename the  (HST AUSW) ones, too. -- Tuválkin ✉ 16:23, 14 March 2013 (UTC)

(with ec)

 (HST AUSW) makes some sense cause we have separate stops on both tracks instead of a complete station (with junctions etc.). But what's the sense of  (BHF AUSW)? And why not using parallel line icons?

Why introducing a new uppercase prefix? And what does 'P' stand for? Should rather be a 'v' prefix ... a×p_de^Hello! 16:39, 14 March 2013 (UTC)

1. P for Passing loop (PSL).
2. Well, yes, I consider the HSTs as part of the group (along with INT).
3. Yes, it could be shown with "v" icons, but would then require four instead of one –   (vSTRa) (dBHF) (dBHF)  (vSTRe). (I didn't notice anyone saying that  (uPSLa)/ (uPSLm)/ (uPSLe) should be replaced with a string of regular icons.)

Useddenim (talk) 23:57, 14 March 2013 (UTC)

Fords

From fWFORD to fWSTR.

Kudos to Useddenim, who’s taking care of the unstandard water line geometry of this set of icons, used mostly for the footpath projects. I have a qualm about the current naming, though. A ford is a place where a body of water is crossed by wading, obviously absent from rail lines and most other concievable usages of RTDs, apart from the titular footpaths. However the current naming "WFORD" seems to me unadvised, as, from definition, a ford is always about water/wasser. If we add a "w" to this out of consistency (akin to, say,  (BRÜCKE) v.s  (WBRÜCKE) et c.), then we should go all the way and name it for what it is — "WKRZ", a crossing of water with the RDT line in question. -- Tuválkin ✉ 20:59, 25 March 2013 (UTC)

Hmm, why not simply   (fWSTR), same as  (hWSTR) or alike. a×p_de^Hello! 13:39, 2 April 2013 (UTC)

Well, you’re right about that. It is a better choice also because it allows things like, say, File:BSicon vSTRa.svg (WSPLa) or  (uWKRXq). -- Tuválkin ✉ 14:33, 2 April 2013 (UTC)

Personally, I think it should simply be renamed fFORD, since—as noted above—a ford is a specific, distinct feature. The examples above are somewhat facetious, but these certainly do exist:  (WRD1),  (WRP1) and  (WRP2). Useddenim (talk) 21:27, 2 April 2013 (UTC) Useddenim (talk) 17:50, 5 May 2013 (UTC)

Oh yes, don't forget  (FALLINGWATER). Useddenim (talk) 21:32, 2 April 2013 (UTC)

Things like  (tWSTR) (hopefully) show how FORD as a root ID is a bad idea. -- Tuválkin ✉ 13:48, 5 May 2013 (UTC)

Purely incidentally and quite overlate, I may note that after some consideration I moved exdhWSTR not to *exhdWSTR, but  (exhdKRZW). Firstly, because we have things like   (WABZ+r) (and now also  (WSHI1l)), so WSTR should theoretically be reserved for  (WASSER) it would be a mauvais ton to continue using WSTR for anything else than water. Secondly, it should be KRZW instead of WKRZ, for pretty much the same reasons. So,  (fWFORD) ->  (fKRZW). YLSS (talk) 12:45, 16 January 2014 (UTC)

WTUNNEL

We have a  (vWTUNNEL), but it is not really a tunnel, rather a bridge over double track carrying a “river” (canal?). I improved the geometry a bit, but the name bugs me. WTUNNEL would be something like  , right? I suggest for this   (vWSTRu) instead. (And ditto, m.m., for all other such WTUNNEL icons.) Opinions? -- Tuválkin ✉ 18:07, 31 May 2013 (UTC)

Meanwhile I needed to create   (vWSTRuh). -- Tuválkin ✉ 18:20, 31 May 2013 (UTC)

"WSTRu" or "WKRZu"? AFAIK, as yet the "u"/"o" suffixed aren't used with STR. Although yes, we do have  (tWSTR) &  (hWSTR). YLSS (talk) 22:13, 1 June 2013 (UTC)

M root modifier

8-way stations

Somewhere else there’s a plead to rename these two:   (MBHF) &   (uMBHF). I suggest  (TBHF1234) &  (uTBHF1234), which are more or less obvious. -- Tuválkin ✉ 10:35, 21 May 2013 (UTC)

 Done. Useddenim (talk) 13:46, 21 May 2013 (UTC)

Any idea why half of the related population of BSicons is TBHF (e.g.  (exTBHFx)) while the other is KRZBHF (e.g.   (KRZBHF))? YLSS (talk) 13:08, 21 May 2013 (UTC)

If we reseach the file histories we’d find out the origin of that divergent naming, but seems that it is more productive to decide which is best. I’m for single ID when possible, thus for TBHF. -- Tuválkin ✉ 13:41, 21 May 2013 (UTC)

Choochoo

Erm... Also  (MSTR) &  (exMSTR) ... YLSS (talk) 18:45, 30 May 2013 (UTC)

These clearly should be renamed using the same approach as  (TRAJEKT). The problem is that there is also the icon  (BOOT). That should be solved by unifying, and thus I suggest this:

•  (TRAJEKT) →  (BOOT)
•  (BOOT)    →   (lBOOT)
•  (MSTR)    →   (CHOO)
•  (MBAHN)   →   (lCHOO)

(And I still think that "l" was a very poor choice. You guys will agree with me, when it is too late.) -- Tuválkin ✉ 17:09, 31 May 2013 (UTC)

(Had I participated in that discussion, I would've voted for "o" or rather "O"; however, as yet I see nothing bad in "l" either.) I thought about BOOT/lBOOT, especially since I retrieved  (uexBOOT2). It seems to be a natural approach; however, we have two dozen similar icons like  (CLRV) that do not presently have any "legende". And seriously, I suppose you meant MBAHN/lMBAHN ;) ? YLSS (talk) 17:19, 31 May 2013 (UTC)

Replying:

1. (Who told you your opinion didn’t count? You should have voted — it is still there…)
2.  (uexBOOT2) (maybe   (uexROW)?) is another of these cases, yes.
3.  (CLRV) and all those many icons, such as  (FLUG) or  (BICYCLE), are not because there are no track+feature icons with them. But if there were (or when there is) something like, say,   — then that should be named "TRAM" and the current one renamed to "lTRAM" (or "oTRAM").
4. I dont mean to propose "CHOO" seriously, but I think "MBAHN" is a poor choice. Maybe "DAMPF"?

-- Tuválkin ✉ 01:18, 8 June 2013 (UTC)

To ease the renaming process, I suggest we restrict ourselves just with getting rid of  (MSTR), and I think it would be quite tolerable to call it   (BHF*MBAHN). " * " is the composition symbol instead of " + " (as I wrote here). Any opposition? YLSS (talk) 21:29, 17 October 2013 (UTC)

Sorry, I have to disagree — on two accounts:

• "*" is a very bad choice to include in a filename (I’m surprised it is not black listed), as it is the wildcard character in many operative systems. If this gets adoped I’ll have to stop creating new icons, or endure a much slower process of opening and selecting my own offline SVG files (I routinely type things like "*STEEL" in my text editor openfile box to restrict the selection to a subset of icon files). The plus sign, while ambiguous, has a clear use: "ROOT+ROOT" means overlay, "ROOT+direction" means origin.
• Renaming MSTR to an equally provisional icon root name is a waste of time. Either it rename to the definitive name, or leave it alone (unless there's a need ro reuse the current name). In this, I’m assuming that the BOOT / lBOOT approach is agreed to be idea.

I would approve to move  (MSTR) right now to  (DAMPF), which addresses everybody's concerns. -- Tuválkin ✉ 23:31, 17 October 2013 (UTC)

OK, no " * ", what about " & "?  (eGRENZE) →   (STR&GRZq)? YLSS (talk) 10:35, 21 October 2013 (UTC)

Pretty sure that I have explained before on one of these BSicon discussion pages just why certain characters should not be used in filenames, but I just can't find it now. The ampersand & has problems because it has special meaning to some operating systems: in Unix it causes a process to run in the background, and under Windows it separates one command from the next. --Redrose64 (talk; at English Wikipedia) 15:00, 21 October 2013 (UTC)

YLSS, I really think that "+" can be used to mark both origins and overlays. When it connects two roots (indeed two full names) it shows an overlay, when after it comes only corners or other directions, it is an origin. I cannot see any possible ambiguity. (And maybe this should be moved to a separate heading.) -- Tuválkin ✉ 22:49, 2 November 2013 (UTC)

MCONT

Argh, they just seem to creep out of nowhere...   (MCONTl) &   (MCONTr). (Not that I have any intentions on creating corresponding masks, but still.) Cf.   (MWCONTl),  (MROADq) and  (AROADlf) vs.  (AKRZlf) below. YLSS (talk) 22:59, 7 June 2013 (UTC)

Hehe, I think this "M"- preffic come from "motorway". It should go away when these roads get standardized. -- Tuválkin ✉ 00:59, 8 June 2013 (UTC)

Prefix order

Place of width prefixes in wide&narrow icons’ filenames

And did you notice Axpde (talk · contribs)’s renaming of  (tdBHF) to   (dtBHF), which royally screws up the Catalog templates? Useddenim (talk) 18:05, 7 January 2013 (UTC)

I noticed. But is this settled? Where should width prefixes ("d", "c", and "b") come in icon filenames? Immediatly before the root, before any others, or something else? -- Tuválkin ✉ 18:54, 7 January 2013 (UTC)

I thought the same place as v, so the {{BS-anleitung}} templates would work correctly. Useddenim (talk) 20:26, 7 January 2013 (UTC)

I.e. «u,e,x,m» «h¦t» «b¦c¦d¦v»; however, I see that Catalog of pictograms > Naming logic > Prefix was never updated to reflect this… Useddenim (talk) 04:18, 8 January 2013 (UTC)

State of affairs

I wanted to edit en:Wikipedia:Route diagram template/Catalog of pictograms to introduce the "l" prefix at last, but realised that I don't really understand its position relative to the "d" prefix. Closer analysis of existing icons made me dizzy. Here's what we currently have:

• "tv" order is nearly universal, in contrast to that guideline
• judging by this category and its subcats, it is 50/50 "vh" vs. "hv" ^{Fixed -- Tuválkin ✉ 21:55, 30 May 2013 (UTC)}
• lotsa "lv...", some still "Lv..."
•   (luvKMW) × 18 (but I have already pleaded before that colour-prefixes should come first)
• 50/50 "dt"/"td" in set u and subcats
• mix of "dt"/"td" in the "bahn" set (unpresentable due to bad categorisation as yet)
•   (dlENDEfq) × 4 +   (dlNULf) × 4
•   (dhNULl) +   (udhSTR) × 8 but   (exhdÜWc1)
•   (dlvNULfq) +  (dvNULfq) +  (tlv-NULf) +  (utlvNULf) × 4
•  (dLHSTACC) &  (v-LHSTACC) (should be lc in any case)
•   (xvdCONTl)
•   (dexvWSLl+l) &   (lfdvBHF-R) (overkill ;)

The only thing I can say is that t, h, l should come in one place as they are any nearly mutually exclusive (except for the rare  (uthSTR) and arrows). Likewise "d" and "v" should do in one place, since parallel lines can fit in a narrow icon only across and can be described using "-" and no "v". I guess the number of renamings would be minimized if we settle on [colour/type] [t|h|l] [c|d|b|v] order. YLSS (talk) 17:17, 27 May 2013 (UTC)

I’ve been slowly trying to fix these; that’s fair because many "vh"s were uploaded by me. -- Tuválkin ✉ 21:55, 30 May 2013 (UTC)

Proposed revision

The prefix indicates the status of the infrastructure (partially in use, not used, disused, or not yet opened), and whether it is elevated or in tunnel:

Zero or more of these prefixes:

u	f	g	e	x	m
U-Bahn / underground	footpath	green	ehemals / erstwhile	ex	Mischbetrieb mit U-Bahn / mixed with metro
e.g. metro, light rail or canal	footpath or hiking trail	unwatered canal	closed, under construction, or planned station/stop/etc. Note that the BSe template requires e to come first.	closed, under construction, or planned track	indicates that the icon contains both heavy and light rail in the same pictogram (see below)

then optionally one of:

h	t
Hochbahn / high level	Tunnelstrecke / tunnel
elevated line	underground line

followed by none or exactly one of these prefixes:

b	c	d	v
breit / broad	schmal / compact	dünn / slender	from the transition between double and single lines
double-width symbols	quarter-width symbols for special arrangements (not shown on this page)	half-width symbols, used in pairs	standard width symbols showing close parallel lines (same as two paired d symbols)

then optionally a ROOT modifier:

A	C	D	K	l	L, LL	M	S	SW	T	W
Autobahn	Cut	Damm	Kopf	Legende / legend	Lücke	Maske, Maskieren / mask	S-Bahn / Suburban	Systemwechsel	Turm	Wasser / water
highway (crossing)	cutting	embankment	terminus	legend	interruption	mask	commuter station	mode change	split level (station)	water (crossing)

The standard order is

"u", "f", "g", "e", "x", "m" – all prefixes concerning the status of the track are first (for different BS-anleitung-templates),

"h"/"t" - prefixes concerning the elevation of the track are next (directly attached to BSicon-ID, and sometimes need to be used as a suffix as well).

"b"/"c"/"d"/"v" – prefixes concerning size of icon third,

root modifier last.

I'd put this whole thing in a box, but I can't figure out how. ({{Box}} isn't what I want.) Useddenim (talk) 18:58, 29 May 2013 (UTC)

I would place "l" before "v" & Co., just to reduce the number of renamings, but on the other hand... When I first read that discussion about introducing "l", I also though of it as a root modifier, but after realising that it has already been used as one of the "outer" prefixes, I've renamed quite a lot on that note. So I really don't know now... BTW, what to you think about the interrelation of "d" & "v" (see above) and "h" & "l" (as here)? YLSS (talk) 20:35, 29 May 2013 (UTC)

Since there is already a lot of icons with "lv" order, and this does not seem to produce any problems, I have BOLDly updated the catalogue following Useddenim's proposal, except that "l" is placed together with "t" and "h". (If anybody is ready to rename all existent "lv" icons to "vl", feel free to revert my edit.) However, something should be decided w.r.t.  (utlvNULf) vs.  (lhBHF) - these are exceptional cases, but still... And there is also a dozen icons combining "d" & "v". Plus, "n" is going to be introduced. YLSS (talk) 11:44, 17 October 2013 (UTC)

Aside: "d" and "v" can coexist in an icon at least in two cases:

1. Lines across (horizontal), something like a half-width  (vSTRq) — to be named either dvSTRq or vdSTRq (Oh, here’s one:   (vdCONTr), by Useddenim. -- Tuválkin ✉ 18:51, 29 October 2013 (UTC))
2. or (I just thought of this!) the two inner halves of a double line:  (dSTR-R※ dSTR-L) , which could be named either dvSTR-M or vdSTR-M.

In short, yes, these two are borderline usable together and therefore a mandatory pecking order is necessary. -- Tuválkin ✉ 18:27, 29 October 2013 (UTC)

1. More can be found at Category:Icons for railway descriptions/half width/parallel lines. Personally, I incline slightly more for "dv".
   Added 00:23, 6 November 2013 (UTC): Omh, we forgot about the army of "bv" icons; so it's certainly "bv" & "dv".
2.  (STR-LR) =>   (dSTR-LR). YLSS (talk) 19:00, 29 October 2013 (UTC)

p

Some time ago I renamed (without any discussion, admittedly) phBHF to  (hpBHF) & uptBHF to  (utpBHF). I hope that did not and does not raise any questions... But at that moment I wasn't aware of the existence of   (pdHST),   (epdHST),   (xpdHST) &   (expdHST) (by Tuvalkin). Now Useddenim has uploaded  (dpHST) (with modern design). Which option is better? (Regardless of that,   (epdHST) &   (xpdHST) should be swapped.) YLSS (talk) 23:38, 25 September 2014 (UTC)

I think the “modern” design for optional halts is much better than the ones I had done, and that all uncorrect names should be fixed. No questions to be raised! :-) -- Tuválkin ✉ 00:53, 26 September 2014 (UTC)

Well, I didn't even question the design (we settled it), only the naming. And having thought more, I came to the conclusion that "p" is more like "k", and should be placed immediately before the root (cf.   (dkABZc1)). Also,  (dpBHF-R) & co. are already in existence. YLSS (talk) 15:30, 26 September 2014 (UTC)

HHST

I was thrilled to see the "H" prefix alive & kicking. Fortunately, these are nearly unused and can be easily moved - I just don't know the target title (no change in light of new naming schemes?):  (uHHSTr),  (uHHSTl),  (uexHHSTr),  (uexHHSTl),  (HHSTr),  (HHSTl). YLSS (talk) 19:50, 30 May 2013 (UTC)

Please tell me it stands for "Half", not for "Horizontal", please? -- Tuválkin ✉ 21:27, 30 May 2013 (UTC)

Actually, I think it was the deprecated (and unappreciated) Horizontal prefix root modifier. Useddenim (talk) 22:55, 31 May 2013 (UTC)

I know, that’s why I’m asking. -- Tuválkin ✉ 17:26, 6 June 2013 (UTC)

Well, there are  (HSTu),  (HSTd) etc. Urgh, "d" & "u" ... YLSS (talk) 21:43, 30 May 2013 (UTC)

 (BHFr) &  (BHFl) should be taken care of at the same time. Useddenim (talk) 13:05, 31 May 2013 (UTC)

Also taking into account that there are   (uBHFl legende),   (BHFr legende),   (vBHFl) (the last one should be  (vBHF-R) I guess). YLSS (talk) 13:38, 31 May 2013 (UTC)

Similar looks

Moved to Talk:BSicon/Roads#Similar looks

Crossing+junction

These icons have a problem with the names, as there are (at least) three lines to be flagged for usage status, and thus the —/e/x/ex system breaks apart. Nothing that wasn’t already covered in the k-series, but needs to be implemented in this set too. -- Tuválkin ✉ 14:50, 13 June 2013 (UTC)

rmSTRrg

Could someone please rename   (rmSTRrg) to   (rmABZrg)? Thanks. User:Deonyi 13:12, 1 August 2013 (UTC)

Honestly, I've never managed to grasp the philosophy of "m" (and it is being currently discussed, moreover), but since the main (straight) line is not restricted here, shouldn't it rather be *  (umrABZrg)? And how should we call the potentially possible File:BSicon rSTRrg.svg ? YLSS (talk) 15:24, 1 August 2013 (UTC)

I’m still not convinced about these icons at all, but if the main line is normal and the secondary is special, then the special letter should come after the root ID, as in  (tTBHF) vs.  (TBHFt). Additionally that’s also why "r" is a bad choice: it should be a letter that has no established meaning as a suffix — maybe "p" makes sense, as in  (pBHF)?. (Granted that pBHF would only match as , but these two notations for limited service seems to be disjunct.)

As for "m" for mixed, complex as it is already, I think should be reserved for color mixing — after all we don’t use "m" in icons such as  (TBHFt); cp.  (mTBHFt).

-- Tuválkin ✉ 02:30, 15 October 2013 (UTC)

File:BSicon_uvxBHF-STR.svg

So we have a light rail version named File:BSicon_uvxBHF-STR.svg, but heavy rail at File:BSicon_vexBHF-STR.svg. The latter was moved from File:BSicon_vxBHF-STR.svg in 2010, but this seems to be at odds with File:BSicon vxHST-eHST.svg, File:BSicon vxBHF-DST.svg, and File:BSicon vxINT-INT.svg, where the "x" prefix was used. So are all these vx icons improperly named, or was vexBHF-STR improperly moved? Either way, I think we need a rationale #6 move request. Vanisaac (talk) 23:30, 12 August 2013 (UTC)

Moved. All of these should have been …vex… not …vx… Useddenim (talk) 23:47, 12 August 2013 (UTC)

A well-timed answer. I also moved  (vACC-exSTR) &  (vHSTACC-exSTR) from titles with plain "x". YLSS (talk) 18:05, 13 August 2013 (UTC)

Those names were based on   (vDST-xSTR),   (veDST-xSTR),   (veHST-xSTR) and   (vHST-xSTR), and we've also got   (vxDST-BHF),   (vuDST-xDST),   (vDST-xBHF),   (vDST-xDST),  (vBHF-xBHF),   (veHST-xHST),   (vSTR-xDST),   (vSTR-xHST), and   (vBHF-xDST), so I think we might have a couple more moves. Vanisaac (talk) 23:13, 13 August 2013 (UTC)

Narrow lines

"SID" BSicons

moved from User talk:Axpde/Archive 2

Well, then ... Seuil d'originalité! And please answer there, where I started! axpdeHello! 11:36, 22 November 2010 (UTC)

I accept !

The files :

• BSicon SIDlf.svg
• BSicon SIDlg.svg
• BSicon SIDrf.svg
• BSicon SIDrg.svg

as been deleted (in use in several pages about railways). Could you undelete them ? If not I have to create them again.
Regards - --Phyls (talk) 13:37, 22 November 2010 (UTC)

(File:BSicon SIDlf.svg), (File:BSicon SIDlg.svg), (File:BSicon SIDrf.svg) and (File:BSicon SIDrg.svg) still exist ... at the moment. They're about to be deleted, because there's too little difference compared with (File:BSicon ABZlf.svg) and alike. See en:Accessibility or fr:Accessibilité! axp_de^Hello! 08:22, 23 November 2010 (UTC)

I am opposed to the deletion of BSicon:SIDlf and alike. Theses icons have not the same signification that BSicon ABZlf and alike. They are usually used for industrial railways.
I mispelled the files deleted :

• BSicon STRlf SID.svg
• BSicon STRlg SID.svg
• BSicon STRrf SID.svg
• BSicon STRrg SID.svg

These files are to be undeleted.

Regards - --Phyls (talk) 10:47, 23 November 2010 (UTC)

I agree, there's too little difference. I think they should be deleted. Wiebevl (talk) 13:52, 23 November 2010 (UTC)

Disagree. Although I don't use them myself, they are noticeably different. Using another colour for industrial tramways or secondary lines or whatever would actually give them more emphasis. Useddenim (talk) 23:27, 24 November 2010 (UTC)

Siding icons

A set of icons were just uploaded today with narrow line, clearly intended for sidings:

•   (exKBSTr-C)
•   (exKBSTl-C)
•  (exKBSTa-C)
•  (exKBSTe-C)
•   (KBSTl-C)
• {{bs-q|KBSTr.-C}} replaced with   (KBSTr-C)
•  (KBSTe-C)
•  (KBSTa-C)
•   (STRrf-C)
•   (STRrg-C)
•   (STRlf-C)
•   (STRlg-C)
•   (exSTRrf-C)
•   (exSTRrg-C)
•   (exSTRlf-C)
•   (exSTRlg-C)

•  (exSTR-C)
•  (exSTRq-C)
•  (eABZrg-C)
•  (eABZrf-C)
•  (eABZlg-C)
•  (eABZlf-C)

They joined two narrow straight-line icons that already existed:

•  (STR-C)
•  (STRq-C)

Four of them are e- forms of the SID root icons:  (SIDrf) etc. and I am tagging them for rename. The station and curve ones are more problematic. How do people feel about a s- lowercase prefix that would fall at the same place as v-? (we should split v/s away from b/d/c: v- and s- refer to the "amount" of track on the icon, not its width as such, and we could very well have all four width in siding, and b- in double track). Introducing s- also means the SID root could be done away and become ABZsr the same way we use -x (sABZr would be main line turning to right, siding continues forward). Circeus (talk) 20:11, 19 September 2011 (UTC)

Here are a few more (for parallel lines, no less!):
  (vKBSTl-exKBSTl)
 (vABZgrC+rC-STR)
 (vABZxgrC+r-STR)
 (vABZCg+r-STR). Useddenim (talk) 21:09, 19 September 2011 (UTC)

1. "SID" is a very poor root ID!
2. "eSID" icons have already been deleted, they were unused and only causing problems!
3. Could anyone please tell me for what reason ever we need another nearly identical set of icons?

a×p_de^Hello! 21:06, 21 September 2011 (UTC)

1. I have GLA (GLeisAnschluss) set aside for them in my scheme. If you have a better idea...
2. The base root have quite the significant usage on de:, fr: and cs:. Define the "problems" that e- roots are supposed to cause?
3. They are no more "nearly identical" to their full-thickness counterparts than the t- or L- forms (which is why I suggested a s- prefix.). I was in the impression that policy was to NOT delete willy-nilly unused icons that had definite potential for usage? We do have entire sets that are nearly unused, and these have far more potential!

Not to mention we should be wary of rejecting an entire icon set who in basic for is already seeing broad use just because we disagree with the Wikipedia project that originated them on their usefulness! Commons is for file management, not decision on how the icons ought to actually be used on Wikipedias. If you have issues, take it to the French, German and Czech users who thought that the distinction was useful! Circeus (talk) 23:40, 21 September 2011 (UTC)

Just noticed some canal icons that design-wise belong to the same set:

•  (ueFEEDER) →   (uexsSTR)
•  (ueFEEDERq) →   (uexsSTRq)
•  (uexFEEDrf) →  (uexsSTRr)
•  (uexFEEDlg) →  (uexsSTR+r)
•  (uexFEEDlf) →  (uexsSTRl)
•  (uexFEEDrg) →  (uexsSTR+l)

Useddenim (talk) 05:00, 8 November 2011 (UTC)

I gathered them all under Category:Icons_for_railway_descriptions/experimental/sidings. -- Tuválkin ✉ 04:53, 2 December 2011 (UTC)

BL

I would suggest renaming the Black Line icons to bring them in line (sorry for the pun) with (most of) the rest of the icon groups:

•   (BLg) →  (BLa)
•  (BL) no change
•   (BLf) →  (BLe)
•  (BLr) →  (BLl)
•  (BLq) no change
•  (BLl) →  (BLr)

•   (BLlf) →  (BLl+g)
•   (BLrg) →  (BLf+l)
•   (BLlg) →  (BLf+r)
•   (BLrf) →  (BLr+g)
•   (BL2rg) →  (BL1)
•   (BL2lf) →  (BL2)
•   (BL2rf) →  (BL3)
•   (BL2lg) →  (BL4)

Useddenim (talk) 23:33, 12 October 2013 (UTC)

(Not that I care much about these icons...)   (BLlf) etc. are IMO more intuitive than   (BLl) etc. Possibly also  (BLeq) etc.? YLSS (talk) 07:37, 13 October 2013 (UTC)

  (BLlf) should be a black version of  (uFEEDlf) etc. Useddenim (talk) 12:11, 13 October 2013 (UTC)

I have nothing against the proposed renaming and I have no strong opinions about the exact suffixes to be used, but I suggest that we take this opportunity to rename the root ID "BL" into somtheing more distinctive, preferably with 3 letters and not starting with a "B". -- Tuválkin ✉ 14:14, 13 October 2013 (UTC)

OK, but we already have  (BL),  (STR-C) and  (ueFEEDER) (plus the aforementioned  (uFEEDlf)). Useddenim (talk) 11:19, 14 October 2013 (UTC)

Well noticed, there’s indeed a common thread here. A new root ID to bag all these is trivial, such as THIN, the problem is how to deal with mixed width icons, such as   (eSIDlf): separate root IDs, or a single one with an affixed modifier? -- Tuválkin ✉ 16:43, 14 October 2013 (UTC)

n (lower case) prefix (for narrow)? used in the same manner as the t prefix/suffix. So we then have:

•   (BLg) →   (nKSTRa black)
•  (BL) →   (nSTR black)
•   (BLf) →   (nKSTRe black)
   
•  (BLr) →   (nKSTRl black)
•  (BLq) →   (nSTRq black)
•  (BLl) →   (nKSTRr black)
   
•   (BLlf) →   (nSTRl+g black)
•   (BLrg) →   (nSTRf+l black)
•   (BLrf) →   (nSTRr+g black)
•   (BLlg) →   (nSTRf+r black)
•   (BL2rg) →   (nSTR1 black)
•   (BL2lf) →   (nSTR2 black)
•   (BL2rf) →   (nSTR3 black)
•   (BL2lg) →   (nSTR4 black)

•   (STR-C) →  (nSTR)
•   (STRq-C) →  (nSTRq)
•   (STRlf-C) →   (nSTRlf)
•   (STRrg-C) →   (nSTRrg)
•   (STRrf-C) →   (nSTRrf)
•   (STRlg-C) →   (nSTRlg)
•   (KBSTa-C) →  (nKBSTa)
•   (KBSTe-C) →  (nKBSTe)
•   (KBSTl-C) →   (nKBSTl)
•   (KBSTr-C) →   (nKBSTr)
  
•   (SIDlf) →   (ABZln)
•   (SIDrg) →   (ABZ+ln)
•   (SIDrf) →   (ABZrn)
•   (SIDlg) →   (ABZ+rn)
  (nABZ would have the main line turning both lines narrow)
•   (vABZgrC+rC-STR) →   (vABZgrn+rn-STR)
•   (vABZxgrC+r-STR) →   (vABZgrn+xrn-STR)
•   (vABZCg+r-STR) →   (vABZg+rn-STR)
   
   

•   (ueFEEDER) →  (uexnSTR)
•   (ueFEEDERl) →  (uexnSTR-R)
•   (ueFEEDERr) →  (uexnSTR-L)
•   (ueFEEDERq) →  (uexnSTRq)
•   (uexFEEDERl) →   (uexnKSTRl)
•   (uexFEEDERr) →   (uexnKSTRr)
•  (WFEEDERqlg) →   (KSTRlg water)*
•  (WFEEDERqrg) →   (KSTRrg water)*
•   (uFEEDlf) →  (unSTRlf)
•   (uFEEDrg) →  (unSTRrg)
•   (uFEEDrf) →  (unSTRrf)
•   (uFEEDlg) →  (unSTRlg)
•   (uFEEDERd) →   (ueTEEan)
•   (uFEEDERu) →   (ueTEEen)
•   (uFEEDERr) →   (ueTEEln)
•   (uFEEDERl) →   (ueTEErn)
  (as  (fTEEa) etc.)
  * yes, I know we don’t have a “set water”, but how else would you describe it: set 007cc3?

As a bonus, this would also (finally) rationalize the canal feeder names. Useddenim (talk) 00:48, 15 October 2013 (UTC)

This seems to be the best take on the matter. I’d say go ahead. (Though I still think that using "_color" instead of "(color)" is a Very Bad Idea.) -- Tuválkin ✉ 02:05, 15 October 2013 (UTC)

+1 on using the "n" prefix/suffix. Just a couple of points:

1. While I agree that BLs show the same geometry as sidings and feeders, and endorse moving them to the proposed titles, I think that redirects from "BL" titles (or some others) should remain in place, categorised under walkways. Just because semantically these are not lines, and when used in RDTs for transfers should be called differently.
2. If we start using "STRa" for things like  , does that imply that "STRa" for splits is finally deprecated in favour of "SPLa" etc.? I hope that "STRa" construction isn't used (or possible) for anything else? I really like "STRa" for  . Also, I suggest  (BLr) →   (nSTRaq black): there would be far lesser chance of conflict with other uses of "l"/"r", which are manifold...
3. "nABZ would have the main line turning": what do you mean? How about:   (ABZgln), File:BSicon STR-C.svg   (ABZgnl), File:BSicon STRlf-C.svgFile:BSicon STR-C.svg   (nABZgl). Yes, I'm a proponent of Axpde's ABZgl instead of ABZl.
4. If we start using the standard nomenclature for all these, then   (nSTRf+r black) will pave way for a new class of non-thin tracks. Is there a full-width icon equivalencing ? Something among Tuválkin's experiments?
5.  (WFEEDERqlg) →   (WSTR-Raq) &  (WFEEDERqrg) →   (WSTR-Req)? ^{Edit: these are 40px-wide, ca. half of 75px-wide WASSER, so no "n" prefix.} Or should they be WASSER-wavy? Just re-upload?
6. Last but not least: prefix order! "used in the same manner as the t prefix/suffix": before or after "t"? Dashed 50px-wide line without a transparent middle, why not?
7. Aargh! Added: Only now I noticed that while sidings (STR-Cs & SIDs) are 50px wide, both BLs and FEEDERs are 40px wide! Personally, I think it would be too much to keep both variations as distinct classes. And since ultimately we deal with 20px icons (= 500px * 1/25), maybe BLs and FEEDERs should be thickened up to 50px (* 1/25 = 2px) ?

-- YLSS (talk) 15:28, 15 October 2013 (UTC)

1. OK.

2. a. I hope so.

   b. How could l/r be used in any other way for a plain line ?

3. D'oh!
4. Don’t know.
5. These were created by DePiep (along with many other oddball single-use icons) for his wild and wonderful Panama Canal map. I normalized the name as best I could.
6. Sure, why not?
7. Definitely.

Useddenim (talk) 00:43, 16 October 2013 (UTC)

2b. E.g.  (CONTl) vs.  (ENDEl). I really don't know how those people who think that some icons continue to the right and others are to right, would treat these stubs. "eq" & "aq" are really just more... safe?

3. Erm... Did you use that for disagreement, frustration or concurring ? ;)

6. So... before or after "t"? And other prefixes? And in case of a crossing with a thin tunnel line across? Wow, we've got a new question: suffix order!!!

YLSS (talk) 10:39, 16 October 2013 (UTC)

3. Concurring—and aggravation at myself for missing the correct version of nABZ!

6. ntICONtn: because t is included as part of the {{BS-anleitung}} cataloguing templates.

Useddenim (talk) 12:17, 16 October 2013 (UTC)

2a. Ouch! We do already use "STRa" construction in e.g.  (tSTR2a). So we have a collision here. Although I must admit that I never liked that application of "a"/"e" suffixes. Tuválkin has recently uploaded icons with TNL root (  (uexvTNLa); was that agreed upon somewhere?), so I would favour moving all such to  (TNL2a) etc. YLSS (talk) 19:28, 16 October 2013 (UTC)

2b. And we do use "l"/"r" with STR!  (STRl),  (tSTRr) and so on, and so on...

2C. Alternative proposal: Call them KSTR !   (BLg) →   (nKSTRa black) etc. I wouldn't even mind having   as "KSTRl" then, mirroring  (KBHFl). (Not really necessary, but is "Kopfstrecke" meaningful in German?)

6. But that would mean tnICONnt, right?.. YLSS (talk) 18:28, 16 October 2013 (UTC)

2. Yup; you’re right. And KSTR is a perfect solution to the l/r/qa/qe conundrum. As far as language goes, who cares? BSicons are already a bastardized mish-mash of German, English and who knows what else? (There’s at least two ikons with Polish root bases.)

6. Yeah, <sigh>. That’s what I get for editing on the fly. Linguistically I prefer ntICONtn, but the templates would would better with tnICONnt (unless I create even more of them…).

Useddenim (talk) 01:36, 17 October 2013 (UTC)

2. Let's celebrate it!  (uextvKSTRe-) &   (uextKSTRl-)!

3. And the last question, I hope: in  (ABZgxr+r), we prepend the "x" suffix-modifier; in  (STR2h+4), we append the "h" suffix-modifier. Since the "n" suffix-modifier will be able to affect nor only corners, but also the "g" and "q" tracks, maybe it should be prepended like "x"? That is,   (ABZgnl) etc. YLSS (talk) 18:35, 17 October 2013 (UTC)

7a. OMG... It seems the tees also need "g":   (gJCTtnl) (→ * (gTEEtgnl)?), because as it is presently named, the branch should be in tunnel... I hoped to escape this. YLSS (talk) 15:11, 19 October 2013 (UTC)

7b. And most regretfully, I noticed only now that while f-versions of these icons use JCT:  (fJCTa) (introduced by footpath people), similar icons in sets "u" & "bahn" were renamed by you, Useddenim, from KRZsmth into  (TEEl),  (uTEEr) etc.; while the JCT root has already been used, also by you, for  (utvJCTgo+l) and others. Maybe it's not too late?.. YLSS (talk) 15:29, 19 October 2013 (UTC)

Nah, it’s never too late…  (TEEa) et al. is the better name for these, with JCT reserved for miscellaneous junctions that don’t match any other configuration. Useddenim (talk) 20:54, 19 October 2013 (UTC)

7a. Thinking more of it... Possibly we can escape "g" for TEEs: the suffix in this case determines the icon unambiguously, in contrast to ABZs. If we take Useddenim's   (gTEEtnl), then a version with a tunnel branch will have "t" after "l"... Of course, all this would break if somebody created  .

  (TEE1) (one). Useddenim (talk) 12:18, 21 October 2013 (UTC)

I meant that anything not exactly "T" in shape would pave way for more complicated junctions that would require "g" & "q". YLSS (talk) 12:23, 21 October 2013 (UTC)

7b. Great, I've renamed "f"-versions to accordingly to  (fTEEa) etc. YLSS (talk) 10:13, 21 October 2013 (UTC)

I really do not get this change... So what is "n": a prefix or a root modifier? Where should it be placed: after "t" (as written above), before "t" (together with "ex"), or adjacent to root? YLSS (talk) 10:13, 21 October 2013 (UTC)

Well, as it turns out, n- happens to share with x- the ability of being usable as a suffix. The problem is really that it's hard to describe in a short expression what links these 4 prefixes. I've edited the table to note that it's 0 or more of them, two, not one or more. Circeus (talk) 21:07, 19 January 2014 (UTC)

vSTR

Moved from User talk:Useddenim

I suppose  (vSTRff) ->  (vSTRf) &  (vSTRgg) ->  (vSTRg) necessitates  (vSTRfg) ->   (vSTRf-STRg) &  (vSTRgf) ->   (vSTRg-STRf). YLSS (talk) 18:56, 27 October 2013 (UTC)

Unless we want to create a shorthand version   (vSTRf-g) and   (vSTRg-f). What do you think? Useddenim (talk) 20:41, 27 October 2013 (UTC)

That may confuse. I've seen icons where "common" suffix is placed after the "-" separating two roots, just like "ex" is placed before "v" (don't remember which ones). Less shorthands, they only complicate things... YLSS (talk) 22:19, 27 October 2013 (UTC)

I agree that shorthands are a bad idea. -- Tuválkin ✉ 17:53, 29 October 2013 (UTC)

But what’s so wrong about "ff", "gg", "fg", and "gf"? -- Tuválkin ✉ 17:53, 29 October 2013 (UTC)

I would have left them as they were, but that was Useddenim's decision, and I'm not against it. "ff" could quite possibly mean "direction forward, shifted forward", as he implemented in the current  (vSTRff), which is quite plausible in view of the discussion above. All that confusion is due do multiple meanings of the same prefixes and suffixes. Maybe we should invent some new way of designating direction?  (STRl) is especially bad. YLSS (talk) 18:42, 29 October 2013 (UTC)

Thanks for the explanation about ff — a very well made point, I understand now. As for your (rhethorical?) question, I think it is not realistic adopting any whole new way at this point, I think — unless tested in a separate sector of the set (like I tried to do with the roads and had to give up). -- Tuválkin ✉ 11:43, 2 November 2013 (UTC)

And more on the evilness of "l" & "r" suffixes:  (STRl) &  (uSTRr) vs.  (hSTRl) &  (uhSTRr). At the very least, these should be renamed to  (STRfq) &  (uSTRgq) &  (hSTRgq) &  (uhSTRfq) respectively; but again, "f"/"g" have already been quite established for "shifted forward/backward", and although in case of STR there is nothing to shift, in case of more complicated icons some confusion may occur. YLSS (talk) 11:11, 2 November 2013 (UTC)

Well those four are even in disagreement with each other, the elevated version seems to have been swapped by mistake. I agree that there should be a "q" in there, and would like to draw your attention to Category talk:Icons for railway descriptions/arrow (albeit experimental). From there I would suggest things like

  (STRge) or   (STRgaq)… And similarly for "ga"/"gaq", "fe"/"feq", "fa"/"faq", and "ge"/"geq". -- Tuválkin ✉ 11:43, 2 November 2013 (UTC)

Well, at least I'll satisfy myself with renaming the "h" versions (but not today). We should then settle that "f"/"g" meaning "shifted for-/backward" are placed after "f"/"g" meaning "direction: for-/backward" (that is,   should be (STRgfq)), and also after "a" & "e" for "start" & "end" (as discussion above). BTW: purely coincidentally, I found this discussion. Axpde, 2010: "<...> I have general objections to theses icons [ (CONTl),  (STRl)] because of the inflationary use of the suffix 'l'. IMHO "STRl" should show this <...> Maybe we should introduce another new root as we did with "CONT" ...". I just seem to be parroting him now. YLSS (talk) 21:48, 2 November 2013 (UTC)

(Edit conflict)

Hmmm... Of course   (STRge) looks fine untill we start thinking of things like   (hSTRga) vs.   (hSTRage??)… All I can say is that these can be made with overlays, and maybe they can only be aptly named with two-root names matching that overlaying. -- Tuválkin ✉ 22:08, 2 November 2013 (UTC)

ÜW and BRÜCKE

I have been desperate to rename these roots long ago for the fact that diacritic alphabet is not a welcomed element in the file name, just as other non-English characters like Chinese. The issue gets uglier when I use my favorite XML editor "FirstObject" to save any file with the "Ü" in the file name, it will instead generate another file by replacing "Ü" with "U" automatically even in Windows 7. As for the actual usage in Wikimedia, just for your information, in Chinese Wikipedia the uppercase of Ü is missing from the special characters list of edit tool bar. I do know the trick of typing alt+220 for the alphabet, but I just can't remember it for a long time as it isn't used the other way in my daily life. The unnecessary copy-and-paste or search for input scheme just make this root so painfully cumbersome to use. So for these reasons I do suggest an actual renaming instead of just redirect. AFAIC, the current redirects to ÜW not only are incomplete, but also inconsistent, for example,  (tSTR2a) to   (ÜWtl). Do we replace "Ü" with "U" or "UE"? As some German insists the latter to be the more accurate transcription of voice. -- Sameboat - 同舟 (talk) 15:43, 20 January 2014 (UTC)

For simplicity, I would vote for “U” to replace “Ü”. Useddenim (talk) 16:38, 20 January 2014 (UTC)

A further thought: would   (ÜWc2) then become STRc2? Useddenim (talk) 16:52, 20 January 2014 (UTC)

I think everybody agrees in theory with your reasoning, but it would be quite tedious to implement this. Agree with STRc2. More suggestions needed:   (ÜWul),   (ÜWtl) (? tSTR2ac),  (ÜST) &  (vÜST),  (vÜWB) and others. WRT BRÜCKE: I have recently moved BRÜCKEa and similar to  (hSTRag) etc. (with supplement  (hSTRa) etc. uploaded); possibly we may rename  (BRÜCKE) →  (hSTRae), since this particular kind of bridge is alignable with elevated tracks;  (WBRÜCKE) →  (hKRZWae) (see #Fords above).  (BRÜCKE1) →  (BRIDGE)? or BRK for short?  (BRÜCKE2) → ? In any case, before proceeding with any of these, we should ping de.wp users. YLSS (talk) 17:26, 20 January 2014 (UTC)

•   (ÜWul) → STR2u
•  (tSTR2a) → tSTR2au
•  (ÜST) → PSLX (cf.  (PSL),  (PSLm)
•  (BRÜCKE1) → STRo – Useddenim (talk) 19:24, 20 January 2014 (UTC)
•  (vÜWB) → vSHI2X – Useddenim (talk) 20:25, 20 January 2014 (UTC)

• I would so rather to leave Ü/U/UE out altogether to avoid the argument of phonetic transcription, so Useddenim's proposal is a good workaround.
• I prefer BRK over BRIDGE to avoid English linguistic imperialism (unless someone wants to make a BRICK icon, just kidding). --Sameboat - 同舟 (talk) 03:11, 21 January 2014 (UTC)
  • ( (BRICK) Useddenim (talk) 12:58, 22 January 2014 (UTC))
    • (Gosh, and you're the second person who calls it that! We should definitely categorise it into Category:Bricks. YLSS (talk) 14:18, 22 January 2014 (UTC))
• hSTRae is acceptable, although I expect some opposition from other project participants.
• I'm not against STRc, just wondering if this would create a potential conflict with uncharted corner icons which would be more suitable with this ID.
• Right now KRZa is redirected to  (KRZhl), any rationale for this?--Sameboat - 同舟 (talk) 03:11, 21 January 2014 (UTC)

Although I'm all for a shortening of the BRÜCKE root, I believe that having a root that can cover those icons is generally useful, and it should be preserved as a separate family of icons. As much as I like the idea of reducing the number of roots as much as possible, we can't merge everything we can, because IMO that ultimately reduces our flexibility to accommodate new icons in the future: who can guarantee we won't ever want a contrast between  (hSTRa) and an hypothetical BRKa? I do, however, like the idea of  (BRÜCKE1) → STRo, as it melds very well with  (KRZo).

I'll voice the same concern as sameboat regarding STRc, but only as a need for a review to make sure there isn't aset of icons that will be accidentally left without a matching root.

Looking at this, though, I'm finding myself sad that the SHI icons are by default 4 character long (there was nothing wrong with SH1, was there?), since the result is this ugly long SHI2X root.Circeus (talk) 20:15, 23 January 2014 (UTC)

•   (ÜWul) → STR2u: if so, then   (xÜWul) → STR2xu,   (eÜWul) → exSTR2u,   (exÜWul) → exSTR2xu, on the model of  (exABZg2u) etc.
•  (ÜWu2) → STRc2o??  (ÜWt2) → lSTRc2o?
•   (ÜWorc2),   (ÜWol clu),   (exÜWol+c2). I would favour STR3+c2 etc.
• Useddenim, I suppose you meant   (ÜWtl) → tSTR2au?  (tSTR2a) no longer redirects to the former, I have uploaded a proper file (and I suppose we're happy with that name). But probably we should rename   (ÜWtl) in line with the previous case, apparently to tSTR2a+c2?
• No Ü, but related.   (STRuh2) → STR2uh,  (STR2uh+4) → STR2+4uh? Not STR2h, that's the same as  (BS2l).
• And there's the unresolved question of   (vÜWol) &   (v-ÜWol) &   (vÜWc1). I still favour vSTR2, vSTR2-L, vSTRc1.
•  (ÜST) → PSLX: I dislike that X. First of all, we have  (ÜSTl), and then there's  (eÜSTl), and we should not eschew the possibility of something like  (evÜSTlxr) in non-parallel version. Possibly  (ÜST) → PSLlr,  (eÜSTl) → PSLxl?
• Similarly with  (vÜWB) → vSHI2X. "X" does not allow enough flexibility. Possibly vSHI2lr, but I don't know... Without "v", SHI2lr should be reserved as a alias for  (BS2lr); but since   would be an overkill for an icon, possibly we can leave vSHI2lr for  (vÜWB). If so,  (evÜSTlxr) → evSHI2glxr;  (vÜWBr) → vSHI2rol?? ;  (vÜWBor+r) → vSHI2grol-?? And then there are  (evÜSTo+l) & co. ...
•  (BRÜCKE1) → STRo: I'm not against that, but take into account that we also have  (HSTo), and it shows a "long" bridge.
• KRZa: an old name, but KRZhl is no better (no "l"!). But that is another topic.
• On corners: currently, we have the following classes of corners:  (ÜWc2),  (kABZc2),   (LLÜWc2),  (vÜWc2),  (SHI1c2),  (SHI2c2),  (SHI3/4c2). Of these,  (ÜWc2) is the most basic. Not to say that STRc2 perfectly matches the simplicity of  (STR2).
• On bridges: no, I'm not saying that we should say goodbye to the concept of "long bridges". I intentionally did not label  (BRÜCKEa) as an obsolete redirect, on the contrary, I categorised  (hSTRag) into elevated lines, but the redirect into bridges. If there would be a need, the redirect could be overloaded with a different icon.
• On shifts: yes, yes, before I went ahead and introduced that root, I pondered for quite a long time myself whether it should be "SHI1" or "SH1" etc. But all the talk was about "SHI1" only (or "BS1"), and I did not have courage enough to drop that "I". But it's too late now. I don't think that it is worth doubling all the renaming and replacing that I've already done just for the sake of one letter. A narrow one, also.

-- YLSS (talk) 22:43, 23 January 2014 (UTC)

OMG. SHI4q set shares the bigger problem of this concern. I prefer the removal of the redundant "I" as well if this doesn't sadden the renaming admins/file movers XDDDDDD. -- Sameboat - 同舟 (talk) 23:11, 23 January 2014 (UTC)

Only if you get yourself filemover rights! YLSS (talk) 07:10, 24 January 2014 (UTC)

Well, I guess I'm the one who has to stamp down English linguistic imperialism, so here goes: No, please do not rename these by dropping the umlaut; those are not the same letter. Fortunately, the Germans actually already have a Basic Latin out for us, but instead of destroying the linguistic basis for the üw and brücke icon sets, it will instead reaffirm it. That solution is Ü -> UE, which is the origin of the umlaut (a small "e" written over a letter), and the sorting behaviour for umlaut vowels (ud < ü < uf). So all we need are redirects from BSicon UEW and BSicon BRUECKE file names. I can do an AWB run to make them if you want. Vanisaac (talk) 23:49, 20 January 2014 (UTC)

I am so sorry to all German speakers but say no thank you to redirect to Ü root. I couldn't be more clear about the problem of using diacritic glyph in the actual file name especially for icons that are so extensively used by users all over the world with little to no knowledge of German language. This also causes problem for users who want to create or modify image with the Ü glyph in the file name. It isn't about linguistic imperialism but practicality. If most non-German keyboards came with the key "Ü" it wouldn't be a problem at all, but it isn't in reality. However, I agree that we should preserve the Ü for the existing roots (ÜW/ÜST/BRÜCKE) as redirects to the new non-diacritic IDs for sorting. -- Sameboat - 同舟 (talk) 01:05, 21 January 2014 (UTC)

Even though I can type those easily with my French-Canadian keyboard, I'm very much with Sameboat. It might be imperialistic, but the root is so irredeemably unintuitive in any other language that this alone is a major argument for a renaming. If anything, the German Wikipedia can use the same trick as the French one, which has created a set of templates renaming most of the icons to localized names. Circeus (talk) 20:19, 23 January 2014 (UTC)

Vanisaac, there is certainly no "English linguistic imperialism" around here; don't forget that we are from all around the would. This is purely pragmatism and convenience. Same reasons why various < * & etc. get turned down.

I was under the impression that the aliasing system was virtually dead at fr.wp? I encounter the old "BS#" templates very rarely, and replace them with modern "BS#bis". YLSS (talk) 22:43, 23 January 2014 (UTC)

So... You may have noticed that I started renaming ÜWc2 →  (STRc2) and so on. Everything seems to be quite straightforward here, except one thing. I renamed eÜWor cru to STR3+xc2, as explained above. I thought about creating an additional redirect from  (eSTR3+c2), but that won't make any benefit, even for galleries, since e.g.  (exSTR+1+c4) would still fall out. Similarly xÜWur → STR3xu. YLSS (talk) 22:16, 26 February 2014 (UTC)

Isn’t   (STR3xu) equivalent to  (eSTR3u)? Useddenim (talk) 04:38, 27 February 2014 (UTC)

I thought about that, but what should be placed under  (exSTR3u): present   (exÜWur) or   (eÜWur)? Because there are quite appropriately named  (exABZg3u) &  (exABZg3xu), so "non-junction" versions would be  (exSTR3u) or  (exSTR3xu), right? YLSS (talk) 06:33, 27 February 2014 (UTC)

  (exÜWur). The ex prefix (should) indicate that everything is out of use, and as there are only two elements — & —in the icon, there is no need for disambiguation (as opposed to the three elements of  (exABZg3u): , & ). Obviously the rule breaks down for more complex icons ( (KRZlr+lr) etc.), but in this case I would subscribe to the KISS principle. Useddenim (talk) 12:04, 27 February 2014 (UTC)

Well, why not, in the end. What's with   (STR3+xc2)? YLSS (talk) 18:12, 28 February 2014 (UTC)

I dunno; not one of mine. Rename to  (eSTR3+c2)? Useddenim (talk) 17:34, 1 March 2014 (UTC)

Huh, I meant "Do you agree with my renaming it from eÜWor cru to   (STR3+xc2) and not to  (eSTR3+c2)?" Apparently not... Well, I don't see much harm if I rename it once again. YLSS (talk) 19:35, 1 March 2014 (UTC)

Oh, by all means get rid of those ghastly suffixes! Useddenim (talk) 00:06, 2 March 2014 (UTC)

FWIW, I also like  (eSTR3+c2) better than   (STR3+xc2). -- Tuválkin ✉ 01:14, 2 March 2014 (UTC)

 Done. (And no need for those smirks, suffixes provide a more flexible system than "-/e/x/ex". Better check the catalogue and please tell if you disagree with anything. YLSS (talk) 20:41, 4 March 2014 (UTC)

Begging your pardon, but “those ghastly suffixes” I was referring to were cro,cru, etc. Useddenim (talk) 02:26, 5 March 2014 (UTC)

And FWIW I also agree with   (ÜWc2) →  (STRc2). -- Tuválkin ✉ 02:11, 2 March 2014 (UTC)

Tuválkin, you should really provide your opinion more often... YLSS (talk) 20:41, 4 March 2014 (UTC)

I’ll try. ;-) -- Tuválkin ✉ 13:27, 5 March 2014 (UTC)