string cleanup and refactoring

Observed behavior

0.12.0 has quite a bit of string-related tech debt:

• crossComponentTranslator was used/abused to allow components to use translated strings from other components
• A subset of strings is now in a ‘common coach strings’ file
• A subset of strings now uses more precise naming conventions to distinguish different parts of speech - for example previewLabel (a noun) vs previewAction (a verb)
• Many strings defined are no longer used

Expected behavior

• We should add four more shared string files: one for core, and one for each of the plugins (learn, facility, device)
• We should remove all uses of crossComponentTranslator by either moving the string to the new component or moving the string to a shared file
• We should move common strings to the new shared string files and give them explicit, conventional names that reflect their part of speech.
• We should create a new linting rule that warns about unused strings

Note on common strings:

First, we should remove the use of computed props and mixins. Instead, we should use $formatMessage(namespace, stringID). See discussion

Second, we should be judicious about what strings are put in ‘common’ files because over-doing this can have adverse affects. In particular, sometimes strings that are the same in English actually need to be translated differently in other languages. For example:

• “preview” the verb vs “preview” the noun
• adjectives that need to agree with the thing they’re modifying
• words that are context-specific, and just happen to be the same in English

Therefore, we should not put a string in common unless it is:

1. used at least 3 times
2. used in exactly the same way (label, button, etc)
3. used to mean exactly the same thing. All strings added to common files should follow the naming conventions in commonCoachStrings

User-facing consequences

none, but affects the costs and difficulty for devs and transators

Context

0.12.0

[rtibbles]

My impression from looking at your profiling code that it is matching based on key, rather than string content? This might be an issue as it may give false positives of repeated strings.

For any future tooling, might be good to use the existing message extraction code that we have - happy to give insights into extending/modifying it for the needs outlined above.

[indirectlylit]

this work is done I believe!

@nucleogenesis correct me if I’m wrong