Automatic PHP linting for invalid translation keys

[emteknetnz]

#10797 identified that easy to miss developer error can lead to malformed translation keys being added that partially break non-english installs, for instance:

_t(self::class . 'GENERALSEARCH', 'General Search') will cause errors

_t(self::class . '.GENERALSEARCH', 'General Search') is prefixed with a dot and is correct

We could simply filter out 'dotless' keys when running i18nTextCollectorTask, however then the develop won't get feedback that they put in an incorrect key and it'll never find its way to transifex. We could alternatively throw an exception but we're moving towards full automation with translations and that would cause the entire process to fall over

There was also a different sort of issue in https://github.com/silverstripe/silverstripe-admin/pull/1518/files where there what looked to be a description as a param in _t() - we could possibly let this one slide though because it's so obscure and developers are really unlikely to do this

Instead I think a better solution would be linting that runs in CI that catches malformed keys and causes builds to fail, so they can be fixed before merging. A CI static analysis linting step can also have more functions added to it later e.g. analysing markdown files for correct API links

We could probably reuse i18nTextCollector::collectFromCode() to do this, where it runs over every php file for the module that having CI run over it

We should also lint the 2nd param of _t() to ensure that it's a string scalar, and not something like implode() - see silverstripe/silverstripe-admin#1521

Another thing that should be linted is duplicated translation keys. This is particularly easy to do because transifix pull and textcollector seem to order keys differently, and when merging up it's easy to end up with duplicated keys

Related issues

• Add linting for docs developer-docs#11