Remove deprecated Drupal\Core\StringTranslation\TranslationWrapper to TranslatableMarkup in Drupal 11

As I see it's used in serialised data, so it needs update hook to update all data?

Agreed with aliasing. If we want to remove the alias, we can try again later. All the cases I could find from manually reviewing the database dump looked like the installed entity definitions in key_value. Opened a follow-up for that specific case at #3284461: Installed entity definitions in key/value use deprecated TranslationWrapper in database dumps, but even once we've done that, we need to keep the alias in the version until after that update has definitely run.

@longwave Nice approach! and no longer need to change all dumps

Whoops I just committed this from needs review, misread #16 as an RTBC. But yes this looks good and we can look into removing the alias in Drupal 11 or later.

This is kinda tricky because just aliasing the class means that using it will no longer trigger deprecation errors. So in some ways we're in a better place with HEAD. One thing we could try is only making the alias available during update. Do we know which tables are still using it? It is in state because that's going to be trickier to update.

+++ b/core/includes/bootstrap.inc
@@ -60,6 +60,11 @@
+/**
+ * Keep backward compatibility for sites with references to TranslationWrapper.
+ */
+class_alias(TranslatableMarkup::class, '\Drupal\Core\StringTranslation\TranslationWrapper', TRUE);

Let's add an example of where this might occur. I think that is a useful justification to maintaining this alias forever.

Another interesting impact of this change is that it means we'll have to load TranslatableMarkup on every request. So that means that we'll have to load \Drupal\Component\Render\FormattableMarkup and \Drupal\Component\Render\MarkupInterface too. So all these things would need to go in the classmap in core/composer.json in order to optimise the cached response autoloading. For me this means we could consider just permanently deprecating TranslationWrapper and being done.

This is kinda tricky because just aliasing the class means that using it will no longer trigger deprecation errors.

This is true, but if contrib/custom code doesn't have usages now, then I don't think it makes it more likely that new ones will be added. Also don't think the deprecation messages will help to remove serialized content - because all our update tests are @legacy anyway.

Could we switch TranslationWrapper from @deprecated to @internal with a comment explaining why?

Can we get away with putting the class_alias() line in TranslatableMarkup itself, assuming that at least one bit of TranslatableMarkup will have already been used by the time TranslationWrapper is needed?

Unfortunately I don't think we could guarantee that.

As I see the usage could only happens in dumps and some serialized caches/data when sites upgraded from 8.x to 10.x but that should not happen when 9.x is not skipped in upgrade process

Maybe better just regenerate dumps without it?

@andypost I'm not sure that's true. The database fixtures have been created by installing 8.x, running updates, then re-exporting again (up to 9.3.0 so far). This means that the updates have not explicitly removed references to this class during that process.

It's possible that real sites no-longer have the references, but there's not really a way for us to prove this.

I keep going around in circles on this issue, I think we should probably do the following:

1. Update the deprecation for removal in drupal:11.0.0 and leave the rest alone for now.

2. Open an issue to try to permanently remove the class if we can - i.e. at least find out why the entity metadata in the dumps never got updated and try to write an update to fix that at least.

Instead of re-purposing this issue, opened a spin-off to update the deprecation, then this can stay open for the actual removal/aliasing.

#3295421: Update TranslationWrapper deprecation to removal in 11.0.0.

Wondered if PHP itself had anything for this, and it does, but... not sure we want to go there https://www.php.net/manual/en/var.configuration.php#ini.unserialize-call...

Postponing then to Drupal 11, given #3295421: Update TranslationWrapper deprecation to removal in 11.0.0 landed. Also moving under the Drupal 11 META that I just created.

Drupal 11 meta seems correct, but we're going to need some kind of 10.x patch before we can actually remove this due to the serialized PHP, so probably more of a 10.1.x task, re-titling now the other issue is in.

Added reroll of patch #14 on Drupal 10.1.x.

Can we have an MR here?

Added a MR and checked for a few more deprecations.

The Needs Review Queue Bot tested this issue.

While you are making the above changes, we recommend that you convert this patch to a merge request. Merge requests are preferred over patches. Be sure to hide the old patch files as well. (Converting an issue to a merge request without other contributions to the issue will not receive credit.)

Removal of TranslationWrapper seems fine and didn't cause any issues

Changed the title to #32 as seems to more match what's happening here now.

Committed 6a9e301 and pushed to 11.x. Thanks!