You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I guess you're talking about a local development/test setup, right?
For a live project I'd simply avoid including the subfolder in the URL by routing the domain (or subdomain) to that folder so that it doesn't show up in the URL.
As I'm also using unique domains/subdomains for local development (via dnsmasq) I haven't played around with a Symphony installation in a subfolder that shows up in the URL for a long time and probably won't find the time to test and fix this edge-case in the near future.
But if your're using version 1.2 I would recommend giving the current 2.0-beta a go: it supports the possibility to include the language-parameter as a url-query-string and that method will be perfectly compatible with your setup!
2.0.0 is working fine and offers a lot more flexibility than 1.X, but documentation isn't finished and I might change/add a few more details before officially releasing it. Hope to get this done till summer :)
Hi, Thanks for the reply.
This was actually tested on 2.0. I really wanted to use the url path so query param was not an option (altough I tested it and it did work perfecty even for a subfolder).
I've actually implemented a working solution (with a new if on the FrontEnd Language Detetcion flow). I can confirm it will work for language-codes without the hifen and region. Have not tested for those.
You are right, this problem arose from my dev environment but is it not possible it would be an issue for someone that only wants a symphony installation on a part of its website (a blog based on symphony inside a larger non-symphonic web app for instance).
Thanks again for the great work on this module and send me a message if you need help on the development to get it up and running before summer ;)
If Symphony's instalation is in a subfolder, the URL Path matching for the language will not be triggered
ex: application/pt/home/
As the matching is done against the match[1], this will always be the subfolder and never the actual language passed on the URI
A possible solution is to try and match it against any part of the URI but I'm not sure at this point what this might cause as a downside.
Thanks
The text was updated successfully, but these errors were encountered: