Pluralizer Ruleset for other languages and uncountable words

[cesarep]

Hello!

A couple months ago a contributed with a pull request (#40336) updating the way the Inflector creates its ruleset with a single string for the desired language, to make it easier to change to other languages. The next step naturally would be to substitute that string with a configuration entry.

The user @CristianH033 started a topic more than a year ago for this same subject, without answer (#34564). Considering that spanish, french and portuguese are among the top 10 most spoken languages (spanish been the 4th) and are all supported by Inflector

I tried substituting the string for Config::get('app.pluralizer_ruleset', 'english') but, to do so, i needed to include a Facade on the file, but Facades apparently shoudn't be mixed here (#40336 (comment)), though it appears to work fine locally.

How can we work this out?

Also, most of the uncountable words are already listed inside Inflector, doesn't it already handles these edge cases? what's the use for these uncuntables?
On the file's history someone once removed those (83abfd5) but it was reverted back shortly after (ce88b25)

[mikeydevelops]

I have an idea, following the pattern from other classes, you can add a closure resolver for the inflector in pluralizer. This will make the inflector be resolved lazily. In a service provider, probably TranslationServiceProvider would be suitable, you would define the inflector resolver, which because it is in a service provider would have access to the application instance therefore you can get the configuration values you need.

Every time the application changes languages, I suggest changing the inflector resolver to address the new language. That can happen if you register a listener for the Illuminate\Foundation\Events\LocaleUpdated event. Keep in mind, the language you receive in the event is user-defined so you would need to guess the inflector language based on that; some projects use ISO-639 format which comes by default from Laravel i.e. en - two letter representation of the language. Some other more complex projects, use the same format but with the country appended at the end to represent a specific dialect for that language i.e. en-US. Some developers use underscores instead of dashes i.e. en_US.

That being said, you should guess based on the language you received from the event and fallback to default app language or if that is not set fallback to English.

I suggest making the result from the inflector resolver cacheable, to ensure close to the original performance of the Pluralizer.

For the uncountable words, you could make a setter in the Pluralizer class and can update them from the service provider and event listener where you define the new inflector resolver. you can use iterator_to_array to set them in the $uncountable variable.