makyen
commented
7 years ago I use the feature that these expand within the request text on a regular basis. My most common use of these are when I choose to mention more than one potential close reason in the request (e.g. "u / t" expands to "Unclear / Too Broad"). Thus, I would prefer to not change to only replacing them when the letter is the single first letter of the reason.
I suspect that the substitution method of splitting on spaces rather than word breaks (\b) was chosen as an easy way to not substitute single letters of code format text. On the other hand, splitting on spaces and using the keys of an Object as a way to perform substitutions is a reasonably typical pattern for performing this type of substitution. Thus, what constraints were being considered when this methodology was chosen is not clear.
For the specific example of that cv-pls request, the way for the user to get what they intended would have been to put the code in code format. In other words, use Typo: `1` vs `l` instead of Typo: 1 vs l.
Base issue: The posted request message was not what the user expected
That the message posted was not what the user expected is a significant problem. The user had no way to know that the message wasn't what they expected until after the request was posted to the chat room. It's not reasonable for users to be expected to check the chat from to verify that each of their cv-pls messages ended up being what they expected. The message posted to chat should come close to the user's expectations. This can be accomplished by either matching the assumed expectations, or setting the user's expectation more accurately. An additional problem is that users are not aware what single character substitutions are available.
I've already implemented two things which should address these problems. While what I implemented still has the single character reason shortcut substitution throughout the reason text, it should alleviate the mismatch between user expectations of what will be posted and what is actually posted to the chat room. What I had already implemented:
- A tooltip on the reason input which shows the user what the single character substitutions are.
- A preview of what the request will look like when posted in chat
Here's what those look like:
I am, of course, open to implementing whatever is desired by the majority of people. If it's really desired that the single character substitutions should affect only the first character of the input (if it's a single character), then I would prefer to add a user-option which allows selecting that functionality or the original functionality. Adding it to the current options should be reasonably easy. However, my opinion is that having the above two features should significantly reduce, or remove, the need for a change to the single character substitution functionality.
The script SECloseVoteRequestGenerator.user.js has a feature of providing shortcuts to most commonly used close reasons like
tfortoo broadanduforunclear. These shortcuts should expand if that is the only text provided in the input. It shouldn't expand if it appears somewhere in the message.Maybe the shortcuts were carefully chosen such that they won't appear as words, but since codes are involved, variable names could be arbitrary.
One such example happened here.
All the reasons provided in the list sound self explanatory to me (or can be made). So an exact matching should be a better policy than word replacement.