Feature: i18n of issues

[alessiostalla]

I've added three fields to the Issue class:

• node: to be able to refer to a node and not just a position
• code: a standardized issue code that we can use to categorize issues, as a key for i18n, etc.
• args: an object holding message arguments as strings, to be potentially interpolated in the translated issue message

The "message" field remains with two purposes:

• as a more technical message (e.g. to write to the application log)
• for issues coming from third-party components (e.g. ANTLR), to hold the third-party message

I've also added a test case showing how the feature could be used with a real-world i18n library (i18next).

[ftomassetti]

It looks good to me.
If it was a PR for Kolasu, I would suggest I use it in the project for the client and then we merge it. Given it is a PR for Tylasu, I think instead that it would make sense to merge it, do a release, and in case I encounter any problem circle back. This is because I am not familiar enough with TS to use a locally published version of the library

Thank you for implementing it!

[ftomassetti]

I wonder if we should bump the version of the metamodel for this

[alessiostalla]

I don't think so, this is only needed because for some reason in the Ecore compatibility layer we decide that something is an issue if it has the same features as the Issue EClass. Since we're going to abandon ECore anyway, I wouldn't spend much on it.

[alessiostalla]

It's a pain in JS/TS to use a local copy. In theory, in package.json you can put an https:// or file:/ URL instead of the usual version. However, in practice, when I tried it it would randomly use stale versions even if you had changed the source code of the library and rebuilt it. So it's a practice I tend to avoid; maybe today things work better, I don't know.