Yes, that’s the reason that I wrote “should be”, not “must be”.
Be very careful … when you are fully and normally booted, you may have access to a keyboard, used by the application that you use to change the LUKS encryption passphrase, that can generate far more characters than can be generated by the keyboard that you use to enter the passphrase during boot.
And in either entry scenario it may not be entirely predictable how a sequence of characters is converted into a sequence of bytes (which is ultimately what will be input to the key stretching process). Sure, if for example both use UTF-8 now and forever, that is fine. (In some situations even the underlying character set could be an issue. Again if for example both use Unicode now and forever, that is fine.)
It is conceivable that if you want to use non-ASCII characters in the LUKS encryption passphrase then you should either make a second key slot, with a longer, safer passphrase or make a backup of the LUKS encryption master key (but if doing the latter, you need to think about how that backup is itself protected.)