1
votes

Inconsistent? In the chapter about translate behaviour in the CakePHP 3 book there are three-letter codes used, derived from English names rather than native names of language like ISO 639-2:

eng (english)
spa (spanish)

with this example to change the language:

I18n::locale('spa');

But in the chapter about Internationalization and Localization it says

Translation folders can either be the two letter ISO code of the language or the full locale name such as fr_FR, es_AR, da_DK which contains both the language and the country where it is spoken.

And the example to change the language looks like this:

use Cake\I18n\I18n;
I18n::locale('de_DE');

So is the chapter about the translate behaviour outdated or are all methods correct? I think it's probably better to be consistent and use the same language codes in both, Translate behaviour and Internationalization and Localization?

Also the i18n schema table example defines the field locale as varchar(6)... if 3-letter-code is required varchar(3) should be enough... But even if I use full local codes like fr_FR varchar(5) would be enough. Why is the example schema using varchar(6)?

1
There are 6 letter languages codes in use such as es-419AD7six

1 Answers

3
votes

I wouldn't say the Translate behvaiour chapter is outdated, because it will work just fine. The Translate behavior doesn't impose any restrictions on the language identifier, the possible values are only restricted by the locale column type/size, ie using spa will work just fine. The length of 6 may be just a typo, or maybe it's taking UN M.49 into account (es-419), who knows.

The translation folder names however are indeed restricted, restricted to the rules applied by ext-intl. To be exact, the folder names are figured from the return value of Locale::parseLocale(), which for example will return es for spa.

See Source > \Cake\I18n\MessagesFileLoader::translationsFolders()

So you could actually use three letter codes like spa in your app and your translation table, but the translation folder would have to use the two letter code, ie es.

I agree that it would be good to have this consistent throughout the book, maybe with some additional info about what happens in the background. You may want to create an issue (or even fix it yourself via a PR) over at GitHub.