Runtime translation download fallback works different from installer translation download fallback

Re-rolled the patch.

Added a project definition to locale_test_translate module. Strange, how tests ever passed without it.

--- a/core/modules/locale/tests/modules/locale_test_translate/locale_test_translate.info
+++ b/core/modules/locale/tests/modules/locale_test_translate/locale_test_translate.info
@@ -3,8 +3,8 @@ description = Translation test module for locale module testing.
 package = Testing
 version = 1.3
 core = 8.x
+project = locale_test_translate
 hidden = TRUE

Bot fails on Updgrade Path test, but test passes locally. Although with an exception, but it is the same exception as when the test runs on 8.x without the patch). I'll give the bot one more spin.

#5: project_api-1832946-05.patch queued for re-testing.

The patch make some changes to .info file properties:

• 'project status url' now accepts a 'FALSE' value.
• 'interface translation project' is removed in favor of the existing 'project' property
• 'project translation server pattern' was previously known as 'interface translation server pattern'

Some examples from the patch:

+ * If a project is not intended to be checked for code updates, add this data
+ * data in the info file: 'project status url = FALSE'

+; Hide this project from update status.
+project status url = FALSE

 ; Definitions for interface translations.
-interface translation project = locale_test
-interface translation server pattern = core/modules/locale/test/test.%language.po
+project translation server pattern = core/modules/locale/test/test.%language.po

IMHO 'project translation server pattern' is not a significant improvement compared to the old 'interface translation server pattern'. Especially now locale module is named 'Interface translation'. If we make any change, I suggest 'interface translation url' as it is an url, and replacement patterns are not required.

I like to use this API as a starting point to create project objects. Project objects can be used to objectify the interface translation code as in #1842380: Convert $source object to a TranslatableProject class. But I'm struggling with the right way to instantiate the project objects. I don't have experience in this field and I can't find proper examples. Below is a scetch of my ideas how to do it.

• SystemProjectFactory is a class which generates and handles SystemProject objects.
• SystemProjectFactory::scan() processes project .info files as project_process_info_list() currently does.
• SystemProjectFactory::getAllProjects() returns array of SystemProject objects.
• SystemProject objects contain project data of a single project as currently returned by project_list().
• class LocaleProjectFactory extends SystemProjectFactory for locale module.
• class UpdateProjectFactory extends SystemProjectFactory for update module.

Examples in code:

// IN CURRENT PATCH ============================
function project_list() {
  if (FALSE && $cached = cache()->get('project_list')) {
    $projects = $cached->data;
  }
  else {
    $module_data = system_rebuild_module_data();
    $theme_data = system_rebuild_theme_data();
    project_process_info_list($projects, $module_data, 'module', TRUE);
    project_process_info_list($projects, $theme_data, 'theme', TRUE);
    project_process_info_list($projects, $module_data, 'module', FALSE);
    project_process_info_list($projects, $theme_data, 'theme', FALSE);
    // Allow other modules to alter projects before fetching and comparing.
    drupal_alter('project_list', $projects);
    // Cache the site's project data for at most 1 hour.
    cache()->set('project_list', $projects, REQUEST_TIME + 3600);
  }
  return $projects;
}

function locale_translation_project_list() {
  $projects = &drupal_static(__FUNCTION__, array());
  if (empty($projects)) {
   $include_disabled = config('locale.settings')->get('translation.check_disabled_modules');
   $projects = array_filter(project_list(), function ($project) use ($include_disabled) {
     return ($include_disabled || !empty($project['project_status'])) &&
       (!isset($project['info']['project translation server pattern']) || $project['info']['project translation server pattern']);
   });
  }
  return $projects;
}

function update_get_projects() {
  $projects = &drupal_static(__FUNCTION__, array());
  if (empty($projects)) {
   $include_disabled = config('update.settings')->get('check.disabled_extensions');
   $projects = array_filter(project_list(), function ($project) use ($include_disabled) {
     return ($include_disabled || !empty($project['project_status'])) &&
       (!isset($project['info']['project status url']) || $project['info']['project status url']);
   });
  }
  return $projects;
}

