search

ChristophP / elm-i18next

https://package.elm-lang.org/packages/ChristophP/elm-i18next/latest
BSD 3-Clause "New" or "Revised" License
67 stars 13 forks source link

Support array values #19

Closed addywaddy closed 3 years ago

addywaddy commented 5 years ago

i18n-rails includes some standard translations where the value is an array. Example:

"day_names": [
  "Sonntag",
  "Montag",
  "Dienstag",
  "Mittwoch",
  "Donnerstag",
  "Freitag",
  "Samstag"
]

It would be nice to access these translations as e.g. "daynames.1"

addywaddy commented 5 years ago

No totally sure about the use of a new Type Twig. Looking forward to any feedback.

ChristophP commented 5 years ago

Hi @addywaddy ,

good idea. I checked if that is just a Rails thing, but it seems like it is also a general feature of the i18next client. https://www.i18next.com/translation-function/objects-and-arrays#arrays . So it seems like a good addition.

Your Twig type is fine, other than maybe a clearer name. But I am still thinking about some things to make it a well rounded feature. For example, what about lists of objects? With the current implementation arrays cannot contain other objects or arrays, only strings. There are some examples here where they have an array of objects and I think that makes sense. https://www.i18next.com/translation-function/objects-and-arrays#arrays The next question is: Should list be allowed on the top level? I am leaning more towards no. The top level should always be an object but it can recursively contain other objects, arrays or plain strings.

Would that fit the use cases you have experienced?

ChristophP commented 5 years ago

Another question popping into my mind is this. If you are using lists, you probably wanna iterate over them. Have you ever done that, and if yes can you share some (pseudo) code example? Nothing is currently exposed to get something of a length for it, and hardcoding the length into the code seems like a bad idea.

addywaddy commented 5 years ago

Hi Christoph. Thanks for the feedback! I really wanted to extend your Branch type to support Dicts or Lists, but ended up getting a bit muddled up with Elm's union types. I also initially start work on a fork where the Leaf type was either of type String String or String List, but then realised this would complicate the interface somewhat: t would now return either a String or a List.

There is a wonderful rubygem named rails-i18n which covers a number of date-specific formats, such as day names. These are provided as an array, so you can iterate over days of the week, for example:

t('day_names')
# => ['Monday', Tuesday', Wednesday', ...]

t(4, scope: 'day_names')
# or
t("day_names.#{4}")
# => 'Thursday'

At the moment, I have to filter out all values which are not strings before passing the remaining translations in as flags. It would be nice to not have to do that :)

But I am still thinking about some things to make it a well rounded feature. For example, what about lists of objects?

That's a good point and would make total sense. Maybe the Branch needs to be either a Dict String Tree or a List String Tree? Then there wouldn't be a need for any Twigs ;)

ChristophP commented 3 years ago

It's been a while. Closing this for now. Couldn't think of any good solutions. Please reopen if you want to continue discussion.