viaLanguage.com -Translation Articles

Speaking Your Customer’s Language:
Eight Keys to Effective Localization

Considering the amount of time and money companies spend on their Web presence and the important communication vehicle it’s become in the overall communications mix, it’s a shame that localization is still so much of an afterthought in the planning process. Granted, not every company has an international customer set or the need to communicate with a non-English-speaking audience, but for those that do, Web localization shouldn’t seem like a daunting task. And the sooner you familiarize yourself with some of the basics, the easier it will be to confidently start planning your approach to delivering a site that truly speaks your customer’s language.

When it comes to the Web, marketing strategies are vast and seemingly endless. Material on the Web can generate leads, showcase your products and services, demonstrate functionality online, or it can act as a storefront or a portal, etc. Whatever your Web strategy, there’s a direct link between it and your business model. Something as simple as growing your international market and improving your service to non-English-speaking customers allowing requests for information and orders to come in from all over the world can be a first step. When a company’s Web site can be used by speakers of other languages—or residents of other countries in their own languages—they instantly feel more comfortable and become more willing to do business with that company. This is one of the reasons businesses like yours are deciding to localize their Web sites: to address that global market. In order for international customers to see all of your order forms, Flash demonstrations of your product and Web pages that allow direct interaction with your customer service team, you need a localized site. And you can do it relatively painlessly if you know what to watch for and how to get off to the right start.

However, starting a localization project can seem difficult at first. The process inevitably involves translation of somewhat more complicated files than just Word or Excel, for example. As you start the process of localization, how do you know which files to send to your Language Service Provider (LSP)? Do you know your HTML from your XML? What’s a CMS and why should you care? How many subfiles and links are there in a Flash file anyway? The technical issues associated with localizing a Web site can seem overwhelming at first glance, but there are several concepts you can learn and some points to remember as you embark on your project that will make the process easier and more effective. Let’s take a look at what those milestones are along the way, as well as some potholes to avoid. That way, you’ll know ‘em when you see ‘em and can steer clear—or at least brace yourself for the jolt.

1. Know your localization goals and expected results up front.
The first phase of your project, proper planning and evaluation of the material to be localized, is really the foundation of your entire project. During this evaluation phase, your LSP team strives to gain a clear understanding of your company’s requirements. These requirements might be related to technology or language and culture, but typically involve project goals, project needs and the scope of work, as well. In this first phase, your LSP team gathers information from your team that will ensure that they know enough about your business process expectations and goals for your localization project. This is a great time to share your goals, communicate your expectations for the process and clarify the desired result with your LSP team. For example, discussing the final appearance of the site, any cultural adaptation issues, or tone of the final site will ensure that your LSP team localizes the material in the most effective way. Don’t neglect this step, as it will make the rest of the process flow much smoother and minimize potential misunderstandings later.

2. Know your file formats and keep them organized.
When planning the project, you have to make sure that your source files (for example . html, . asp or .XML) are well organized and clearly labeled so that the translator knows which ones to translate. You may know what they are and which ones are important, but don’t assume that your LSP will without some explanation and intuitive labeling. As mentioned, files involved in a localization project can be a little more complicated than everyday files. A Web site could be made up of files containing mark-up language (such as HTML or XML). These files contain not just the body of the Web page to translate, but also mark-up code designating layout, where images should be inserted, and how elements like titles and lists should be treated. It’s important to remember that the code itself won’t be translated, but the titles, body text and titles of figures will be. Your LSP can easily work around the mark-up code using various translation tools that ignore the code until it’s needed for the final presentation on the Web.

3. Understand what your LSP needs from you up front.
It can make the process easier for both you and your LSP when you know exactly what’s needed by your localization team in order to localize the material quickly and accurately. When sending source files to your LSP team, specify which files should be translated and what parts of those files should be translated. Be sure to decide which figures and graphs should be translated and how. Keep in mind that navigational buttons and instructions should be localized into the target language. Where you have versions of a page or a site in a different language, provide a way for the user to view the material in the language they prefer. Also, when providing links to pages in other languages, don’t forget to include the names of the languages or countries in the native language. For example, you would use “Deutsch” instead of German or “Español” instead of Spanish.

Even though your LSP team can easily work around mark-up language like HMTL, sometimes your team will want to submit material exported from these Web files as Excel or Word files. Perhaps your team wanted a reviewer who is not used to viewing Web pages with code to review the material and then send the revised version to be localized, or maybe your team just wants the material translated as a Word file because the final Web page is undergoing a redesign. Whatever the case, a good LSP will ask you if you’d like them to receive and translate the material directly from the source files, whether that be .XML, .SGML, or. HTML. Why not cut out the middle step and have your LSP translate directly from the source? This will save your team time and effort.