// PROPOSAL ============================
function locale_translation_project_list() {
  if (FALSE && $cached = cache()->get('locale_translation_project_list')) {
    $projects = $cached->data;
  }
  else {
    $module_data = system_rebuild_module_data();
    $theme_data = system_rebuild_theme_data();
    $factory = new LocaleProjectFactory('locale_translation_project_list');
    $factory->scan($module_data, 'module', TRUE);
    $factory->scan($theme_data, 'theme', TRUE);
    $factory->scan($module_data, 'module', FALSE);
    $factory->scan($theme_data, 'theme', FALSE);
    // Allow other modules to alter projects before fetching and comparing.
    $factory->alter();
    // Cache the site's project data for at most 1 hour.
    cache()->set('locale_translation_project_list', $projects-getAllProjects(), REQUEST_TIME + 3600);
  }
  return $projects;
}

function update_get_projects() {
  if (FALSE && $cached = cache()->get('update_projects')) {
    $projects = $cached->data;
  }
  else {
    $module_data = system_rebuild_module_data();
    $theme_data = system_rebuild_theme_data();
    $factory = new UpdateProjectFactory('update_projects');
    $factory->scan($module_data, 'module', TRUE);
    $factory->scan($theme_data, 'theme', TRUE);
    $factory->scan($module_data, 'module', FALSE);
    $factory->scan($theme_data, 'theme', FALSE);
    // Allow other modules to alter projects before fetching and comparing.
    $factory->alter();
    // Cache the site's project data for at most 1 hour.
    cache()->set('update_projects', $projects-getAllProjects(), REQUEST_TIME + 3600);
  }
  return $projects;
}

This is working code to replace update_process_info_list() (or project_process_info_list() if you wish). I like to have comments on the objectification of the code. Pointer to good examples are appreciated too. A know omission is a missing ProjectInterface class, but that should be easy to extract. Also like to have comment on the above usage of this ProjectFactory class. The implemententation is slightly changed as you can see below.

The two debug calls give the same data.

  // New using ProjectFactory
  use Drupal\Core\Project\ProjectFactory;
  $factory = new ProjectFactory('locale_translation_project_list');
  $factory->parse($module_data, 'module', TRUE);
  $factory->parse($theme_data, 'theme', TRUE);
  $projects = $factory->getAllProjects();
  debug($projects);

  // Existing using update_process_info_list();
  module_load_include('compare.inc', 'update');
  debug(update_get_projects());

Thanks for moving this forward, this is probably a good idea so we can share more code between update manager and other parts of core. I don't have time to do a thorough review, but this is now on my radar and I hope to look more closely Soon(tm).

However, do we really want this to consume the "project" namespace? That's not going to be any fun at all for the project module, which is kinda important for d.o and our community. :( I guess in the past the attitude has been "if core wants a namespace, contrib be damned", so perhaps we're just going to have to somehow deal with this in D8 and rename that module (or something). But holy crap, that's going to be a HUGE amount of work, and perhaps core could save us the trouble of basically rewriting the whole thing (again) by using some other namespace for this...

Thanks,
-Derek

I agree with @Jose Reyero to make Project as simple as possible. But by adding classes for Modules and Themes would make this a Drupal 9 issue. But we should add those eventually.

By adding a [projectname].project.info we can speed things up.

As we are adding an API we should add a class for Project like \Drupal\Core\Project so there is no namespace problem with the Project project. We do have \Drupal\Core\SystemListingInfo.php so I'm a little confused as that comes close to our needs.

In discussing with @Sutharsan I proposed composition design pattern for update / locale like

class Project {
  function getName() {
    return spl_object_hash($this);
  }
}

class TranslationProject {
  var $_langcode;
  var $_project;

  function __construct($project) {
    $this->_project = $project;
  }
  function getProjectName() {
    return $this->_project->getName();
  }

  function setLangcode($langcode) {
    $this->_langcode = $langcode;
  }
}

My 2cents

Update module and Locale module have different needs for project data. Where Locale only requires as list of projects with name and release version, Update module needs more details such as sub-modules(/themes) project time stamp, package, etc. IMHO class inheretance/override is the ideal for this differentiation. The attached patch tries to combine this with a minimum added complexity. A Project class holds the project data and a ProjectBuilder class contains the logic to process the module and theme data and build a project object. Locale and Update have their own inherited builder class to differentiate. LocaleProjectBuilder filters only the required data, UpdateProjectBuilder does some additional data processing on top of the ProjectBuilder results.

I have the following OO related questions:

