There is no point in retiring to replace this with essentially the same Kata. I'm already taking care of fixing all the translations to accept bytes, and to fix many other issues.

E.g. the JS test suite runs a grand total of 7 random tests (picking from 10 fixed inputs and outputs), and one fixed test that does the opposite of what the kata description tells you: it passing in a padded base64 value and expects your solution to parse this.

I would rather retire the kata and make a new one with a better design that explicitely passes arbitrary bytes to be encoded (C# and Python have a byte(s) datatype for that, JavaScript could perhaps use UInt8Array).

I find the current design with strings confusing and ripe with potential misunderstandings, especially for beginners who frequently don't understand what strings actually are under the hood.

Strings have completely different semantics depending on the language, so the semantics of the kata are different in each case. There are the languages where strings are just arrays of 8-bit bytes (C, PHP, ...), those where they are arrays of 16-bit code-units (JavaScript, Java, C# ...) and those where they behave as if they were arrays of codepoints (Python). In each case the meaning of what a "character" is differs (by "character" I mean what you actually get when you do string[0]).

There is also the issue that the JavaScript version asks for a prototype extension, which is widely seen as an antipattern on Codewars (except when the kata is JS-specific).

encoding with padding is an error

Why is that the case ? I know the padding is not necessary for decoding, but for example btoa() in JavaScript does produce trailing =.

We'll be cleaning this up.

The intent is to not use padding; encoding with padding is an error. I don't think that decoding needs to ignore padding; there is currently no explicit requitement that solutions report trailing data as an error and I don't intend to change this.

This kata is trivially adaptable for this in most languages.

E.g. I have forked my Rust translation to illustrate what the kata would look like when focused binary data instead of strings, and have the Python version ready too.

The only reason that this Kata started as 'ASCII String only' is because it was written as a JS kata at the start and in JS the atob and btoa functions can't handle binary data, and clearly the author had not learned about the correct APIs for this task. There is no reason to stick to this rather broken convention. Katas should be language agnostic, and not sticking to broken APIs just because they have been here for a decade now.

Then specify a character set or something (and therefore the binary representation of the text), there is no need to change the entire premise of the kata after 12 years, you might as well just make another kata.

It does need addressing in one way or another, because if tests use a reference solution to calculate expected, users need to know how input strings are turned into binary form when calculating expected, and use the same transformation. It is not a problem as long as both encoding and decoding happen in the same place and are symmetrical, but as soon as you need assymetrical implementation (for example, user encodes and tests decode, or user encodes, tests encode, and result is compared), you introduce a hidden variable which is a) technically wrong, and b) needs to be specified. Setup without hidden variable would be not just cleaner, it would be technically correct. We already have a lot of kata with broken designs, and if we fix one, it won't be a big loss.

While you may be correct, base64 is used to encode strings all the time in the real world (Looking at you, crappy web games). I don't think this is an issue that really needs to be addressed.

Why is this Kata asking you to encode strings to Base64? Base64 is fundamentally a binary codec, that is it's raison d'être after all.

Currently, some of the translations here don't even have random tests to cover decoding, presumably because the authors of those translations found it hard to generate random Base64 data that's still decodable as text (be it from ASCII or from UTF-8; the trick is to generate random text, encode that to UTF-8 or ASCII and from there to Base64).

Can we discuss getting the one Base64 kata on CW in a better shape and actually encode from binary to Base64 and vice versa?

I created a Rust translation, please review and approve!

On second thought, lets not use that one. I've started creating translations across all the languages here to fix a series of issues with this kata and the Rust version has had an update to match that. See other posts in this discourse.

Note: This kata uses the non-padding version ("=" is not added to the end).

Some reading will help

Just like how alphabets are handled.

I have this problem:

Traceback (most recent call last):
File "/workspace/default/.venv/lib/python3.10/site-packages/codewars_test/test_framework.py", line 112, in wrapper
func()
File "/workspace/default/tests.py", line 52, in __
test.assert_equals(from_base_64(s), expected)
File "/workspace/default/solution.py", line 7, in from_base_64
a = base64.b64decode(b)
File "/usr/local/lib/python3.10/base64.py", line 87, in b64decode
return binascii.a2b_base64(s)
binascii.Error: Incorrect padding

What should I do to fix it?

I really don't remember what this was about, but are you referring to this?

Note: This kata uses the non-padding version ("=" is not added to the end).

Because I think that must have been added to the description after I had written the comment.