Why does Kohana's I18n suck

Introduction

I18n = Internationalization = I18[letters]n

I've been using Kohana framework for quite a long time, even since 2.x. Originally it was just a slightly improved CodeIgniter that I’ve hated right after the first project. The only advantage of CodeIgniter over Kohana is a plenty of docs (really, framework should be buried but there is quite a number of docs and tutorials; unfortunately Kohana lacks for it). 3.x branch separated from the fucking CI and released as an independent small, fast and clear framework. It suffered (and suffers) from the lack of documentation (which is represented by API browser and few usage examples) even more, though.

However, it’s not a problem to google some information about it or to take a look at the source code. So another website tends to be mutilangual.

The usual approach

How is it made usually?

Application deals with identifiers like ‘form.validation.alphanum’ or ‘footer.copyright’. Each of them has a match for the languages the website uses; it is stored somewhere else (translation files, database, any key-value storage), but alwaws separate from the source code.

What usually happens if there is no translation? It depends on developer’s and translator’s attitude to the project. Could be a string that matches the identifier in default translation, could be just idetifier (for the case there is no translation in any language or the developer is a loafer).

What does Kohana offer

I18n in Kohana itself consists of few lines of code so its reading and understanding won’t take long. It’s not an internationalization facility, actually, it’s just for translation strings and performing substitutions in those strings. It has nothing to deal with currency, date and number formats, language features, etc.

So the point is to use string in the default language as an identifier.

In this case user never gets a faceless identifier. In the worst case it will be a string from default translation, which is always exists because it is used as a key which means it is hardcoded. One more feature: default translation comes ‘for free’ meaning used resources. Default translation doesn’t require translation (default language is an identifier, that’s no need to select a matching string in this case). Well, seems pretty cool at some point. Moreover, the Kohana maintainers seem to be blindly sure in its absolute coolness.

Curiosity about possible best practice and dealing with cons of this approach made me to consider googling. And what? Seems like nobody gives a damn about some obvious misses.

• It makes developer to think twice about any phrase being written. It’s not possible to type just a key (about.description or so) and to forward the textwork to whoever cares about texts and whose time is cheaper.
• Just imagine that native language is not English. That original translation could say even less that [usually] English-speaking identifiers that [usually] stores the essential meaning, short but clear. Then, is it a problem to return a string from default translation which is [usually] complete? Yeah, the case it’s incomplete brings us to the prime argument of ‘identifiers vs complete strings’ discussion.
• Any change in default language forces changes in all the translations: it is necessary to change a key in all the non-default languages.

So, considering all the cons, aren’t that ugly identifiers an appopriate price for separation source and translation and all the flexibility they provide?