-
The fail could be at any of the many layers of the stack, from stupid restriction by front-end designer on down. I worked on an early PaaS system where the terribly clever logging framework failed on non-Latin characters, unlike every other part of the system. Since they'd been extra clever, failure of the logging component broke the system (real talent, there).
that said, it's not a massive ask to change these characters to something less problematic on submission.
In the case, as here, of a city name in an app explicitly designed for non-UK citizens, you'd expect that to be being stored plain-text in a database. If the database schema didn't allow for UTF here, the designers are morons. This is a data driven app and the bounds of that data should be communicated all the way up the stack. There shouldn't be anything problematic about non-Latin characters going straight all the way back down the stack, either.
Edit: Yes, this one shouldn't be stored, doh. But since they will have to be processing lots of non-latin character set data for the applicants anyway, any Latin-only restrictions are pants.
itsbruce-
a city name in an app explicitly designed for non-UK citizens, you'd expect that to be being stored plain-text in a database.
I don't get this bit - isn't the city name a password here, so should not be stored in plain text?
I'm a BA though, so I'd just handwave it all as 'authenticate the user' in a vague business process diagram and the rest all comes under 'tech's problem'.
chez_jay
More often than not, these sort of things are thrown up because the back end system the form is writing to only accepts certain characters, that said, it's not a massive ask to change these characters to something less problematic on submission.