Removed an i18n override for Gutenberg. (#13432)

Previously we were using our own generated files to provide translations for Gutenberg blocks. But since Core can already do it for us, we just remove the override mechanism and let blocks load translations from the Jetpack textdomain. This fixes broken block translations.

class.jetpack-gutenberg.php

@@ -642,32 +642,11 @@ public static function enqueue_block_editor_assets() {
 			)
 		);
 
-		wp_set_script_translations( 'jetpack-blocks-editor', 'jetpack', plugins_url( 'languages/json', JETPACK__PLUGIN_FILE ) );
-
-		// Adding a filter late to allow every other filter to process the path, including the CDN.
-		add_filter( 'pre_load_script_translations', array( __CLASS__, 'filter_pre_load_script_translations' ), 1000, 3 );
+		wp_set_script_translations( 'jetpack-blocks-editor', 'jetpack' );
 
 		wp_enqueue_style( 'jetpack-blocks-editor', $editor_style, array(), $version );
 	}
 
-	/**
-	 * A workaround for setting i18n data for WordPress client-side i18n mechanism.
-	 * We are not yet using dotorg language packs for the editor file, so this short-circuits
-	 * the translation loading and feeds our JSON data directly into the translation getter.
-	 *
-	 * @param NULL   $null     not used.
-	 * @param String $file     the file path that is being loaded, ignored.
-	 * @param String $handle   the script handle.
-	 * @return NULL|String the translation data only if we're working with our handle.
-	 */
-	public static function filter_pre_load_script_translations( $null, $file, $handle ) {
-		if ( 'jetpack-blocks-editor' !== $handle ) {
-			return null;
-		}
-
-		return Jetpack::get_i18n_data_json();
-	}
-
 	/**
 	 * Some blocks do not depend on a specific module,
 	 * and can consequently be loaded outside of the usual modules.