As one of the Internationalization representatives, it is my responsibility to make sure that our automation framework code uses ToUpper() & ToLower() correctly. In almost all cases this does not matter and therefore people don’t bother to remember this at all, but if you call the To…() methods with no arguments, you get the conversion based on your system locale, and in one case, your code will break.
This block of code
case “integer” : ;
will fail if user enters “INTEGER” on Turkish locale because there I gets converted to ı, not i.
The correct code here is to use myType.ToLower(System.Globalization.CultureInfo.InvariantCulture)
This will correctly match I & i irrespective of the operating system locale.
English has two i’s => I & i
Turkish has four => İ & I, plus ı & i.
With non-turkish locale, I & i are our familiar ones, while İ & ı are unicode characters that are not recognized as characters to covert to.
As a result, I & İ both will lowercase to i, while i & ı both will uppercase to I.
On a turkish locale, the relationship changes.
i & İ are one upper-lowercase pair, I & ı are the other. (dotted i’s together, non-dotted together!)
Only with InvariantLocale can you make sure that you accidentally do not match the two sets of I’s as I & i lowercase & uppercase to each other, while İ & ı stay unchanged. Therefore you will never end up with “III” == “İİİ” or “iii” == “ı ı ı ” as a result of case conversions.
Right now I am looking at 138 cases of potentially bad ToLower() calls I need to code review & fix!