Yes, you can have a :tr sub that returns the right tr function.

Of course, you'd use that sub only in views. And you can wrap it in a function so that it's easier to use, something like:

(defn <tr []
  @(rf/subscribe [:tr]))

So there is a difference between returning the fn from a subscription and having a plain fn use the subscription to build the tr?

Only if you have code like

(def tr @(rf/subscribe [:tr]))

OK, but then I don't see how I can avoid subscribing in every component or at the top lvl and passing tr to sub-components? Or are you saying build a component that calls defn ? Sorry if I am being dense.

Right now I am doing a require [dict :refer tr] in all view files and just use that whenever I render text. Ideally I would like to preserve that somehow.

> I don't see how I can avoid subscribing in every component Why would you want to avoid it? Just do it. :) Actually, this is roughly what I'm doing in one of my projects (not exactly what I proposed above, but similar):

(ns my-app.i18n
  (:require [re-frame.core :as rf]))

(rf/reg-sub :tr
  (fn [db [_ key]]
    ... call some actual `tr` function on the `key` ...)

(defn tr [key]
  @(rf/subscribe [:tr key]))

(ns my-app.views
  (:require [my-app.i18n :refer [tr]]))

(defn button
  [:button {:on-click #()}
   (tr [:the-button-label])])

Ah, I think I got it. Use the subscription to perform the actual translation. And have the sub look up the key and the current language.

Yep. And if you have so many strings to translate that it starts to affect performance, you can always put the i18n stuff outside of re-frame. Either in a plain ratom or even an atom (then you'd have to re-render the whole app manually on language change).

Thanks, much apreciated.