If your team still wants to export material into a Word or Excel file, the exported material will most likely contain links. Be sure to let your LSP team know whether or not to translate the titles of the links or the links themselves. Usually titles of links are translated on a Web page because they refer to an English page, form or manual, or maybe even to another localized Web page or document. Unless the title is an actual link, the functionality of the link remains untouched by whatever the descriptive (or visible) text for the link is. The only rule is that the name of the link should be consistent with the page title to where it leads. If the link "Informationen zur Fehlersuche bei Anschlussproblemen," for example, jumps to an English manual called "Connectivity Troubleshooting Guide," you would have to change the German manual title in the document back to English. Apart from that, "links" in these files might function as placeholders to show how where there is a link in the actual Web page or to show the Web site programmer what the links should look like.

4. Know where the content is—and how to get at it: Content Management Systems and localization.
A content management system (CMS) is a computer software system that helps users manage a large body of documents and other content, like images and multimedia resources. A CMS can help bring documents and other media together in a creative way. An example of a CMS would be an electronic catalog of products for a business. A Web content management system has additional features to make it easier to publish Web content to Web sites. These can be used for storing, controlling and publishing documentation like operators’ manuals, technical manuals, sales guides and marketing materials.

Localizing CMS material can be useful because you can reuse the material again and again throughout the system. If there are modifications necessary once in a while, it’s usually very easy to make a small change to one piece of material and have it used throughout your business by using the CMS. In addition, translating material and then using it in a CMS improves quality and consistency since the documentation shows up correct however it’s accessed.

5. Understand the applications and technology.
When you’re working with localization projects, sometimes the technical side of the process can be challenging. Two file types you’ll want to gain a better understanding of are .XML and Flash files. Both file types sometimes include subfiles and reference material that you can provide to your LSP in order to make the localization process easier.

XML stands for Extensible Markup Language. This mark-up language is seen as an improvement over HTML because it doesn’t have a fixed format like HTML does. This allows the creator of XML Web pages to be more creative and extensive when setting up a site. To correctly localize XML documents, the LSP team needs to know things like which elements and attributes are translatable. They also need to know which elements are inline—meaning they should not break a sentence—and which elements are structural. In order to know which material to translate and which material not to translate, it’s good practice to send your LSP a file called a DTD (Document Type Description). It sets out what names are to be used for the different types of elements and shows how they all fit together. DTDs are not required for processing well-formed documents, but they are needed if your team will be using the more complicated functions of XML.

Flash files are designed for video, graphics and animation and are often used in Web sites or online presentations. Flash source files have an .FLA extension and are editable with Adobe or Macromedia Flash software. Flash often reads text from resource files, which are often .XML files, so your LSP team could translate the .XML files associated with the Flash file. Your LSP could translate and localize the text strings, re-insert them in the Flash file and then test the movie or presentation for broken links and other errors.

6. Ensure correct encoding of localized documents.
For Web sites in non-Western languages such as Japanese or Russian, choose Unicode or UTF-8 when encoding your page. In fact, even for Western languages, it’s safest to encode with Unicode because Unicode is a universal character set. It standardizes and defines all the characters needed for writing the majority of living languages in use on computers.

7. Always, always, always take culture into account when localizing.
Cultural adaptation, in terms of the images you use, the format for dates and fill-in forms and the tone of the translation, is very important. Be careful when setting up forms and fill-in boxes or fields on your Web site. Don’t assume that the target country or language sets addresses and names as we do in the U.S. In some cultures, there are no street names; in others the house number follows the street name. Sometimes more than one line is needed for the part of the address that is before the city name. When building your site, be careful of how you label forms showing numeric dates because most cultures set the day, month and year in a different order. As mentioned, keep your target audience and target culture in mind when selecting images of people or symbols for your site. For example, two fingers held up in a “victory” sign has an extremely offensive meaning in some cultures, and some cultures might not want to see photos of women that can be deemed “immodest” on a Web site. Considering all of these factors is essential when localizing a Web site.

8. Don’t neglect testing and Quality Assurance
Testing is one of the last steps in the localization process and one of the most important. It goes hand-in-hand with Quality Assurance. Your LSP can help you by testing your final Web site for you, or they can guide you through the testing process so that one of your international branches can carry out the testing process. The important point here is that you actually devote the time to testing and QA. Testing a localization project involves looking for broken links, ensuring compatibility with native operating systems, and catching any language mistakes that might have been introduced during the localization process. The LSP can also do one final check for cultural issues and functionality of Web forms, etc.

