Help understanding a possible tone indicator from 2010...
October 2, 2024 6:19 PM Subscribe
I'm in the process of making private the many hundreds of Facebook posts I made in middle school (2008-2011). I've noticed that seventh-grade me added "\n" at the ends of certain sentences. It resembles a tone indicator (such as /s for sarcastic, /gen for genuine), but I can't remember or think of what it could mean! Does anyone here retain any knowledge of 2010s internet lingo that could shed light on this? Could it have something to do with line breaks? Maybe a waving emoticon? See examples of usage inside.
"Put too much chocolate syrup in her milk. XP A lesson is learned... \n"
"Tornado watch time.\n"
"I couldn't care less about Picture Day.\n"
"Loneliness, for me, is beautiful as well as horrible.\n"
"Awkward Friday!\n"
"Put too much chocolate syrup in her milk. XP A lesson is learned... \n"
"Tornado watch time.\n"
"I couldn't care less about Picture Day.\n"
"Loneliness, for me, is beautiful as well as horrible.\n"
"Awkward Friday!\n"
Is it a person raising their hand? the n is their head, and the slash is their arm
\n = 🙋
posted by nouvelle-personne at 6:27 PM on October 2 [1 favorite]
\n = 🙋
posted by nouvelle-personne at 6:27 PM on October 2 [1 favorite]
\n is a pretty standard way to denote a line break in a lot of programming languages, and I would not be at all surprised to learn that Facebook's automated process for archiving and de-archiving ancient posts had at some point encoded messages with trailing line breaks that way and then failed to undo that encoding on retrieval.
If you can find a message that has \n embedded inside it and you can see that it would make more sense to have a line break embedded there instead, that would be pretty good support for this guess.
posted by flabdablet at 6:30 PM on October 2 [47 favorites]
If you can find a message that has \n embedded inside it and you can see that it would make more sense to have a line break embedded there instead, that would be pretty good support for this guess.
posted by flabdablet at 6:30 PM on October 2 [47 favorites]
Seconding that it's probably a newline indicator, especially if you don't remember why you would have added it. Are you also seeing the occasional "&" or similar garbled text?
posted by fifthrider at 6:34 PM on October 2 [6 favorites]
posted by fifthrider at 6:34 PM on October 2 [6 favorites]
Mojibake … is the garbled or gibberish text that is the result of text being decoded using an unintended character encoding.
I.e. flabdablet has it. Do you really think you forgot something you used heavily? Or is it more likely FB is a lazy greedy clusterfuck.
posted by SaltySalticid at 6:35 PM on October 2 [5 favorites]
I.e. flabdablet has it. Do you really think you forgot something you used heavily? Or is it more likely FB is a lazy greedy clusterfuck.
posted by SaltySalticid at 6:35 PM on October 2 [5 favorites]
Response by poster: flabdablet: The line break explanation is interesting and plausible!... However, there are a few details that make me think it's more likely something else:
-All of the posts in question are only a single sentence or phrase, with \n at the end
-There are many similar one-sentence posts that don't have \n at the end
-There are other multi-line posts from the same period that are correctly formatted, and I haven't seen any other examples of garbled text
-I was quick to adopt (and drop!) texting styles in middle school... so it's possible that it's something I only tried out for a short while!
brook horse, nouvelle-personne: An exasperated emoticon would make sense! And I can definitely see a person raising their hand or waving.
posted by Lurch at 7:08 PM on October 2
-All of the posts in question are only a single sentence or phrase, with \n at the end
-There are many similar one-sentence posts that don't have \n at the end
-There are other multi-line posts from the same period that are correctly formatted, and I haven't seen any other examples of garbled text
-I was quick to adopt (and drop!) texting styles in middle school... so it's possible that it's something I only tried out for a short while!
brook horse, nouvelle-personne: An exasperated emoticon would make sense! And I can definitely see a person raising their hand or waving.
posted by Lurch at 7:08 PM on October 2
This is a newline symbol. Facebook exports text poorly.
All of the other suggestions are interesting, but not correct. The use of a symbol or symbols to indicate a newline preceeds computers.
posted by blob at 7:20 PM on October 2 [4 favorites]
All of the other suggestions are interesting, but not correct. The use of a symbol or symbols to indicate a newline preceeds computers.
posted by blob at 7:20 PM on October 2 [4 favorites]
Best answer: -All of the posts in question are only a single sentence or phrase, with \n at the end
-There are many similar one-sentence posts that don't have \n at the end
There are a lot of factors that influence whether text entered into a web form ends up with a trailing newline or not, so I wouldn't put much weight on that observation.
-There are other multi-line posts from the same period that are correctly formatted
Multi-line, or multi-paragraph? \n encodes the non-printing control character that denotes a forced line break rather than the soft kind that web browsers automatically insert between words when rendering paragraphs that are too long to display on a single line, such as this one.
I haven't seen any other examples of garbled text
Embedded newlines are not really a text encoding issue in the same way that e.g. UTF-8 vs ISO-8859-1 is, so absence of other kinds of garbling is also not definitive.
Where it makes sense to encode a hard newline occurring within a text as \n is when it becomes necessary to represent the whole of that text as part of a larger text stream within which an actual hard newline character is used as a record delimiter, such as an SQL database table dump.
It would be super easy for a database table reconstructed from such a dump to end up not having those \n sequences properly reconstituted into actual newlines, especially in the context of an organization with as little respect for user data as Facebook. FB has always cared much more for the integrity of what they can glean about you than that of the specific text they store on your behalf.
So you might be right; you might have been typing \n on your own keyboard for reasons now lost to non-middle-school you. But based on having seen a fair bit of non-Facebook database-stored text affected in exactly the same way, I still think it's overwhelmingly more likely that this is a side effect of some minor bug that existed on Facebook's side for some period of time during which the affected messages were shuttled between databases via backups of same.
posted by flabdablet at 8:01 PM on October 2 [13 favorites]
-There are many similar one-sentence posts that don't have \n at the end
There are a lot of factors that influence whether text entered into a web form ends up with a trailing newline or not, so I wouldn't put much weight on that observation.
-There are other multi-line posts from the same period that are correctly formatted
Multi-line, or multi-paragraph? \n encodes the non-printing control character that denotes a forced line break rather than the soft kind that web browsers automatically insert between words when rendering paragraphs that are too long to display on a single line, such as this one.
I haven't seen any other examples of garbled text
Embedded newlines are not really a text encoding issue in the same way that e.g. UTF-8 vs ISO-8859-1 is, so absence of other kinds of garbling is also not definitive.
Where it makes sense to encode a hard newline occurring within a text as \n is when it becomes necessary to represent the whole of that text as part of a larger text stream within which an actual hard newline character is used as a record delimiter, such as an SQL database table dump.
It would be super easy for a database table reconstructed from such a dump to end up not having those \n sequences properly reconstituted into actual newlines, especially in the context of an organization with as little respect for user data as Facebook. FB has always cared much more for the integrity of what they can glean about you than that of the specific text they store on your behalf.
So you might be right; you might have been typing \n on your own keyboard for reasons now lost to non-middle-school you. But based on having seen a fair bit of non-Facebook database-stored text affected in exactly the same way, I still think it's overwhelmingly more likely that this is a side effect of some minor bug that existed on Facebook's side for some period of time during which the affected messages were shuttled between databases via backups of same.
posted by flabdablet at 8:01 PM on October 2 [13 favorites]
Response by poster: flabdablet, thank you for the detailed explanation! Knowing that, I think I'll try to export my Facebook data ASAP... :P
posted by Lurch at 8:11 PM on October 2
posted by Lurch at 8:11 PM on October 2
Just to make things a little more complicated, Windows has historically used a pair of escaped characters, "\r\n" to indicate a new line. "\r" is carriage return, "\n" is linefeed. This is a throwback to the old teletype printers and even many early display terminals. In all the software updates since you were in middle school, it's possible that the "\r" was retained (to produce a new line) and the "\n" was left hanging.
posted by SPrintF at 8:42 PM on October 2 [2 favorites]
posted by SPrintF at 8:42 PM on October 2 [2 favorites]
To dig the rabbit hole a little deeper still, plain text is anything but.
ASCII (American Standard Code for Information Interchange) won the first round of the plain text encoding wars, and almost all of the text storage and interchange encodings in common use today wholly embed it as a subset. ASCII defines assorted control codes for specifying things to be done with text, as distinct from representations of text, many of which have been pressed into service for purposes never envisioned by ASCII's designers in weird and mutually incompatible ways. The Wikipedia article on ASCII has a decent rundown of these.
Probably the single most annoying of these incompatibilities is the extent to which a control function that was included in ASCII - a set of delimiter characters specifically intended to facilitate the structuring of text into logical items (aka units), units into records, records into groups, and groups into files - has been so comprehensively ignored in favour of assorted misapplications of printing control characters such as TAB, LF and CR or, worse still, conventions based on printable characters like CSV or HTML.
The trouble with relying on specially defined delimiter codings as in ASCII is that there are many occasions where it's useful to be able to package up a self-contained blob of arbitrary data whose meaning is completely opaque to the packaging process, the sole requirement of which is guaranteeing that the blob will be bit-for-bit identical when it comes out as when it went in. This requirement means that there must exist some reliable way of distinguishing data codings inside the blob from the delimiters that mark its boundaries.
Again, there are hordes of mutually incompatible ways to do that job. One very common one relies on so-called escape sequences, where some small and specific set of prefix characters marks the start of a secondary encoding for data within the blob that would otherwise be indistinguishable from delimiters. Any such secondary encoding must perforce include a way to encode in-blob occurrences of the prefix character(s) themselves.
The influential programming language C popularized the use of \ as an escape prefix, originally to allow arbitrary data to be represented within string literals in the source code of a C program. The same convention has since been widely applied in other contexts, including database backups. In particular, \n is the escaped encoding for a newline character (ASCII LF) and \\ is the escaped encoding for \ itself (i.e. an actual literal backslash).
Sometimes you'll encounter a blob within an outer blob that has itself been subjected to escape coding. In such a context, \\n represents a newline within the inner blob. And things get weirder still when using something like the the Perl-based rename program from inside a bash terminal session or DOS command window, where \ might get interpreted in any of several ways or not at all, depending which layer actually gets to it first.
Computing is a mess, and the more you study it, the worse the mess becomes.
posted by flabdablet at 11:42 PM on October 2 [8 favorites]
ASCII (American Standard Code for Information Interchange) won the first round of the plain text encoding wars, and almost all of the text storage and interchange encodings in common use today wholly embed it as a subset. ASCII defines assorted control codes for specifying things to be done with text, as distinct from representations of text, many of which have been pressed into service for purposes never envisioned by ASCII's designers in weird and mutually incompatible ways. The Wikipedia article on ASCII has a decent rundown of these.
Probably the single most annoying of these incompatibilities is the extent to which a control function that was included in ASCII - a set of delimiter characters specifically intended to facilitate the structuring of text into logical items (aka units), units into records, records into groups, and groups into files - has been so comprehensively ignored in favour of assorted misapplications of printing control characters such as TAB, LF and CR or, worse still, conventions based on printable characters like CSV or HTML.
The trouble with relying on specially defined delimiter codings as in ASCII is that there are many occasions where it's useful to be able to package up a self-contained blob of arbitrary data whose meaning is completely opaque to the packaging process, the sole requirement of which is guaranteeing that the blob will be bit-for-bit identical when it comes out as when it went in. This requirement means that there must exist some reliable way of distinguishing data codings inside the blob from the delimiters that mark its boundaries.
Again, there are hordes of mutually incompatible ways to do that job. One very common one relies on so-called escape sequences, where some small and specific set of prefix characters marks the start of a secondary encoding for data within the blob that would otherwise be indistinguishable from delimiters. Any such secondary encoding must perforce include a way to encode in-blob occurrences of the prefix character(s) themselves.
The influential programming language C popularized the use of \ as an escape prefix, originally to allow arbitrary data to be represented within string literals in the source code of a C program. The same convention has since been widely applied in other contexts, including database backups. In particular, \n is the escaped encoding for a newline character (ASCII LF) and \\ is the escaped encoding for \ itself (i.e. an actual literal backslash).
Sometimes you'll encounter a blob within an outer blob that has itself been subjected to escape coding. In such a context, \\n represents a newline within the inner blob. And things get weirder still when using something like the the Perl-based rename program from inside a bash terminal session or DOS command window, where \ might get interpreted in any of several ways or not at all, depending which layer actually gets to it first.
Computing is a mess, and the more you study it, the worse the mess becomes.
posted by flabdablet at 11:42 PM on October 2 [8 favorites]
I've stripped and downloaded a bunch of my data multiple times between 2009-2015 and yeah, it's what the other commenters are saying and is a bug.
posted by yueliang at 12:27 AM on October 3 [1 favorite]
posted by yueliang at 12:27 AM on October 3 [1 favorite]
Another argument in favor of the newline theory: tone indicators virtually always use a forward slash (/), probably because they were originally (metaphorically or conceptually) linked to HTML. As in, adding /s after a sentence is like adding a closing tag, indicating that the text following the indicator is no longer sarcastic.
Is it possible you just got the slash wrong, especially in 2011, and doubly so if you weren't familiar HTML or related markup languages at the time? Could be. But it's an error I'm not sure I've ever seen in the wild.
posted by pullayup at 4:47 AM on October 3 [3 favorites]
Is it possible you just got the slash wrong, especially in 2011, and doubly so if you weren't familiar HTML or related markup languages at the time? Could be. But it's an error I'm not sure I've ever seen in the wild.
posted by pullayup at 4:47 AM on October 3 [3 favorites]
Just to simplify flabdablet’s excellent response you probably occasionally just hit enter at the end of a post inserting an unnecessary (and generally unnoticed) new line at the end. This would explain its erratic nature.
Personally, as a dev, I normally remove all excess white space from the end of user form submissions but this to prevent it but this isn’t a standard practice since the excess space could have meaning.
posted by bitdamaged at 5:39 AM on October 3 [2 favorites]
Personally, as a dev, I normally remove all excess white space from the end of user form submissions but this to prevent it but this isn’t a standard practice since the excess space could have meaning.
posted by bitdamaged at 5:39 AM on October 3 [2 favorites]
I *think* I remember this convention and it's related numbering of a series of tweets or posts on the same topic. People use 1/9 etc to denote that a post is part of a series. The letter n is often used as a substitute for the total number of something so if you're starting a chain and you don't know how long it will it's 1/n, 2/n etc.
Just using /n indicates that this is one of many posts you have made or will make on the same topic because of how passionate you are about it, or how regularly the issue comes up.
posted by *becca* at 3:35 PM on October 3
Just using /n indicates that this is one of many posts you have made or will make on the same topic because of how passionate you are about it, or how regularly the issue comes up.
posted by *becca* at 3:35 PM on October 3
That might be relevant except that this is about \n and not /n (to be fair, a distinction that matters much more to computer programs and programmers than to anybody else). And while /n might plausibly be somewhat idiomatic among non-programmers, \n is a dirt common idiom in programming circles.
posted by flabdablet at 9:32 PM on October 3
posted by flabdablet at 9:32 PM on October 3
→
There are a couple of "seemed fair at the time" reasons that we don't use those control codes:
posted by scruss at 8:08 AM on October 4
a set of delimiter characters specifically intended to facilitate the structuring of text into logical items ... has been so comprehensively ignored
There are a couple of "seemed fair at the time" reasons that we don't use those control codes:
- They were added to ASCII without much previous industry uptake. Somewhere there's a quote from a member of the standard committee who said they'd hoped people would adopt them, but they never gave any guidance or legal requirement to use them, so no-one did.
- IBM's System/360 didn't use ASCII at the time, and their field/record separator codes were different.
posted by scruss at 8:08 AM on October 4
You are not logged in, either login or create an account to post comments
posted by brook horse at 6:25 PM on October 2