• Is the ProjectBuilder class a correct way of creating objects? I've chosen to build an array of object inside the class because of the nature of the building process. It needs to build lists of sub-modules for each project, therefore it can only generate all projects at once and not one a the time.
• The ProjectBuilder class instantiates Project objects. But should be able to determine which (derived) project class to use. I've use a protected property $project_class. Is this a proper way to do it?
• The UpdateProjectBuilder adds a method processVersionInfo() which does not exist in the base ProjectBuilder class. Is this good practice?
• Does Project need an abstract base or interface class?

Some more notes on the code: I changed the project parsing code in ProjectBuilder as little as possible. Its complexity holds me back, but I would rather break it up to make the base project class more lean and move the Update module specific stuff into the UpdateProjectBuilder. In other words, more differentiation between Locale and Update project data. The UpdateProject is not used, but I left it there for now to show the kind of data Update modules calculates. I did not want to modify the Update module code which uses the $project array and convert it into a $project object. As a temporary solution I introduced a getAllProjectsAsArray() method to the UpdateProjectBuilder which is now used by Update module to retrieve the project data.

I like the idea to add a *.project.info file to each project. If it includes the data we need to build projects (including a list of sub modules/themes), it would make the project building process much easier.

Though a Project class may be something to aim at, that should start with component classes (Module, Theme)

I don't agree with @Jose Reyero on this. A project is a container of components, where the only (required) relation between them is that the project must know the names of the included components. Ideally these are not names, but component objects. Currently only Update module has the requirement for this data and I have the impression that this data only required for displaying a list of included modules/themes in the interface. I don't want to postpone the introduction of project objects until Component objects are introduces. I need the project objects to start with improvements on automatic translation import.

@ClemensTolboom, I don't want to jump into TranslationProject yet. Getting the base Project class right is difficult as it is ;) But thanks for your cents.

I promised some feedback on this patch, but first a disclaimer: I have nfi about the inner workings of either locale module or update module :-P This feedback is just about the class design.

Also, I think it might be a good idea to get chx to look at this, because he has done a lot of work around module/theme discovery and has further plans in that area I believe. It would be a shame if there were efforts being duplicated.

Here are my comments on the classes...

Project class:

+++ b/core/lib/Drupal/Core/Project/Project.phpundefined
@@ -0,0 +1,94 @@
+  /**
+   * Array of project info, as defined in the .info file.
+   *
+   * @var array
+   */
+  public $info = array();
+
+  /**
+   * The timestamp of project release.
+   *
+   * @var integer
+   */
+  public $datestamp = 0;
+
+  /**
+   * Array of modules included in this project.
+   *
+   * @var array
+   */
+  public $includes = array();
+
+  /**
+   * Array of disabled modules in this project.
+   *
+   * @var array
+   */
+  public $disabled = array();
+
+  /**
+   * The type of project. e.g. module, theme.
+   *
+   * @var string
+   */
+  public $project_type = '';
+
+  /**
+   * The project status. 1 = enabled, 0 = disabled.
+   *
+   * @var string
+   */
+  public $project_status = '';

It looks like most of these properties can get set on instantiation. Use setters for the rest instead of having public properties.

ProjectBuilder class:

