Good catch. I double-checked the framework code, and here is the actual execution order from my understanding -> `ignition.php` and `Core.php`, the flow is roughly:

1. Config files load
2. Custom routing is applied
3. SEGMENTS are generated from the routed URL
4. Interceptors run
5. Core dispatcher starts
6. Dispatcher decides whether the request is:

• a vendor asset
• a module asset
• a controller request

One simple way to support any language prefix without breaking module assets is to restrict the language segment to something predictable (like a two-letter code) instead of using `(:any)`.

For example:

This allows URLs like:

The interceptor can then read the first segment (`en`, `fr`, etc.) and set the active language as already implemented.

Thanks DaFa. I didn't know you could put those constraints on the custom routing. And thank you for having written the module in the first place.

Before I read this, I issued some pull requests to your repo updating some of the above. The documentation will need to be later amended to include what you said here.

Do you think you will look at those pull requests for merging, or not? One is just renaming before to init, one adds an option for having a message for a missing translation, and the final one adds to the documentation. I could see them not aligning with what you have.

You have been very helpful. Thank you for everything.

G’day PartialShawn,

Thanks for the PRs and the kind words, much appreciated.

I’ve been flat out with work and only just had a chance to look through them. Since then, I’ve applied the regex routing refactor, pulled in the rename from **before → init**, and left a couple of comments on the remaining PRs with some small adjustments requested.

Once those tweaks are made and rebased onto `main`, I’m happy to merge them in.

Thanks again for contributing to and improving the module.