Problem/Motivation
I have problems again with a site with multilanguage defined, I think that we have incomplete work there, as we end up setting the endpoints as LANGCODE_NOT_SPECIFIED : that covered a site with a changed default language(in /admin/config/regional/language ) Now, it's not working as it should (tldr; langcode_not_specified will not ensure unlocalized urls since D10.1.x ). But also and more important, this way of defining language is not recommended; in config form can be read:
> The site default language can also be set. It is not recommended to change the default language on a working site. Configure the Selected language setting on the detection and selection page to change the fallback language for language selection.
So in a recommended multilanguage site, it is recommended to leave the English as default (in /admin/config/regional/language ), and use the detection and selection (/admin/config/regional/language/detection) fallback option ( Last Selected language settings in /admin/config/regional/language/detection/selected ). In such configured site ActivityPub endpoints are not working as it should because we'll get endpoints with mixed langcodes, as by default, the url prefix will add the langcode for every language, and as we saw in first
multilanguage issue →
, it's something that is not expected by other activitypub services (language alias in actors are not used) as changing the interface or content language will change the actor endpoint, and if self link changes and is not equal to id, the actor could not be ensured; so it's impossible to be discovered by other parties (it can be seen in how mastodon checks webfinger ids in https://github.com/mastodon/mastodon/blob/0479efdbb65a87ea80f0409d0131b1... ).
So I think that we need a way to provide non localized url by now, not only for actor ids, also for its properties (inbox, outbox, following, followers, etc.) How can we make it work again and why using LANGCODE_NOT_SPECIFIED, the way how we workaround by now is not working?
This is easy to see in https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/langu... , if using NOT_SPECIFIED, it will use to current language (with its prefix).
First because of
https://www.drupal.org/project/drupal/issues/2883450
🐛
Missing url prefix on language neutral content
Fixed
( that makes non specified lang not imply prefix removal).
Steps to reproduce
Install site.
Enable multilingual and add another language, set detect and select language as it needs to be.
Enable activitypub.
Check if actors are discoverable by other services.
Proposed resolution
Lucky for us, it was also a problem by openid module and since
https://www.drupal.org/project/drupal/issues/3385550
🐛
Language negotiation breaks updating Drupal 9 to 10
Needs work
drupal core let us use LANGCODE_NOT_APPLICABLE as a language without prefix. (like in https://git.drupalcode.org/project/openid_connect/-/blob/3.x/src/Form/Op...)
So this could be a way to go by now! But it may be changed in the future as said in
https://www.drupal.org/project/drupal/issues/3385550#comment-15311785
🐛
Language negotiation breaks updating Drupal 9 to 10
Needs work
(to address sticky ui translation).
Just guessing but if this happen maybe we could reimplement the toUrl for activitypub entities to remove the language option while they are not translatable, or we could add a new OutboundPathProcessorInterface::processOutbound just for activitypub endpoints...
Anyway, by now changing language to not applicable will make everything work as it should. I'll provide a MR that will change LANGCODE_NOT_SPECIFIED to LANGCODE_NOT_APPLICABLE will cover the by now not unlocalized outbox and inbox, and also will try to enhance the functional tests to cover the use case.
Remaining tasks
One other question here may be if actors need to be translatable, as it's not yet implemented in the way specified by spec ( being by context https://www.w3.org/TR/activitystreams-core/#defaultlangcontext or being by https://www.w3.org/TR/activitystreams-core/#naturalLanguageValues ).
Do we need a translatable actors? maybe when someone needs it we can see how we can offer... but by now I choose the not applicable to generate unlocalized urls for actors endpoints.