Country config values

[Jarlskov]

In our project we require some country-specific config values to be exported, ie. countries.en.currency. As it is now, we need to add the config value to the $config setting for each country, which is cumbersome and error-prone, even more so when we add a new country. Right now we've fixed this by adding an additional config array with all theses values. When we generate the config output we just iterate through all values of the $locales array, for each value in this country config array. Others might have similar needs, and it seems natural that a localization package can work with localized data :-) Would you accept a PR on this? I'm thinking:

1. Add a new $countries_config config array
2. Iterate through the $countries_config array for each value in $locales, when generating the json output JsLocalization\Caching\ConfigCachingService::createConfigJson()

[andywer]

Hmm. Is there a strong reason why the country-specific data is not just in lang/, next to the string translations?

Seems to me that everything that is locale-specific should be there, anyway. But maybe I am missing the point here 😉

[Jarlskov]

I didn't really think about putting it in lang/, but again, it's configuration, not text strings so logically I don't think it makes much sense. That would split your configuration all over the place :-)

Not all config values are text strings either, we need both booleans, ints and arrays, so I think it would be a bit of an abuse of the lang/ content. It would also make it harder to differentiate between which countries our service is opened up to (the ones we have configs for) and the ones that the system is actually translated into.

So we probably could add our config to lang/, but I think it'll increase complexity more than would be worth it :-)

[andywer]

I see... And what about putting the currency data in the config, like Config::get('currency.usd') === [ 'symbol' => '$', ... ] and putting a "reference" to it in the i18n data, like Lang::get('currency') === 'usd'?

You see, the reason why I would like to avoid adding another feature for this is that I fear this will attempt to fix a problem in a different place than where it originates. There should either be a more elegant solution to solve this issue with the existing tools or if not then it is rather a missing feature in Laravel (complex locale-specific data structures).

[Jarlskov]

It would probably be possible to do using the current translations, but I think it would be a gross misuse. foreach(trans('country.vat_rates') as $vat_rate) { - again, it's not translations, it's configuration :-)

In my opinion, this package is a sign that localization is not properly addressed in Laravel (heck, the documentation only mentions translations).

I can understand if you don't want to include this in the package, I wasn't sure whether you would consider it out of scope :-)

We have a solution that works for us, so we're fine, I just wanted to offer to share the solution :-)

[andywer]

I appreciate it :) Just fearing that we open Pandora's box here...

So in the end it all boils down to

• country-specific configurations should be stored as configurations, not translation data
• you don't want to export those configurations for all locales to JS, but just for the current one

[Jarlskov]

No, I can live with exporting for all locales, I just don't want to manually maintain the list of config options for each locale :-)