+++ b/core/lib/Drupal/Core/Project/ProjectBuilder.phpundefined
@@ -0,0 +1,303 @@
+  /**
+   * Parses module .info files data to collect project information.
+   */
+  public function parseModules() {
+    $module_data = system_rebuild_module_data();
+    $this->parse($module_data, 'module', TRUE);
+    if ($this->include_disabled) {

We generally want to avoid calling out to procedural functions within our classes - and seeing as we are always going to need this information, why not pass it as a parameter to the constructor?

+++ b/core/lib/Drupal/Core/Project/ProjectBuilder.phpundefined
@@ -0,0 +1,303 @@
+      if (!$project = $this->getProject($project_name)) {
+        // Only process this if we haven't done this project, since a single
+        // project can have multiple modules or themes.
+        // @todo dynamically define a class.
+        $project = new $this->project_class($project_name, $project_display_type);

A nicer way of dealing with this might be to use a ProjectFactory, which could also be passed in the constructor of the ProjectBuilder, so then you would do something like...

$project = $this->projectFactory->getInstance($project_name, $project_display_type);

+++ b/core/modules/locale/locale.compare.incundefined
@@ -127,73 +121,29 @@ function locale_translation_build_projects() {
+    $builder = new LocaleProjectBuilder();
+    $builder->parseModules($include_disabled);
+    $builder->parseThemes($include_disabled);
+    $projects = $builder->getAllProjects();

Looking at this calling code to see how the ProjectBuilder class gets used, and taking the above comments into account, I think what you want to end up with is calling code that looks like this:

$module_data = system_rebuild_module_data();
$theme_data = system_rebuild_theme_data();
$builder = new LocaleProjectBuilder($module_data, $theme_data, $include_disabled, new ProjectFactory());
$projects = $builder->getAllProjects();

... assuming it never makes sense to have a ProjectBuilder object that has not parsed the data, i.e. so you would just call the parse() method in the constructor and be done (the parseModules() and parseThemes() methods would then be unnecessary.)

I hope this helps!

@katbailey, thanks for your review. Regarding public properties, I see a number of classes using public properties such as file, node and (other) entities. I guess this is for backwards compatibility only, or am I missing something? Also I have not found any rules or coding standard for this in Drupal yet.

This is just bog standard encapsulation. Is there a reason you think those properties should be public or that they can't be set in the constructor?

I used public properties because this required the least amount of changes when re-using existing code ($project['foo'] changed to $project->foo) and I found public properties used in various places in core. I'm not defending my code, I will rework it without hesitation to comply with best practice, but I'm searching for the right and the proper (and all the exceptions to that ;) ) and trying to understand it all.

I don't think there's any need to be overly tentative about the extent of the changes you'll be making here. We are embracing OOP in D8 and this has already entailed enormous changes to the way we write code for Drupal. One huge advantage to embracing a very commonly used set of design principles is that we don't have to maintain coding standards documentation about things like the question of public/protected/private properties - we can just follow general OOP best practices. We *want* Drupal to not be special in this regard.

The only reason I can think that you might want to use public properties would be as a micro-optimization, i.e. to avoid the method call, as discussed here: http://stackoverflow.com/questions/6215398/calling-the-variable-property...

But in this particular case, as I said the majority of those properties look like they can be set on instantiation and will not be changed again. And even if they did need to be set again, using setters is still the best practice - the kind of micro-optimization mentioned above is definitely not the norm.

Possibly related: #1833592: [META] The road out of module build circular dependency hell I checked with chx, this is the issue where the work for 'module/theme discovery' is going on. See katbailey's remark in #19.

This patch now uses project classes as katbailey suggested:

• Class Project.php: protected variables. Does this need an underlying interface class?
• Class ProjectBuilder.php: Building array of classes from supplied module and theme data. Changed to use the Project getters and setters.
• Class ProjectFactory: Very minimal. Should we use this or use a Project::create() method instead and call ProjectBuilder::__construct() with the required class name?

@katbailey, I would appreciate your review on the above.

Some observations on the system_project_list() as a single source of project data.

• system_project_list() is now the only project list source. This is now back as how it was in the initial patch by Jose Reyero. system_project_list() return an array of objects. This however has some consequenses:
• Locale and Update module both still expect the project to be an array. In locale_translation_project_list() and update_get_projects() I've added code to convert the data to an array. This needs a follow-up.
• In update_process_project_info(), update_calculate_project_data() and update_calculate_project_update_status() add some 14 more parameters to the (current) project array. If we modify the update module to use a project object instead of an array, these 14 parameters must be added to the Project class or the parameters must be added to an UpdateProject class which extends the Project class.
• For Locale module, the introduction of a project class is required for #1842380: Convert $source object to a TranslatableProject class. The Project class must be extended into a TranslatableProject class. I think this requires TranslatableProject to extend Project class, but perhaps there are different ways.
• system_project_list() makes a list of all projects both enabled and disabled and it caches the result. Disable projects are filtered out in update_process_project_info(). This however results in the update page to show both enabled and disabled modules included in for example Drupal Core. Since both Update and Locale module use their own 'show/hide the disabled project' setting, changing this back to the original behaviour will lead to removing the cache from system_project_list() and using individual caches in Update and Locale. Any other ideas?

@Jose Reyero, I understand your desire for a single list to be used by both Update and Locale. But IMO the arguments for separate data, are growing in number. I'm trying to make this patch according to your single source idea, but I am running out of ideas to combine it in a decent way with one single project object.

I think this would be an API refactoring, not a feature. Marking as such. @katbailey: thank you help review the recent updates? Sounds like we are on the right path.

agree with #27 - this is task!

Sorry for taking so long to look at this again. This is looking much better. Regarding the questions above, yes we need a ProjectInterface and a ProjectFactoryInterface. Then the advantage of passing in an actual factory rather than a string representing a fully-qualified class name for a Project class is that we get much better error handling, i.e. if you pass in anything other than an object implementing the ProjectFactoryInterface it will blow up with a nice helpful message.

Below are just some minor points about method names.

+++ b/core/lib/Drupal/Core/Project/Project.phpundefined
@@ -0,0 +1,284 @@
+  /**
+   * Gets human readable project name.
+   *
+   * @return string
+   *   Human readable project name. Falls back to machine name if not available.
+   */
+  public function getProjectName() {
+    return isset($this->info['name']) ? $this->project->info['name'] : $this->name;
+  }

I'd call this getHumanName() as then it's clearer why you're not just returning $this->name.

+++ b/core/lib/Drupal/Core/Project/ProjectBuilder.phpundefined
@@ -0,0 +1,283 @@
+  /**
+   * Stores a project in the internal project array.
+   *
+   * @param object $project
+   *   Project object.
+   */
+  protected function setProject($project) {
+    $this->projects[$project->getName()] = $project;
+  }

This should be addProject() as you're not setting the $project property but adding to the $projects property.

Edit: I thought dreditor had lost my changes initially, but it hadn't - removing the duplication.

@katbailey, thanks for the review. I've been offline for D8 work for a while. But I hope to get back to this issue shortly.

Stright re-roll of #25

I took a look at
core/modules/update/update.compare.inc
http://drupalcode.org/project/drupal.git/blame/HEAD:/core/modules/update...
and git blame --since="January 30, 2013" core/modules/update/update.compare.inc

fea7acc2
#1547008: Replace Update's cache system with the (expirable) key value store
http://drupalcode.org/project/drupal.git/blobdiff/980cb9c54851e7d279e0cc...

6bf13bd8
#1793074: Convert .info files to YAML
http://drupalcode.org/project/drupal.git/blobdiff/13bd2b25ec747e83417288...

59bd679e
#986888: Undefined index warning in "Available Updates List" with hidden=TRUE base themes
http://drupalcode.org/project/drupal.git/blobdiff/ccb9c924b0f5b69eb73e83...

The syntax error was due to a missing closure parenthesis in update_get_projects(). Also fixed an error with the use path of LocaleProjectBuilder.
Patch follows

For evaluation: interdiff-1832946-31-34-no-white-space.txt
For git apply: interdiff-1832946-31-34.txt
Needs more work to process katbailey's comments, but first I want to agree with Jose on the direction.

Trigger testing for the latest patches...

We have been discussing this with Sutharsan, and there are more important things to work on now and this did not get the kind of interest we hoped from outside our little bubble, so marking this postponed.

That's unfortunate as I had to look at the locale "file" handling stuff and it made my head hurt, but we'll have to live with that I guess ;)

I think we all agree this is a great cleanup effort. In the meantime, we did not manage to sign up a reasonable amount of people for this to work on it and we have important things to work on unfortunately. This one being pretty important right now: #1998056: Automatically update interface translations using cron.

Setting back to sprint and active for focus to get this in before the code freeze.

I've discussed yesterday with Jose to revive this feature. We will go back to the root of the issue and create a simple API with minimal changes and aimed at removing the dependency of Locale upon Update module. Re-roll of the original issue will be the first step.

Re-roll of patch in #5.

Tagging for the rocketship.

Fix tags.

This looks like a massive API change. I believe we did the moving of functions around already. Is there anything else left here to do?

@Sutharsan: are you still working on this? Is this still needed? What kind of API changes are needed?

The issue summary could really use an update that explains what the API changes introduced in this patch are in order to expedite approval.

An explicit list would be especially helpful, e.g.: https://drupal.org/node/2056513#summary-api-changes

I received your comments, but I may need a few days to find the time to write something about the status of this issue.

Needs Reroll

I've updated the API summary.

The below functions in #55 are no longer needed as their functionality is now included in \Drupal\Core\Utility\ProjectInfo. This patch removes them.

• project_process_info_list()
• project_file_get_name()
• project_filter_info()

@dww was concerned in #12 for core taking on some of the project_* namespace. From the issue summary, this looks like still being the case? This should be reviewed with a core maintainer for API change approval before substantial further work is put into it.

Yup, still concerned, but don't have the time/energy to follow closely or keep fighting. Thanks for bringing that back up!

Updated API changes

I agree that we badly need to clean up this code. Like @Berdir, I also had a very hard time in debugging test failures in the current project-related Locale code.

When proceeding here, it would be a good idea to move the generic parts out of Utility and into Drupal\Core\Extension\Project\* instead (or perhaps even Drupal\Core\Project), since this entire code heavily depends on the extension system, so various services should be injected.

It may be possible if it does not involve API changes or API changes are needed due to major or critical bugs. #2501035: Without "Update Manager" module enabled, "Available translation updates" does not get updated, should be documented is a related UI issue.

Note that when I wrote that I was going by https://www.drupal.org/contribute/core/beta-changes which is the policy. Sounds like this may or may not be argued under the "reduced fragility" umbrella even in D8 but ideally should be discussed with core committers first.

API additions are allowed at 8.x.y. Do we really need to change underlying APIs? Couldn't we keep those as wrappers and deprecate them?

Right, moving back to 8.0.x unless it's shown that there's no way to do this in a BC way. (And possibly even then; needs a beta evaluation.)

So while it could be possible and easy to provide some partial project translation information and download it without update manager, I am not sure it is worth the trouble

It was not much trouble, working code was already available in Localization Update module. I've created a patch at #2550137: Improve interface translation fallback if Update module is disabled

IMO an 'all or nothing' (with update/without update) option is way easier to understand than 'you only get updates for some projects beacause of this and that...'.

Generally I agree, but when I saw the practical implication in #2501035: Without "Update Manager" module enabled, "Available translation updates" does not get updated, should be documented. That we are going to tell the user that a status page is not available...

I have no opinion on the direction of this issue (yet).

#2113957: Build server side version fallback system for translations has some examples, eg /files/translations/6.x/gallerix/gallerix-6.x-1.x.ja.po

Merged the solution from #2550137-5: Improve interface translation fallback if Update module is disabled. Making the regex less specific and adding a check for '-dev' in the issue string for performance.

Patch needs cleanup and tests. Not changing the status yet.

Looks cool on a short review :)

Next iteration:

• Renamed LocaleUpdateNotDevelopmentReleaseTest to LocaleUpdateDevelopmentReleaseTest
• Renamed module locale_test_not_development_release to locale_test_development_release
• Update the test for locale_translation_build_projects() in the above test class
• Small clean-ups

Todo: Add a new assertion. See the @todo in the patch.
Probably all the test that now fail, fail because locale_translation_build_projects() does return data when Update module is disabled. So test must be adapted to this new, desired, behavior.

Bring on D8MI sprint for tracking :) Thanks for working on this.

