I don’t think this post is intended to state any more “seriousness” about translation than before the post was made - but that @cjdb’s experiment in diagnostic phrasing may be best phrased as a translation. (more or less what was important to me was a sort of “zero/one/infinity” - I didn’t want the new phrasings to be baked in as a special case to the existing diagnostic files - that if we were going to support one rephrasing, I’d like it to be done in a way that’s easy to add/remove N rephrasings/translations)
If there are things that might be useful to include in that direction to avoid digging us in a hole/incurring further technical debt we’d obviously want to avoid - we should talk about those. Are there particular things you have in mind that you think are within the reasonable costs of @cjdb’s work/needs/direction?
From the original post: “: incompleteness will be allowed, and anything that doesn’t have a value will default to the fallback diagnostics that Clang ships with.” (ie: the existing diagnostics stay compiled-in to Clang (so Clang can’t fail to have diagnostic text if a supporting metadata file is missing/can’t be found) and by the fallback if anything is not translated into a particular phrasing/language) - the intent is not to translate wholesale, or require any changes to the developer workflow as it stands today.
See the discussion here: RFC: Improving Clang’s Diagnostics for the current motivation. An experiment in rephrasing (still in English) diagnostics to see if it makes a significant difference to the developer experience.