When you look to make your product available in many languages, or when you are looking to extent the availability to a new language, there is the need to do an effort estimation. After all, there is a cost involved with ensuring that your product is available in a new language; with these costs being:
- Cost of manipulating your code to ensure that it can support the new language (for example, if you want to have your product available in Arabic, you need to ensure that your product support the right-to-left style that is supported by Arabic, rather than the convention left-to-right that is supported by English and most other languages). There are other areas in the code which may need to be manipulated before the product can be available in the new language.
- Cost of translation of the application. This involves translation of all the UI elements in the application (and in the second half of this post, I will provide more details of what this means).
- Cost of doing an initial testing of the application in the new language to ensure that you have identified places where the translation needs to be done (this is different from the more detailed testing that needs to be done once all the translated elements are put into the application)
- Functional and linguistic testing that needs to be done to ensure that the application works properly in the new language. You would wonder as to why the translated application needs to have functionality testing, after all, there is no change in functionality. However, there is a lot that can go wrong from a functional perspective during the translation process. Once we had a case where the parameter for the new language was being passed incorrectly, which meant that the application was not working in a specific area, and this was caught during the functional testing and quickly corrected.
- If the application uses external components, then it is needed to be ensured that all these external teams either already support the new language, or provide the required support in your scheduled time.
Once you have worked out all these effort estimates, you need to get onto the actual effort involved with translation, and this can be tricky. There are different UI elements that need translation, with different levels of effort required for these translations. For example:
- There are simple UI text elements. These need to be sent off to the translating team and received back. There is very little complexity in such elements.
- There are images that need translation. If the images have either a snapshot of a section of the application or something in text inside the image, then there is a problem. You need to get snapshots of the application with the new language, and that takes time and effort, but is not complex. However, if you have text within an image (supposed this is showing an image of a template), then you need to get the original image (typically a Photoshop format, a PSD) and then translate the text, and re-insert the new image. This is more complex, and if the application has been in existence for some time, the original image may even have been misplaced.
- If you have videos within the application, that either show instructions or show the application interface, then it gets more complicated. You may need to re-shoot the videos, and that can quickly turn out expensive. Similarly, if you use Flash Video within your application, you will need to generate them again.
- And then there is the complexity associated with languages where the length of the text in certain languages is more than that of the original language. So, when you consider conversions into say German or Japanese, the converted text would be longer than the original text and may not fit properly in the application. In such cases, either the translation has to be tweaked and made shorter, or the application needs to be tweaked to accept the longer text. In both cases, there is a lot of coordination and process.
- Cost of manipulating your code to ensure that it can support the new language (for example, if you want to have your product available in Arabic, you need to ensure that your product support the right-to-left style that is supported by Arabic, rather than the convention left-to-right that is supported by English and most other languages). There are other areas in the code which may need to be manipulated before the product can be available in the new language.
- Cost of translation of the application. This involves translation of all the UI elements in the application (and in the second half of this post, I will provide more details of what this means).
- Cost of doing an initial testing of the application in the new language to ensure that you have identified places where the translation needs to be done (this is different from the more detailed testing that needs to be done once all the translated elements are put into the application)
- Functional and linguistic testing that needs to be done to ensure that the application works properly in the new language. You would wonder as to why the translated application needs to have functionality testing, after all, there is no change in functionality. However, there is a lot that can go wrong from a functional perspective during the translation process. Once we had a case where the parameter for the new language was being passed incorrectly, which meant that the application was not working in a specific area, and this was caught during the functional testing and quickly corrected.
- If the application uses external components, then it is needed to be ensured that all these external teams either already support the new language, or provide the required support in your scheduled time.
Once you have worked out all these effort estimates, you need to get onto the actual effort involved with translation, and this can be tricky. There are different UI elements that need translation, with different levels of effort required for these translations. For example:
- There are simple UI text elements. These need to be sent off to the translating team and received back. There is very little complexity in such elements.
- There are images that need translation. If the images have either a snapshot of a section of the application or something in text inside the image, then there is a problem. You need to get snapshots of the application with the new language, and that takes time and effort, but is not complex. However, if you have text within an image (supposed this is showing an image of a template), then you need to get the original image (typically a Photoshop format, a PSD) and then translate the text, and re-insert the new image. This is more complex, and if the application has been in existence for some time, the original image may even have been misplaced.
- If you have videos within the application, that either show instructions or show the application interface, then it gets more complicated. You may need to re-shoot the videos, and that can quickly turn out expensive. Similarly, if you use Flash Video within your application, you will need to generate them again.
- And then there is the complexity associated with languages where the length of the text in certain languages is more than that of the original language. So, when you consider conversions into say German or Japanese, the converted text would be longer than the original text and may not fit properly in the application. In such cases, either the translation has to be tweaked and made shorter, or the application needs to be tweaked to accept the longer text. In both cases, there is a lot of coordination and process.
No comments:
Post a Comment