Orchardcore: Default culture does not apply (in Localization settings)

[ampadashi]

The default culture of my application is en-US. When I add fa-IR culture and set it as default, the language of the admin panel will not be changed. The only way to change the language is to remove en-US culture from website which is not a good idea. Even when I add ?culture=fa-ir to the address, it will changed the language of the current page only.

[Skrypt]

This is not an issue it's working as expected. What you need is a culture picker in the admin which is probably missing an implementation. The proper solution for you is to keep both culture set in OC and to change the priority of cultures in your browser settings by setting fa-IR as the default culture of your browser and to keep en-US as a second choice for now.

[sebastienros]

To explain what @Skrypt said differently, even if you set IR as the default language instead of EN, the admin will take what your browser requests first, and we suppose that you have set en before ir in your browser. This is the accept-language header that your browser sends. To be able to force an admin language we need to implement a custom culture picker for the admin, which would have a higher priority than the header your browser is sending. You can implement it if you want, and we'll gladly accept a PR.

[ampadashi]

I usually use google chrome and in its settings, when we move up the Persian language to the top, the language of the browser will change to persian too which it’s not desired. Mostly, Iranian users prefer to set English as the default language of their browsers. So, We must be able to use fa-IR culture without changing the language of the browser. Please let me know your comments.

[sebastienros]

As suggested then you need a culture picker feature in the admin such that each user will be able to chose the version of the admin.

Another solution, which would not be incompatible, is to add a new setting to select which culture should be used for the admin, with a higher priority than the accept-language header. But a lower one than an eventual culture picker.

[ampadashi]

I think it’s a good idea. With this solution, even if we set more that two cultures, we can switch easily.

[hishamco]

@sebastienros what if we tweak the localization middleware little bit by enforcing that localization settings default culture get served first if the localization module is enabled otherwise localization middleware will work as usual.

FYI no need to introduce culture picker in my case

If sound is good I can send a PR for it

[sebastienros]

What you are suggesting is the same as me if:

• We add a checkbox in the settings to "Use the default culture for the admin interface"
• Create a new culture provider named DefaultCultureAdminProvider that would be registered before the accept header one.

[hishamco]

It could be checkbox, I was thinking to add it as LocalizationOption in the code, and it's on by default unless you don't like the behavior you can override it

While it's scheduled for 1.0.x, I will send a PR at that time

[sebastienros]

This would mean to change it by code and I think it should be simpler for users. Also the current default is totally fine. The new behavior should be triggered by a gesture.

[ampadashi]

Hisham, in a cms, i think it’s so important to be able to apply default culture without changing browser settings. It’s an important issue and it’s better to solve it the version 1, as soon as possible.

[hishamco]

This would mean to change it by code and I think it should be simpler for users.

Yes it's, by changing this property via the admin, like what we did in localization settings

Hisham, in a cms, i think it’s so important to be able to apply default culture without changing browser settings.

Seems you didn't see my comment and it's on by default

It’s an important issue and it’s better to solve it the version 1, as soon as possible.

I am not authorized to schedule the tasks

[hishamco]

@ampadashi you can implement this by yourself if you are on harry, believe it or not there 're a lot of things we should do before 1.0.0 release, the important thing is stability and bug free as much as we can

[ampadashi]

@hishamco ok, i try. thanks;)