Working with different UI elements for translation ..

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.

What we can do to avoid browser incompatibility?

Malfunctioning of the web sites across various browsers has become a topic of utter annoyance.

Why it happens so that your web site functions perfectly well on one browser and at the same time fails to perform well in some other browser?
Why it appears to be missing some thing while it appears as proper on other browsers?

The root cause of all such errors and differences is the browser incompatibility.

WHAT IS BROWSER INCOMPATIBILITY & TOOLS FOR DETECTING BROWSER INCOMPATIBILITY

- There are various tools that can help you across detecting the browser incompatibility.

- Such tools check for the browser incompatibility by comparing the various snap shots of the web site operating under various web browsers.

- Different browsers and different browser versions all add up to the browser incompatibility.

- Browser incompatibility though cannot be eradicated fully; it can be at least reduced to a certain extent.

- Though the browser is only to be blamed for its incompatibility, the measures to reduce or avoid it can be taken from both sides.

- It can be done by improving either the standards of the browser or by taking care of the web site.

- If the web site in its design and code is good, incompatibility will be noticed less.

WHY INCOMPATIBILITY ARISES?

- It arises either because of the incompatibility of the web browser or because of the problems in the web site itself.

- So you need to focus on the design an implementation of your web site rather than bogging up yourself with the browser issues.

- Employing cutting edge HTML can also run you in to the incompatibility problems as the HTML standards usually are a way step ahead of what is supported by the web browsers.

- Till now, no such browser has been developed that will take in to consideration 100 percent HTML.

- No doubt there are certain browsers that are a bit close to this value than the others.

- Using latest versions and standards of the HTML is always not a good choice. So be wise when you choose the version of HTML for designing up your web site.

- Another fact to be kept in mind is that not all the web browsers are equally efficient in translating the HTML code in to formatted web sites.

- There are some browsers that may leave certain parts of the HTML code because they are not able to execute it and again you will have trouble with your browser compatibility.

- Also all the web browsers do not translate a web page in the same manner and don’t give the same results.

- Before you start building up your web site, check out the compatibility of the different browsers so that you will have an idea what all formats and standards they support and you can build your site according and simultaneously avoiding a bug deal of incompatibility.

- After you have finished developing your web site, have your pages validated. If you are getting errors in your web site try out the trail and error debugging method.

Though the World Wide Web consortium has specified the standards for using HTML, you can very well invent your own and design your web site accordingly. But this has a disadvantage that the browser may reject the parts that cannot be executed and the appearance and functioning of your web site will be affected.

The basic difference between the two versions of a browser lies in the support they provide for the HTML. But on top of all it would be better if you pay attention to the browser compatibility while designing your web site. This will prevent you from running in to future issues regarding the incompatibility of the browser.