All good now. Thanks for the translation!

Sorry man, I approved your translation but then by accident removed it. Could you kumit another translation? Thanks!

I get the following error when I try to approve:

"Description cannot be approved, recent changes from related record must be merged first".

I have no idea what this means.

This is a common issue in randomly-generated test cases. To generate a random number using Math.random(), there needs to be a lower bound (included) and an upper bound (excluded). However, since numbers in JS are doubles, they start losing some precision after a certain point. This will, in very rare cases, cause the upper bound to be included. If you're interested, you can take a look at MDN's explanation here: Math.random() - JavaScript | MDN.

Test cases, for the purpose of this Kata, require the returned value or index to be numbers. When you get a failed test like this, the first thing you need to do is to check the type you're returning. Then you can deduce why your solution is wrong.

Little Kata like these are cute. Mind-boggling before you figure it out and so straightforward afterwards.

This was fun! Took all morning.

It would be cool if the kata required the greatest product of n consecutive digits.

The kata also needs randomized test cases, like it was mentioned before.

The description needs to be a bit clearer. When we're looking for the greatest product of n consecutive digits, we first need to get all the possible n-digit numbers from the original number. For instance:

'123834539327238239583' // => '12383', '23834', etc... (notice the overlap)

I believe this has to do with the execution order of code blocks when you submit your solution. The way I see it, the order goes from Preloaded -> Your solution -> Kata's test fixture. It seems that your own test fixture gets its own environment, unaffected by the Preloaded code block.

5th test case is a bit tricky. You need to keep in mind that modifications to a character also count. For instance, one could apply a deletion and then an insertion, but why not a modification in the first place?

On test case:

Test.assertEquals(type(1), "Number Integer");

It is wrong to say 1 is an Integer, because all numbers on JavaScript are doubles up to 53 bits of precision. Either the test case accepts a broad definition of what is a "Number" or the instructions must assume that integers can be perfectly represented up to 53 bits of precision.

Thanks for this Kata, I've learned a lot with it!

Thanks for all the feedback. Got me on the right road.

However, Codewars has been experiencing some issues with Unicode characters. I sent Nathan the link to this Kata and hopefully I'll have no problem in dealing with future issues for it.

Should be better now. What else should I modify?