You’ve already given the answer using auto_update_translation. I wasn’t aware this didn’t work after manual updates (and haven’t tried it) but perhaps also look at async_update_translation which according the documentation “Asynchronously upgrades language packs after other upgrades have been made”.
Regardless of the above, I recommend a different approach whereby the community translations are still installed, but your own custom translations override when (and only when) they exist.
This means you have the advantage of improving the translations you dislike, while still benefiting from any new translations appearing before you know about them. (i.e. source strings changing after plugin updates).
To do this you’ll have two copies of each language file and force WordPress to load them on top of each other with yours taking precedence.
(1) Mimic the languages folder structure in a parallel directory, and move your own custom translation files so you have paths like this for whatever your language is:
wp-content/my-translations/plugins/foo-en_GB.mo
(2) Add the following code as a must-use plugin to ensure it’s ready before anything else tries to bootstrap its translations.
<?php
/*
Plugin Name: Custom Translations
Description: Merges translations under my-languages on top of those installed.
*/
function my_custom_load_textdomain_hook( $domain = '', $mofile="" ){
$basedir = trailingslashit(WP_LANG_DIR);
$baselen = strlen($basedir);
// only run this if file being loaded is under WP_LANG_DIR
if( $basedir === substr($mofile,0,$baselen) ){
// Our custom directory is parallel to languages directory
if( $mofile = realpath( $basedir.'../my-languages/'.substr($mofile,$baselen) ) ){
load_textdomain( $domain, $mofile );
}
}
}
add_action( 'load_textdomain', 'my_custom_load_textdomain_hook', 10, 2 );
Note that your custom files need only contain the strings you want to change. This relies on WordPress’s current merging strategy. In the code above your file actually completes first, then is merged on top of the installed file.