Closed YetAnotherMinion closed 7 years ago
Hi @YetAnotherMinion,
I originally thought of that too, but then decided to go with the short version because
translateWithFallbacks
+ arguments really makes for pretty long lines.So basically I opted for convenience over explicitness in this case and thought this would be most converniant for 80% of the use cases.
If a lot of people agree that that the long names make more sense I will probably change it, but this is the first time somebody brought this up. In the meantime you could rename the functions when importing like
import I18Next exposing (t as translate, tf as translateWithFallback, ...)
I know that's not great but will suit your preference.
I had no idea that you could use as
inside the import tuple. That is exactly what I needed to avoid aliasing your functions with new names right after the import.
Edit @ChristophP what version of the elm compiler are you using, because that as
syntax does not work for me on 0.18.0 or the elm-lang.org/try
Ah damn, you're right. For some really I really thought this worked. Sorry for this wrong piece of information.
That we do at my companyb is this (I know this actually works this time :-))
-- alias the curried translate function
type alias Translator = String -> String
view: Model -> Html Msg
view model =
-- partially apply the translations to the `tf` function
let translate = tf model.translations
in div []
[ subView1 translate
, subView2 translate
]
subView1 : Translator -> Html Msg
subView1 translate =
text (translate "some.translation.key")
Does that help you?
I am not a fan of the terseness of the translate functions. I propose renaming these functions so that reading code will be closer to reading english. The current names make me feel like I am code golfing or takes me back to the days when the name i18n was coined (limited length for variable names).
t
->translate
tr
->translateWithReplacements
tf
->translateWithFallbacks
trf
->translateWithReplacementsWithFallbacks