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?

8 thoughts on “Working Out Context in the Enterprise: Localize That!

  1. Renato Beninatto

    Add to this the type of employee and connotations that the word can have. In Brazil, employee can be translated as “empregado” or “funcionário”. In some circles, “funcionário” is associated with public servants. So, for example, employees of Petrobras, a private company owned by the government, abhor being called “funcionários,” while at Shell employees don’t mind being called either.

    Very confusing indeed.

  2. Ultan

    True and a great example. Actually Brazilian Portuguese was one of the cases in point that exposed the issue this time. Arabic too.

  3. Valerij Tomarenko (@En_De_Ru)

    We should bear in mind that even within one single language, a generic term like “worker” or “user” can be appropriately translated as “worker” (or “user”) in one context, but would be completely out of place in another sentence (depending on the situation described). Russian certainly belongs to the list of languages like Arabic or Brazilian Portuguese and, generally, can better tolerate variance (Russian readers are probably more used to flexibility and fuzziness both in oral speech and in writing).

  4. Oleksandr Pysaryuk

    Indeed, translations and usage of these terms in Russian and Ukrainian can be confusing.

    Context aside, into Russian it can be translated as “работник”, “сотрудник”: roughly “worker” and “co-worker” respectively. First term has the root of “work”, second has the root of “labour”. Work-nik & labour-nik. Note the -ник suffix (analogy is “Sputnik”) that has the same morphological role here: this suffix denotes the quality of a person that relates him/her to an activity.

    Situation is similar in Ukrainian. Terms are “робітник”, “працівник”: roughly “work-nik” and “labour-nik”. Same roots + same suffix. Another Ukrainian term is “співробітник”. It’s close to Russian “сотрудник”(“co-worker”), verbatim means “co-worker” as in colleague who you work with. Sometimes “співробітник” is used to denote a generic “employee” of some research/science facility, e.g. in the context of an institute, academy, research clinic.
    More info here, if you understand Ukrainian:
    If not, Google-translate this:

    In context, it’s a matter of choice but that choice will be guided by common usage practices, as in the example of a research institute or clinic above. In the context of software we make at Achievers where I work now, we use the term “employee” in English. We call our software Employee Success™ Platform. Sometimes some of our clients prefer to use the term “team mate”. Never “worker”. Never “user”. In non-English, this has not been brought up as an issue, but I’ve had this feeling it would one day.

    Thank you for your blog! I am planning to do a deeper “localizability” study with my localization vendor, on the usage of localized terms for worker/employee in the context of software of my organization.

    1. ultanultan Post author

      @Oleksandr Good insights. In the enterprise, we have Human Capital, Human Resources, Personnel (less so these days) and similar departmental names related to welfare of people in the enterprise and they sound somewhat “cold”. At a more granular level, the term worker sounds outdated to be begin with. What organization advertises for workers? The term Employee sounds useful as we approach something scalable, though. Perhaps the adage that “work is a four-letter word” should be a language guideline! Ultimately, though, the choice and use of term (if you cannot avoid it completely) is contextual. Perhaps we should ask the “users”….:) If you can share your study’s findings with the UX/GILT industry at some point in the future it would be great!

      @Valerij Thank you for that. In fact, Arabic was another of the languages that triggered this issue (French being the other one, along with Brazilian Portuguese). It is, of course, all about context. A “One Size Fits All” approach never works when it comes to enterprise methodology (or other areas too), so providing customization and personalization functionality in the software would be my recommendation to enabling a more compelling user experience in some kind of scalable and simple way.

    2. Ultan (Oracle Apps UX)

      To follow up, my employer, Oracle is using the following terms in French HR applications, after discussing with the key stakeholders (of course, the context cannot be shown here):

      Employee = Employé
      Worker = Salarié
      Nonworker = Non-salarié
      Manager = Responsable

  5. Kirsty

    One of our software products uses the term employee (with a dash of user, user ID, user name thrown in to keep it fun!). It also has the concept of “non-employees” to cover other people who might need system access, but are perhaps contractors or third parties. The non-employees may be visitors who are never in any kind of direct employment contract with the organisation using the software, such as third-party visitors to a mine site, but workplace health and safety information needs to be recorded in some manner when they visit the mine.
    I haven’t had too many issues with our localisations of the term employee so far, but might need to go and check out the Brazilian Portuguese translation memory to see what we’ve used … 😉

Comments are closed.