is that plan concrete implementation wise though? My impression is that we have broad strokes (e.g., maybe even what platform to use) but not the details.
Once we have diagnostics structs as listed in the issue then it should be easy ish to add i18n based on various json files or something that key off of the text error code or something
This assumes there's a human-understandable "error code" like
object-safety-generics that we can key off of but if we decide against codes then we can still use this internally
(split off into new topic)
@simulacrum there are some open questions but in this case I think it's _mostly_ clear implementation wise what we can do
We don't even necessarily need to pull in Fluent
@Manish Goregaokar hm, okay
that's farther than I thought we were
Error i18n is blocked on y'all implementing the diagnostics derive
error index i18n isn't blocked on anything someone just needs to do it, also it would make sense to hold off until after we figure out error codes
@simulacrum note that this is only a plan, no implementation
But please loop me in on PRs implementing the diagnostics derive so I can ensure it's compatible with this
I was going to do it myself but I keep not having time lol
yeah, this also all sounds mostly compatible
I continue to be skeptical about the "many files on disk", but of course the final artifacts can bundle things up if needed
@Manish Goregaokar did you have thoughts re. translation of error descriptions though? (i.e. the
.md files we have today)
As long as there's something to key off of this is quite easy.
Again, some open questions.
it's basically just a string code that is linked up via a rustc_driver hashmap to descriptions
it's very isolated
but I was wondering re. the linking aspect; e.g. how do we store the translations and how does rustc load them?
@centril rustup component, basically json files or something. which specific format depends on what works with Pontoon and what can support the detail we need. I think for error codes the json format is fine.
Could also bake it in, but at least to start with a rustup component makes sense to me
For diagnostics we may need to use a format a bit more powerful than json
Either way these files are never hand generated
Or read by humans.
Error descriptions are basically just a long string, so it requires nothing technically complicated beyond that I think
I continue to think the linking aspect is not too interesting :)
like, we can definitely do it
I personally favor the existing solution as being just fine
I agree in the sense that it's not complicated
@Manish Goregaokar I suspect the error descriptions are the most readily translatable asset we have
since it's so simple
Yes those are the easiest
basically you need to swap out a string for another string
I actually started doing them at one point lol and then left it
It's not hard tbh
Like if you want me to jot down a full plan in an issue I can
yea; if we setup some infra I bet people will come and do it
there's a bunch of initial work that needs to be done
@Manish Goregaokar in rustup?
Okay one question: presumably y'all still want to write these as MD files yes? So we should be generating the English json files via some step which Pontoon can then consume
@centril also in rustc so it knows how to load these etc
For all of this there are two options: forcing rustc users to write things in the json/whatever format, or using what we use today and having an autogenrtation step
MD files is a pretty new (but nice!) thing -- they used to be hard-coded strings in the
Both work, it's up to y'all
I know! I wrote half of them :)
also in rustc so it knows how to load these etc
@Manish Goregaokar could we start with a dumb
-Z flag perhaps?
and no rustup support initially
If y'all want I can file a bunch of concrete issues
And a meta issue and a plan or whatever
sounds helpful :heart:
Don't have bandwidth to do this myself but I can watch and help
I was mostly waiting for diagnostics derive to happen first
For short diagnostics we may not be able to have a sensible generation step and diagnostics writers may need to write text for the diagnostic in a file fwiw
But maybe not
maybe we can hard-code the English strings in the struct to make the diagnostics dev UX less "jumpy"
also to facilitate the move
@centril we can hardcode provided there's a way to extract it in a structured format, which is trickier for structs
That said it's possible to just use a basic parse script for this. Annoying