Build complex self-service web applications, using content types and Fields generated via Features modules.
Rolled out as an install profile, because the site/code/configuration has to pass through the whole stack of dev/test/preprod/prod environments.
The sites we build are only presented in a single language (so far) so stricly speaking we could have made everything in non-English (Danish, that is).
But that approach would - once and forever - prevent support of more languages. And all code would be filled with non-English gibberish texts; non-Danish speaking developers would be left entirely in the dark.
And .po files are just great; non-developers can write copy entirely separated from code, and .po's work great with install profiles.
We realized at an early point that field label translation simply doesn't work - neither by means of core Locale, nor by the i18n Field module.
i18n Field only translates labels in a few contexts (like not in form validation) - and then it uses 'textgroup', which effectively ruins .po workflows.
And Features only extract label and description from fields, not properties like list option labels.
Another thing is non-contextual translation... Reusings translation (across contexts) may be great in a simple site.
But in our case we have lots of (content type) forms, reusing several fields - and then the editor tells you that 'bicycle' has to be phrased 'bike' in some of the forms (but not all).
First off, we did a (terrible) hack of setting the admin's language to non-English during site install. That made translation work, sort of.
No, actually all fields simply got build once and for good with Danish labels.
If somebody/something (like cron) later changed the admin's language to English, Features would re-build all content types and fields - turning the site into an unwholesome mixture of English and Danish.
In the end I started digging into form and field hooks, trying to figure out when to 'get in' and do a little translation.
Localize Fields (https://www.drupal.org/project/localize_fields) is the result of that.
It doesn't invent anything, or herald a grand new internationalization paradigm.
But it did solve all our field label translation issues, in a fairly sound manner.
Wonder if it could be of any use to someone else...