Comments on: Localization Testing Part IV http://www.testingmentor.com/imtesty/2009/11/18/localization-testing-part-iv/ Treatises on the practice of software testing Tue, 07 Feb 2012 09:15:11 -0500 hourly 1 http://wordpress.org/?v=3.1.3 By: Bj Rollison http://www.testingmentor.com/imtesty/2009/11/18/localization-testing-part-iv/comment-page-1/#comment-595 Bj Rollison Sat, 23 Jan 2010 16:50:53 +0000 http://testingmentor.com/imtesty/2009/11/18/localization-testing-part-iv/#comment-595 Hi Jason, Thank you for reading my blog. I hope the information was useful. Localization can indeed be costly; sometimes more so than necessary. After a brief look at the MTS site I suspect you software products are pretty critical for the end-user and can understand the importance of context in the translation. However, I also suspect there are easier ways to accomplish that. Since I suspect you are already doing usability testing on the English language version the 'usability' of the localized versions really doesn't change that much. For example making sure key mnemonics work (checks for duplicate shortcut keys can often be done by the localization tool), tab settings (if the localizer has to muck around with a dialog, clipping, truncation, etc. With regard to writing tests to expose dialogs/messageboxes/windows at runtime for 'linguistic experts' I agree that is a lot of overhead. Many localization tools display a static dialog/window containing the strings they need to localize. One suggestion might be to have the localizers capture an image of the dialog/messagebox/window after they localize it and let the 'language experts' review those captured images. (Of course, sometimes the layout of a dialog/window appears differently at runtime, but it doesn't change the translation.) If you'd like to discuss this more please contact me and we can perhaps brainstorm a solution that is less costly for your team. Hi Jason,
Thank you for reading my blog. I hope the information was useful. Localization can indeed be costly; sometimes more so than necessary.

After a brief look at the MTS site I suspect you software products are pretty critical for the end-user and can understand the importance of context in the translation. However, I also suspect there are easier ways to accomplish that.

Since I suspect you are already doing usability testing on the English language version the ‘usability’ of the localized versions really doesn’t change that much. For example making sure key mnemonics work (checks for duplicate shortcut keys can often be done by the localization tool), tab settings (if the localizer has to muck around with a dialog, clipping, truncation, etc.

With regard to writing tests to expose dialogs/messageboxes/windows at runtime for ‘linguistic experts’ I agree that is a lot of overhead. Many localization tools display a static dialog/window containing the strings they need to localize. One suggestion might be to have the localizers capture an image of the dialog/messagebox/window after they localize it and let the ‘language experts’ review those captured images. (Of course, sometimes the layout of a dialog/window appears differently at runtime, but it doesn’t change the translation.)

If you’d like to discuss this more please contact me and we can perhaps brainstorm a solution that is less costly for your team.

]]> By: Jason Cordes http://www.testingmentor.com/imtesty/2009/11/18/localization-testing-part-iv/comment-page-1/#comment-592 Jason Cordes Fri, 22 Jan 2010 21:33:20 +0000 http://testingmentor.com/imtesty/2009/11/18/localization-testing-part-iv/#comment-592 Bj - Thanks for your posts on localization testing. This is a difficult subject to find information about, yet a very important topic because it is a very costly process. One of the teams at my company is in the process of feeling the pain you describe. We have a new application that contains approx. 300 screens and thousdands of strings that we are supporting in 12 languages. We have a process that is very brute force. We don't think it is a great process, but haven't been able to find anyone else in the industry willing or interested in talking about a better way to do this. Our most glaring problem is that we are using local language experts for context & usability testing. The language experts are not framiliar with our software. We have written manual test cases to help them find all the screens. These test cases come at a cost to write plus a cost to maintain. We have a complex application that comes with a setup cost just to be able to run our application. Since or language experts are not framiliar with the software, we don't have a lot of confidence in them successfully reaching all of the screens, and also recognize that it takes them longer to do this than it would a member of our test team. The thing we continue to wonder is, is there a better way? We figure there must be some sort of tool that can rip our all of an app's windows (in local language) and put them in some sort of e-document so that our local langague experts don't need to waste time learning on how to run our software, and can just review the windows, screen by screen, in an unitimidating environment. Can you comment about any specific expreiences you have with our problem, or maybe any comments about how Microsoft deals with this? Thanks again for the posts. It was amazing to read that you described all of our issues to a T. Jason Bj – Thanks for your posts on localization testing. This is a difficult subject to find information about, yet a very important topic because it is a very costly process. One of the teams at my company is in the process of feeling the pain you describe. We have a new application that contains approx. 300 screens and thousdands of strings that we are supporting in 12 languages. We have a process that is very brute force. We don’t think it is a great process, but haven’t been able to find anyone else in the industry willing or interested in talking about a better way to do this. Our most glaring problem is that we are using local language experts for context & usability testing. The language experts are not framiliar with our software. We have written manual test cases to help them find all the screens. These test cases come at a cost to write plus a cost to maintain. We have a complex application that comes with a setup cost just to be able to run our application. Since or language experts are not framiliar with the software, we don’t have a lot of confidence in them successfully reaching all of the screens, and also recognize that it takes them longer to do this than it would a member of our test team. The thing we continue to wonder is, is there a better way? We figure there must be some sort of tool that can rip our all of an app’s windows (in local language) and put them in some sort of e-document so that our local langague experts don’t need to waste time learning on how to run our software, and can just review the windows, screen by screen, in an unitimidating environment. Can you comment about any specific expreiences you have with our problem, or maybe any comments about how Microsoft deals with this? Thanks again for the posts. It was amazing to read that you described all of our issues to a T.

Jason

]]>