Adrian Imfeld

@nono1971: After looking at your code again, you probably don't use a custom translator, since you're using Zend\I18n\Translator\Translator::factory(). To make the breadcrumbs view helper use the correct translator instance, try:

public function getServiceConfig()
{
    return array(
        'allow_override' => true,
        'aliases'        => array(
            'translator' => 'mvcTranslator',
        ),
    );
}

@nono1971: If my hunch is correct and you indeed use a custom translator, you might want to check out this issue.

@nono1971: Interesting solution, but you might run into some trouble when translating directly in your config like this. Translating into exactly one language which is determined before the config merge process should work. But I suspect you may not be able to to translate into other languages (e.g. according to user languange preference) or to display the original English strings. Once the config is merged with the translated strings, you cannot then translate to some different language.

Maybe you use a custom translator class and which is not picked up in the breadcrumbs view helper? I had the same problem and I fixed it like this:

Here's my custom translator class

namespace MyLib\I18n\Translator;

class Translator extends \Zend\Mvc\I18n\Translator
{
    // Some costum translate functions like translateFrontend() and translateBackend()
    // These functions are parsed by poedit into separate translation files.
}

Here's the translator factory for creating the custom translator:

namespace MyLib\I18n\Translator;

use Zend\ServiceManager\ServiceLocatorInterface;

class TranslatorServiceFactory extends \Zend\Mvc\Service\TranslatorServiceFactory
{
    public function createService(ServiceLocatorInterface $serviceLocator)
    {
        // Configure the translator
        $config     = $serviceLocator->get('Config');
        $trConfig   = isset($config['translator']) ? $config['translator'] : array();        
        $translator = Translator::factory($trConfig);

        return $translator;
    }
}

And heres the Module::getServiceConfig() to set the translator factory. The custom translator will then be used in viewhelpers (e.g. breadcrumbs).

public function getServiceConfig()
{
    // See http://packages.zendframework.com/docs/latest/manual/en/modules/zend.service-manager.quick-start.html
    return array(
        // As of zf 2.2.2, the translator service has been renamed to mvctranslator (https://github.com/zendframework/zf2/issues/4910)
        'allow_override' => true,
        'factories'      => array(
            'mvcTranslator' => 'MyLib\I18n\Translator\TranslatorServiceFactory',
            'navigation'    => 'Zend\Navigation\Service\DefaultNavigationFactory',
        ),
        'aliases'        => array(
            'translator' => 'mvcTranslator',
        ),
    );
}

Maybe this section in the ZendDiCompiler documentation helps clarifying.
It's a little complicated and a lot of confusion comes from using terms differently in different articles. Let's define composition root as "the single place in your application where the composition of the object graphs for your application take place". If you inject the DiC into your controller class and pull the controller dependencies from in there, there is no composition root, since object graphs are now constructed in many places with $dic->get($className) calls. I call this using a DiC as a service locator.

The purist way is to construct the whole object graph in a single place (composition root). In a ZF2 application, this means creating controller instances using a DiC in Module.php, and not inject the DiC into controllers or into their dependencies. Here's a code example.

public function onBootstrap(MvcEvent $mvcEvent)
{
    $serviceManager = $mvcEvent->getApplication()->getServiceManager(); 
    $this->zendDiCompiler = $serviceManager->get('ZendDiCompiler'); 
}

public function getControllerConfig()
{
    return array(
        'factories' => array(
            'MyModule\Controller\Index'    => function () {
                $controllerClass = 'MyModule\Controller\IndexController';
                return $this->zendDiCompiler->get($controllerClass);
            },
        ),
    );
}

@elpinois This tool is actually better for testing for spam: http://isnotspam.com/

@elpinois Here's a really cool tool for testing why your mails are getting marked as spam: http://www.emailspamtest.com/. Please report whether it has anything to do with the Content-Type header...

Thanks, I fixed the code snippet. I also work with gmail and I have never experienced the spam problem you mention. I suggest you compare mail headers and see, if other things than 'Content-Type' have changed...

However, IMO dark themes only make sense if they are implemented consistently. Having a dark theme for Word, Excel, Chrome, etc doesn't help much, if the displayed document / website still has a white background. Indeed, using an inconsistent dark theme (e.g. dark program background with bright document background) may even be worse than the default bright themes, due to a resulting high contrast between documents and program.

For a discussion of dark vs. light themes, also see http://skeptics.stackexchange.com/questions/6925/are-light-on-dark-colour-schemes-for-computer-screens-better-for-programmers