Update README.md

misc. copyedits

Author: SMcCandlish

README.md

@@ -255,9 +255,9 @@ If you were already using an old version prior to RH Topic Tags v3.0.2, then the
 - See `add-on-comma="false"` in `adm/style/topictags_blacklist.html`, `adm/style/topictags_whitelist.html`, `styles/all/template/event/posting_editor_subject_after.html`, ``, possibly in other places. May be possible to turn on ability of comma to serve same as Enter/Return in ending a tag, which is common/expected behavior, and makes sense since commas cannot be used in tags anyway.
 - There is a significant amount of code in here (e.g. in `service/tags_manager.php`) to support an option for case-sensitive tagging (or at least case-sensitive sorting and other display considerations regarding tagging; the full intent isn't clear yet). But there is no ACP option to enable such a thing, it's always defaulting to "false" or was even hard-coded that way in a few places (i.e. to be case-insensitive).
  - Case-sensitivity of actual tags would probably be undesirable for most use-cases (e.g. if someone created a "YouTube" tag and someone else wrotes it as "Youtube" or "youtube" or "YOUTUBE" you'd end up with redundant tags, and this is especially likely on a busy board with many topics and users). But a niche recipe site with tagging controlled by only a few editors, for example, might want to distinguish between Turkey the country and turkey the bird or between Chile the country and chile the pepper. So, having a way to enable this is a planned future upgrade.
-- In `service/tags_manager.php` there is a "Note: that $query needs to be at least 3 characters long", and code like `if (utf8_strlen($query) < 3)`; this may have to be changed entirely and properly support 2- and 1-character tags in every circumstance, though in testing so far they have been working fine anyway. Depends on exactly what circumstances this 3-char. constraint is being applied to. So far, it looks like this only affects `get_tag_suggestions()`.
-- Not an "issue", per se, but the original codebase seemed to be expecting 4 spaces per tab (in most cases, but was not entirely consistent in alignment). I've thus been using 4-per-tab for this project. It may look weird if you're set for 8-per-tab.
-- RH used v2.1.1 of ngTagsInput and then custom tweaked it to work around a bug, and this extension has continued with RH's "v2.1.1-1" for years. But ngTagsInput is now at v3.2.0 and apparently has the underlying issue fixed, so the code should be reworked to use that version probably. It's unclear at this point what (if anything) would break if v3.2.0 were just swapped in. Odds are that the syntax of how it is called would have to change in some way.
+- In `service/tags_manager.php` there is a "Note: that $query needs to be at least 3 characters long", and code like `if (utf8_strlen($query) < 3)`; this may have to be changed entirely to properly support 2- and 1-character tags in every circumstance, though in testing so far they have been working fine anyway. Depends on exactly what circumstances this 3-char. constraint is being applied to. So far, it looks like this only affects `get_tag_suggestions()`.
+- Not an "issue", per se, but the original codebase seemed to be expecting 4 spaces per tab (in most cases, but was not entirely consistent in alignment). I've thus been using 4-per-tab for this project. It may look weird if you're set for 8-per-tab. phpBB's coding standards require 4, anyway.
+- RH used v2.1.1 of ngTagsInput and then custom tweaked it to work around a bug, and this extension has continued with RH's "v2.1.1-1" for years. But ngTagsInput is now at v3.2.0 and apparently has the underlying issue fixed, so the code should be reworked to use that version probably (and phpBB's extension coding standards say to use current versions of third-party libraries like this anyway). It's unclear at this point what (if anything) would break if v3.2.0 were just swapped in. Odds are that the syntax of how it is called would have to change in some way.
 - Another third party has forked RH Topic Tags, and released a non-free (paid) tagging extension. I have not attenpted to use it directly, but have examined its documentation and screenshots. It is clear that A) I have fixed things and introduced features that developer has not; B) that dev has added features and constraints that I have not; and C) our visions of how a tagging extension should operate are very, very different. (There are also more trivial differences, like the shape of the displayed tags.) In summary, that dev's version appears to be aligned with a tagging model in which admins/mods apply a fixed set of tags to topics, then use drag-and-drop to priority-organize them on a per-topic basis, with tags not being otherwise sorted in such a display at all (probably just raw database order, i.e. creation date, by default). My version is geared for much more public tagging, applies alphanumeric sorting automatically, and has no concept of tags being priority-sortable on a per-topic basis (a subjective determination only a admin/mod or other topic "controller" could make). So, my version is suited for boards where tags are used the way they are on a social-media site, and indeed on most web-boards. The other person's version is geared to highly "curated" tagging by dedicated staff not by general-public users of the board.
 - A feature I want to add is a new permission to edit a the first post in a topic (the one to which tags are attached) and only be able to change the tags and other post metadata (title and, if the extension for that is installed, topic description) without being able to touch the content of the post (unless able to do so already by being the original post author or by being an admin/moderator). This would great expand the utility of RH Topic Tags by making tagging a community-managed affair, instead of only something adjustable by a tiny number of overworked invidivuals.
 - Another new planned feature is tag descriptions, managable in the ACP, and producing a `https://yoursite.com/taglist` page, and perhaps a mouse-hover tooltip that describes the tag. This will take some significant work to implement.