stop the wild-grow of language, culture & currency setti

Under Administration >> Settings we've got a perfectly good way of setting front-end and back-end languages. However lately there's an increasing wild grow of advanced language settings that make it unpractical and un-telerik worthy for any true multi-lingual website.

First we've got Cultures > PredefinedLanguages > dutch-nl.
That has a key which is nowhere used visually where culture and UICulture are both set to 'nl'.

Secondly we've got Cultures > PredefinedCultures > dutch (netherlands)-nl-nl.
The key is visually nowhere in use and both culture and UICulture are now set to nl-NL.

Then we have Ecommerce > Countries > NL
Where we have an iso code of 'NL' (caps, not lowercase like in PredefinedLanguages), the culture doesn't match the PredefinedCultures key, but both its values.

And then we move on to Resources > Cultures > dutch-nl
With fields matching exactly the PredefinedLanguages.

And lastly Resources > BackendCultures> dutch-nl
Wich is similar to the front-end languages from above.

---
I understand that front end and backend cultures/languages may differ (resources>cultures / resources>backendcultures). But can't we extend the frontend resource cultures to include all definable fields and adhere to ISO standards?

That would give us a single point of editing and a standardized method of utilizing multi-lingualism.

So we'd get something like:

key: dutch-nl
ui-culture: nl
culture: NL
ISO Countrycode: 528
Displayname: Nederlands
Englishname: Netherlands
LanguageName: Dutch
ThreeLetterISORegionName: NLD

And since we're consolidating the information, we add the currency information on it as well:

currency: EUR (from a dropdown)
currencyname: Euro
currencysymbol: €
Number of digits after decimal seperator: 2
symbol: Euro

Currency in the above example gets pulled from a dropdown, populated by a consolidated settings page where we define the basics:

key: EUR
EnglishName: Euro
ISO-NumericCode: 978
ISO 4217 Code: EUR
Exchange-rate: 1.3166
RoundToTheNearest: none

This way all related country/language/culture information is stored/editable in a single table/form where even a novice user can find and alter them and the fields are all based on .NET & ISO standards.

The language/country also has currency instantly applied, allowing for an easy configuration in combination with E-Commerce. Instead of having to configure multiple options/settings in order to get multi-currency functionality, it would now be only a matter of adding 'Dutch' as a 2nd front-end language in order for it to work.

Hello Jochem,

What you want to achieve can be done with a custom culture.

msdn.microsoft.com/.../ms172469(v=vs.80).aspx

However, we haven't added such option to Sitefinity, because the configuration and changes that you will make when modifying a culture, will affect the .net framework of the machine, where the your project is running. This is out of the scope of Sitefinity and might lead to unwanted behavior. If you, for example,  later move the website to another server, where the .net framework doesn't include your custom culture, you will probably receive exceptions and other problems.

Hello Jochem,

You may also find this article useful:

www.codeproject.com/.../NET-Internationalization-The-Developer-s-Guide-to

Hey Jen,

I know things can be customized, my suggestion was just to consolidate the first 4 options into a single standard based back-end setting.

Why have cultures>PredefinedLanguages, cultures>PredefinedCultures, ecommerce>countries AND resources>cultures where we can use 1?

Why have  cultures>PredefinedCultures both point to the lowercase .NET standard language name (nl) and then on cultures>PredefinedLanguages have both fields point to language AND regionname (nl-NL / en-US) ?

Given the fact that by now we've over (3x) defined the way we want to display that particular language (because its a frontend language, which gets set by resources>cultures) why on earth do does ecommerce have to have yet another 'culture' field which defines again, both language and culture?

By now there are so many nl / NL / nl-NL fields to screw up, it'll easily turn into misconfigurations.

My suggestion was merely to consolodate all front-end language/culture/currency settings into a single page where we fill in a few fields according to predefined standards (.NET & ISO) instead of having to guess that a Sitefinity 'culture' field maps to a .NET language name and a Sitefinity 'language' field needs to be filled in as a .NET language+region field unless you're in ecommerce where a 'culture' field maps to .NET language+region.

+1 for anything that keeps stuff at one place and simply (adding a forget password takes my brain to full gear)

I also think that sorting is once again an issue. it takes a while to find what you need to change.
Keep the languages together sf_language_cultures_02.png

Markus

PS: Did I ever mention that I would like the SBE to have multiple backend languages. Because you can add 10 back-end languages but use only one :-) - I know I might be repeating myself, but I am old and forget so please forgive me :-)

Hello guys,

I discussed your recommendations  with our architects and we concluded that they are reasonable. This is why I've logged a feature request for extending the language/cultural settings in Sitefinity. Here's the PITS:

www.telerik.com/.../pits.aspx

Hey Jen,

Glad to hear they were in a good mood this morning ;)

Jochem