cake language domain

[AD7six]

The cake language domain has been removed just before the 2.0 release.
I'd mainly just like to know why as going back to putting loads of
unchanging strings back into app po files doesn't make sense to me. At
all.

Refs:
http://cakephp.lighthouseapp.com/projects/42648/tickets/2103-default-domain-for-fields-label-translation
https://github.com/cakephp/cakephp/commit/6bf6d799793ffe0dd0da8b6965dabd587d572d0f
(and a few other follow up commits)

Some background:
Translating apps is hard work. It's laborious, time consuming and
relatively expensive.

One of the most annoying aspects of translating cake apps in 1.3 was
that you generate your pot files, send them off to get them
translated, and have to answer questions like "what does 'Running %s
%s %s' or 'Controller::__construct() : Can not get or parse my own
class name, exiting.' or etc. mean?". As these strings are not end-
user strings, you end up either ignoring the core from the scope of
the extract task, manually or otherwise stripping out these unwanted
translations, or putting up with the fact you're sending po files off
that are 80% irrelevant.

This problem is made worse by that fact that I have _never_ had a
project where you write the code, all of it, then send of the po files
to get your app translated, and you're done. It's always iterative,
but a month could pass between translation-iterations. That means that
a) you might be sending the files to a different translator and b) you
have to explain, again (even if it's the same translator) to ignore
all these irrelevant translations. It's made even worse if your
translator is simply a native you know - they _will not_ understand
how to use po edit correctly no matter how many times you explain it.
Infact that applies to professional translators I've worked with too.

So for 2.0 I took a look at addressing the problem and used the
following domains within the core:
"" => no domain, use app translations. Appropriate for anything that
changes _project by project_
"cake" => core strings that do not change from project to project
"cake_dev" => messages just for the developer
"cake_console" => messages just for the developer, when using the
console

Some examples:

// Paginator Helper
$title = __(Inflector::humanize(preg_replace('/_id$/', '', $title)));
// Time helper
__d('cake', 'Today, %s')
// TestsuiteShell
__d('cake_dev', 'Please install PHPUnit framework <info>(http://
www.phpunit.de)</info>')
// BakeShell.php
__d('cake_console', 'What would you like to Bake?')

Now things are IMO quite confused in the core. The default pot file
has 200 definitions in it when ran on an empty project. That's
typically 200 translations that are quite simply: noise (I mean,
seriously: who has ever translated the msgid s that come out of
scaffolded views? Why must every project translate month names?).

Cake ought to be in a position to be able to distribute cake.po,
cake_dev.po and cake_console.po files to immediately i18n-ize an app
by default, and each application only needs to translate (and/or
override) translations they want to.

So: why the step backwards? Does anyone else have an opinion on the
topic?

AD

[ADmad]

Andy I share your pain about unwanted strings in app's default.po and have experienced the same issues you discuss. The month names is a perfect example of string that shouldn't be in default.po. You just translate them once save in a separate file (cake.po) and be done with. Strings from your app and the ones from core should be separate and not mixed in the same file as those form core are gonna be same always. Adding the 'cake_dev' domain was a good improvement but other strings from core which could show up for the end site user should also be in a separate domain/file.

[mark_story]

The main reason I changed it was that a ticket on lighthouse was
opened about them missing from the app domain, and put into the
cake.pot file.

I'm indifferent either way. I don't really do much in the way of
translated applications. Perhaps I was wrong in removing the cake
domain. If people think it was wrong, feel free to revert the
changes :)

-Mark