Use ILocalizationService instead of get all cultures #14934
Conversation
src/OrchardCore.Modules/OrchardCore.Search.Elasticsearch/Controllers/AdminController.cs
Outdated
Show resolved
Hide resolved
| { | ||
| model.Cultures = CultureInfo.GetCultures(CultureTypes.AllCultures) | ||
| .Select(x => new SelectListItem { Text = $"{x.Name} ({x.DisplayName})", Value = x.Name }); | ||
| var supportedCultures = await _localizationService.GetSupportedCulturesAsync(); |
There was a problem hiding this comment.
@sebastienros I'm not sure this is appropriate to list only supported cultures. This means that now the ElasticSearch indices culture can only be supported cultures that are added in the Admin UI. This means that I need to add translations to each of these supported cultures while I could have been able to loosely couple a culture with an index before.
There was a problem hiding this comment.
As an example of that I could have a website that is majorly written in french but has some content in english which I would want to index in a different indice if required.
There was a problem hiding this comment.
This means that I need to add translations to each of these supported cultures while I could have been able to loosely couple a culture with an index before.
How this different from getting all cultures?
There was a problem hiding this comment.
They come from the framework instead of the DB. And the ASP.Net localization middleware will support these cultures if they are added. if you just list cultures that are in the framework ; it doesn't do anything else than that.
There was a problem hiding this comment.
I knew what you mentioned :)
What I mean how the change that I made is different for the Elastic search module?
There was a problem hiding this comment.
Different in what matter? I'm just saying that we should not use supported cultures only for this and also Lucene or any other Search index configuration.
There was a problem hiding this comment.
Frankly, I didn't understand why using the supported cultures in this case is not preferred!! maybe @sebastienros understands what you are referring to
There was a problem hiding this comment.
You could have a website that is majorly written in english. You would have only "en" as a supported culture.
But your website has content written in french for a specific content type... then you would not want to support "fr" but only index that content type for the "fr" culture in a custom IndexingHandler...
Now, I understand that what you expect is to see the same cultures as the ones that are supported in these index settings but it is not everyone that uses OC that way. This is limiting options for people that have custom handlers.
And now I need to support all the cultures which means that I need to do custom code to remove these supported cultures from the LocalizationMiddleware.
No description provided.