Talk:SR

Clean-up

This page was tagged for cu in July 2009; no reason was given. What do others think needs to be done here? Thanks, Boleyn3 (talk) 13:51, 9 July 2009 (UTC)

• I tagged it, rather than be distracted from Times vs. Sullivan, which then had a red-link to S.S. Seay, SR, apparently the result of someone copying without insight or curiosity from an all-caps rendering of the title of the legal case in which S. S. Seay, Sr. was a respondent.
  Thanks for drawing my attention back; besides other relevant edits, i've resolved to my satisfaction the relevant section of the accompanying Dab.
  In addition, i continue concerned about the general state of neglect that the Dab exhibits:
  1. While i often convert section headings to sectionless ones, i've done the reverse with this one: there are enuf headings that the user needs a ToC providing an overview of them.
  2. I've moved the obviously misplaced codes into their appropriate top-level sections.
  3. More generally, the operative principle is, paraphrasing Lenin, that the purpose of a Dab is to disambiguate. As to the first section:

     * Saudi riyal, the currency of Saudi Arabia.

     All the user needs is "Saudi", once, and the fact that it's a currency; the remaining 4 words are distraction and clutter that is insufficiently justified by aiding the few users who got "Arabia" from the context without either

     also getting "Saudi" or

     realizing that "Arabia" never means anything but "Saudi Arabia" in a current context -- which is the only kind of context where "Saudi riyal" could be what they are looking for.

     * Slovakia, aka Slovak Republic

     OK as is. (I'd prefer "Slovak Republic, a.k.a. Slovakia", but that may be my quirky minority view, and it's not worth discussing.)

     * Socialist Republic, as in "SR Serbia", "SR Croatia", etc.

     Socialist Republic is a Rdr to Socialist state. I'd probably recast as

     SR, "Socialist Republic", as part of the formal name of a socialist state

     * Suriname (ISO 3166-1 alpha-2 country code)

     Too much info. "Code for country Suriname"; however, the standard needs to be ID'd in the article Suriname, and isn't, so it's probably worse to fix the Dab w/o fixing the article, than to leave both unfixed.

     * San Rafael

     San Rafael is a Dab, but "San Rafael (disambiguation)" is IMO an illegitimate fix. If i had sufficient commitment to the accompanying Dab, i'd check to see whether the article San Rafael, California (the most likely meaning in English texts) states it is referred to as "SR", and if so, convert it to

     San Rafael, California

     and remark on the talk page that any other San Rafael verifiably called "SR" ("LA" and "KC" are used; "SF" e.g. is very rare) can be individually added, once that is documented in its corresponding article.

     IMO the crap level in the other sections is comparable, but the entries have few relevant common elements other than neglect and obliviousness, on the part of the non-neglecting editors, to the entries' purpose. And some of them require significant effort to fix.

--Jerzy•t 22:37, 9 July 2009 (UTC)

It appears that Sr partially duplicates information on this page. We should merge the articles, or link to Sr from SR. I have cleaned up Sr somewhat, but the duplication is not helpful to readers, i think. Comments? —fudoreaper (talk) 03:09, 12 July 2009 (UTC)

• The accompanying main-namespace page was a Dab for nearly 5 years, then converted to a Rdr to the Dab SR, which is how it stayed for about 18 months. I converted it back to the Dab, reasoning that SR is so huge that readers who type "Sr" rather than "SR" should logically not be burdened with all those entries that they explicitly didn't want.
  An arguably parallel example is Raid and RAID (altho the Dab Raid handles several acronym-cased terms before the various senses of "raid"): each links to the other (the article RAID has a HatNote Dab to the Dab page), so that the casing-explicit request for an article on an acronym takes you straight to the primary acronym's article (with an escape route via the HatNote) and the casing-explicit request for a word takes you to the equal-disambiguation page Raid (which includes acronyms as well as words, providing a less handy escape route). I still like Sr as it is, but i think the issue is worth a wider discussion, unless you know of where it has been thoroughly thrashed out already.
  I'd particularly like to see a medium-term issue discussed: The "Go" tool treats the inputs "Sr" and "sr" the same, but distinguishes "SR". I just tested "sR", which on reflection behaves as i should have expected (same as SR, thus echoing our fundamental principle that the case of the initial letter is non-significant: the two names refer to a single page). Especially now, when Usability Initiative beta-testing is taking change suggestions, this might be the time to consider a server tweak that could change the optimum approach to this Dab-consolidation question. The aspect of the Go and perhaps Search tools' behavior i've just referred to is related to, but not at all the same as the principle "two links that differing only as to the casing of the first character always link to the same page". In fact, part of that behavior seems (in contrast to links) to make a distinction between titles of existing and non-existing pages: i tried several keys like "RAiD" and "RAId" (presumably neither one a main-namespace page title), without finding one that went elsewhere than Raid. I infer that where an exact match as to letters but not as to case exists in Go/search pain input, an existing page that has all lower case after the first character is preferred over one with all upper case, even if its number of casing mismatches is the greater one.
  I consider it obvious that that behavior should remain the default, but this is a matter of the private user interface, and users could be permitted to change that behavior, for their input. Given that option, i would specify at least that my input of all lowercase is to leave the server free to apply its default, but mixed case (even if only the first character is upper) implies that i'm doing my best to get close to the actual casing (other than that of the initial character) of the page title: e.g., "sr" is in my mind an exact match for SR if Sr does not exist, and is an ambiguous request by me if they both do, but if they both exist, "Sr" is an explicit request for Sr rather than SR. The relevance of that tweak to our question is that if users are given the ability to choose to convey more info about what they are seeking, it increases the value of keeping separate pages with different casing.
  I'll probably raise this; are you interested in presenting a pro-merging PoV, beyond what you've already said?
  --Jerzy•t 07:32, 8 August 2009 (UTC)
  

Silicone Rubber?

Does anyone know for sure if SR is used as an abbreviation for silicone rubber? Friendlyliz (talk) 03:12, 25 September 2010 (UTC)