Add linting/warnings
samhh opened this issue · comments
This could lint against:
- Redundant constructs e.g.
{n, plural, other {}}(#108) - Advanced usages that may confuse translators e.g. more than one
select/plural/etc in a message *
* I feel like this should be configurable, but that's probably overkill for now.
Notably these should be warnings, not errors. As such they need to be expressed via stdout, meaning we may want to start writing to files directly. Relevant: #1, #25
- Advanced usages that may confuse translators e.g. more than one
select/plural/etc in a message *
Note that in most cases these advanced usages only start to appear after we flatten—so we would want to lint the flattened output?
Note that in most cases these advanced usages only start to appear after we flatten—so we would want to lint the flattened output?
If we lint against {x, select, foo {}} {y, select, bar {}} in the knowledge that with flattening it becomes nested then that accomplishes the same thing.
TIL that > redirects stdout but not stderr, so printing to stdout doesn't block this ticket. We just need to print lint warnings to stderr. (What about the exit code?)
#!/bin/sh
echo stdout!
echo stderr... >&2$ ./script.sh > out.txt
stderr...
$ cat out.txt
stdout!Alternatively we could add a distinct lint subcommand. That'll be a bit slower as it means parsing everything again, however that does strike me as potentially the cleanest approach.
This can either be a subcommand in the preexisting binary or a new binary - it doesn't make much difference in code as everything that matters is in the shared library.
I'm tempted to say that it should be a new binary given how opinionated towards our own needs it'll be. Current rule plans and whether they're not too specific to our needs: