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

U01BZ7Q3XRV

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

U012PCVT2DB

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

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

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

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

@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

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

@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

from my testing yesterday:

U01BZ7Q3XRV

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

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

U01BZ7Q3XRV

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.