Deprecate and remove procedural code from content_translation.module

There is a deprecation being hit somewhere.

content_translation_language_configuration_element_process() is still being called directly.

I left a couple of comments to consider.

You might need to add before/after examples to the two existing change records. I usually have to do it.

The addition of ContentTranslationManager->access() might need a change record. Maybe https://www.drupal.org/node/3567484 can be edited to serve both purposes.

Thank you for considering my feedback.

It seems it was already in https://www.drupal.org/node/3567484.

I don't remember what I was thinking the other night when I wrote that comment. Maybe I thought that it needed its own change record separate from the deprecation or something. But it's OK the way it is now.

The new changes look good to me. RTBC.

Left a few minor notes.

There are existing issues about some of those functions, such as #2155787: Introduce more flexible access control for content translation operations but they are _very_ old. Still, I think we might want to give the new content_translation maintainer a chance to comment on this.

There's also #3497534: [meta] Clean up content_translation hooks and legacy files that @nicxvan created, that's also about restructuring the hooks *and* remaining functions, the hook part is still something we want to refactor, so we can repurpose that I think.

re: #12: In contrib, there are 2 modules using it:

• data_policy uses this in an upgrade path from 8.x-1.0-rc2 to their first stable release. They are at 2.0.0 already.
• The other occurrence is social_language_modules_installed, in the submodule social_language from OpenSocial.

Both are part of OpenSocial (so easy to ask for feedback if needed).

As this was underscore prefixed, not sure if we really need to deprecate: the impacted surface is quite low, and this was using the procedural PHP version of "hey this is a private function subject to change without notice".

I haven't reviewed the MR itself, so leaving the tag Needs subsystem maintainer review for now.

Just a heads up we've worked with the core committer team to come up with a policy since there are so many functions to manage as part of this initiative.

We will deprecate all functions, if they are underscore the removal is drupal 12.

Edited to add that the description of the deprecation decisions are in the parent issue.

I updated the deprecation versions, this needs a rebase.

I think this is pretty close, @penyaskito not sure if you've had a chance to review. I would also like to point out that I think @berdir added the tag so you could review whether we could deprecate and move the functions as is here of they should be addressed in the other issue.

In general we've been keeping the momentum and addressing them in issues like this, but if there is a pretty significant API change issue that has momentum already (or is pretty close and just needs a reroll) then we've made exceptions and resolved the functions in the older issue.

However looking at the other issue one of the remaining tasks is to still agree on an approach and is 13 years old, I'd push rather strongly to just deprecate and move them like we did here, then address that issue as follow up once everything is in classes.

Only had some nits about service injections that we better take care of at #3497534: [meta] Clean up content_translation hooks and legacy files, so ✅ from my side.

I think with this we also make the path forward easier for more granular access controls in #2155787: Introduce more flexible access control for content translation operations.

updated search link for #12: _content_translation_install_field_storage_definitions It seems like for D10+ modules there is only one usage. (the search engine doesn't index profiles) the matches from gitlab include modules that are not compatible with D10+

Sorry, needs another reroll.

Tests failing:

Symfony\Component\DependencyInjection\Exception\RuntimeException: Cannot autowire service "Drupal\content_translation\Hook\ContentTranslationFormHooks": argument "$contentTranslationWidget" of method "__construct()" references class "Drupal\content_translation\ContentTranslationEnableTranslationPerBundle" but no such service exists.

Reviewed the individual commits since #21 and CI is green, back to RTBC.

Applied to main, committed and pushed. Doesn't cherry-pick cleanly so keeping open for backport.

Reviewed the changes match what was committed to main.

Did you know? In gitlab UI, folders come first on commits vs files on a root folder, but the opposite for MRs. So annoying to compare.
Edit: so annoying I reported it https://gitlab.com/gitlab-org/gitlab/-/work_items/593851

Committed and pushed 2606e2747e9 to 11.x. Thanks!