> In order to tackle https://gitlab.com/gitlab-org/manage/issues/20 we need to detect and fix bare strings that are not externalized for translation. > > We can achieve this using existing static code analysis tools at gitlab. > These tools allow us to measure and autofix language-specific cases to varying degrees. The biggest problem we face here is false-positives. I expect there to be a large number of cases where there are string literals that we do not actually want to wrap in a particular function call. This should still be considered as experimental, we have not yet reached a threshold of done to see that this is not easily managed in an automated way at all. The general process for implementing each linter: 1. We should autofix as many cases using the linter as we can and this should be split across many MRs to allow for easy manual review. 1. We should use danger to enforce externalization in the changes of a branch going forward. 1. We should generate a list of cases that can't be autofixed to be worked through manually or to have autofix functionality written for them. QA: <details> <summary> Can we grep strings and wrap them? </summary> Yes and no, the problem is that we have strings located in Ruby, HAML, JS, and Vue files. We'll have to implement linters to recognize strings in each format but they can still miss things or catch false-positives. This is essentially what linters do. Linters implement or integrate a parser that reads your source code and creates a large tree of data out of it. It understands what each character, word, and symbol means to the language's spec and can, therefore, create a very useful tree that describes the abstract structure of the program. You can take these trees (Abstract Syntax Tree), change some data and parse them back into code! For example, using the [esprima parser](http://esprima.org/demo/parse.html) we can see that `__('hello')` is much more abstractly understood as... ``` { "type": "Program", "body": [ { "type": "ExpressionStatement", "expression": { "type": "CallExpression", "callee": { "type": "Identifier", "name": "__" }, "arguments": [ { "type": "Literal", "value": "hello", "raw": "'hello'" } ] } } ], "sourceType": "script" } ``` This immediately tells us much more. We can see that there is an expression, it is a call, it is identified by `__` and it has 1 argument, which is a string literal of value `hello`. As you can imagine, these can get pretty complex. Linters provide simple interfaces to query and traverse the tree, as well as reporting functionality. You can use all of this together to create rules. </details>