LogicException: The database connection is not serializable (StringOverridesTranslation missing DependencySerializationTrait)

Note I had a weird issue after doing updates that I could not properly edit views. I would get errors trying to add fields. I was stumped and for the first time I tried 'CLAUDE" the anthropic AI. Let me say it took me down a hell of a lot of rabbit holes, after about an hour of try this and try that I think we found the issue was this module. I made the edits it suggested and for now I seem to be able to add fields in views again.

I am forwarding Claude's recommendation in case someone else had this issue. I am not a fan boy of AI for resolving problems, but maybe it really did, maybe not. Here is what it gave me to give you:

----------------------------

# Issue title

LogicException: The database connection is not serializable (StringOverridesTranslation missing DependencySerializationTrait)

# Issue category

Bug report

# Component

Code

# Version

2.0.1 (also present in 2.0.0 and the 2.0.x-dev branch — the underlying class is unchanged)

---

## Problem/Motivation

`StringOverridesTranslation` (`src/StringOverridesTranslation.php`) holds a live `CacheBackendInterface` service (`$cacheBackend`) and a `ConfigFactoryInterface` service (`$configFactory`) as plain object properties, injected via its constructor. The class does not implement `__sleep()` and does not use `Drupal\Core\DependencyInjection\DependencySerializationTrait`.

Drupal's `TranslationManager` keeps a list of all registered translator services (`$sortedTranslators`), and `StringOverridesTranslation` is registered as one of them via this module's service definition. Any code path that ends up serializing something holding a reference to the translation manager — directly or indirectly — will therefore also try to serialize `StringOverridesTranslation`, and with it, the live `$cacheBackend` object. Since the default cache backend is backed by the database, this ultimately tries to serialize the database `Connection` object, which throws:

```
LogicException: The database connection is not serializable. This probably means you are serializing an object that has an indirect reference to the database connection. Adjust your code so that is not necessary. Alternatively, look at DependencySerializationTrait as a temporary solution. in Drupal\Core\Database\Connection->__sleep()
```

This is the same class of bug documented in core issue #2987548: LogicException: The database connection is not serializable.(https://www.drupal.org/project/drupal/issues/2987548) and the [meta issue #3400483](https://www.drupal.org/project/drupal/issues/3400483) for `StringTranslationTrait` consumers generally, and matches the fix pattern used in numerous other contrib modules (e.g. #3307045: LogicException: The database connection is not serializable.(https://www.drupal.org/project/domain_path/issues/3307045), #3279917: LogicException: The database connection is not serializable(https://www.drupal.org/project/honeypot/issues/3279917)) — add `DependencySerializationTrait` to any class holding injected services that might get serialized.

In our case the trigger was the core Views UI module, which caches the in-progress `ViewUI` object into the user's `SharedTempStore` after every AJAX step (add field, change row style, etc. — see `Drupal\views_ui\ViewUI::cacheSet()`). `ViewUI` holds a reference to the site's string translation service, which pulled in `StringOverridesTranslation` and its live cache backend. Any views edit via the admin UI's AJAX interface fails as soon as this module is enabled, regardless of the view or field being edited — confirmed with a brand-new view on a brand-new content type using only core field types.

Given that `TranslationManager` and its registered translators can plausibly be reached from many other serialization paths across core and contrib (any object using `StringTranslationTrait` that ends up cached/serialized), this likely affects more than just Views UI for sites running this module.

## Steps to reproduce

1. Install a standard Drupal site (11.4.5 tested, but the affected code is unchanged since at least 2.0.0).
2. Enable `stringoverrides` (2.0.1).
3. Go to `/admin/structure/views/add` and create any view (any base table).
4. In the view's Fields section (or when switching the row style to "Fields" on an existing view), click "Add" to add any field, or click "Apply" after switching row style.
5. Observe the AJAX request fails with "Oops, something went wrong."
6. Check the site's error log (`/admin/reports/dblog`) for the `LogicException: The database connection is not serializable.` entry, with a backtrace through `Drupal\views_ui\ViewUI->cacheSet()`.

Confirmed via a custom reflection-based debug hook (that respects each object's own `__sleep()`, matching real `serialize()` semantics) that the actual unserializable path is:

```
stdClass::$data -> Drupal\views_ui\ViewUI::$stringTranslation ->
Drupal\Core\StringTranslation\TranslationManager::$sortedTranslators -> [1] ->
Drupal\stringoverrides\StringOverridesTranslation::$cacheBackend ->
Drupal\Core\Cache\DatabaseBackend::$connection
```

## Proposed resolution

Add `Drupal\Core\DependencyInjection\DependencySerializationTrait` to `StringOverridesTranslation`. This strips container-service properties (`$cacheBackend`, `$configFactory`) before serialization and transparently restores them from the container on wakeup, with no other behavior change.

### Patch

```diff
--- a/src/StringOverridesTranslation.php
+++ b/src/StringOverridesTranslation.php
@@ -3,6 +3,7 @@
namespace Drupal\stringoverrides;
use Drupal\Core\Cache\CacheBackendInterface;
use Drupal\Core\Config\ConfigFactoryInterface;
+use Drupal\Core\DependencyInjection\DependencySerializationTrait;
use Drupal\Core\StringTranslation\Translator\StaticTranslation;
/**
* Provides string overrides.
*/
class StringOverridesTranslation extends StaticTranslation {
+
+ use DependencySerializationTrait;
+
/**
* The cache backend.
*
```

Tested locally against 2.0.1 on Drupal 11.4.5 / PHP 8.3.30: applying this patch resolves the Views UI AJAX error with no other observable side effects, and String Overrides' string-replacement functionality continues to work normally.

## Environment

- Drupal core: 11.4.5
- PHP: 8.3.30
- String Overrides: 2.0.1
- Reproduced with only core modules required for the repro steps (Views, Views UI) enabled alongside `stringoverrides` — not specific to any other contrib module on the site.