This probably works on an emulator, because emulating the Wii hardware means you can read the length of the raw string (text), and do other shortcuts to speed up emulation (like maybe even ignoring what the system says the length of the string is). When run on real hardware, the strings have an offset associated with them somewhere else in the memory that tells the wii how long each string (text field) is. When the text field isn't the same length as what the wii thinks it is, the wii's memory is no longer properly aligned. At this point, the wii's memory offsets are all wrong, which means it's using the wrong data in the wrong places. To fix this, you need to modify the actual System Menu's code to tell it how long each of the things that you changed are.
So if there's some text that says "Some Text Field Here" but you want it to read "Some Text Field There", you have to find in the System Menu's code where it sets "Some Text Field Here" with a length of 20 and set it to "Some Text Field There" with a length of 21. If you're editing this with a Hex editor, it might help to first, find the string (text), then look somewhere around that same place in memory for something that represents the length. In my previous example, you'd search for options, and then search for "14" nearby (14 is hex for 20) and change it to 15 (hex for 21). Doing that exactly probably won't work, because each character may be more than one byte, OR it may measure the length in binary (doubtful).
This is all just a hunch, but makes sense with my software engineering background.
