User's language is "wrong" in URL-Hooks

[BernhardBaumrock]

Short description of the issue

Use-case: I wanted to create an url-hook to open a PDF or, if any page was saved in the meantime, re-create that pdf on the fly and redirect to that file. The PDF is in english (default) and german.

The problem is that the language of $this->wire->user is always the default language inside the hook!

public function init() {
  wire()->addHook("/create-cv",                 $this, "createCV");
}

public function createCV(HookEvent $event): void
{
  bd($this->wire->user->language); // always the default language!
}

Expected behavior

I'd like to get the user's current language inside the hook via $this->wire->user->language

Workaround

I came up with this workaround:

public function init() {
  wire()->addHook("/create-cv",                 $this, "createCV");
  wire()->addHook("/de/create-cv",              $this, "createCV");
}

public function createCV(HookEvent $event): void
{
  bd($this->wire->user->language); // is now either default or de
}

So that tells me that because the hook is applied to the root-page / PW thinks that the language is always english, but that's not really the case in my scenario.

I understand why it's technically always english, but I think it should be the current language.

[ryancramerdesign]

@BernhardBaumrock Do you have the LanguageSupportPageNames module installed? That would make the URL dictate the language. But if you don't have that module installed then it should fall back to whatever the user's configured language is.

[BernhardBaumrock]

Hey @ryancramerdesign yes, I have installed that modules. It's a multilang site both on the frontend and the backend, so I need multilang page names as well.

I understand the way it works at the moment from a technical point of view. Calling the hook on /create-cv looks like a page path of the default language. So for german I'd need to call the endpoint /de/create-cv.

The problem is that I don't think that this makes sense for url hooks. I can't think of any use case where I'd want the language to be defined by the hooks url. Also, I don't think that it makes sense to attach hooks for all languages. I think for hooks it should always be ONE endpoint and the endpoint should be aware of the user's language.

Jürgen had the same problem some time ago: https://processwire.com/talk/topic/27370-new-url-hooks-do-not-consider-user-language/?do=findComment&comment=225343

Imagine I want to load content via AJAX for a modal. I'd want to create one endpoint, eg. /load-modal and that should return content in the user's language. I'd not want to have to think about that on the frontend implementation because PW does that all the time automatically. Like with any $page->title call etc.

If you think that would be too risky to change now as some might be relying on that behaviour even if I can't think of a use case maybe you could make the user's language available from within the hook? Maybe $event->getUserLanguage() or something?

[mpsn]

User::getPreferredLanguage($page = null) which grabs the best match from settings or language headers?

Regarding ajax: I've deliberately used the current behaviour for ajax requests by stuffing the local url into whatever script did the client side work. $pages->get(modalpage)->localUrl($user->language)
Ensuring that the ajax-requested page always uses the same language as the originally requested one. By identifying the modal page via ID/template/etc you don't have to care about the current users language, and frontend code stays the same. Adding a language attribute to the HTML (and later on, as parameter to ajax requests) would also be possible.
Well, these are not hooks, but it works within PWs current language identification.

I agree that there are some downsides with the current approach. Like having to manually redirect visitors to their preferred language on their first visit to the root url, and other language-dependent redirects can also be a pain. But to be fair, such behaviour depends on the use case, and i'd argue that (while it certainly could provide some easy call to determine a preferred one) it is not neccessarily PWs job to remember the last used language.
Which leads to my personal conclusion that URL hooks should always be default language [even if the hook matches a language path. and even if the user is logged in?] because there is no associated page, and that language handling inside URL hooks should always require explicit programming.