Author: alon
Description:
When given a non-ASCII filler, padright: and its kin apply the right number of
an incorrect element (see [[:meta:User:Taragui#Padright test]] for an example.
Handling of Unicode seems broken in any case: non-ASCII characters in the first
argument are counted '''according to their byte length''' (i.e., as 2 to 4
characters) instead of as one each, as they should. This breaks the fix for the
unavailability of a <code>strlen</code> function proposed at
[[:meta:Talk:ParserFunctions#strlen & substr]].
Version: unspecified
Severity: normal