Welcome Guest, Not a member yet? Register   Sign In
Allow for route matching without need for {locale} placeholder for localized URI's
#1

CI4 requires you to add the '{locale}' placeholder within user-defined routes in order to match URI paths that *might include a locale code in the 1st segment. There's currently no way to force the router to match routes on such URI's without explicitly including the '{locale}' placeholder.

In CI3, I had to create my own custom routing logic that would automatically detect the 'locale code' from the first URI segment (if present). It would then set the locale globally for the request based whether or not it detected a locale segment. If no locale was detected, it would use the default fall-back locale (all of this is obviously similar to what CI4 does now). 

However, in contrast to how CI4 works, my solution would then completely remove the 'locale' segment from the internal URI mapping for all of CI's subsequent routing & URI logic. What this meant is that I no longer needed to constantly worry about dealing with the 'locale' segment when defining routes & dealing with URI paths / segments. 

(FYI, If I really needed to know if the original URI included the locale code, I would set a global flag during locale detection, 'uriLang = true', and use that as necessary)

Here's an example of what I'm describing in CI3 w/ my custom Router/URI handling:
Code:
// a route such as this: 
$route['product/:num'] = 'catalog/product_lookup';

// would work for all of the following URI's
// /product/100         // locale segment !found  ==> set locale to 'en' (default/fallback)
// /es/product/100    // locale segment  found  ==> set locale to 'es'
// /fr/product/100     // locale segement found  ==> set locale to 'fr'

// also, with a URI request for '/fr/product/100',
// the following code...
echo(uri_string()); 

// ...would output '/product/100', *without* the '/fr/' locale segment 

In CI4, there's still a need to add the '{locale}' placeholder within each&every defined route. Otherwise, the routes won't match. This is extra work that's unecessary and prone to error.

Also, the URI functions will redundantly include the locale within the URI, even when it's not always desired (example: when creating a 'switch language' widget that should switch the locale segment while still linking to the current URI path)

Feature Request(s):
It would be easier if there was a way to simply force CI to assume that there *can* be a locale segment present within the request URI, and, if present, to deal with it accordingly. It would also be helpful if other functions that dealt with the request URI, such as the URL helper, also provided a way to get the URI path *without* including the locale segment (if present).

I'm proposing that perhaps this functionality could be optionally enabled in CI4 via a config parameter, something like 'useLocalizedRoutes = true;' within Routing.php', or by some other means. The idea is to get CI4 to match defined routes regardlless of whether or not the locale segment is present. The logic for the HTTP Request & Router  logic would need to be adjusted accordingly.

Simplified example of how it could work:
Code:
// in CI4, instead of constantly
// having to do something like this:
$routes->get('({locale}/)?users', 'Users::list');

// ...a route such as this:
$routes->get('users', 'Users::list');

// ... could be forced to match these URIs:
// '/users'
// '/en/users'
// '/fr/users'
Reply
#2

bump...

Are people still active on this forum, or have things been abandoned???
Reply
#3

Is this what you need?
Reply
#4

IncludeBeers Web Site Multilingual web  site.

Creating a multilingual website with CodeIgniter 4 (part 1)

Creating a multilingual website with CodeIgniter 4 (part 2)
What did you Try? What did you Get? What did you Expect?

Joined CodeIgniter Community 2009.  ( Skype: insitfx )
Reply
#5

What you are offering is not for everyone.
 Why do you need a locale at all if it's not in the URL?
 You need a switch+sessions/cookies.  How it works in CI4 - is a general practice.
Reply
#6

It seems that those of you who replied did not understand my feature request.

I wasn't asking for information on how to setup & use localized URLS; I already know how to do this. I DO understand how to use '{locale}' placeholder within the routes config (I even mentioned this in my post). I also wasn't referring to the use of session cookies (I don't even understand what that has to do with this request).

The goal of my request was simply to suggest making URI-based locale handling more transparent & easier to use within CI4 by removing the necessity of including the {locale} placeholder in every single route which might be subject to localization, and to remove the locale segment from CI's built-in URI libraries/functions.

Why? Well, if a site has been built & configured to implement URI-based localization, it's UNDERSTOOD that there *MIGHT* be a locale string present in the first segment of the request URI, so there's really no need to include this segment within CI's internal routing & URI handling features; it will only complicate any further processing of the request routes & URI. CI should just handle the presence of a URI locale segment auto-magically and then allow the user to handle things accordingly.

Another example:
Assuming that I've setup my site to handle localized URL's,  with a request for either of the following two URL's...

https://mysite.org/foo/bar/baz
https://mysite.org/en-us/foo/bar/baz

...the only URI segments of IMPORTANCE would be '/foo/bar/baz', and NOT the optional locale string '/en-us/'. It shouldn't be necessary to include the {locale} placeholder in a route for '/foo/bar/baz' in order to match either of these URI's, and it subsequently also doesn't need to be included in CI's request URI object.

Again, having to do something like "$routes->get('({locale}/)?foo/bar/baz', 'Foo::bar/baz')" is UNNECESSARY. 
The single, simple route of "$routes->get('/foo/bar/baz', 'Foo::bar/baz')" should suffice for both URI's.

IOW, I shouldn't have to care if the locale segment was present in the original URI request. The framework should just handle it and allow me to check for its presence by some other means (via something like '$request->hasLocale()' or '$request->getUriLocale() should be sufficient).

All of this seems fairly obvious & self-explanatory, but apparently my explanation isn't being grokked.

In any case, I'm now going to be forced to build this functionality myself, which means having to dig into CI4's system libraries, which was something I wanted to avoid  before attempting to bring it up as a feature request. However, if the CI community doesn't appreciate or understand the value of this functionality, then I guess I'm on my own.
Reply
#7

This is one special set of features that should be called "automatic locale routing".
Such a feature would be useful in your particular scenario.

But it changes many existing behaviors.
E.g., the {local} segments that actually exist in the URI would disappear from the code.

I do not know if such a feature will be accepted, but if you think it would be useful,
please send us a Pull Request.
Reply
#8

I don't understand the translation well. What happens if site.com/foo/bar /{locale}/baz? How can the router figure out where the locale is?
The framework has a more general set of functionality. Therefore, there are always times when you need to create exclusive solutions yourself.
Reply




Theme © iAndrew 2016 - Forum software by © MyBB