bonesbro
Posts: 14
Joined: 2/25/2011 Status: offline
|
Ah. That's the classic "Turkish I" problem. The developers are almost certainly determining which invasion tactic is selected by comparing the string value in the dropdown to a list of specific strings. And the list of strings they are comparing against has a different case than the case that is used to display the string. Perhaps they have a switch(dropdown.value.ToLower()). And the default: for the case statement is to show the warning. So they are reading the string from the dropdown "Do Not Invade" and the code is comparing it against the the constant string "do not invade". It is a character problem. In English we have capital-I-without-dot and lowercase-i-with-dot. In the Turkish language there are both uppercase and lowercase versions of i-with-dot and i-without-dot. When you call string.ToLower() in .NET, the default is to perform a culture-sensitive operation. In a computer whose currentlocale is set to English, the I in "Invasion" changes from capital-i-without-dot to lowercase-i-with-dot, and the string comparison matches. On a computer that uses the Turkish language, the capital I in "Invasion" goes from capital-i-without-dot to lowercase-i-without-dot, and the string comparison does not match. The fix is to do one of three things: change your string comparisons from equality to StringComparison.OrdinalIgnoreCase(), pass in CultureInfo.InvariantCulture as an optional parameter to string operations, or use String.ToLowerInvariant() instead of String.ToLower(). There's also an FxCop globalization rule that catches this error. A similar bug is visible in dory's final screenshot of the planet names. I suspect that the planet names are stored lowercase, and there is a method that formats the strings for display purposes, and that method calls ToUpper() on the first character of the planet name. So the lowercase-i-with-dot becomes uppercase-i-with-dot in Turkish, which leads to the screenshot above. Another fix the developers will probably want to make is to set the DataSet.Locale property on all DataSets used in the codebase. Yall will probably want to set it to CultureInfo.InvariantCulture, which might avoid some other funny globalization issues, like the way that some languages sort characters in a different order. I don't remember offhand if that will cause problems in places where string operations should be culture-sensitive, like formatting dates or decimal numbers, though I also can't think of anywhere in DW that displays decimal numbers.
|