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.
