constants.xml: replace extra spaces

[mmalferov]

No description provided.

[kamil-tekiela]

Does this make any change? Are any automated checks complaining about this?

[mmalferov]

This only changes how the indents are placed inside the entries. I just asked myself: Would it be better if I replaced the indentation from two spaces with one? And the answer came when I answered myself: To see if it will get better, imagine that you replaced the indentation from two spaces with zero, or three, or eight)) In other files, the indentation of paragraphs or entries is of a single space. I don't find any reason to leave two spaces in the current file unless two spaces are better than one for some reason

[kamil-tekiela]

Then it's not worth merging this PR. Unless it causes problems, leave it like it is.

[cmb69]

There are only few style guidelines, and one item is that indentation should be a single space. As such, I think this change is good, but the whole file should be changed. And if we commit with [skip-revcheck], there should be no additional work for translators.

[mmalferov]

In my opinion, the [skip-revcheck] tag is a one-time use. Other translators will still have to do this job when the file changes the next time without the tag, in the future. Only then will the translators have to make both the last change and the accumulated "caring" changes, which are marked with a tag

[cmb69]

To be honest, I've never worked with revcheck. When I was working on the German translation years ago, the docs had been in SVN where you had consecutive revision numbers (much easier to handle). Apparently, revcheck doesn't work as it should, although I don't understand what's the problem exactly. It seems to me that translations who come upon a [skip-revcheck] could just update the EN revision number, and be done.

[Girgias]

In my opinion, the [skip-revcheck] tag is a one-time use. Other translators will still have to do this job when the file changes the next time without the tag, in the future. Only then will the translators have to make both the last change and the accumulated "caring" changes, which are marked with a tag

Arguably this is because how we generate the diffs is "naive", possibly already having a diff that ignores whitespace changes might be an improvement. Also using something like difftastic would make for easier diffs to parse.