Return to Answer

###Topic's premise

###What the URL can be made of?

###Available options ... as I see them.

###Query is Α and Ω ..

###Language as parameter

###Isn't here a third option?

##Which approach to use?

###Can it be done in Laravel?

###It's routed. What now?

Topic's premise

What the URL can be made of?

Available options ... as I see them.

Query is Α and Ω ..

Language as parameter

Isn't here a third option?

Which approach to use?

Can it be done in Laravel?

It's routed. What now?

###It's routed. What now?

As a result of all you would end up with two valuable pieces of information: current language and translated segments of query. These values then can be used to dispatch to the class(es) which will produce the result.

Basically, the following URL: http://site.tld/ru/blog/novinka (or the version without '/ru') gets turned into something like

$parameters = [ 'language' => 'ru', 'classname' => 'blog', 'method' => 'latest', ]; 

Which you just use for dispatching:

$instance = new {$parameter['classname']}; $instance->{'get'.$parameters['method']}( $parameters ); 

.. or some variation of it, depending on the particular implementation.

While they all interconnected in different ways, from CMS point of view they are managed using different UI elements and stored differently. You seem to be confident in your implementation and understanding of the first two. The question was about the latter aspect.

First, you need to match the query to one of defined routing pattern (if your pick is Laravel, then read here). On successful match of pattern you then need to find the language.

You would have to go through all the segments of the pattern. Find the potential translations for all of those segments and determine which language was used. The two additional sources (cookie and header) would be used to resolve routing conflicts when (not "if") they arise.

In this case too there is a secondary source of language: the cookie value. There is no point in messing with Accept-Language header, because you are not dealing with unknown amount of possible languages in case of "cold start" (when user first time opens site with custom query).

Yes, technically you can combine both approaches, but that would complicate the process and only people who want to manually change URL of http://site.tld/en/news to http://site.tld/de/news and expect the news page to change to German.

While they all interconnected in different ways, from CMS point of view they are managed using different UI elements and stored differently. You seem to be confident in your implementation and understanding of the first two. The question was about the latter aspect - "URL Translation? Should we do this or not? and in what way?"

First, you need to match the query to one of defined routing patterns (if your pick is Laravel, then read here). On successful match of pattern you then need to find the language.

You would have to go through all the segments of the pattern. Find the potential translations for all of those segments and determine which language was used. The two additional sources (cookie and header) would be used to resolve routing conflicts, when (not "if") they arise.

There is also a secondary source of language: the cookie value. But here there is no point in messing with Accept-Language header, because you are not dealing with unknown amount of possible languages in case of "cold start" (when user first time opens site with custom query).

Yes, technically you can combine both approaches, but that would complicate the process and only accommodate people who want to manually change URL of http://site.tld/en/news to http://site.tld/de/news and expect the news page to change to German.