Localization sharing with the core Translate interface

Good idea. The trick in this case is that the core UI allows you to provide translations for the same string for multiple languages at once, so we'd need to initiate probably many HTTP requests to send your data and possibly find out you are not even a member of some of the translation teams. So maybe some local caching of your membership data / success rate would be useful in that case.

I think a good first step would a more reusable API, like #912252: Build reusable API, add hooks for modules, etc..

Then we can think of adding some form submit callbacks easily.

About remote submission failures it could be good enough some per request status variable so if we've failed once, we don't try anymore.

Btw, the l10n module already works with such submissions (core translate UI) so it keeps track of string status (which ones have been translated locally) so we should work on a joint solution. I think the patch mentioned above will do for that, so we can just implement some hook_l10n_client() and and update string status accordingly.

This is implemented in the Drupal 8 version with the localization contributor module (which is a requirement for the unique UI module). Not going to backport that to Drupal 7 and especially not unsupported Drupal 6.