2

In our application, we have a bunch of translations in different languages, in English, German, Arabic, and Spanish.

I think, 100% Unit testing coverage can be useful to check the translations, because when the app gets bigger and bigger:

  1. Translations tend to cause human error in manual testing.

  2. Testing translation takes a lot of effort and time when manual testing.


The perfect practice is End2End testing. Then, we need to run manual testing for translations as well.

  1. Given that we have 100% coverage on unit test level,how much manual testing for translation is enough? 100% coverage, 30%, etc...

  2. If the coverage depends on some other factors, then how may i calculate the best coverage?

  3. How should we choose our testcases? We can open a page randomly, and check the translations of this page. But, i am not sure if it is the best approach.

  4. If you have any experiance in testing translations, please specify, how did you do it?

  • Can you clarify how the translations are generated? What specifically are you trying to validate? The translation, or the interaction of the translated text and the system under test? – Kevin McKenzie Jan 13 at 17:53
4

I am not sure unit testing is a good way to test translations. Since what you call a translation is just a static text. It is not built within an algorithm. Normally, when you localize your app for different locales, you describe the text as properties which have different values for different languages. Application then detects the locale and takes the appropriate property values (text in suitable language).

So when you develop a commercial application you usually have original set of Strings. You then pay the native speakers to translate your strings and put a file for particular locale to your app sources or deployment.

So then you just cover your app with manual testing or introduce Selenium (for web) or other sort of tests. But definitely not Unit Tests.

3

It depends.

Unit tests are probably not the best way to test software localization because there is typically a single function that retrieves the proper text from the application resource dictionary.

Typically, localization testing would be done with either UI automation or manually, and would be best handled with a combination of UI automation and manual testing. You would use UI automation to verify that the strings match the expected value for the chosen locale/language. Manual testing would check that the translated strings didn't overlap text, wrap inappropriately, or be cut off.

You'd also want to use manual testing to check input in the different languages. While you could automate some of this, the automation would not catch problems with keyboard input in the other languages - something I've experienced. A US-English keyboard configured to type Turkish gave the software no problems, but a Turkish keyboard caused errors with one specific input. Test automation can't catch this kind of thing.

In the localization testing I've done, there were two phases. Phase one was to check that all the strings used for menus, labels, and buttons were localized. To do this, the software had a fake language that rendered every localization as a random string of numbers. We'd switch to the fake language, then go to every screen looking for anything in English.

Phase two checked that the localizations were correct. For that, there was either someone who spoke the language in question or Google Translate. Again, we'd go to every screen, and check that the correct strings showed up for the language, and that the screen looked right. Since English is a very concise language when it needs to be, most of the localized strings are longer in other languages, which meant that buttons could end up overlapping each other or labels would wrap when they shouldn't, and so on (in my experience, German is the worst for word length, Spanish can be quite wordy, and languages that use different alphabets can cause issues with display sizing because something that's perfectly readable in English with an 8 point font size will be impossible in say Japanese with an 8 point font size).

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.