But I don't think it was reviewed properly. So anyway what does everyone think? Should such feature be part of FuelPHP or not?
But PLEASE read everything before commenting. I'm pretty sure I've refuted all pointed out issues if not please say. Also I prefer valid arguments not just "No, because I don't like" (same goes for "Yes, because yes")
I listed benefits it will give. Maybe even not all but most.
Dealing with i18n is very application specific, and should imho not be part of the framework. If you incorporate this, you will "force" users to use this method. It might also impact the app, suppose you use this, support 'en' and 'fr', and have a controller called 'de'? Will 'de' be detected as language, or as controller to call?
The strength of FuelPHP is that we don't enforce the user to use a specific solution, the framework must provide the flexibility to allow you to use any solution you want.
If you want to use a setup with this kind of URI structure, you can do that in about 10 lines of code in your app.
Or deal with this in other ways, for example in a rewrite rule, which I use in several apps. I convert http://hostname/lang/this/that to http://hostname/this/that?lang=lang, and in my config.php I set the language to $_GET['lang']. No impact to that app whatsoever, and no core code changes needed.
About forcing users use this method, that's valid argument. But I think it doesn't really force. Because like now it's possible for everyone to extend Lang class with own needs. And here we're just giving default option for everyone who don't want to bother much.
For your question. It depends how you configure routes in config/route.php. Correctly configuring 'de' will be controller. Just take a look at implementation...
Yes, that's also good point. But like I said this doesn't really enforce using this solution. It doesn't change API. So how it would stop user from using his own solution?
While URL rewrite is actually quite good approach. There's few drawbacks. For example if you need to take supported languages from database. Or you determine languages from folder names in app/lang/ . In URL rewrite you have to manage that manually. But there's also some cases where URL rewrite would suit better. Anyway this feature doesn't conflict with your URL rewrite. In fact it's possible to improve this feature even more so in your case you wouldn't need to worry about $_GET['lang'] at all. It would be handled automatically. Of course then would have to add another configuration option in config/config.php
Since there are a lot of possible implementations, it does not belong in the framework. Dealing with i18n is (very) application specific, and we are very strict in this: application specific code will not go in the framework. We are not going to polute the code with stuff that is not generic.
Besides this, there is no need to change any of the core classes, as you can achieve exactly the same (strip segment 1 from the URI and assign it to the language) with a handful of lines of code.
+1 yes, actually you're correct. While it could be handy such feature. Actually there's no need to be it integrated. It can be simply provided as package.
In fact I just created such package https://github.com/davispuh/FuelPHP-Lang It simply extends Lang class and is outside from FuelPHP So for anyone who need such functionality should be quite easy to use it :)
Donate
