This is funny. Is there a way to keep the table name? Or any suggestions? (except change the table name :)) because it's already used by another app whit this name.
I understand this is not controlled by you directly. But I think IPluralizer Interface gives some abilities to add custom rules. Can't you add these kinds of words to these custom rules? It could be useful.
As far as we know the only way to avoid this is by writing our own custom table naming convention however at the moment this is not in our immediate plans.
I always try to understand your limitation or priority but; I really disappointed when I read your response. I think we are not looking at the same perspective.
I'll try to explain you.
I did not share the following issue with your team. This is a dramatic Turkish "ı" problem. Sometimes new softwares face the same problem. I had not reported this issue because it's cosmetics and it's not affected the final product.
But the naming issue affects the product. This is not a cosmetics problem but a quality problem. Because you condemn me to work with a wrong or an unwanted result.
You can correct this issue with a couple of lines. You are already using Plurazition Interface so you add that to your code. How difficult can be to add a similar to the following code?
using System.Data.Entity.Design.PluralizationServices;
public string Pluralize(string word)
{
// Custom pluralization rules
if (word.Equals("SomeWords", StringComparison.OrdinalIgnoreCase))
{
return word; // Return the singular form unchanged
}
// Default pluralization logic
return EnglishPluralizationService.CreateService().Pluralize(word);
}
public string Singularize(string word)
{
// Custom Singularization rules
.......................
.......................
// Default singularization logic
return EnglishPluralizationService.CreateService().Singularize(word);
}
This does not create extra workloads. Only you have to insert this into your plan. Sometimes you have to do some favor to your customers. Because your customers are not consuming, they are producing new products with your product and their quality level is depending on your quality level.
I'm not talking about a general custom naming rules module but;
Pluralization can be given as an option in table naming.
You can provide the developer with a list of words to bypass.
I hope that I explained enough this request is not unnecessary or insignificant and it's easy.
You misunderstood my response. We are not using directly IPluralizer - this interface is part of default Microsoft EF scaffolding services used under the hood in Radzen Blazor Studio. To implement a dictionary with custom words that should not be pluralized like EBITDA we need to bypass the entire default naming convention and this is not going to be trivial task.
This alone would take at least a month to develop as it affects a lot of our code generation templates. As @enchev this is not a trivial task at all and we don't plan to add it immediately.
And I hope you understand your request isn't trivial to implement and not just two lines of code.
If would recommend to name your tables in English. Otherwise if you happen to work for a foreign customer they would end up with a Turkish codebase which may not be ideal from maintenance point of view.
Sorry for the misunderstanding. But I thought you used directly this interface because of the following response.
You say IPluralizer is used internally, this is what I understood.
I can understand if you use your own codes instead of IPluralizer workload could be higher than my suggestion (Why? I can not question this because of your technical decision. I only use the result.).
And I do not evaluate as trivial any line of your code.
Thank you for your suggestion about table names. But you have to know this not only table names but also remark lines are in English in my code in fact. And RatiosEbitda is a combination of two English Words. Ratios + EBITDA(Earnings Before Interest, Taxes, Depreciation, and Amortization). This is not related to Turkish. Isn't it?
If it was a Turkish word, believe me, I wouldn't report it. I gave the Turkish "ı" example for this. It's just a cosmetic issue and won't affect the result.
I reported some problems with language in the past. But these were not Turkish language-oriented but localization oriented.
I always appreciate your effort and your products as a result. I hope you think to add this feature in the near future.
PS : I hope you will appreciate that when I (or one of your users) report a problem, I do it to improve the quality of RBS, not for my own convenience.
Would you consider putting this feature in the inferring rather than the database definition phase? It can give the developer much more flexibility. (Of course if it's possible)
