Translation Woes …

Recently I was engaged in a brief translation task aimed, in part, at promoting multilingualism in our society. On the surface—despite the embedded politics, which I shall attempt to avoid—the task seemed easy. There was but a single expression to translate: “a proud service co-creator”!

The expression in question is the new tag line for the project I research under: Siyakhula Living Lab project. Living Labs operate under the philosophy that to create (or build) meaningful services or products, end-users have to be involved actively as innovators together with those who will provide or develop the services or products. To highlight this partnership between users and providers, words like “co-creator” and “co-innovator” are typically used.

Using the above as context for translating the tag-line into Sesotho, I crossly underestimated the dynamics of the language. I attempted to create a more or less direct translation: “moetsi-mmoho ea motlotlo oa lits’ebeletso”. This translation is not flawed, but from what I gathered, “moetsi” as a representative word for creator, brought a degree of confusion. Of course, I found this a bit surprising given we do have idioms in the day-to-day Sesotho that suggest “moetsi” is a familiar word that can be understood in context; the most popular idiom being “moetsuoa ha a lebale” (the victim never forgets) and by implication “moetsi oa lebala” (the perpetrator forgets).

As always, I took the criticism in my stride. And through the help of those who speak the language, I began to interrogate how the simple idea of working in partnership is communicated in Sesotho, particularly in a context of trying to emphasise the individual. As I re-engaged myself to the task, one thing was clear: anything with “ts’oarana ka matsoho” (holding hands) would be a lazy translation—precisely because the expression is popularly used and I didn’t want to take part in reinforcing a prevailing and very misguided idea that our African languages lack the capacity to serve the knowledge society.

Driven by my ‘politics’ and, of course, the desire to see the task to completion, I generated a number of translations. Ironically, many of these translations stemmed from attempting to run away from the holding hands metaphor. Some were literally centred on how the word ‘hold’ is used to convey different kinds of participation in collaborative work.

As an individual, I can communicate, in at least three ways, my role in collaborative work: 1) “ke a ts’oarisa”, 2) “ke a ts’oarisana” or 3) “ke a ts’oarisoa”. The first two expressions are similar in that I would (supposedly) be defining my role as one of helping (lending a hand), but in a manner that may suggest differing levels of commitment. In the third expression while the idea of teamwork is not lost, I am not necessarily being coy about my role and that of others in performing the task at hand: I am the lead and others are the supporting act. If you detect a hint of militancy, then it means you grasp the depth of the language; you appreciate that such an assertion is occasioned by circumstances that deviate from the norm—circumstances that warrant clarity on whether we are all in this (work) together as equals—“re Makaota, mmoho ts’ebetsong na?

Again, I should stress that Living Labs operate under the ethos of ‘perfect’ partnership. That some animals may be more equal than others is a taboo.

With the above in mind, the following translation won hands down (or should I say hands out of the picture): “Tjaka ea tlama-thata kahong ea lits’ebeletso”!

In my (not very humble) opinion, this translation brings some oomph to the tag-line. “Tjaka” (used often as a synonym for “seithati”) embeds pride at a level that is dependent on how one chooses to interpret the word: epitome, role model, heroine or hero are a few possible candidates. The translation then becomes: A role model for building services in tight-unison!

Picture Perfect

If the world were perfect, these are the only thoughts that Alfredo (my supervisor) would want me to have for the duration of my studies. Basically, in this Utopian version of the world, all thoughts would precipitate into action that always yields high quality papers. (And of course the relationship between students and supervisors would purely be that of interdependency.)

The ideal research student

Partner or Perish

In academia, it is often stated that one must publish or perish but times have changed. We now live in an era of partner or perish. If this is not the case, then people like me who are all committed to the cause of open source are doomed. Doomed in a sense that we should be subscribing to the notion that sharing is key to levelling the playing fields and ensuring that all benefit. Therefore, if we believe this principle applies only for software, we need to be condemned!

Lets think about it. If we believe in the promise of open source, which translates to better quality, higher reliability, lower costs and freedom from any vendor. We should believe that these same rewards can be reaped in all areas of life if we work in partnership. If not that, we could contemplate why our parents and/or guardians made it their cause in life to instil in us that “sharing is caring”. I did contemplate the question myself and came up with a few interesting things. The first was conspiracy to rob me of my sweets. The second was that the dear old folks were locked in the dawn of the 70s. (A period of true social consciousness, and as I am told a time when good music was fashionable; a time in which the likes of John Lennon, Curtis Mayfield, Ottis Redding and Bob Marley through their music advocated for a united and peaceful world.)

After going through a few other “theories” of why sharing is possibly caring, I decided to trust in the wisdom embodied in clichés. I realised that I didn’t know any old adage or cliché that encourages one to do anything on their own. Therefore, putting emphasis on publish cannot possibly be acceptable. It should be all about partnering and publishing the best work that two or more minds can generate. Otherwise as academia we fail in our social responsibility to uphold good values. We fail also to appreciate why the business community has suddenly decided to value what they term strategic partnerships and therefore why there is much emphasis on creating synergies and thinking win-win.

