Default locale not being set

Question

Default locale not being set

tardinha opened this issue 6 years ago · 14 comments

When a new member is created via the registration form, their locale is not being set (it defaults to the first in the list, Afrikaans).

In SS3, this would default to the default locale.

Answer 1 · 2018-09-14T05:19:06.000Z

The Member class sets the default locale in the onBeforeWrite. does that not work?

Answer 2 · 2018-09-14T05:31:14.000Z

Doesn't seem to be.

Answer 3 · 2018-09-18T23:10:50.000Z

I can confirm this. Although I don't really understand why...

Answer 4 · 2018-09-19T00:31:19.000Z

My default locale is configured as 'en_AU' for Australian sites. But the locales provided in the Locale dropdown in the CMS only contain 'en_GB' and 'en_US' as options. So the locale of new Members is probably set corrently to 'en_AU', but this can't be displayed in the CMS.
Any ideas how to fix that?

Answer 5 · 2020-01-15T03:05:19.000Z

This is still a thing...

Answer 6 · 2020-06-02T05:50:59.000Z

I finally managed to put some time aside to run this module up and dig into this (on SS4.5), but would you believe.. I'm not seeing any issues haha. The following shows 2 users I created in the CMS, and 1 user I created using the member profile registration page:

This might just be because I'm using the default locale, so I'll try something like en_AU next.

Answer 7 · 2020-06-02T06:02:10.000Z

Okay interesting results. So yeah, the locale dropdown for a member in the CMS doesn't contain en_AU so when I set the default locale to en_AU, this ends up showing as Afrikaans (South Africa). If you hit save, this is actually saved as af_ZA. If you create a member using the registration page, you get the expected locale of en_AU as seen below:

Answer 8 · 2020-06-02T06:03:48.000Z

So from what I can see, the module is behaving as expected, however it's not ideal that the locale dropdown in the CMS excludes certain locales. Perhaps this is something to follow through with a core issue and/or pull request? Would love to gather your thoughts before I close this however, as perhaps your issues are project specific?

Answer 9 · 2020-06-02T07:33:07.000Z

What happens if we set multiple locales, maybe the second can be used if the first is not found? e.g.;

i18n::set_locale('en_AU');
i18n::set_locale('en_GB');

We don't have any multilingual sites, and users will only have access to the front end, so from our point of view, we want all users to be en_GB.

Answer 10 · 2020-06-02T10:24:44.000Z

I agree with Mark. Maybe there should be a setting in the module what available CMS locale should be set for new registered users? similar to the group?

Answer 11 · 2020-06-03T00:43:12.000Z

@tardinha setting i18n::set_locale('en_GB'); (but preferably using YAML) should solve your problems if I'm understanding you correctly? In regards to having multiple locales, I don't believe i18n supports this outside multilingual SS modules.

I guess it makes sense that en_AU isn't selectable since it's technically the same as en_GB in regards to language, but perhaps there are improvements that can be made around this especially if you want newly registered users to have a locale different to the default.

Answer 12 · 2020-06-03T00:50:57.000Z

@nglasl it does, but that's kind of a hack. As we should be setting our Aussie sites as en_AU (particularly for frontend stuff).

I guess then we need to make sure we manually set our templates to en_AU and not use $ContentLocale :)

Answer 13 · 2020-06-03T01:47:14.000Z

I think ideally the dropdown should include any locale that's valid (including en_AU), because that's important when you take time zones into account. But yeah, not sure why that isn't the case.

Answer 14 · 2020-06-03T03:13:19.000Z

Seems they’re using locale and language interchangably