Rename cancel to abort

Yes and all of those could easily have a BC layer. The tough one is the cancelTranslation() method on the translator plugins, there we would have to come up with some sort of trick to not break them.

1. +++ b/entity/tmgmt.entity.job.inc
   @@ -644,21 +648,32 @@ class TMGMTJob extends Entity {
   -    // We don't know if the translator plugin was able to cancel the translation
   +    // We don't know if the translator plugin was able to abort the translation
        // job after this point. That means that the plugin has to set the
   -    // 'cancelled' state on its own.
   -    return $controller->cancelTranslation($this);
   +    // 'aborted' state on its own.
   +    if (method_exists($controller, 'cancelTranslation')) {
   +      return $controller->cancelTranslation($this);
   +    }
   +    return $controller->abortTranslation($this);
   

   This looks good but lets add a description why we are doing it, probably with a @todo to remove it, for example in 8.x-1.x.

2. +++ b/entity/tmgmt.entity.job.inc
   @@ -644,21 +648,32 @@ class TMGMTJob extends Entity {
   +  /**
   +   * @deprecated
   +   * @see abortTranslation()
   +   */
   

   The D8 coding standard says that @deprecated should specify if and when it will be removed. Not sure. The most important part is the call to the translator. I'm actually fine with removing the methods on the job.

Also, let's keep the rule, I did enough rules debugging for the next few months ;) Add a @todo and say, rename it to abort.

+++ b/entity/tmgmt.entity.job.inc
@@ -608,6 +608,7 @@ class TMGMTJob extends Entity {
   /**
    * @deprecated
+   *   Use aborted() instead. Will be removed in 8.x-1.x.
    * @see aborted()
    */
   public function cancelled($message = NULL, $variables = array(), $type = 'status') {

Why keep cancelled() when you remove cancelTranslation()? cancelled()/aborted() is mostly internal anyway, you probably shouldn't be calling it directly.

Not 100% sure yet about the rule, actually, it's just so ugly ;) Other projects have similar problems, anything that has dynamic actions based on a machine name or so for example, see https://drupal.org/node/923874. We don't use it that much, so maybe we should just rename it and document it in the change record, with a reference to that documentation.

Committed and pushed, published the change record.