this is either not true or was fixed by someone. Codewars supports both JUnit 4 and JUnit 5. In JUnit 4 the order is assertEquals(message, expected actual), in JUnit 5 the order is assertEquals(expected, actual, message). This kata uses JUnit 4.

I guess I understand now the process...
and I guess that was my first and last translation.

This process is not like modern engineering, where you get early feedback.
Better process would be that translations are generally approved
and new translations are blocked, if someone of the first users complains about something in the translation.

Thanks for the hint. Change is done.

This display note: @DisplayName("Sample tests, e.g. countBy(2, 5) should be {2, 4, 6, 8, 10}") is not really good, because the "e.g. ..." part does not reall explain much and can be misleading. Ideally, the note could be just as much as "Fixed tests", and inputs of each test case could be displayed in an assertion message on failure.

It can take quite long, especially for languages with a low traffic, like Kotlin.

How long does it typically take until a translation is approved?

duplicate issue, see below

Thanks for recommendation, I added the @DisplayName annotation.

It's recommended to add @DisplayName for classes + messages for each test; e.g. it can be "countBy(1, 5) should be {1, 2, 3, 4, 5}.

Circumvent it.

Check row can be done easier with: for (int[] row : sudoku)

My algorithmn fails at "moreDifficultTests" with 23 mines.
My solution is not using the knowledge about having 23 mines in total in this field
and I did not implement a back-tracking algorithmn.

I guess this is not solvable without using back-tracking and the knowledge about 23 mines.
Is that the case?

In Java version all assertEquals have wrong ordered parameters. The explaining message is set as expected so the tests can not pass.

For Kotlin in assertEquals the parameters are switched.
It should be first expected and then actual.

It is relevant. It's the design of the kata. It's good to have this information, since it can validate some basic approaches that would fail with maximum integer (and FIY: there is no such a thing as maximum integer in languages like Ruby or Python). How would this be an issue?