Page MenuHomePhabricator

VisualEditor: Automatically use "smart quotes" and convert other typing to more advance characters (as an option)
Open, LowestPublicFeature


From user suggestion, along the lines of how Microsoft Word works.

This would involve a number of language-specific substitutions (and probably some shared ones); for English, I believe it would at least involve:

  • If a user types the character string 'foo "bar', on the pressing of the 'b' it would convert the '"' character to a an “.
  • If a user types the '"' character whilst in a string that has an “ in it earlier, convert the character to an ”.
  • If a user types in ' - ', on the pressing of the space character after the hyphen, covert the hyphen to an &endash;.
  • If a user types in ' -- ', on the pressing of the space character after the second hyphen, covert the two hyphens into one &emdash;.

Worth considering as a nice to have; this would probably want to be both site-configurable (is it available at all; if yes, is it default-on), and user-configurable.

Version: unspecified
Severity: enhancement



Related Objects

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 22 2014, 1:04 AM
bzimport set Reference to bz38724.

Also ellipses (... -> …) and other auto-conversions, if this is done.

wmf.amgine3691 wrote:

And use bom. It's the right thing to do.

en.wp user Ruud Koot requests "--" be converted to endash and "---" to emdash, which is slightly different to comment 0.

For German, that would mean changing "" in „“, like it is being suggested at de.wp.

I actually can't promise that I'll implement this soon, so I'm unassigning myself; sorry. I'm still interested in this, and proper typography on the wikis in general :)

Anything going on? It's high time that typography is corrected automatically; I don't get how you can classify this as lowest priority!

We have several user scripts that do exactly what is requested here. Maybe take some ideas from them? The feature should be available for everyone and would prevent a lot of unnecessary typographical corrections.

VisualEditor now has a framework for implementing autocorrection (and more generally, doing things in response to specific text being typed). In VE we mostly use it to add wikitext-inspired shortcuts for certain features, e.g. opening the link dialog when typing [[, inserting a bullet list when typing * .

I know of one script that used it to implement autocorrection rules for German:

However, doing it for the 100+ supported MediaWiki languages would be a lot more work, and personally I'd be afraid that it would be really annoying if it was done wrong. Or even if it was correct, but against the style accepted by a given wiki's community: for example, English Wikipedia prefers to use straight quotation marks:

I don't think we want to take responsibility for writing and maintaining that at this time.

Hm, fair enough. Sounds a bit English-centered, but I get that the number of potentially supported/affected languages is a fact that should not be overlooked. I am indeed using Schnark’s tool and it works fine overall (except for single quotation marks, but even MS Word still can’t deal with those, so I guess there is no proper solution), also for other languages than German. As always with such tools, I just do believe that they would be most useful for new editors, and like this there is a only a small chance that they would find out about and start using it by themselves. That leaves us once again with lots of unnecessary corrections all over the articles. Furthermore, with every year that passes, the chance that some wikis might want to start “enforcing” proper typography is diminishing; I had a long discussion on itWP years ago about the issue and it was clear that without a generally available autocorrect function nobody would be willing to change the typography rules. I guess with autocorrect available from the beginning, even the (to say the least: debatable) MoS rule on enWP would not exist in this form.

Anyway, I get why we are at this point, but it’s very unsatisfying.

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:14 AM