Consider clj18n-style `t` closure about tower

[asmala]

A couple of suggestions to the above, based on my experiences with clj18n:

1. Run expand-dict upon compile or setup time. That way create-t only needs to grab a value (map of translation strings) from the dictionary by key (locale), which should make memoization unnecessary.

2. Don't use bindings, just use closures. You can replace most (all?) uses of bindings with simple closures inside a let. Or even a def for REPL-based development. Something like:

   (let [t (create-t :en_US dict)]
       (build-window (t :window/title))
       (let [t (scope-t t :dialogues.login)]
         (build-dialogue (t :sub-title) (login))))

3. Consider meta attached to the compiled dictionary as an alternative to the config atom.

Whether the change is worth it is probably a matter of taste, though. I personally prefer not using bindings (or behind-the-scenes config atoms) since they are arguably less purely functional than e.g. closures. And of course there's effort and backwards compatibility to consider. Perhaps something for a 2.0 rewrite?

[ptaoussanis]

Hi Janne,

Sorry about the delay replying to this!

Run expand-dict upon compile or setup time. That way create-t only needs to grab a value (map of translation strings) from the dictionary by key (locale), which should make memoization unnecessary.

What I like about the memoization is allows convenient REPL dev - if the dictionary changes, it'll get recompiled. Also removes the necessity for any special compilation time/step, and removes the necessity for a "make-t" fn. Instead you can just create a t partial with the dictionary you want and use that as the closure for middleware, etc.

Don't use bindings, just use closures. You can replace most (all?) uses of bindings with simple closures inside a let. Or even a def for REPL-based development. Something like:

Yes, I'm definitely in agreement with this and would be happy to see this happen in Tower v2. I do think the create-t is unnecessary and will complicate things like a wrapper to check for changed dicts on disk. (For example, t's config arg could be a map or a filename on disk to watch for changes in dev-mode).

Consider meta attached to the compiled dictionary as an alternative to the config atom.

If it's actually useful config stuff (e.g. default fallback language, etc.), then I don't think it should be metadata. Not a problem though - I would suggest t take a config map. This will contain the dictionary and anything else necessary for t config.

---

Have just begun a new project that I'll be focusing on for a while, so I may be unusually unresponsive for a while. You've got commit access to Tower - so feel free to experiment aggressively on a v2 branch if you like, and we can talk about merging changes later. Otherwise I'll keep an eye on clj18n and I'll give you a shout later when my schedule normalizes.

Thanks again for all your awesome work and input, cheers! :-)

[asmala]

Thanks!

If I'm hearing you correctly regarding the use of partial to replace make-t, you mean something like this:

; Assuming that we have a translate function with the following footprint…
(translate dict locale [:a.namespaced/key :a.fallback/key] "Interpolation" "arguments")

; …then we could create t with a call to partial
(let [t (partial translate dict locale)]
  (t [:a.namespaced/key :a.fallback/key] "Interpolation" "arguments"))

(partial translate …) is not significantly longer than (make-t …) so that seems workable.

I'm not sure, though, how the memoization would work or if it's even necessary. If dict is a "compiled" map of a reasonable size, then getting a translated string would be a simple matter of calling (get-in dict [locale :key]), which should be fast enough. Could you say more about why we'd need memoize and how you see that working?

Two other topics to discuss in the context of refactoring this bit would be:

• How to pass around the configuration? (#28)
• How to scope keys? (#29)

No hurries with this one. Better we consider our options carefully. In the meantime, Clj18n can be the Wild West test bed for ideas.