Calling Developers!
We are reenergizing our code contribution process! Learn More

What are the Slack Archives?

It’s a history of our time together in the Slack Community! There’s a ton of knowledge in here, so feel free to search through the archives for a possible answer to your question.

Because this space is not active, you won’t be able to create a new post or comment here. If you have a question or want to start a discussion about something, head over to our categories and pick one to post in! You can always refer back to a post from Slack Archives if needed; just copy the link to use it as a reference..

Hi, does anyone know a good way to add a locale to Zed, but not to Yves? (Use Case is the Store shou

Options
U01BZ7Q3XRV
U01BZ7Q3XRV Posts: 148 🧑🏻‍🚀 - Cadet

Hi, does anyone know a good way to add a locale to Zed, but not to Yves? (Use Case is the Store should only be available in German, but there are non german speaking people working in the project and in Zed - so meaning just the translations of Zed UI, no "real" store locale). It seems to be much more complicated then it should be

Comments

  • U012PCVT2DB
    U012PCVT2DB Posts: 66 🧑🏻‍🚀 - Cadet
    Options

    We have our translation for Zed here:
    Zed/Translator/data//en_GB.csv

    and then execute these commands:

    docker/sdk console translator:clean-cache
    docker/sdk console translator:generate-cache

  • U01BZ7Q3XRV
    U01BZ7Q3XRV Posts: 148 🧑🏻‍🚀 - Cadet
    Options

    thx, I'll try that. But it seems that the error is thrown as the locale is not defined in the store config

  • giovanni.piemontese
    giovanni.piemontese Technical Lead @ Löffelhardt Spryker Solution Partner Posts: 871 🧑🏻‍🚀 - Cadet
    Options

    U can add dynmically the "en_US" or "en_GB" as locale for Zed in stores.php if APPLICATION env is ZED... then u have only in ZED also the en locale and not in Yves..

  • giovanni.piemontese
    giovanni.piemontese Technical Lead @ Löffelhardt Spryker Solution Partner Posts: 871 🧑🏻‍🚀 - Cadet
    Options

    smth so... i just write here the code.. u have of course adapt it...

    $isZed = defined('APPLICATION') ? (APPLICATION === 'ZED' ? true : false) : false;
    
    if ($isZed === true) {
    //the first locale is the default
        $stores['YOUR_STORE']['locales'] = array_merge([
            'en' => 'en_US',
        ], $stores['YOUR_STORE']['locales']);
    }
    
  • U01BZ7Q3XRV
    U01BZ7Q3XRV Posts: 148 🧑🏻‍🚀 - Cadet
    Options

    @UL65CH0MC thx, this seems to be the best approach so far. Only downside is probably having required fields for localizable fields in en_US, then. But maybe that would be ok since the long term goal is definitely to extend the system for the international market

  • michael.schmetter
    michael.schmetter Posts: 119 🧑🏻‍🚀 - Cadet
    Options

    Did any of you solve that?
    Get rid of the necessary fields for English, if the shop is and will be only German (or what ever)?

  • U01BZ7Q3XRV
    U01BZ7Q3XRV Posts: 148 🧑🏻‍🚀 - Cadet
    Options

    @U02JWPGK5CZ the clean solution would probably be to decouple the translation of zed from the actual store locales and would require some changes in the core modules. A workaround I currently want to investigate, is to add an additional config for allowed locales for Zed.

  • U01BZ7Q3XRV
    U01BZ7Q3XRV Posts: 148 🧑🏻‍🚀 - Cadet
    Options

    from my testing yesterday:

  • U01BZ7Q3XRV
    U01BZ7Q3XRV Posts: 148 🧑🏻‍🚀 - Cadet
    Options

    I tested just commenting out the following line: vendor/spryker/kernel/src/Spryker/Shared/Kernel/Store.php:333

    Then it actually works as intended (but of course we are missing an important check now for the correct locales).
    what is working:
    • store config has only de_DE
    • But now basically any locale can be set without an exception
    • translations in Zed are in en_US (if en_US is configured for the user)
    • localizable required fields in forms are generated from store config (so only for de_DE)
    what is not working
    • missing the check that only configured locales can be used
    ◦ So we would need an additional config where locales can be configured, that should be available in zed
    ◦ In \Spryker\Shared\Kernel\Store::setCurrentLocale the locale check must be extended by checking for application context = ZED and then merge the additional locales from the new configuration (to add en_US locale)
    • Locale can be used, but not selected in the user configuration (since the dropdown is loaded from the store config locales)
    ◦ So when the locales are loaded for the locale dropdown in user configuration, it has to be extended by the additional locales from the new config
    I’m still seeing a general problem with that approach since the setCurrentLocale is by design intended to only allow locales from the store config. So this could introduce problems in future updates of the store logic.

  • U01BZ7Q3XRV
    U01BZ7Q3XRV Posts: 148 🧑🏻‍🚀 - Cadet
    Options

    just fyi if anyone has the same problem: This approach also has been disproved. Reasoning:

  • U01BZ7Q3XRV
    U01BZ7Q3XRV Posts: 148 🧑🏻‍🚀 - Cadet
    Options

    we approached this issue by trying to extend the Spryker\Shared\Kernel\Store, by adding a specific ZED specific locale(s).

    However, we found the major issue: Store.php is a Singleton, which uses Store::getInstance() static method for it’s instantiation.

    If we would just create a Pyz\Shared\Kernel\Store , this would not change the underlying implementation, as all the places that call \Spryker\Shared\Kernel\Store::getInstance() would still call the underlying Spryker implementation without any modifications to the ZED specific locale.
    The sollution would be to override all the places where \Spryker\Shared\Kernel\Store::getInstance() method is called to \Pyz\Shared\Kernel\Store::getInstance() to avoid any potential issues.
    If we search the whole Project for Store::getInstance() , we get 146 results. This would mean the work would be quite time-intensive and error prone.