search

vanniktech / multiplatform-locale

Type Safe Kotlin Multiplatform Locale implementation
Apache License 2.0
27 stars 4 forks source link

Language (, Country, ...) should be a data class, not an enum #182

Open westnordost opened 6 months ago

westnordost commented 6 months ago

The issue with Language being an enum is that it is closed. I.e. if a language given as ISO 639-1 code is not present in that enum, I read that this library will return null when trying to get an instance of this language by code. And I can already see that the enum list is far from complete. But you made it so that unlike the API in Java, it is necessary to get a Language instance to get e.g. the display name of the language.

ISO 639 is a living standard, things change. Ideally, the library was made in a way that it would not require maintenance for when codes change, are added, etc.

Country has exactly the same issue.

vanniktech commented 6 months ago

Right now, I'd prefer the type safety over an open structure. What's your use case? Do you only want to get the display name of the language? If so, we could extract this to just accept the ISO identifier.

westnordost commented 6 months ago

In my case, I need to display the language name and country name in another given language. But I am not (considering) using this library yet, I was just looking around for solutions and browsed the code. So, this is just general feedback.

Type safety is a bit difficult for languages, IMO, as there are ... well... really a lot of languages, and I didn't look it up but I would expect ISO 639 to not be a stable standard as opinions / scientific evidence might change whether one obscure language spoken in a few villages in the mountains is a dialect of another or rather an own language etc. - (yeah, I know, mostly irrelevant for most use cases)

vanniktech commented 6 months ago

Then I'd for now keep our type safety and add languages as needed and for displaying the language / country in a desired language, we could provide an API for that.