Filter out translation and documentation commits

[allanday]

It's not that translation or documentation commits are unimportant - of course they are - it's just that they are a different type of activity which deserves its own analysis. Particularly including translation commits in with the general analysis makes the results hard to analysis, since they could be a high proportion of the overall number of commits. It's helpful to be able to look at the results and charts and know that it is just code changes.

@felipeborges @neilmcgovern

[hpjansson]

Yes. The SQL database would need an enum column to identify what kind of change is introduced by each commit. We may need a "mixed" category for the few cases where there are e.g. .po file changes and .c changes in the same commit. The alternative would be to make multiple database entries for such commits, but it would fit the existing data model poorly.

In the frontend we could add a --filter switch (or something like that) orthogonal to the other options, so you could make various cross-sections of the data and benefit from the same visualizations (authors, commits, changes, ...).