Poll: URI language identifier in core? You do not have permission to vote in this poll. |
|||
yes | 22 | 52.38% | |
no | 11 | 26.19% | |
maybe | 9 | 21.43% | |
Total | 42 vote(s) | 100% |
* You voted for this item. | [Show Results] |
Add URI Language Identifier to core? |
(04-28-2015, 02:49 AM)ivantcholakov Wrote: Once we have the URI-segments implemented in a transparent to the routing system manner, then we can have sub-domains implementation also. This could be configurable. It's either transparent to it, or built into it ... can't be both. If it is the former, then it has nothing to do with URIs and this topic is irrelevant.
(04-28-2015, 04:18 AM)Narf Wrote:(04-28-2015, 02:49 AM)ivantcholakov Wrote: Once we have the URI-segments implemented in a transparent to the routing system manner, then we can have sub-domains implementation also. This could be configurable. Simply, the initiator of this thread formulated the topic in narrow meaning. my-site/en/my-page - this is what he wants. en.my-site/my-page - this is possible also, with a small amount of additional code, why should we neglect this option. (04-28-2015, 08:14 AM)ivantcholakov Wrote: Simply, the initiator of this thread formulated the topic in narrow meaning. This is why I think it would be better to have a method of recognizing language codes, rather than focusing on a particular routing solution (or a particular set of routing solutions). Once something like that is in place, it becomes fairly easy to give a couple of examples of how it could be utilized by the routing to support the developer's needs, rather than forcing them to choose between a built-in method or implementing their own solution. Besides, any of these routing methods could be implemented at the server level, which would make the routing within CodeIgniter a non-issue. Code: $route['{?lang}/something'] = "Go to hell"; This can be easy parsed as: If you catch "something" and it has or it has no prefix LANG (which will have some kind of validation not anything can be accepted) > Go to hell.. This LANG can come as config from config.php and it can be used at all places where devs need it. With optional allowed langs list and optional supporting locales as en / en-US with proper validation.. For those who are using subdomains this wont have any effect as they wont add it to their route configuration.. But they still can use that LANG at their CI application (skipping routes) by manipulating it depending on their subdomains.. like.. Code: fr.domain.com > set_item( 'lang', 'fr') Best VPS Hosting : Digital Ocean
CI4 could implement this core feature as:
1) Rule: The URI language identifier (if present) must be first segment in route path. for example: http://localhost/es-US/controller/action 2) The user must configure if the URI lang feature is enabled. If it is not enabled, CI4 must treat route path as always, unchanged. 3) if the URI lang feature is enabled, the user must configure the regexp that the URI lang must match to be considered as a language identifier. This is because URI lang may be not specified in the URI. for example: http://localhost/es-US/controller/action is a valid URI and http://localhost/controller/action is valid too! 4) The route handler: if first segment in route matches the regexp defined then it can be stored somewhere inside the CI instance and continue processing the rest of the route as always, unchanged. 5) The application gets the stored language for the request and executes whatever must be done, (probably loads a language file...) Here I link to a post (of my own) with this proposition implemented using just URI Callbacks. http://forum.codeigniter.com/thread-62100.html regards!
For clarification, I would say in a simplistic way: "Trasparent" means don't touch $route[...] settings for language support.
|