In 2006, the rebuilding Iraqi police recognized their need for a software system to serve a wide range of functions, including providing a “back office” infrastructure. In Iraq, unlike in the United States, the Ministry of the Interior (MoI) hires and manages the police throughout the country, so the system deployment would be on a vast scale.
The software would address basic human resources (HR) issues, such as tracking and recording who was hired, and how much pay they received. Additionally, the system would handle equipment inventory, and the collection and reporting of crime statistics for the entire country.
Ideal Innovations, Inc (I-3) received the request to develop this software system to support the Iraqi Police. I-3 had already designed and developed several software systems for the Iraqi government. Several earlier projects in Iraq failed due to inadequate user training and support. I-3 was determined not to make those mistakes, so training was an important element from the beginning of the project.
I-3 utilized its Texas-based software development and training teams in conjunction with project management located in Washington, D.C., and a “forward” group situated in Baghdad’s Green Zone. The forward group hired local Iraqis to work in various positions, and to do translations.
“The biggest challenge was that we didn’t know what the system was going to look like, and we knew it was going to change a lot,” said Dr. Alex Kilpatrick, Vice President of OCONUS (Outside Continental U.S.) Operations for Ideal Innovations. Because of the imminent deadlines, the teams needed to develop both the software and the training nearly simultaneously, even though the requirements were vague. This meant there would be a fair amount of rework. It also made it difficult to schedule the training development, because of lag time that occurred when the training team had to wait for the software development team to finish designing different modules of the application.
The forward team in Iraq worked to collect requirements for the system from the client, and communicated with the entire team via weekly conference calls and e-mail. I-3 also created a Microsoft SharePoint portal to keep all project-related documents and resources in one place. The portal was an instrumental collaboration tool that permitted the teams in different locations and countries to share files. It also served as a back-up archive of the entire project.
In the earliest design stages of the software, the training team identified, and started to address, some of the issues that would be problematic for training development. There wasn’t good information about the computer skills of the target audience, and there was conflicting information about the infrastructure, such as how readily available computers and the Internet are to users.
Therefore, the team decided to create training materials in both a paper-based, instructor-led format, as well as a self-paced e-Learning format for distribution via CD or the Internet. Out of necessity, the team would create the training in English, the native language of the entire development team, before translating it into Arabic and Kurdish for distribution to the learner audience.
Arabic basics
There are 18 basic letters, augmented by dots, in the 28-letter Arabic alphabet. Written Arabic mostly leaves out vowels, except in religious texts or books for children and learners. Most Arabic written for adults assumes that readers will understand vowels from context.
The first thing most people notice about the Arabic alphabet is that it proceeds from right to left. Numbers, however, go from left to right.
At the beginning of the project, none of the instructional designers or training developers had experience with Arabic, or with working with any right-to-left languages.
“We didn’t expect language to be an issue, but it has been,” said Dr. Kilpatrick, “Getting Arabic on the screen wasn’t that difficult. We originally tried to translate isolated text, but we discovered in the QA (Quality Assurance) phase that subtlety and meaning were lost. This was true for both the software user interface and for the training modules. We translated strings of text correctly, but once the testers started to use the integrated application, we discovered that many of the error messages and instructions didn’t make sense in the context of the application. Also, the field validation was different for English and Arabic, and the development team spent unanticipated amounts of time writing code for two different sets of validation rules. Having the translators working with both the application and the training for the application together made both the application and the training better.”
“Flipping” the interface
The team had experience in designing and developing e-Learning in multiple languages, including work with the most-common romance languages. In earlier projects, an outsourced company usually provided the translations. Previous experience taught the team that translating training content was never a straightforward process, and that it was important to include client members who spoke the target language in the selection of translation companies.
In the normal process, the teams developed training in English, and then extracted the content into a table the translators could use. One column had the English text, broken up as needed, and the translation company put the translated text into a second column. A script automatically re-populated the content into a new instance of the interface to create the new version. (See Figure 1.)
Figure 1 The development team created the training in English first, for later translation.
For this project, we had to reverse the entire interface to display from right to left. The menu bar started at the upper right corner of the window, and the “next” button was on the left side of the navigation bar.
Interface design and graphic selection
Because the English version of the training was for development purposes only, the team built the interface in both languages with a right-to-left design. (See Figure 2.) This was a bit awkward at first for the training team, but made developing the Arabic version later on much easier.
Figure 2 The interface organized content from right to left, regardless of language.
The team created several interface prototypes for review by the target audience. From previous projects, I-3 had already learned about some Iraqi preferences; in general, Iraquis prefer interfaces and styles far more ornate than those normally seen in business applications. The interface went through several revisions, with minor adjustments made along the way. The design of the training interface influenced the design of the software interface; after seeing early prototypes of the computer-based training, the developers went back and put more effort into designing the look of the software.
Graphical elements
In the analysis phase, the team received conflicting information on the education level of the learner audience. While the population in general is well educated and computer-literate, this project was to be released across the entire country. (See Figure 3.)The team wasn’t certain of the education level and computer literacy levels in more remote areas. Under the assumption that the translations would not be perfect, they designed graphic elements to strongly support the content.
Figure 3 Uncertainty about the quality of translation led to creation of graphic elements that would strongly support the content.
For a diverse, nationally-dispersed population, creating appropriate graphics provided new challenges. Generic blue featureless figures originally represented people in all of the training graphics. This changed with the need to differentiate between types of users of the system; the system was for the Iraqi Police, and I-3 needed to differentiate between police officers and recruits. (See Figure 4.)
Figure 4 Graphics had to differentiate between different types of users of the system, for example, between police officers and recruits.
Later, the team changed the graphics again to reflect an appropriate representation of audience types. Even more so than in the United States, in Iraq it is important to have both male and female police officers, because only men can search and interview men, and only women can search and interview women. Clearly, the graphics needed both male and female figures, and a later change included the addition of skirts and head scarves, or hijab, for some of the female figures. (See Figure 5.)
Figure 5 Graphics needed to represent individuals in culturally appropriate ways.
Photographs augmented the drawings, and some portions used video. It was easy to obtain photographs of the equipment, but for the video elements, it was important that the people in the video be consistent with our target audience.
Security considerations for graphics
Traditionally, the biggest concern for training graphics was getting proper releases from the subjects who were photographed or videotaped. In Iraq, this presented a new concern. Iraqis working as policemen and policewomen, as well as their families, faced a significant danger if they were broadly identified as being part of the police force. Finding any Iraqis who were willing to serve as models for the training was impossible.
Not wanting to use American models, the team tried to use models from other Middle-Eastern countries, but test subjects immediately identified them as “non-Iraqi.” Furthermore, in Arabic culture, people generally consider it rude to photograph any female.
Using caricature type representations of the Iraqi police that were sometimes static and sometimes animated proved to be the best solution. We could use real models in cases where their faces did not show. This solution turned out to have some unexpected benefits.
First, the Iraqi police uniform was undergoing rapid changes at the time the teams were developing the training. By using cartoon-style graphics, the training depicted a general uniform idea, not any specific uniform style. (See Figure 6.) This eliminated any problems reconciling differences between Baghdad Ministry of Interior police uniforms and Kurdish Regional Government police uniforms. Furthermore, because the cartoon figures had no real faces, there were no issues related to representing females.
Figure 6 Cartoon style graphics solved a number of problems related to uniform details.
The cartoon figures also provided more flexibility in presentation. Instead of having to keep going back to Iraq to get a different pose for a model, we could just change the graphic.
Timing considerations for audio
The computer-based training modules consisted of a mixture of video, flash animation, and static images. By not relying entirely on video, the audio recording process was much easier. With video, the timing of the video sequence limits the length and timing of the audio. Because we relied mostly on Flash animation, the Arabic speakers were not concerned with limiting their translation and recordings to a specific time period. They could easily manipulate the animation to match the timing of the Arabic audio. Moreover, the animator did not need to understand the Arabic audio files because their segmentation matched each scene in the training module. The e-Learning included Flash elements with embedded audio. In order to create the Flash with Arabic text and audio, translation and recording of the content had to be in both English and Arabic.
The first audio recording was in English in a draft form, using neither professional voice talent nor a recording studio. (See Figure 7.) It was only for the working version of the program. The English audio helped the developers time the Flash interactions.
Figure 7 Making the first recording in English helped developers time Flash interactions.
The developers broke the content into chunks based on the animation timing. The translators also worked with the text. In this way, the team could redevelop the animations using Arabic text and audio while maintaining proper timing. The development team could not read or understand spoken Arabic, so a sound QA process was critical for project success.
I-3 used a mix of male and female voices for audio. The team opted for a mix instead of a single narrator because of uncertain availability of voice talent. They knew they would have to do a lot of re-work, and a single, original narrator might not always be available. By intentionally using a mix of voices, I-3 ensured that the audience would not be surprised or distracted when the voice of a narrator changed.
Initially, developers received advice that both male and female Iraqis respond better to a male voice. However, after further investigation, it became clear that this was far from universally true. Using a mix of male and female voices increases the training’s appeal to different audiences, and keeps the learners engaged with different voices as well.
Lost in translation
On the other side of the world, the translating team had varying degrees of experience in translating technical and training content. One team member was fluent in both English and Arabic and was a skilled translator; others had less experience, but were more familiar with technical vocabulary. For example, in one early version, the team discovered that the word “training” had been translated using an Arabic word more appropriate to “training an animal” as opposed to “learning.” The team adjusted the translation process to include a step for having a second Arabic-speaking native double-check each translation. This turns out to be an essential and critical step, especially in the case where the training development team does not speak the language of the deployed training system. There is little reason to have an instructional designer take the time to carefully craft learning interventions if the nuances of meaning are lost because of poor translations.
Another added benefit from having a central QA person who reviews all the translation is that this person will experience the training module in its entirety, and will look for consistency in wording and style in various sections that, due to the time crunch, were translated separately or by multiple people.
We used the same translators to translate the text, to translate the user interfaces, and to review the audio, animation, and video in the final and completed training module.
Integration
Adobe hinted that Flash would support bidirectional languages like Arabic in the latest version, but the support wasn’t available in time for this project. As a first approach, the development team searched the Internet to find some sort of code that a fellow Flash-user might have written that would parse through the text and invert characters so that Arabic would display properly. This approach didn’t cost any money, but it didn’t yield perfect results.
The developers didn’t know enough about Arabic to write such a function themselves, and the functions they found didn’t always display mixed strings (with Arabic, English, and punctuation marks) correctly. They adapted it to fix one obvious problem, but the approach was still not bullet proof.
Another drawback was that the team could not embed fonts in the Flash movie. They could only get the code to work properly by using the default sans-serif font on the end user’s computer, and this meant that they couldn’t apply special filters to the text (e.g. drop shadows) or get text to fade in and out.
More recently, the team purchased a component that seems to be well coded and well supported: Flaraby (http://www.arabicode.com/flaraby/flash_arabic_support.php ).This component permits the embedding of either the “Traditional Arabic” or “Andalus” fonts, and seems to handle the various text mixtures without error. It’s trickier to use (you must use scripting to implement it), but it enables normal visual effects and doesn’t display parentheses in the wrong places or facing the wrong direction (left to right versus right to left).
Another integration challenge is that Arabic fonts display at about two sizes smaller than English fonts. When we increased the font size so that the Arabic user could better read the text, we had to check for possible changes in line breaks and make sure all text was still visible.
Summary
The lessons we learned from this interesting and challenging experience were:
- Keep an open mind about the culture, language intricacies, the technological challenges and advances for the language, design preferences, talent pool available and expectations of your target audience. Working with a new culture or language will be a learning experience, and it is important to set up your team so that it can adapt to the cultural variations – some of which you may discover while the project is in progress.
- If you don’t already do this, use a portal or a file sharing mechanism that allows you to collaborate with all teams in their various locations, and include the client if required. We used a SharePoint portal because some of our government clients did not have FTP access, whereas everyone has access to the Internet via a Web browser. We also found regular conference calls instrumental in collaboration.
- Use varying training media (CD, Internet, paper, instructor-led courses, etc.), and base you choice on the technologies available to the end-users. The infrastructure in other countries is not always the same as in the US. Some countries have a better infrastructure, but in most cases the infrastructure is either similar to the U.S., or worse.
- One of our advantages is that our software developers had worked with the Arabic language before, even though the training team had not. It’s good to have technical persons accessible who understand the technical challenges of working with the language. It may also be useful to provide the team with a brief understanding of the cultural and language differences. Such information is available online, but a linguist or native of the language who is working with your team will be able to provide a better explanation.
- Assign a primary translation QA person who will oversee all of the work. This person’s role is to understand the full training module, and make sure the translations are in context. This person will also help unify the terminology and style of the training course. Repetition is one important learning technique, and the translations will not have the same effect if different synonyms are used to relay any deliberately-repeated information.
- If your development team does not speak the language, if possible use a dynamic training solution that allows them to flip back and forth between English and the target language.
- Show your work at different milestones to the translation team, and to the client if that is possible. It’s important to obtain feedback about critical issues early on.
- Research technical issues that arise with the language you are working with. Others out there may have encountered the same issues and have found useful work -arounds.
Developing training modules for a client in a foreign culture, who speaks a language different from your own, can be very challenging. However, in our global economy, where the world is constantly shrinking due to the advances in technology, it can be a rewarding experience, expanding the expertise of the team and expanding the horizons of each individual team member.