I wonder if it isn't better to generate the messages as an AST, and have a language generator, the back-end of a compiler really, that generates strings for each language. I'm sure there will be less edge cases that way.
/edit: wow, downvotes.
/edit: wow, downvotes.
The representation makes no assumption of SVO order, the grammatical category of numbers, and what cases and tenses are available.
(OPRESENT ((OSUBJECT (OPRONOUN (3, 0))) ((OVERB, "like") OMUL (2, (OCAST (OATTR (OCOLOR "brown")), (ONOUN (OANIMAL, "cat")))))))
And I will be able to correct my S-expr to get rid of more assumptions, and I will just make it longer perhaps, but I won't need to write all the convoluted code prevalent in the article.
Also, with AST-based representation you can add whatever context you need. For example, were I to have used "pig" instead of "cat", this would have already worked fine, since we have (OANIMAL, "pig") and not (OPERSON, "pig"). This is trivial, but you can add whatever amount of context required.
An analogy to my other comment on AST translation: in English you "like doing something" but in German you "do something gladly" (and again in English you "like a person" but in German you can "have a person dear", akin to English "hold dear"). If we expect that the AST can produce a translation using the single verb "like", we may be in for trouble if the target language doesn't do that (although maybe code can be written that uses the AST and that's aware of this complexity as part of the realization of the translation).
Another example could come from the problem of describing states of being or perception, like "I'm cold", "I'm tired", "I'm hungry", "I'm thirsty", "I'm sick", etc. In English we really like using "to be" plus adjectives for such situations, but other languages have other preferred strategies. For example Latin has specialized verbs for the actions of (at least) being hungry, thirsty, or sick (like esurio, sitio, aegroto); in Romance languages people often "have" hunger or thirst (Spanish "tengo hambre", lit. 'I have hunger'; Portuguese "estou com fome", lit. 'I am with hunger'); in German it is cold "to" a person ("mir ist kalt", not "ich bin kalt" 'I am a cold person').
If you imagine having your AST start with Latin, you may have a challenging story about how you could get from "sitisne?" to "are you thirsty?" "¿tienes sed?" "está com sede?" and "hast du durst?" -- not to deny that it may be achievable with enough work.
Besides, I see two issues with that:
- While it may be more machine-readable, it's absolutely not human readable
- Something like (OPRONOUN (3, 0)) assumes that pronouns work like in English. Want to represent text in a language for which it is not the case with this system? No dice.
In short, I'd rather have an improved gettext (without hacks to detect if you're gettext'ing printf'd text...) than your proposed AST solution.
First, I am talking about generating text. In software. Translators would really only need to check the text so that it's correct, and when it isn't, they should submit bug requests so that the programmers implementing the language back-end can fix them.
Second, an AST is nothing but the result of applying grammar to some input, something which translators are very familiar with (probably more than programmers). It is utterly trivial to teach a translator a new textual representation of what they already know.
It's a tree of nodes connected by arrows. They learned the parsing stage in school. At least here in my country, everybody is required to decompose a phrase in it's underlying grammatical constituents in the eight grade. You just never draw it as a tree, but it's trivial to learn to draw it as a tree and read it from a tree.