A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Ensuring decimals and date formats are correct in language versions of software

When a software is designed by a company that is based in the United States, there is sometimes not enough care taken to ensure that region specific modifications are done before the software is released in Europe and other regions. These can in turn get the software in problem with both consumers and regulators in different regions. Sometimes this is done because not enough effort has gone into having onboard experts in those regions or languages, and sometimes this is done because there is effort required to make the change, and that amount of effort is not budgeted by the team during the release. In many cases, there is not enough thought put into these changes and the effort required. What are some of these changes across regions ?
– In the US and many other regions, the date is read in this format: mm/dd/yyyy, so the date of 29th June 2013 would be denoted as 06/29/2013
– In Britain, UK, and many other regions, the date format is dd/mm/yyyy, so the date would be denoted as 29/06/2013

Similarly, there are differences with regard to how the decimal vs. comma are used as separators. In the United States and many other regions, the comma is used as a separator. $ 1 million would be read as $ 1,000,000 while the same in many parts of Europe would be read as $ 1.000.000
These are fundamental properties of various values that are read differently in different regions of the world. In order to work properly, the software should ensure that depending on the language (or the country, depending on what the team decides), the software should display these in the correct way. In such a case, there are several steps to be taken:
– If the software is not handling these properly, the software needs to be modified to ensure this, and instructions to ensure that all future date and money fields should be there in the guidelines (if they refer to a common structure, then it is more easily done by making changes to the common area)
– The software and the different language versions need to be tested by language experts to see all the cases where such changes need to be made, and these need to be flagged for testing
– Even more critically, there needs to be cases for determining that if there is there is some data, and the same data is taken to a different language version of the software, it shows up appropriately. We had a software that dealt with portfolios of people, and it was critical that the software should work perfectly in all such cases (this was important for cases where the same organization was using the software in different regions, or even the case where you had a German speaking person who was able to use the English or German language versions, or whose family could be using the different language version). I got a feel for how our customers feel about such issues, when I read a complaint from one of our German customers, who felt that the company did not care about German customers as much as they felt about other customers.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>