ObjC itself is not responsible, it's NeXT and Apple's fault for perpetuating that abominable naming convention for much too long.
As for localisation, only a tiny fraction of strings in a software program are user visible. I don't think we should be designing language syntax around that edge case.
ObjC is one of the most readable languages around. That's mostly because of the param:value syntax, which is much better than C-like syntax because you can see the parameter names. But the long method names aren't a problem once you have autocompletion. They also make it clearer what the best name for a method is - if you call something fmt() you start needing to make up equally clever short names for everything else, and it becomes less principled.
For algorithmic string building, I'm not sure how often you want + (aka appendString:), appendFormat: or componentsJoinedByString: are more flexible.
Not necessary. There's a very sensible "huffmanization" principle created within Perl/Raku community which says that the need for a name/token to be overly descriptive is inversely proportional to frequency of its usage. So you can have short names and they still be human-parseable just because they are used often, and your brain used to register it. FWIW they will be easier human-parseable, because longer words take longer to read. With this approach one can has both fmt, and formatSomethingSomewhereSomeday
https://github.com/SerenityOS/jakt
Notable differences:
1. param:value is used, but convention is param:value not the gratuitous Engrish verbingParamProposition:value ObjC inherited from Smalltalk.
2. param: is optional if the variable holding value in the calling function is named "param" at compile time. This pushes you to name your params "param" everywhere that makes sense.
Jakt's popularity is limited, obviously, but it's a compile-to-C++ language, so you could use it many places.
Smalltalk does not have this convention.