Translation aliases

[philipa]

Peter,

What do you think to aliases in dictionaries:

 {:en  {:example {
    :bar {:baz ":en :example.bar/baz text"}
    :greeting  "Hello {0}, how are you?"
    :yo :example/greeting
    :baz2 :example.bar/baz}

Usage:

(with-locale :en
  (is (= (t :example/yo "Bob") "Hello Bob, how are you?"))
  (is (= (t :example/baz2) (t :example.bar/baz))))

?

Benefits:

• A little more flexibility when maintaining large translation files - e.g. you can leave legacy keys in place and not update all the code that uses them at that time.
• You might use scopes to define a set of standard keys for a repeating class of things, but want to share the translation values.
• General DRYness.

If you like this, you might also consider allowing

...
:bar2 :bar}
....
(is (= (t :example.bar2/baz) (t :example.bar/baz)))

- Phil

[ptaoussanis]

Hi Phil, this is fantastic - much appreciated!

If you like this, you might also consider allowing

I'm keen in principle if the implementation could be kept relatively simple. Am definitely open to PRs if you feel like having a go at it.

Thanks again!

[philipa]

OK.

Scope aliases should probably be resolved at compile time, so are a
little more involved. I don't need them yet, but I'll work on it if and
when I do.

Regards,

• Phil

On 23/05/13 06:42, Peter Taoussanis wrote:

Hi Phil, this is fantastic - much appreciated!

If you like this, you might also consider allowing

I'm keen in principle if the implementation could be kept relatively
simple. Am definitely open to PRs if you feel like having a go at it.

Thanks again!

[ptaoussanis]

OK. Scope aliases should probably be resolved at compile time

That'd be my first thought too. If you do end up taking a look at this at some point, I'd also consider possibly making the standard aliases compile time while you're at it

As an aside - always enjoy the high quality of your contributions. Wish everyone provided "benefits" on PRs for example, nice idea.

[ptaoussanis]

Hi philipa,

Am busy experimenting with some breaking changes to the t API on the v2 branch: https://github.com/ptaoussanis/tower/blob/v2/CHANGELOG.md

While I was at it, I incorporated your previous alias mechanism into the dictionary compiler. To keep things simple, I did this as only a single-phase transform: https://github.com/ptaoussanis/tower/blob/v2/src/taoensso/tower.clj#L290

Your implementation supported >1 step aliasing. Is that actually a requirement in your use case, or would the current (single-step) implementation be okay?

Cheers :-)

[philipa]

Sorry I've not been able to work on this myself - I've got a new job IRL.

For my needs, 1 step aliasing is fine, so long as it does something obvious if you chain aliases.

[ptaoussanis]

Great, okay - will keep the simple implementation then. And absolutely no need to apologize - wasn't waiting for you, only working on this now since I wanted to replace the config atom and was refactoring the compiler.

For my needs, 1 step aliasing is fine, so long as it does something obvious if you chain aliases.

It'll just count chained aliases as nil (missing) translations.