It’s no secret that I love cross-cultural issues in iMedia. This probably stems from my origins in linguistics and English as a Foreign Language. So I was particularly intrigued in a detailed article about the challenges that asking someone to input their name can cause in data capture for an international (global?) audience. It is aimed more at web programmers and I’m amazed that so much of it makes sense to me as I’m no programmer. Furthermore, I see the article as a great piece of covert training for your iMedia clients. It’s perfect for explaining that those simple changes that clients suddenly ask for can be complex, and therefore expensive. They need to trust you to accept the vagaries of the costs of those seemingly small changes that crop up during a project. Trust in iMedia development is key to forming good client relationships. And we all want those.
What am I on about? Here are a few examples if you’re using data capture for names in any of your projects. If we are too rooted in our own culture then how does our name data capture work with cultures that traditionally use their last name first? Is the capture comfortable with hyphenated last names or even ‘von’ or ‘de’ (usually lower case) or the apostrophes in the shortened ‘de’, ‘d’’ or even ‘O’Neil’, and so on? How do we denominate the names used? Do we call them Christian or First name, Surname or Last Name, or something else entirely? How do we deal with nicknames or variations of names used instead of full names like ‘Dee’ for ‘Denise’ or ‘Joe-Joe’ for a child to differentiate from a father called ‘Joe’. Americans are used to using ‘Junior’, of course. And I haven’t mentioned non-Roman scripts yet!
Some cultures work with initials more than names. So in Hong Kong it is still common for Chinese to have a Chinese name but an Anglified equivalent where initials are common – like ‘D.A. Ho’. This all gets further complicated when the marketers want you to capture a name that the person wishes to be addressed by so they can send marketing mails. Some cultures change the form of address they use according to the person’s age or status and this is very important if you are trying to influence these people. Imagine, if you get the form of address wrong in the email, they are hardly going to be disposed to read the rest or be influenced by it! I can feel marketers quake if they haven’t taken this on board before.
If you expect me to give you the answers as to how to capture all the data and make it work for all your clients, I’m not! The article on the W3 web site is very detailed and comprehensive, but even so, it probably won’t cover all eventualities, I’m sure.
I had to come to terms with this type of problem when I created a database of first name origins. I quickly realised that I had to limit the data to mainly Anglo-European names and state this upfront. Otherwise, I wouldn’t have been able to complete this particular project at all. Name databases need constant monitoring and updating because fashions dictate new names appearing and even switches between male and female names: such as Ashley which is more often female now but has been male in previous decades. Variations in names in spelling alone makes the database vulnerable, and new spelling forms appear quickly because people want to personalise their name by making it slightly different. Just consider the spelling variations and nick names from ‘Ellen’: ‘Ella’, ‘Elle’, ‘Ellie’, ‘Nell’, ‘Nellie’, ’Elen’, ‘Elin’, ‘Elyn’, ‘Elon’, ‘Ellan’, ‘Ellin’, and ‘Ellon’. Yes, I’m sure I’ve missed some!
If you are Anglo European and have a first name (Americans often have Anglo-European origins) then check out the name origin at www.atsf.co.uk/iconnection/namesearch.php as it might surprise you. Do let me know if the database doesn’t cover your Anglo-European name and I’ll research and add it.
So, lots more to names and name databases than you imagined, I expect. Data fields can be minefields, so respect your programmers.