Spryker generally provides multilang via different domains, in one of our projects we needed multi l

UKAFY33RP

Spryker generally provides multilang via different domains, in one of our projects we needed multi lang via sub-directories so we did a small "hack" in the YvesBootstrap. this is also a blueprint how to maybe customize URLs via config rather than overriding provider classes https://gist.github.com/lsmith77/cdb6c0d5cf686c7792f8c9aa34f5a673

UKAFY33RP

note we also separated our projects into a public and private catalog on different domains, so this solution also includes a way to hide routes depending on the domain

Stanislav Matveyev

in one of our projects we needed multi lang via sub-directories

this is really specific case (not common)

Christian von Schassen

Thanks for sharing , Lukas! What would the URLs look like in that case? (Feel free to anonymize)

UKAFY33RP

f.e foo.com/en/about vs. foo.com/de/ueber-uns

UKAFY33RP

it also handles redirecting from the top level

UKAFY33RP

ie. if you forget to add a language

Christian von Schassen

Nice one. What would it do in case someone mixes Lang and term, i.e. foo.com/de/about ?

Unknown

@UJLM6CAFR 404 I would suggest
@UKAFY33RP Spryker by default uses a language path part in the URL. It is fairly easy to create multiple routes to the same controller actions using the existing controller provider mechanism. This way you can already have multiple (language specific) URLs pointing to the same controller action.

UKAFY33RP

@UJLM6CAFR don’t remember .. I might have added a redirect to the correct language

UKAFY33RP

but this is of course a project specific business requirement

UKAFY33RP

@UK5EG6PBM I am of course a Symfony framework developer and would wish Spryker would be build on Symfony full stack

UKAFY33RP

one of the biggest short comings of spryker that too much config is done via code

UKAFY33RP

specifically routing, services and config itself

UKAFY33RP

with this solution I now have a central location where any human can have an overview of all the routes

UKAFY33RP

in a compact format

UKAFY33RP

without having to override code which is impossible to quickly read to get an overview

UKAFY33RP

this on top of the fact that spryker offers no effective way to debug routes is a huge step forward imho

Unknown

one of the biggest short comings of spryker that too much config is done via code

That's a big advantage that Spryker has imho. No magic, it's all right there in code.

Unknown

with this solution I now have a central location where any human can have an overview of all the routes

Understandable from a project perspective. I guess for Spryker this is a no-go since it creates unnecessary coupling and I would agree on that

UKAFY33RP

imho dedicated DSL’s for services, config and routing increase clarity by a billion times and the out comes are predictable enough in most cases and I appreciate the “magic” a lot for services. but yeah that is a philosophical issue I have with Spryker and indeed a lot of people prefer it the way it is. some of my problems with the “code for config” approach is that then I would wish all the more for tools that could export this information in a compact format

UKAFY33RP

but with the above solution stakeholders can now actually see (and a technical PO could even adjust) the routing

UKAFY33RP

and to me routing isn’t something developers should need to care about all that much

Denis Turkov

Spryker by default uses a language path part in the URL.

@UK5EG6PBM we are working on some cool updates here. Lang will become optional and detached from URL definition in a new Router.

@UKAFY33RP as we would like to release own Router leveraging Symfony Chain Router power, maybe you could point out some interesting requirements we could consider to add?

Unknown

Thanks for the update @UJ8Q2T36E

UKAFY33RP

@UJ8Q2T36E approaching it via a custom router certainly makes sense .. especially in order to also be able to deal with this for categories

Denis Turkov

Right! If you have specific use cases / requirements we could validate them against the implementation. 😉

UKAFY33RP

@UJ8Q2T36E you can check with @UK5EG6PBM on that .. the project you know they took over also needs the ability to handle categories via sub-directories .. the hack I did to make this possible is indeed quite ugly and should be removed (if it hasn't been removed already)

Denis Turkov

Ok, thanks!