Talk:SAT (disambiguation)

Merge with sat?

I recommend that this page be merged with "sat". — Preceding unsigned comment added by 68.109.19.13 (talk) 00:26, 19 November 2004 (UTC)[reply]

False. This is an article about the various uses of SAT. SAT is an article about the test, which is the dominant meaning. 66.245.11.4 00:27, 19 November 2004 (UTC)[reply]

English SATs

I added SATs into the page, as this can help. I have also added it to Sats disambiguation page. — Preceding unsigned comment added by Caledones (talk • contribs) 16:01, 30 April 2007 (UTC)[reply]

File extension formatting

I'm bikeshedding, I know, but: I can't find anything that says not to mark a file extension with <code> tags, I think it makes sense, and there seems to be precedent. • I've checked WP:MOS, MOS:TEXT, and MOS:CLI, and all are silent on the topic of formatting file extensions, or the <code> tag in general. H:MARKUP mentions that a syntax highlighting extension is installed, but that's it. • I think it makes sense because file extensions are a type of code -- not a programming language, but they certainly codify information in a machine-friendly manner. • Finally, the file extension article uses <code> tags throughout for this, so I'm apparently not the only one who thinks this. • Respectfully submitted, —DragonHawk (talk|hist) 12:27, 12 May 2011 (UTC)[reply]

So there is no guidance to use special formatting for file extensions. And most publications do not use special formatting for file extensions. And you've not articulated a clear reason for using special formatting apart from I think it makes sense. The sensible conclusion is that there is no reason for using special formatting. That one article that is flagged as needing attention uses the formatting could be considered as a case of Other stuff exists and not necessarily something to emulate. The linked article does not use code markup for the file name extension. In the absence of any guidance to use special markup, there is really no good reason to use it. A file name extension is not code in any usual sense. older ≠ wiser 22:16, 12 May 2011 (UTC)[reply]

Thank you for your reply. I'll break this down point by point, in an effort to improve clarity.

No, there is no guidance to use <code> for file extensions, but we don't have to have a rule for everything. "Anything not compulsory is forbidden" is not the wiki way.
"most publications" is a handwave (citation needed/weasel words). I've seen plenty that apply special formatting to file names, and plenty that don't. I doubt either of us has reference to anything like a comprehensive survey. I sure don't.
File extension is not flagged as needing attention on anything other than additional citations, which has nothing to do with formatting style decisions.
WP:OSE argues "Other stuff exists" is a bad argument for inclusion/exclusion decisions only, and even explicitly endorses looking to articles for style matters.
Looking to more articles: A very cursory and unscientific survey of pages linked from List of file formats (alphabetical) find some articles use no special markup in their content, some use <code>, and some use <tt>. So little help there. But I found that Template:Infobox file format uses <code>, and a great many file format articles use that template. Does that count as convention by transclusion? :)
I certainly did articulate a reason: "file extensions are a type of code -- not a programming language, but they certainly codify information in a machine-friendly manner". You may not agree with my reasoning, but I did offer it. To expand: <code> seems to get used to wrap text which has a particular meaning to a computer. We wrap programming and markup languages in it. We wrap template node and names in it. Complete command lines get indented and monospaced and gray-backed (MOS:CLI), but inline fragments tend to get code tags. Some registry stuff gets it. So I see file extensions fitting that pattern: A file extension is not part of the name humans are assigning, but something the computer is doing for its internal purposes. File extensions are not human-friendly text; they're a code, a compact representation for something else. This is my reason for doing so. I obviously think it's a good one.

Respectfully submitted, —DragonHawk (talk|hist) 00:21, 13 May 2011 (UTC)[reply]

I doubt that we will agree on this. I simply disagree that file extensions are a type of code or that there is any good reason for using special markup. I'm well aware that other stuff exists is an essay about deletion practices. I was drawing an analogy with it. Simply because some article in need of attention (that it is tagged only for lacking citations is not really relevant -- the point is that the article is not something that can be easily relied upon as an exemplar for anything. You say that "Anything not compulsory is forbidden" is not the wiki way, but by the same token, style guides exist for a reason and the use of special markup is generally not something that is encouraged. older ≠ wiser 01:38, 13 May 2011 (UTC)[reply]

If that's your stance, I don't think we're going to make any progress here. I've tried to explain my reasoning, repeatedly articulating particular reasons; I don't feel I've been reciprocated there. But I don't care enough to make a bigger issue out of this. Have it your way. —DragonHawk (talk|hist) 18:57, 13 May 2011 (UTC)[reply]

As a disinterested bystander who happens to have this page on my watch list, I vote no coding. There's no reason to make the entry, font and page look different/weird. Normal font gives perfectly clear and readily understandable information to anyone reading, and this matches the format used in all other Wiki file entries. If it becomes an article, it's not going to be in code font, so it shouldn't be one now. Softlavender (talk) 05:33, 14 May 2011 (UTC)[reply]

"Sats disambiguation" listed at Redirects for discussion

An editor has asked for a discussion to address the redirect Sats disambiguation. Please participate in the redirect discussion if you wish to do so. DannyS712 (talk) 06:14, 2 January 2020 (UTC)[reply]