Got the tests working, by adding locale_test module to language related tests. The module prevents core from being translated when for example a language is added. Lets see if the bot agrees.

Next iteration ...

Last patch tested Ok :)

Updated issue title and summary significantly.

Annoying bot

Looks like legitimate needs work now.

1. +++ b/core/modules/locale/src/Tests/LocaleUpdateInterfaceTest.php
   @@ -7,6 +7,7 @@
   +use Drupal\Component\Utility\FormattableString;
   
   @@ -87,8 +88,12 @@ public function testInterface() {
   +    $release_details = new FormattableString('@module (@version). @info', [
   +      '@module' => 'Locale test translate',
   +      '@version' => '1.3-dev',
   +      '@info' => t('File not found at %local_path', array('%local_path' => 'core/modules/locale/tests/test.de.po'))
   +    ]);
   

   Test fails due to no FormattableString.

2. +++ b/core/modules/locale/tests/modules/locale_test_development_release/locale_test_development_release.module
   @@ -0,0 +1,42 @@
   +}
   \ No newline at end of file
   

   No newline.

Fixed both points in #107, which are trivial changes, so back to RTBC.

The language switching test is again a victim of the language adding leading to translation problem.

I don't understand how adding the locale_test module fixes the problem?

@wimleers See #82.

function locale_test_locale_translation_projects_alter(&$projects) {
  // Drupal core should not be translated. By overriding the server pattern we
  // make sure that no translation for drupal core will be found and that the
  // translation update system will not go out to l.d.o to check.
  $projects['drupal']['server_pattern'] = 'translations://';

There is also the import_enabled killswitch in locale.settings (testing profile ships with its own locale.settings to kill automated imports) but that does not seem to play nice with the config system when we actually enable locale in the testing environment. (Note that this problem did not pop up before because the code that identified the projects to deal with was dependent on update module, and this patch obviously removes that dependency, so it starts downloading translations where locale is enabled but update is not, but that is a good thing mostly, except some tests :).

Thanks!

RTBC if green.

Pushed to 8.0.x.

Grumble.

Yay, thanks all!