Add URI Language Identifier to core?

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