Template talk:R from railroad name with ampersand
 | Template:R from railroad name with ampersand is permanently protected from editing because it is a heavily used or highly visible template. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by consensus, editors may use {{edit extended-protected}} to notify an administrator, template editor or extended-confirmed editor to make the requested edit. Usually, any contributor may edit the template's documentation to add usage notes or categories.
Any contributor may edit the template's sandbox. This template does not have a testcases subpage. You can create the testcases subpage here. |
 | Redirect Template‑class | ||||||
| |||||||
Printability[edit]
To editor Fabartus: the printability or printworthiness of a redirect has nothing to do with whether or not it is a good search term. We tag redirects as "printworthy" if we want them to be included in a printed version of Wikipedia, and we tag them as "unprintworthy" if we don't want them included. Readers of a printed version who would search the index for, say, "Denver & Rio Grande" would easily find it under "Denver and Rio Grande", and that goes for all the railroad names. In researching this, I did happen across a redirect that should be printworthy because it is a former name, so I will alter this rcat to default to unprintworthy and allow for some redirects to be printworthy. Paine Ellsworth put'r there 04:47, 22 March 2017 (UTC)
- Unfortunately, printworthy also affects the search bar and whether search engines see the redirect pages. So I disagree with the software as implemented as doing a poor job. My search window should show both, and similarly, things tagged with {{R from US postal code}}; I'd much rather test '..., PA' than wait for a 'Tamanend, Penns... to evolve the list, or not. (Some like Stoddartsville are lost to history.) My tired old brain needs to do a lot of spell checking. Still Thanks, Paine Ellsworth. Haven't seen you around in ages! (My bad! ... and loss!) FrankB 05:41, 22 March 2017 (UTC)
- Hi and thank you, FrankB! At least we now account for those names that may be printworthy with this rcat. Not quite sure I understand how the printability affects searches. If that is so, then all redirects tagged with {{R from misspelling}}, {{R from incorrect name}}, etc., that are kept for the specific reason that they are good search terms must be misleading searchers, since they also default to unprintworthy. So how precisely does unprintworthiness adversely affect searches? Paine Ellsworth put'r there 05:57, 22 March 2017 (UTC)
- It's a list function and a 'my preference' thingy. Put 'Malden, P' in the search window, and the village shows the printable Malden, Pennsylvania, but not Malden, PA-a redirect with {{R from US postal code}}. Now for a short nondescript village like that, there is no big list of alternatives. But extend that to railroad names, where end words after long leading names such as Railway, Railroad, Rail Road, Railroad Company, Railway Company are all commonplace endings, and that ampersand and 'and' equivalence in such long names becomes ... annoying, at the least. Add in a popular corporate prefix, such as Pennsylvania or Lehigh, and the list becomes long and the desired title may be well into the character count before it can be seen. I submit, the '&' in corporate names, esp. Railroad names is far more likely to trigger the right part of the list than any 'and'. Most times I'm trying to check name syntax without following the link, just trying to edit in the correct link, so the printworthy behavior becomes... annoying. Kapish Paine Ellsworth!? OK, soul bared, Think it's getting to be beddy-bye time! // FrankB 07:25, 22 March 2017 (UTC)
- Sleep tight 'n comfy, FrankB. I need to think on it all. See if I can find why WP prefers the "ands" rather than the "&s". Paine Ellsworth put'r there 07:30, 22 March 2017 (UTC)
- It's a list function and a 'my preference' thingy. Put 'Malden, P' in the search window, and the village shows the printable Malden, Pennsylvania, but not Malden, PA-a redirect with {{R from US postal code}}. Now for a short nondescript village like that, there is no big list of alternatives. But extend that to railroad names, where end words after long leading names such as Railway, Railroad, Rail Road, Railroad Company, Railway Company are all commonplace endings, and that ampersand and 'and' equivalence in such long names becomes ... annoying, at the least. Add in a popular corporate prefix, such as Pennsylvania or Lehigh, and the list becomes long and the desired title may be well into the character count before it can be seen. I submit, the '&' in corporate names, esp. Railroad names is far more likely to trigger the right part of the list than any 'and'. Most times I'm trying to check name syntax without following the link, just trying to edit in the correct link, so the printworthy behavior becomes... annoying. Kapish Paine Ellsworth!? OK, soul bared, Think it's getting to be beddy-bye time! // FrankB 07:25, 22 March 2017 (UTC)
- Hi and thank you, FrankB! At least we now account for those names that may be printworthy with this rcat. Not quite sure I understand how the printability affects searches. If that is so, then all redirects tagged with {{R from misspelling}}, {{R from incorrect name}}, etc., that are kept for the specific reason that they are good search terms must be misleading searchers, since they also default to unprintworthy. So how precisely does unprintworthiness adversely affect searches? Paine Ellsworth put'r there 05:57, 22 March 2017 (UTC)
- To editor FrankB: I asked over at Wikipedia talk:Manual of Style#& type railroad names, because it seems to me that a clause in the style manual specifically tells us to use the ampersand in these railroad article titles. So for example, Denver & Rio Grande Western Railroad should be the article title and Denver and Rio Grande Western Railroad should be the unprintworthy redirect. Paine Ellsworth put'r there 15:44, 26 March 2017 (UTC)
- OoooohhhhhKkkkkaaaayyyyyy, Thanks Paine Ellsworth! Bit more attention than I'd figured on, but I sink my time into some silly time sinks here for scant reason as well... Can tell you stories bout maps developed and so forth. I think I recall that NAMCON myself, but the Railroad lists seem to be organized the other way, use the and forms. Bottom line, historically speaking, I suspect the '&' usage was often a function of the printing medium and need for space. Most typesetting techs didn't have variable spaced fonts. If it were a news headline, or in the body, it might get padded or shortened as needed, and so forth. According to an email I had with the Pennsylvania Dept of State making an inquiry about the official name for Lehigh Coal & Navigation Company, they filed legal papers over 166 years using both, and was apparently true for many a company. (Just caught up on me sleep for once, went in for a test, and the docs decided it needed to be a two day two partner, and put me up in a ER room for an extra 24 hrs. Thank the Lord, I took my Kindle! // FrankB 01:17, 28 March 2017 (UTC)
- I tested this in IE 11, FrankB, and have results for the "Malden, P" search term. I was unable to make "Malden, PA" appear on the Wikipedia search-field list at all. It didn't matter whether or not the redirect was tagged as unprintworthy, or printworthy, or when printworthiness was not tagged. The printworthiness also didn't affect Google searches, which didn't even show "Malden, Pennsylvania" on their list, as Wikipedia's search field does. So at this point I must breathe a sigh of relief, because if printworthiness had adversely affected the search list, then my entire philosophy about printworthiness would have been altered. In my estimate, the way this works is for the search term to be typed into the field in its entirety – in this case, "Malden, PA" should be used. When that is done, then "Malden, PA" is at the top of the search-field list, and when it is clicked, the redirect does its job and takes the searcher to "Malden, Pennsylvania", just as one would expect. Thank you for making that redirect, BTW, as it seems to be a great search term! And I hope you get better and better! Paine Ellsworth put'r there 01:44, 29 March 2017 (UTC)
- Should also note that the entire name isn't always needed. For example, the names with the ampersands often just need the title up to and including the "&", which will then show a top term on the list that will take searchers where they want to go, either directly or by redirect. Paine Ellsworth put'r there 03:50, 29 March 2017 (UTC)
- OoooohhhhhKkkkkaaaayyyyyy, Thanks Paine Ellsworth! Bit more attention than I'd figured on, but I sink my time into some silly time sinks here for scant reason as well... Can tell you stories bout maps developed and so forth. I think I recall that NAMCON myself, but the Railroad lists seem to be organized the other way, use the and forms. Bottom line, historically speaking, I suspect the '&' usage was often a function of the printing medium and need for space. Most typesetting techs didn't have variable spaced fonts. If it were a news headline, or in the body, it might get padded or shortened as needed, and so forth. According to an email I had with the Pennsylvania Dept of State making an inquiry about the official name for Lehigh Coal & Navigation Company, they filed legal papers over 166 years using both, and was apparently true for many a company. (Just caught up on me sleep for once, went in for a test, and the docs decided it needed to be a two day two partner, and put me up in a ER room for an extra 24 hrs. Thank the Lord, I took my Kindle! // FrankB 01:17, 28 March 2017 (UTC)
- To editor FrankB: I asked over at Wikipedia talk:Manual of Style#& type railroad names, because it seems to me that a clause in the style manual specifically tells us to use the ampersand in these railroad article titles. So for example, Denver & Rio Grande Western Railroad should be the article title and Denver and Rio Grande Western Railroad should be the unprintworthy redirect. Paine Ellsworth put'r there 15:44, 26 March 2017 (UTC)
@Paine Ellsworth: :OK, thanks for the due diligence. Perhaps there has been a system software change that altered my findings of way back (? 2008-2010 daze?). Thanks for the well wishes, I'm well enough, but had a minor coronary infarction in January, and some disparate symptoms seemed they might be another cardiac event early in the week. Hence a double-dip nuclear image stress test. At least I caught up on my sleep for once! // FrankB 00:50, 30 March 2017 (UTC)