Our Workflow

• Documentation
• Help files
• User interface
• Collateral
• Linguist selection

Documentation

Most technical documentation is laid out using Adobe FrameMaker. Recent versions of the program let you create multiple versions of the same documents within the same file. For example you could have one version for print/PDF and a second version for the Web, or maybe you could have different versions of the manual for different versions of a hardware device. In some cases the documentation is written as a set of interlinked HTML files. The workflow for documentation in HTML format is similar to the one for FrameMaker files described below.

Define project timeline and resources – One project manager is the focal point for the localization. Larger projects may also have a senior translator for each language who acts as a team leader for her language. The PM selects the linguists who are the best fit for the type of project. The PM and the client define and agree on a schedule and on the project deliverables. During the course of the project, the PM keeps all the members of the team – including the client – informed on the status of the project.

Prepare a project glossary – We read the English documents and identify terminology that may need to be part of a glossary used during the project. Typically this will include user interface elements (menus, window names), product names, titles of manuals, as well as technical terms specific to the topic or to the client. Creating a glossary helps keep terminology consistent through all the phases and between the various translators that will be involved. We find that time spent in this phase helps minimize problems and questions in later phases. A style specification may also be developed at this point to define how to handle acronyms, UI elements, terms not to be translated, etc.

Align previous translation – If you have previously translated some similar documentation (perhaps for previous version of the same software or hardware), we may be able to reuse some of the translation by "aligning" the existing text and creating a translation memory that can be used as a stating point during the translation of the new documents. This can help reduce the costs, sometimes dramatically. The major drawback is that if the quality of the translation in the documents used for the alignment is not good, the editing phase will take more effort to improve the quality of the old parts of the document to bring them to the same level of new document. And if you already have translation memories in any format, we can use them or convert them to a usable format.

Screenshots – If there are any images included in the text that show elements of the user interface of the program (such as menus, window titles, etc.) that wave been localized, we take screenshots of those images from the localized program. Specialized screen capture software and graphic software is used to perform screen captures and to manipulate the resulting images so that the size and format of the localized graphics matches the corresponding source images. If there are any additional images that need to be localized (charts, diagrams, etc.) these are modified wherever feasible using the same graphics program used to generate the original image, after the text has been translated and edited.

Prepare files for translation – We take the English FrameMaker files and convert them to tagged RTF files that are sent to the translators.

Translation and editing – Translators use the Computer Aided Translation (CAT) software Trados to translate the tagged file within Microsoft Word. Using CAT tools helps in keeping terminology and style consistent and allows reuse of existing translations that reduce the cost of translation. Depending on the size of the project there may be more translators working in parallel on different documents or different parts of the documents. The primary responsibility of the translators is to deliver text that reflects the original, using correct terminology (including the terminology from the project glossaries) and grammar. The translator also documents any problems found with the source text or any problems using the glossary terminology in the context of the document. After the translation is complete, a second translator edits the translated text. This provides a built-in quality control step. The responsibility of the editor is to verify that the document reads well in the target language and that there is no untranslated text. The editor also evaluates the quality of the translation in terms of correct use of grammar, terminology and style.

