Before trying to understand why terminology is so important in the localisation process, we should first pose the question what software terminology means for localisation.
Software terminology does not have much in common with classical specialised terminology, except for the common goal of a "smooth understanding". One important difference is that software terminology aims towards the communication between humans and machines, whereas specialised terminology serves for communication between humans. Though it is often the case software users do not necessarily need specialised knowledge, the percentage of specialised terminology contained in a particular software package can vary depending on the degree of specialisation of the software. (cf. Kemmann, 2002:88)
Since the users in a particular target market should (and want to) be addressed in their mother-tongue, searching for terminology in the target language becomes an important step in the software localisation process, which usually poses interesting challenges. In the software localisation market it is often the case that terminology does not exist in the target language and translators/localisers have to structure the source language terminology and fix the possible target language equivalents prior to project start. The consistent use of terminology from the very beginning to the closing phase of the project is a sine qua non for software localisation. Otherwise, think of the tower of Babel that it could arise if terminology is not used consistently when translating all software components – software as such (user interface) and documentation (online help, written documentation and product web pages)? Another reason for defining the terminology to be used in the initial phase of projects has to do with the fact that software localisation projects are often complex projects with very tight deadlines where several people are involved (cf. Schmitz, 2005a:9-10).
Experiences in the field of software localisation have shown that commonly-used terminology data categories (such as the ISO 12620 from 1999) are not enough when performing terminology work for software localisation.
But why is this so? The reason has mostly to do with the fact that in software, one single term can refer to different concepts depending on its immediate context (e.g. if it appears in a menu, in a dialog window or in an error message).
In addition, there are differences between the terminology used in software documentation (online help and websites) and that used in software user interface. Software documentation can be considered "normal" specialised text containing terms, which can be treated as concept-oriented terminology entries . However, when using some of the terminology found in software user interfaces as an example – such as "save as", "insert table", "mark index entry", etc. and other sort of system messages – it is not easy to define the concept (according to terminology science) of such "terms".
A partial solution would be to process such user interface terminology (e.g. system messages) in translation memory tools instead of terminology management systems. The problem is that TM tools do not allow to accurately describe localisation units using data categories.
Another option is to use specific data categories for localisation units. The following table shows Reineke's (2003) proposal for localisation specific data categories. They are assigned to all levels of an entry and allow terminological description of elements present in software interfaces (cf. Schmitz, 2005b:42-44).
Localization Type | Type of the localizable element (main resource type) (menu, dialogue window, system message etc.) |
| Type of menu element (menu type) (menu, bar, menu item etc.) |
| Type of dialogue box element (control type) (check button, push button, static etc.) |
| Type of system message (string type) (message, status bar etc.) |
Environment subset | Indication of validity in a specific environment (environment subset) (e.g. Windows) |
Product subset | Indication of validity for a specific program (product subset) (e.g. Notepad) |
Resource ID | Unique ID of localization unit (resource ID) (meaning entry level) |
Localization source | Locale of original software (localization) (e.g. en-US) |
Localization target | Locale of software to be localized (localization target) (e.g. de-DE) |
Reineke’s localisation specific data categories: Repetition for every term and localization unit (taken from Schmitz, 2005b:44)
Here are some general tips regarding terminology work which can be useful for translators/localisers as well as for technical writers when doing software localisation:
- Create a glossary or (even better) a terminology database for the specific localisation project with terms related to the product, company or industry.
- Use simple and concise phrases. For example, define from the outset if you want to use "click on", "click", "choose" or "select" when describing commands.
- Maintain consistency across all software components – software (user interface) and documentation (online help, written documentation and product web pages).
(Adapted from Esselink, 2000:28)
Contextual information and available reference materials are very important for the completion of terminology work. Translators should know the context of text elements that can appear as stand-alone elements, for example in the software interface. They should also be aware of the software context, which means the environment to which the software belongs and that can demand the use of a specific given terminology – e.g. Windows terminology. Among the materials that translators/localisers can use as reference for context are:
- Glossaries for operating systems
- Help files, online help
- Reference manuals with description of individual elements
- Operating system in target language
- Current functioning version of the application in the source language
- Previous version of the application in the target language
(Adapted from Ottmann, 2002:149)