Working Out Context in the Enterprise: Localize That!

I just came across an interesting terminology issue for enterprise applications’ user experience and localization, generally. What should we call the people in an organization who do the work of the business and rely on software to help them do so?

Honest labor. But honestly, what to call the person doing it! Image sourced from Ikipedia Commons and in public domain.
Honest labor. But honestly, what to call the person doing it! Image sourced from WIkiPedia Commons and also in public domain.

Take the English language term worker appearing in a software application’s user interface (UI). That term doesn’t work well for every organization’s set up or localized well into every language either. In some contexts, worker might mean someone who is involved in manual labor and is an individual contributor. It others it doesn’t. Consider how that term worker be perceived by the manager of a team of people, or someone who performs “knowledge-based” work (actually, all workers use knowledge, so I always found that qualifier to be somewhat snotty)? Then, there are organizations that have corporate requirements  about how they refer to, and manage, their workers, referring to them as employees, partners, or something else.

So, how could worker be easily localized into other languages given the challenges with the English term in the first place! I have seen localization bugs being logged for the “wrong”  term appearing in a localized UI. In some cases, that may be the case, but the cause, of course, could also be traced back to choice of English language source term and a lack of context or understanding about how it is used.

Should we even bother with such a generic terms as worker, employee, partner, and so on, anyway? In a role-based access world of enterprise applications, perhaps job titles might be more suitable? But then, how would such an approach scale? And, how could it account for an increasingly consumer-driven user experience of enterprise technology where notions of identifying and labelling different types of users doesn’t apply. Then again, if it’s a role-based access implementation, then why bother mentioning someone by title in the UI and not just their profile‘s real name?

Then, there’s that term user; a term in wide use in the drug and software industry, but not elsewhere. What could user be replaced with? Customer? Oh, let’s not go there. I’m confused enough!

Ultimately, of course, this conundrum is really a question of context. Coming up with a common, generic term that suits every organization, with operations in many languages, and that spans all kinds of domains and expertise really is not possible.

Mistranslations of course, can happen, and superior, generated context for translators to localize the source terms accurately will help alleviate problem that for sure. But, coming up with a source term that is broadly acceptable, applied sparsely in the UI, and easily adapted in context is the way to go. Enabling er, users, to change simply one term to another that suits individual (through a personalization option) or organizational requirements (using a customization tool feature) seems a reasonable, consumer-driven approach that doesn’t require an IT project or a translator to be on 24-hour standby either.

One size doesn’t fit all.

Comments welcome. What do you call your workers or users?

Ultan Ó Broin
Ultan Ó Broin (@localization), is an independent UX consultant. With three decades of UX and L10n experience and outreach, he specializes in helping people ensure their global digital transformation makes sense culturally and also reflects how users behave locally. Any views expressed are his own. Especially the ones you agree with.


Weekly Digest

Subscribe to stay updated

MultiLingual Media LLC