wptexturize doesn't correctly translate doublequote in brackets

[Kafkaesqui]

When a doublequote directly follows an opening bracket (parenthesis, etc), the quote is incorrectly translated to the closing doublequote ncr (”). I've modified line 30 of functions-formatting.php to partially account for non-whitespace characters before the opening quote.

Patch to functions-formatting.php for wptexturize doublequote regexp fix.

Patch won't apply -- for one thing the filenames are different now.

Also, I'm not fluent in REGEX, so I'm not sure. Probably needs testing.

We need some examples of input text and output text (and desired output).

Example: ("ABC") should render as (“NRDC”), but in fact renders as (”ABC“) - precisely backwards. These types of expressions are often used in legal texts (and lots of other texts) to signify abbreviations that will be used throughout the text the first time they are encountered. The only example I can find at the moment is  here (search for "NRDC").

As far as I can see, ideal behavior for wptexturize would require that: (1) opening quotes (entities &#8220 or &#8216) never appear immediately before a closing bracket of any sort or whitespace of any sort; and (2) closing double quotes (entity &#8221) should never appear immediately after an opening bracket of any sort or whitespace of any sort.

The closing single quote (entity &#8217) is trickier, because there may be times when a parenthetical or other bracketed expression starts with a contracted year reference or a slang term ("cockney") beginning with an apostrophe (though these should be rare), and obviously any of those expressions will usually be preceded by whitespace.

The two rules above, though, should be top-level rules that trump all other smart-quote replacement rules, shouldn't they?

See also ticket #1258 for problems with quotes near whitespace.

Oops, that should read: Example: ("ABC") should render as (“ABC”), but in fact renders as (”ABC“) - precisely backwards.

I agree with thee17, so closing as wontfix for now.

Feel free to re-open if you have additional patches/information/suggestions/...

I'm reopening, as this bug still exists. The current behaviour is:

• ("test") converts to (”test”)
  • incorrect, should be (“test”)

• ('test') converts to (’test’)
  • incorrect, should be (‘test’)

• ('twas) converts to (’twas)
  • correct, cockney.

I've attached a patch against HEAD which fixes the two incorrect behaviours, and doesn't alter the third, correct, behaviour.

Fixed in [11813]