I think, if you have this problem, your tooling is bad. There are broadly two approaches to git commit history: (a) it should reflect the historical development process; and (b) it should be cleaned up and pretty.
If you're taking approach (b), then the maintainer is responsible for rewriting commits (e.g. squash merge). If using GitHub, only the commit description given in the PR is used, and the "true" history is discarded, so it doesn't matter.
I prefer approach (a), but even something as primitive as gitk (from Git GUI) would let me browse the history you describe without issues. Provided that the merge commit is a summary in the project language, intermediate "true-history"-style commits are most useful as a mnemonic aid to the original developer, and secondarily as evidence for a retrospective investigation (for which you want as much primary-source data as possible: even if the author's fluently bilingual, translating risks losing valuable information).
The best approach, imo, is to be fine with this, and take measures to ensure that it does not impede your workflow. An acceptable, professional approach would be to add a contributor's guide, requiring that all commit messages have their first line in English.
If you're getting angry, that suggests you're doing something silly like relying on GitHub's useless web view.