DTP – The translated and edited RTF files are converted back into FrameMaker and the files are given to a third linguist who will do minor changes in the layout to make it fit the translated text. PDF files of the source and target documents are used to proofread the document and verify that the layout of the source and target match and that there are no missing or incorrect tags causing visible differences in the two documents. The proofreader also verifies that the terminology used in the images within the document (for example a screenshot of the program's UI) corresponds to what is used in the text, and that images that should be localized are in the correct language. Any changes to the FrameMaker files are also implemented in the corresponding translated RTF files. This guarantees that the final translation memory for the project is a true image of the completed document.

Delivery and Archive – The translated documents are delivered to the client, together with a copy of the translation memory for the project. This translation memory can be used for future translation even if the clients uses another translation service provider for their future needs (but we hope you will choose us once again next time). One copy of all the files generated during the project is archived. The archive is kept for at least one year from the end of the project, as defined in the project deliverables.

Help Files

Help files are often the largest component of a localization project. Most help files for both Windows and Mac operating systems are sets of linked HTML files. It is not unusual to have hundreds of individual HTML files included in the help for a single product. Programs like RoboHelp from eHelp are used to create the help structure. Recent versions of Adobe FrameMaker let you create a help file structure directly from the files used for the documentation of the program. In Windows the HTML files are compiled to create a single searchable file. Older programs may use legacy help systems based on RTF rather than HTML, but the workflow is similar.

Define project timeline and resources – One project manager is the focal point for the localization. Larger projects may also have a senior translator for each language who acts as a team leader for her language. The PM selects the linguists who are the best fit for the type of project. The PM and the client define and agree on a schedule and on the project deliverables. During the course of the project, the PM keeps all the members of the team – including the client – informed on the status of the project.

Prepare a project glossary – We read the English documents and identify terminology that may need to be part of a glossary used during the project. Typically this will include user interface elements (menus, window names), product names, titles of manuals, as well as technical terms specific to the topic or to the client. Creating a glossary helps keep terminology consistent through all the phases and between the various translators that will be involved. We find that time spent in this phase helps minimize problems and questions in later phases. A style specification may also be developed at this point to define how to handle acronyms, UI elements, terms not to be translated, etc. In this phase we also identify those elements such as contact phone numbers and addresses, URLs, etc. that will need to be different for each language.

Align previous translation – If you have previously translated some similar documentation (perhaps for previous version of the same software or hardware), we may be able to reuse some of the translation by "aligning" the existing text and creating a translation memory that can be used as a stating point during the translation of the new documents. This can help reduce the costs, sometimes dramatically. The major drawback is that if the quality of the translation in the documents used for the alignment is not good, the editing phase will take more effort to improve the quality of the old parts of the document to bring them to the same level of new document. And if you already have translation memories in any format, we can use them or convert them to a usable format.

Screenshots – If there are any images included in the text that show elements of the user interface of the program (such as menus, window titles, etc.) that wave been localized, we take screenshots of those images from the localized program. Specialized screen capture software and graphic software is used to perform screen captures and to manipulate the resulting images so that the size and format of the localized graphics matches the corresponding source images. If there are any additional images that need to be localized (charts, diagrams, etc.) these are modified wherever feasible using the same graphics program used to generate the original image, after the text has been translated and edited.

Prepare files for translation – We take the English HTML files and convert them to tagged RTF files that are sent to the translators.

Translation and editing – Translators use the Computer Aided Translation (CAT) software Trados to translate the tagged file within Microsoft Word. Using CAT tools helps in keeping terminology and style consistent and allows reuse of existing translations that reduce the cost of translation. Depending on the size of the project there may be more translators working in parallel on different documents or different parts of the documents. The primary responsibility of the translators is to deliver text that reflects the original, using correct terminology (including the terminology from the project glossaries), style  and grammar. The translator also documents any problems found with the source text or any problems using the glossary terminology in the context of the document. After the translation is complete, a second translator edits the translated text. This provides a built-in quality control step. The responsibility of the editor is to verify that the document reads well in the target language and that there is no untranslated text. The editor also evaluates the quality of the translation in terms of correct use of grammar, terminology and style.

Help Testing – The translated and edited RTF files are converted back into HTML and the files are given to a third linguist who will compare the source and target documents to proofread the document and verify that the layout of the source and target match and that there are no missing or incorrect tags causing visible differences in the two documents. The QA tester also verifies that the terminology used in the images within the document (for example a screenshot of the program's UI) corresponds to what is used in the text, and that images that should be localized are in the correct language. The index is edited to eliminate redundant entries and to alphabetize the entries correctly in the target language. Internal links within the help files are normally tested using automated tools such at HTMLQA. Any changes to the HTML files are also implemented in the corresponding translated RTF files. This guarantees that the final translation memory for the project is a true image of the completed document.

Delivery and Archive – The translated documents are delivered to the client, together with a copy of the translation memory for the project. This translation memory can be used for future translation even if the clients uses another translation service provider for their future needs (but we hope you will choose us once again next time). One copy of all the files generated during the project is archived. The archive is kept for at least one year from the end of the project, as defined in the project deliverables.

User Interface

While the format of the documentation and help components of a localization project are fairly standardized, localizing the user interface can require a customized approach for each project. The workflow listed below is just an example that may be applicable to the most common projects. In all cases, the localization of the UI requires more upfront preparation work than the other components of the localization project.

Define project timeline and resources – One project manager is the focal point for the localization. Larger projects may also have a senior translator for each language who acts as a team leader for her language. The PM selects the linguists who are the best fit for the type of project. The PM and the client define and agree on a schedule and on the project deliverables. During the course of the project, the PM keeps all the members of the team – including the client – informed on the status of the project.

Prepare a project glossary – We read the English documents and identify terminology that may need to be part of a glossary used during the project. Typically this will include user interface elements (menus, window names), product names, titles of manuals, as well as technical terms specific to the topic or to the client. Creating a glossary helps keep terminology consistent through all the phases and between the various translators that will be involved. We find that time spent in this phase helps minimize problems and questions in later phases. A style specification may also be developed at this point to define how to handle acronyms, UI elements, terms not to be translated, etc. In this phase we also identify those elements such as contact phone numbers and addresses, URLs, etc. that will need to be different for each language.

Extract UI strings – In many cases the strings used in the user interface may be part of a separate resource file. Otherwise we can use specialized software such as Catalyst or Powerglot to extract the translatable strings directly from the program. The same programs are used after the translation to insert the strings back into the localized software.

Prepare files for translation – We take the string files and convert them to tagged RTF files that are sent to the translators.

Translation and editing – Translators use the Computer Aided Translation (CAT) software Trados to translate the tagged file within Microsoft Word. Using CAT tools helps in keeping terminology and style consistent and allows reuse of existing translations that reduce the cost of translation. Depending on the size of the project there may be more translators working in parallel on different documents or different parts of the documents. The primary responsibility of the translators is to deliver text that reflects the original, using correct terminology (including the terminology from the project glossaries), style and grammar. Standard terminology for the operating system elements is used. The translator also documents any problems found with the source text or any problems using the glossary terminology in the context of the document. After the translation is complete, a second translator edits the translated text. This provides a built-in quality control step. The responsibility of the editor is to verify that the document reads well in the target language and that there is no untranslated text. The editor also evaluates the quality of the translation in terms of correct use of grammar, terminology and style.

Initial delivery – For resource files, the set of translated and edited strings is then delivered to the client to be inserted back into the program and compiled.

Testing – Once the translation is inserted back into the program, the software needs to be tested for linguistic accuracy. The QA tester verifies that there are no untranslated strings (in most cases those will be hard coded stings not part of the resource files), that the text fits in the text boxes, dropdown boxes, etc., and that the translation is correct in context. In some languages the same English term can have different translations depending on the use (in menus, buttons, text boxes, etc.) and it may not be possible to confirm that the term used in the translation is correct until the string is viewed in context. The tester also verifies that high ASCII characters (mostly accented characters) are rendered correctly and that entering high ASCII characters in text boxes (for example to enter first and last name in the registration page within the installer program) works as expected. All cosmetic and functional bugs found during testing are logged and documented using screenshots wherever feasible. In most cases we can fix the truncation bugs ourselves by tweaking the layout of the UI windows (using the same programs that the client uses such as Visual Studio, CodeWarrior, etc.), while other bugs may require some action by the client. After the bugs fixes are implemented, we regress each bug to verify that they are indeed fixed. Wherever feasible, changes to the UI are also implemented in the corresponding translated RTF files. This guarantees that the final translation memory for the project is a true image of the completed document.

Delivery and Archive – At the end of the project,  a copy of the translation memory for the project is delivered to the client. This translation memory can be used for future translation even if the clients uses another translation service provider for their future needs (but we hope you will choose us once again next time). One copy of all the files generated during the project is archived. The archive is kept for at least one year from the end of the project, as defined in the project deliverables.

Collateral

Besides the User Interface strings, the documentation and the help system, there can be a number of other smaller components to a localization project. Collectively these components are referred to as collateral. Typically you will need localization of:

• Software box
• CD label
• License agreement
• Warranty/service information
• Tutorials
• Product information on a website
• Last minute information, readme file

• Primary language being the target language (requirement)
• Years of full time experience in translation and/or software localization
• Years of full time experience in a computer-related profession
• Highest level of education
• Translation and interpretation degree
• Technical degree in an engineering or science field
• Accreditation in the language pair by a national translator association
• Level of experience with computer aided translation and/or with localization software
• Level of involvement in the translator community through conference presentations, Internet resources, teaching, etc.

After they start working on localization projects their work is evaluated at the end of each project, based on the feedback from editors, proofreaders or the client. The feedback is provided to the linguist as an opportunity to learn and improve. Linguists who consistently receive evaluations below average will receive lower ranking and may be pulled from the vendor database.