Seen it in a few post but there doesn't seem to be a pattern

I haven't noticed it, but I'll look for it now

Would have to go back through the post I read.

Try "View" > Repair text encoding.
This is for Firefox. You may need to search your settings.

...I can't access any of the fixes suggested.

Seeing this post from you makes me think something else is up, tho.

All around the same time and different posters.

‘Peace President’ Breaks Record for Attacking the Most Countries

https://www.thedailybeast.com/peace-president-donald-trump-breaks-record-for-attacking-the-most-countries/

Oddly, the excerpted text no longer matches the text in the article.

Here is what I pulled out of the article that is similar:

"In the same period, though, he has ordered strikes against targets across no less than seven nations—Iran, Nigeria, Venezuela, Iraq, Somalia, Syria and Yemen—at a rate that has already outstripped the total sanctioned by Joe Biden throughout the Democratic president’s four years at the White House,"

https://www.thedailybeast.com/peace-president-donald-trump-breaks-record-for-attacking-the-most-countries/

Not seeing the issue anymore

Your curly quote will appear as the weird three characters in the window where you go to make edits, and will post that way if you re-post.

That page looks fine to me. Not a lot of help I know, but fyi. The characters around Peace President are unicode open and close quotes (3 bytes each).

The line in the DU post: �Peace president� breaks record for attacking the most countries

When I right click on the du page and go to view page source, I see : �Peace president� breaks record for attacking the most countries

When I go to the Daily Beast source and do view source page, I see this (in a very long line): "description":{"basic":""},"display_date":"2026-03-02T14:15:32.449Z","distributor":{"category":"staff","name":"thedailybeast","subcategory":""},"first_publish_date":"2026-03-02T14:15:32.449Z","geo":{},"headlines":{"basic":"‘Peace President’ Breaks Record for Attacking the

I've been having similar issues today, as well.

Or the computer language changed (less likely)

They're using Safari, and I'm on Firefox, and I had the same problem.

It's the editing and previewing processes (see my posts 17 and 18 below ) that create the character set issue.

when the user Edits (or Previews) their post.

�Here is a sentence encased in double quotes done on a PC in Word and pasted to DU�
�Here is a sentence encased in double quotes done on a PC in Word and pasted to DU�

If I post that directly without preview, the proper characters show. But if I preview first, when I get to the preview window, they're all four munged up with 3 characters that are NOT quotes.

I EDITED the above content just now, and now I'll paste the same two sentences in that I posted the first time:
“Here is a sentence encased in double quotes done on a PC in Word and pasted to DU”
‘Here is a sentence encased in double quotes done on a PC in Word and pasted to DU’

But because I posted directly and did not preview first, they posted correctly (that 2nd time).

It's the DU site that's doing this, and it is almost surely a Windows (ISO‑8859‑1 / Windows‑1252) vs UTF-8 character set issue.

... because that came up once before, quite a long time ago. But then it started to seem *maybe* more complicated than that.

In particular when data is pulled out of the DB and placed onto the DU form. When you're in "Preview" or "Edit" mode, what you're looking at (the text you're able to edit) has already made a round trip to the DB (your initial draft was saved to the DB IOW).

Now, that's also true when you just make a post and it shows up on the site (which is also reading posts from the database) but this a different sort of operation (using the web server) vs. pulling data out of the DB to enable editing (uses an app server typically, which is different software vs the web server).

The fact the problem only occurs when a post is edited by a user (but an UNEDITED post shows up fine on the forums) tells me the problem almost surely occurs when pulling data from the DB into the Editor. I'd expect something to the effect that the DB stores the data as UTF-8 (pretty sure DU is on mysql database, and some form of UTF-8 is default), the Web Server expects the same form of UTF-8, but the EDITOR expects a character set that's somehow different (could be a different UTF-8 version, of which there are a few, or maybe Windows).

They are sets that are LARGELY translatable seamlessly, but some characters (and smart quotes are notorious for this) don't translate perfectly, so we get these wrong characters show up in the Edit/Preview window, and then these 'wrong' characters save to the DB when the user updates, and then show up on the site as wrong.

it's nice to know it's something rational and technological, not unhappy demons or, worse, hostile mobile code. My browser is set to the "default" character set; I think I'm going to force it to UTF-8 for a while and see what happens.

In my experience, saying "it's Microsoft's fault" at the beginning of the process often saves time, so that was my first thought. Didn't they invent smart quotes ??

But it may be the case that Word was the first program (or at least the first really famous one) that automatically converted to them as you typed and sorta 'pairs them up' for you, such that the first one you type curves one way (an 'open' version, if you will), then the next one (in the same line) curves the other way (the 'closing' version). Like so: “Example”. I used the same key for both of those double-quotes, and Word converted them to an open/close pairing like that, that's where the "smart" part comes in.

I don't know that the browser's character set setting impacts this at all, I suspect the issue is already there before you actually see it rendered in your browser but I don't care enough to dig into it, nor know if I could even figure it out. If I was going to guess, it'd be a translation issue happening with the ODBC or JDBC database driver that connects the app server to the DB, which means basically at the exact point the data is pulled from the DB, before anything else happens to it downstream.