For what it is worth, I honestly believe that de-emphasising publish would not result in fewer publications. I believe that by emphasising the need to partner we would in fact increase the publications output. Perhaps, I believe all this because I have been brain washed with old Sesotho sayings like “kopano ke matla”, “matsoho a hlatsoana”, “lets’oele le beta poho” ! (Translated: unity is power, hands wash each other, masses rein in a [raging] bull).


Phew! Finished writing SATNAC paper on time. It was a pretty short paper but it is one of my milestones for the semester so I am pretty happy. I guess I have earned a few brownie points 😉 .

Last Steps of the Journey: Part III

I realise that other bits of the journey have been left out but it doesn’t really mean that they didn’t happen! I am still trying to tie loose ends in writing everything down. This part of the journey is comparable to surfing except sometimes it doesn’t feel like one is on water. It feels like one is surfing on land and at other times on fire! It is truly an incredible experience with rewarding and less rewarding days…but I guess it is all part of the journey.

Now let me return to the reading, writing and deleting of things 🙂 .

Last Steps of the Journey: Part II

This entry will continue from the previous blog. The focus will be on the strategy employed to develop the prototype. As mentioned before, the prototype service is needed for validating the proposed architecture for building IVR systems. The development involved three major phases excluding the requirements analysis phase. These are:

  1. Building the service ontology – This ontology captures information about services in Grahamstown. The ontology answers questions such as: ‘where to get a free service?’ and ‘which non-governmental organisation offers X ?’
  2. Designing the VoiceXML application – This part of the work focused on the actual dialogs that constitute the service. Since IVRs are notorious for causing frustration to users, the goal was to attempt to create an application that provide users with a satisfactory experience 😉 .
  3. Implementing the whole system – The focus here was on bringing all elements together such that a user can call, put a request, have the ontology queried and finally have a response returned back to the user. Gaining “perfect” fluidity to this seemingly simple goal involved a number of things, which I shall not discuss in this blog (partly because I am tired but mostly because I don’t want focus to be removed from the value of employing a strategy that encourages divide-and-conquer).

Last Steps of the Journey: Part I

It is has been a while since I blogged. So I will break down what I have been up to over a few blog entries. This particular blog will focus on the overall picture of my work.

My work is underpinned by a need to have an architecture that is flexible and standard based for supporting development of IVR (Interactive Voice Response) applications. As it stands, despite providing unsatisfying user experience in the past, IVR technologies are still seen as pivotal in realising a new generation of self-service voice systems. There are a number of reasons for this including the fact that telephones and mobile phones are ubiquitous (just go to and download the Africa Mobile Factbook for statistics on the mobile phones penetration in Africa). This means that there is, for example, a strong “market” for IVR applications – not just in the commercial sense but also for use in supporting social innovation 😉 .

With the above providing part of the motivation, the goal is to use IVR technologies (specifically VoiceXML) to propose an architecture for building IVR systems with high configurable dialogs to improve user experience. The premise is that the effort to customise (configure) each dialog to suit each users’ goals will bring intelligence to IVR systems – a component that is possibly a source of much user frustration.

In a nutshell, the proposed architecture builds IVR systems by generating dialogs using VoiceXML and a rich backend. The backend comprises of a specially built interface that allows a reasoner to interact with any ontology-based knowledge base in order to generate dialogs. In the context of AI, the interface can be regarded as some sort of an inference engine.

Architectural Design Considerations

An overarching consideration is to ensure that the architecture is flexible. Another important consideration is to ensure that the generated dialogs do not violate any principles of user interface design. This translates into ensuring that:

  • Menu options do not exceed five options. Otherwise this is will result in an overload on the short-term memory of the user. Consequently, the user will have problems remembering the presented options.
  • Break content into small chucks to enhance memorability by introducing rhetorical questions or using quiz type questions. However, the number of dialogs generated should be kept at a minimum.

Case Study: Service Directory for Locating HIV Test Providers

As part of the methodology, a case study is included to act as a proof of concept for validating the proposed architecture. This proof of concept case study is a service directory for locating HIV test providers.

The case study is built from a service provider ontology, which together with individual facts about specific service providers forms a knowledge base. This is strictly in the context of defining a knowledge base as an entity made up of a terminological box (TBox) and an assertional box (ABox). In simple terms, TBox refers to the definitions of various concepts and how they relate to each other within an ontology while ABox refers to the individual facts associated with the definitions in the TBox.

Below is a quote from good old Wiki to provide another angle to the definitions of TBox and ABox:

Tbox statements are sometimes associated with object-oriented classes and Abox statements associated with instances of those classes.

Debugging: Joys and Pain

I have spent hours trying to figure out why my ontology is suddenly inconsistent. That was not a trivial exercise though the mistake itself was trivial. I guess it is true that sometimes one spends a huge portion of their time on seemingly trivial tasks… Oh well I now that I have that sorted out, it is time to move on. 🙂