After some careful planning and evaluation of your localization project up front, discussion with your LSP of your localization and business goals for a project and learning about some of the technical issues involved in translating Web sites, the localization process should go very smoothly. It’s amazing how much of a difference it can make to follow these steps when starting localization of your Web site.


	viaLanguage Translation Articles Speaking Your Customer’s Language: Eight Keys to Effective Localization Considering the amount of time and money companies spend on their Web presence and the important communication vehicle it’s become in the overall communications mix, it’s a shame that localization is still so much of an afterthought in the planning process. Granted, not every company has an international customer set or the need to communicate with a non-English-speaking audience, but for those that do, Web localization shouldn’t seem like a daunting task. And the sooner you familiarize yourself with some of the basics, the easier it will be to confidently start planning your approach to delivering a site that truly speaks your customer’s language. When it comes to the Web, marketing strategies are vast and seemingly endless. Material on the Web can generate leads, showcase your products and services, demonstrate functionality online, or it can act as a storefront or a portal, etc. Whatever your Web strategy, there’s a direct link between it and your business model. Something as simple as growing your international market and improving your service to non-English-speaking customers allowing requests for information and orders to come in from all over the world can be a first step. When a company’s Web site can be used by speakers of other languages—or residents of other countries in their own languages—they instantly feel more comfortable and become more willing to do business with that company. This is one of the reasons businesses like yours are deciding to localize their Web sites: to address that global market. In order for international customers to see all of your order forms, Flash demonstrations of your product and Web pages that allow direct interaction with your customer service team, you need a localized site. And you can do it relatively painlessly if you know what to watch for and how to get off to the right start. However, starting a localization project can seem difficult at first. The process inevitably involves translation of somewhat more complicated files than just Word or Excel, for example. As you start the process of localization, how do you know which files to send to your Language Service Provider (LSP)? Do you know your HTML from your XML? What’s a CMS and why should you care? How many subfiles and links are there in a Flash file anyway? The technical issues associated with localizing a Web site can seem overwhelming at first glance, but there are several concepts you can learn and some points to remember as you embark on your project that will make the process easier and more effective. Let’s take a look at what those milestones are along the way, as well as some potholes to avoid. That way, you’ll know ‘em when you see ‘em and can steer clear—or at least brace yourself for the jolt. 1. Know your localization goals and expected results up front. The first phase of your project, proper planning and evaluation of the material to be localized, is really the foundation of your entire project. During this evaluation phase, your LSP team strives to gain a clear understanding of your company’s requirements. These requirements might be related to technology or language and culture, but typically involve project goals, project needs and the scope of work, as well. In this first phase, your LSP team gathers information from your team that will ensure that they know enough about your business process expectations and goals for your localization project. This is a great time to share your goals, communicate your expectations for the process and clarify the desired result with your LSP team. For example, discussing the final appearance of the site, any cultural adaptation issues, or tone of the final site will ensure that your LSP team localizes the material in the most effective way. Don’t neglect this step, as it will make the rest of the process flow much smoother and minimize potential misunderstandings later. 2. Know your file formats and keep them organized. When planning the project, you have to make sure that your source files (for example . html, . asp or .XML) are well organized and clearly labeled so that the translator knows which ones to translate. You may know what they are and which ones are important, but don’t assume that your LSP will without some explanation and intuitive labeling. As mentioned, files involved in a localization project can be a little more complicated than everyday files. A Web site could be made up of files containing mark-up language (such as HTML or XML). These files contain not just the body of the Web page to translate, but also mark-up code designating layout, where images should be inserted, and how elements like titles and lists should be treated. It’s important to remember that the code itself won’t be translated, but the titles, body text and titles of figures will be. Your LSP can easily work around the mark-up code using various translation tools that ignore the code until it’s needed for the final presentation on the Web. 3. Understand what your LSP needs from you up front. It can make the process easier for both you and your LSP when you know exactly what’s needed by your localization team in order to localize the material quickly and accurately. When sending source files to your LSP team, specify which files should be translated and what parts of those files should be translated. Be sure to decide which figures and graphs should be translated and how. Keep in mind that navigational buttons and instructions should be localized into the target language. Where you have versions of a page or a site in a different language, provide a way for the user to view the material in the language they prefer. Also, when providing links to pages in other languages, don’t forget to include the names of the languages or countries in the native language. For example, you would use “Deutsch” instead of German or “Español” instead of Spanish. Even though your LSP team can easily work around mark-up language like HMTL, sometimes your team will want to submit material exported from these Web files as Excel or Word files. Perhaps your team wanted a reviewer who is not used to viewing Web pages with code to review the material and then send the revised version to be localized, or maybe your team just wants the material translated as a Word file because the final Web page is undergoing a redesign. Whatever the case, a good LSP will ask you if you’d like them to receive and translate the material directly from the source files, whether that be .XML, .SGML, or. HTML. Why not cut out the middle step and have your LSP translate directly from the source? This will save your team time and effort. If your team still wants to export material into a Word or Excel file, the exported material will most likely contain links. Be sure to let your LSP team know whether or not to translate the titles of the links or the links themselves. Usually titles of links are translated on a Web page because they refer to an English page, form or manual, or maybe even to another localized Web page or document. Unless the title is an actual link, the functionality of the link remains untouched by whatever the descriptive (or visible) text for the link is. The only rule is that the name of the link should be consistent with the page title to where it leads. If the link "Informationen zur Fehlersuche bei Anschlussproblemen," for example, jumps to an English manual called "Connectivity Troubleshooting Guide," you would have to change the German manual title in the document back to English. Apart from that, "links" in these files might function as placeholders to show how where there is a link in the actual Web page or to show the Web site programmer what the links should look like. 4. Know where the content is—and how to get at it: Content Management Systems and localization. A content management system (CMS) is a computer software system that helps users manage a large body of documents and other content, like images and multimedia resources. A CMS can help bring documents and other media together in a creative way. An example of a CMS would be an electronic catalog of products for a business. A Web content management system has additional features to make it easier to publish Web content to Web sites. These can be used for storing, controlling and publishing documentation like operators’ manuals, technical manuals, sales guides and marketing materials. Localizing CMS material can be useful because you can reuse the material again and again throughout the system. If there are modifications necessary once in a while, it’s usually very easy to make a small change to one piece of material and have it used throughout your business by using the CMS. In addition, translating material and then using it in a CMS improves quality and consistency since the documentation shows up correct however it’s accessed. 5. Understand the applications and technology. When you’re working with localization projects, sometimes the technical side of the process can be challenging. Two file types you’ll want to gain a better understanding of are .XML and Flash files. Both file types sometimes include subfiles and reference material that you can provide to your LSP in order to make the localization process easier. XML stands for Extensible Markup Language. This mark-up language is seen as an improvement over HTML because it doesn’t have a fixed format like HTML does. This allows the creator of XML Web pages to be more creative and extensive when setting up a site. To correctly localize XML documents, the LSP team needs to know things like which elements and attributes are translatable. They also need to know which elements are inline—meaning they should not break a sentence—and which elements are structural. In order to know which material to translate and which material not to translate, it’s good practice to send your LSP a file called a DTD (Document Type Description). It sets out what names are to be used for the different types of elements and shows how they all fit together. DTDs are not required for processing well-formed documents, but they are needed if your team will be using the more complicated functions of XML. Flash files are designed for video, graphics and animation and are often used in Web sites or online presentations. Flash source files have an .FLA extension and are editable with Adobe or Macromedia Flash software. Flash often reads text from resource files, which are often .XML files, so your LSP team could translate the .XML files associated with the Flash file. Your LSP could translate and localize the text strings, re-insert them in the Flash file and then test the movie or presentation for broken links and other errors. 6. Ensure correct encoding of localized documents. For Web sites in non-Western languages such as Japanese or Russian, choose Unicode or UTF-8 when encoding your page. In fact, even for Western languages, it’s safest to encode with Unicode because Unicode is a universal character set. It standardizes and defines all the characters needed for writing the majority of living languages in use on computers. 7. Always, always, always take culture into account when localizing. Cultural adaptation, in terms of the images you use, the format for dates and fill-in forms and the tone of the translation, is very important. Be careful when setting up forms and fill-in boxes or fields on your Web site. Don’t assume that the target country or language sets addresses and names as we do in the U.S. In some cultures, there are no street names; in others the house number follows the street name. Sometimes more than one line is needed for the part of the address that is before the city name. When building your site, be careful of how you label forms showing numeric dates because most cultures set the day, month and year in a different order. As mentioned, keep your target audience and target culture in mind when selecting images of people or symbols for your site. For example, two fingers held up in a “victory” sign has an extremely offensive meaning in some cultures, and some cultures might not want to see photos of women that can be deemed “immodest” on a Web site. Considering all of these factors is essential when localizing a Web site. 8. Don’t neglect testing and Quality Assurance Testing is one of the last steps in the localization process and one of the most important. It goes hand-in-hand with Quality Assurance. Your LSP can help you by testing your final Web site for you, or they can guide you through the testing process so that one of your international branches can carry out the testing process. The important point here is that you actually devote the time to testing and QA. Testing a localization project involves looking for broken links, ensuring compatibility with native operating systems, and catching any language mistakes that might have been introduced during the localization process. The LSP can also do one final check for cultural issues and functionality of Web forms, etc. After some careful planning and evaluation of your localization project up front, discussion with your LSP of your localization and business goals for a project and learning about some of the technical issues involved in translating Web sites, the localization process should go very smoothly. It’s amazing how much of a difference it can make to follow these steps when starting localization of your Web site.