Well, that’s a big topic, and I really only want to consider a few things that pertain to globalization. Specifically, those in RFC 2119:
1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification. 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)
Well, that just about says it all. Or, actually, not quite.
Trying to get some editors to use those, or rather to not ban them, can be trying. While modal verbs in English can be difficult for non-native English speakers, you simply cannot get around using them unless you wish to alter the meaning of a sentence.
This is particularly important for technical discussions and documentation. RFCs are there for a reason, and anyone working in tech needs to know them or at least how to use them when relevant.
RFC 2119 differs from most in that it sets forth some terminology for all RFCs and how they communicate information. “Should” is unambiguous and clearly defined. Similar for “may” and “must”. Those that wish to participate in technical fields in English need to know RFC 2119 and understand it. If they do not have sufficient English language skills, they need to develop them.
While making things accessible to everyone is a noble goal, there are times when you just have to set minimum standards and say that those that do not meet the minimum requirements just aren’t invited to the party. This is particularly poignant in globalization. While simplifying your writing is a good thing, there’s such thing as too much of a good thing, and that’s bad.
Bastardizing meanings for the sake of making content more accessible works in some contexts, but not for tech where very often meanings must be precise. For example, the statements:
If you notice anything abnormal, turn off the power.
If you notice anything abnormal, you should turn off the power.
If you notice anything abnormal, you must turn off the power.
If you notice anything abnormal, you may turn off the power
None of them are similar.
The first is an imperative. The next three are statements. “Should” indicates weak obligation. “Must” indicates strong obligation. “May” indicates permission. None may be used as substitutes for each other and maintain the same meaning.
Those state affirmative cases for turning off the power. However, consider the negative cases and how they compare:
If you notice anything abnormal, do not turn off the power.
If you notice anything abnormal, you should not turn off the power.
If you notice anything abnormal, you must not turn off the power.
If you notice anything abnormal, you may not turn off the power
As above, the first is an imperative, the second is weak obligation, the third strong obligation, while the last is permission to not turn off the power, which interestingly enough, is not the opposite of the positive case above. After all, you cannot have permission to do “nothing” in the sense that granting permission requires an object of that permission, i.e. permission for what? “Doing nothing” at work is still doing something. Think of it as the difference between zero and null. Or think of it in Heraclitean terms: “Being is and non-being is not.”
In each case, meanings are distorted by swapping them out for another. This is a loss of information (meaning) and not acceptable where precision is required.
