Add URI Language Identifier to core?

Another attempt: https://github.com/ci-bonfire/Sprint/blo...8n.php#L70

Ah, dang, you had to bring me into this discussion didn't you?

The version that we're implementing there is very simplified and only supports the first URI parameter to check against. It misses so many other things that would be needed to add true localization, but we're trying to add some basics. However, it was a really simple problem that could have been done in just a handful of lines in a MY_URI class so I'm not sure if that's something that needs to be in core, honestly.

Support Development •  CodeIgniter 4 Foundations • Practical CodeIgniter 3  • CodeIgniter Tutorials

@kilishan

But despite of some doubts and difficulties it is doable, right? :-)

I voted No, because I do not want the framework to dictate how I choose to handle multi-language implementations.

This is absurd sentence .. How you handle languages in a PHP script ? with CSS / JS or with PHP ?
And if you use CI for your PHP code why not to have an easy option to manipulate languages?

And at the end, you are always are free not to use it but to think for another faster and better way to handle languages..

Like query strings? Language subdomains (i.e. en.example.com; this is more common for large companies)? Stored in a cookie or session variable (possibly even on top of a user profile setting)? The HTTP Accept-Language header (in fact, this is the only method that you can argue to be a standard)?

There are many ways and preferences on how to implement this, and there's nothing absurd about the statement that you quoted.

Its absurd because developer always will have the option to decide either to rely on the framework or on something else..

50% of devs may not use such element but other 50% of devs may use it. 
I think that 50% are more than enough add it inside the framework. 
And no one from the 1st 50% will be forced to use it. 

Best VPS Hosting : Digital Ocean

I voted No, because I do not want the framework to dictate how I choose to handle multi-language implementations.

This is absurd sentence .. How you handle languages in a PHP script ? with CSS / JS or with PHP ?
And if you use CI for your PHP code why not to have an easy option to manipulate languages?

And at the end, you are always are free not to use it but to think for another faster and better way to handle languages..

Like query strings? Language subdomains (i.e. en.example.com; this is more common for large companies)? Stored in a cookie or session variable (possibly even on top of a user profile setting)? The HTTP Accept-Language header (in fact, this is the only method that you can argue to be a standard)?

There are many ways and preferences on how to implement this, and there's nothing absurd about the statement that you quoted.

Its absurd because developer always will have the option to decide either to rely on the framework or on something else..

50% of devs may not use such element but other 50% of devs may use it. 
I think that 50% are more than enough add it inside the framework. 
And no one from the 1st 50% will be forced to use it. 

Sure, you won't be forced to use it, but having it built into the very core of the framework is a form of endorsement, an officially supported method, or whatever you wish to call it. And that is for a feature that can be implemented in at least 5 different ways that are already mentioned in this thread, meaning that we'd be satisfying 1 of 5 perfectly proper and valid use cases, leaving the rest of them uncovered.

Having that said, how would you like it if we chose another one of the 5, one that you wouldn't want to use? Wouldn't you feel that the framework is (indirectly, but still) dictating how you implement language switching?

Also, you say 50% is more than enough, but 50% of what? And how did you come up with that number?
Is it 50% of CI users? Or is it 50% of CI users that do implement language switching?
That is pure speculation, considering that (as I already said) it's only 1 out of 5 possibilities.

I took the values from the JSON files, codes there are with dashes (pt-BR, es-419), here is copy/paste of the English one:

Apparently, I was mistaken, Unicode LDML specifies that either a dash or underscore may be used as a separator, and that BCP 47 identifiers are used in most cases. (BCP 47 being the same IETF syntax used by the W3C standard for language tags in HTML/XML.) Of course, BCP 47 does not permit underscores as separators, but the primary area of interest is the language/locale tags themselves, which are generally derived from the ISO 639 series of standards.

@mwhitney
"At that point, the system should be able to handle language tags in any number of formats, preferably with configurable choices between '-', '_', and '/' for the separators used between language tags and subtags as well as configuration of default language choices for the general tags as well as the lack of language tags, since all of these impact the ability to use those language tags with varying standards and extensions (or for use in a URL routing scheme)."

Re:
I agree with this, but to some degree, in this area it is easy to come to something quite complicated. Routing by language segment implementation actually is the easy part.

Dashes or underscores - this is solvable, it is not quite important now.

That's all, more or less, my point. The routing is the portion most subject to the whims of the individual user. Language and locale tags have standards which define them in ISO 639-x and a series of IETF RFCs referenced as BCP 47 which have been adopted by the W3C for use in language attributes in HTML/XML. If the Lang class could understand language tags with a reasonable amount of variance (e.g. allow definition of the separator as a method argument), all of these other issues become much easier for the developer to solve in a manner that adheres to best practices.

The tricky part is how external components (PHP or JavaScripts) identify languages, well, they do this in different ways:
PHPMailer - https://github.com/PHPMailer/PHPMailer/t...r/language
CKEditor - https://github.com/ckeditor/ckeditor-dev...aster/lang
Datatables - https://github.com/DataTables/Plugins/tree/master/i18n
etc.

Translation between language identifiers is inevitable.

I agree that this is inevitable (and even necessary for short-term compatibility within CI itself, given the current language "idioms"). I even like the way you have implemented it so far.

I don't think it's particularly tricky, once you have a method for dealing with standardized language identifiers. As you've shown in your own case, a simple mapping between the standard identifiers you already have and the component's non-standard identifiers is all that's needed.

PHPMailer and CKEditor may not even need any significant mapping, in this case, and any mapping can be handled when integrating the component into your project. It may even be the case for any given project that someone has already created a mapping like this.

Bonfire

Practical CodeIgniter 3
CodeIgniter Testing Guide

http://blog.jquery.com/2015/04/23/announ...alize-1-0/
CLDR again.

I prefer subdomains for langs, and URL segments for langs just forces devs to conform to something that should be their choice. Community Auth demonstrates subdomains for langs, but I wouldn't want to force people to always use that concept for langs. If I could make all of the decisions, CI4 would be a minimalistic framework where anything besides the core was a separate component.

Expert Website Development - Temecula, CA
Community Auth For CodeIgniter 3

I don't understand that logic with "prefering" subdomains or other..

All projects are different some times you can make subdomains sometimes you can't.
If you are making some selling script you can't force clients to register subdomains for languages but its good that you have the option to suggest it, same for as part of the urls or even at query string..
I don't understand why any one will be against something that can be useful for others.. Its not a private framework .. it was in the past as for Ellislab but now I think its not...
So start thinking for what will be good for All not just what you will like or not !

Best VPS Hosting : Digital Ocean

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.