David Flanagan [:djf] Assignee
	Description • 12 years ago

Bug 865484 implements a pretty robust auto correction engine, but no algorithm can get everything right all the time. In any given language (for any given dictionary), there are likely to certain common inputs that do not auto-correct they way that users (and vendors) expect and want.

This bug is to implement a per-language setting for custom corrections.  

In English, we'll probably want "teh" to correct to "the" instead of "Tehran", for example, and "ill" should correct to I'll instead of remaining "ill". Andreas suggests that "s" should correct to "a" also.

This bug is not about creating any kind of UX to allow the user to edit these custom corrections. That's out of scope for v1.1. The idea of using a setting is to make it easy for vendors to add custom corrections.  Without a mechanism like this, I expect we'll start seeing lots of bugs from vendors about certain corrections not working right in the language of their market.  My experience with the correction algorithm is that tuning it to make one desired correction tends to break other desired corrections, so some kind of custom list like this seem inevitable.

By storing these custom corrections in the settings db (instead of in the dictionary file) we enable third-party apps to edit the setting, and we have the option of adding UX in the future for users to enter their own custom corrections.

	David Flanagan [:djf] Assignee
	Comment 1 • 11 years ago

With further experience, I no longer think that this needs to block 797170 or 873934. It might be a nice feature to add in v1.2, but auto corrections seem robust enough that this is not needed for v1.1.

Leaving it open, but clearing the blocking flags.

	David Flanagan [:djf] Assignee
	Comment 2 • 10 years ago

This bug is probably completely obsolete now that someone is working on personal dictionaries.