This looks quite nice and powerful and indeed an elegant way of solving the problem with multiple plural forms in a string. The only concern I have with that syntax is that it's yet another DSL, or markup language and translators need to know it, or could get it wrong. Granted, a program for helping translators might do automatic linting (much as Qt's Linguist already warns if you omit placeholders from the translated phrase that are there in the original).
Another thing is that the mini-language grows complex enough that the resulting text can be quite hard to read and understand:
{people, plural, offset:1 =0{No one went.} =1{{user1} went.} =2{{user1} and {user2} went}.} other{{user1} and # others went}}.
is just a single (or two) placeholder and it takes a while to even parse how it's supposed to work.
Well, if we're going to introduce that level of complexity into a DSL, why not go full Turing-Complete and write it in code?
(case (length folks) (0 "No one went.")
(1 ((elt 0 folks) " user went."))
(2 ((elt 0 folks) " and " (elt 1 folks) " went."))
(otherwise ((elt 0 folks) " and " (length folks) " others went.")))
You can wrap that in a lambda that concatenates resulting strings and voilà, you have "smart" string tables. And it's not a problem to make it even more DSL-y and translator friendly.
And then you have the exact same problem as if you'd write that logic in your source code. Just with half a dozen layers of abstraction, a more cumbersome way of displaying strings in your application and another programming language on top. I'd say that's not a net positive.
I disagree. That logic has to go somewhere anyway - you can't skip it because it's inherent in the problem of displaying a proper message. So you could at least write it in an expressive language instead of encoding it into what looks almost as readable as regular expressions.
No you don't, in much the same way that you don't need a translator that "knows JSON or XML". Just don't tell them it's Lisp. That's how you do DSLs.
Also, I advocate closer work between translators and developers. Let the translators give the text and explain corner cases to someone who can code up the logic.
BTW. Lisp is only hard for people who acquired this stupid meme that "Lisp is weird/for crazy people". You'd be hard-pressed to find something which is simpler in terms of syntax and readability.
I recommend that you need to teach the translator about the markup. It's really easy to understand.
The way L10ns try to mitigate the complexity of the markup language is to provide buttons for pasting the correct markup for translators. Also a developer translates on his own language first. And this example will always be visible to the translator of an another language for easy reference. So the programmer offloads the logic thinking from the translator.
IMO ICU's messageformat markup is also slowly becoming the standard for localizing strings. It is already used widely by big organizations such as Apple, Google and Yahoo.
L10ns pre-compiles all message string. So it offloads the parsing performance.
Another thing is that the mini-language grows complex enough that the resulting text can be quite hard to read and understand:
is just a single (or two) placeholder and it takes a while to even parse how it's supposed to work.