For awhile I had a coworker with less than stellar English skills. Said employee wrote an error message that was poorly worded, and somehow we missed it and the poor English was shipped to customers. The response was that everyone on the team had to have their error messages reviewed by a member of the docs team before we could commit any code with error messages.
I never did decide if it was OK to be annoyed by that policy.
It seems like the best response to both that mistake and that situation would have been to have a policy of pulling any error messages (or other text that'll be visible to users) from a resource file. If you made the resource file use a simple enough format, you could just pass the entire thing off to the docs team before each release and let them edit it directly. It'd also make future i18n efforts far simpler.
If all of the engineers on the team are quasi-literate, then sure, the policy is defensible to use copywriters to vet messages.
Everyone makes mistakes, though. A much better policy, just in general, would have been to require all commits be reviewed by someone else (by an engineer, or by an editor, if the commit has new messaging). I've heard Google uses this "looks good to me" sign-off process.
3 comments
[ 24.5 ms ] story [ 995 ms ] threadI never did decide if it was OK to be annoyed by that policy.
Everyone makes mistakes, though. A much better policy, just in general, would have been to require all commits be reviewed by someone else (by an engineer, or by an editor, if the commit has new messaging). I've heard Google uses this "looks good to me" sign-off process.