X hits on this document

137 views

0 shares

0 downloads

0 comments

53 / 67

CUSTOM CULTURES

However, you need to find the right balance: You must use values that are suffi- ciently different from English, to be clear that the application is not using the default culture, yet you must use values that are sufficiently understandable, to make the application still usable. Consider the following two currency strings, which were converted to a string using 123456789.123456.ToString(“C”):

$123,456,789.12 1’2’3’4’5’6’7’8’9@1235 ~

The first uses the “en-US” culture, and the second uses the “pd-PD” culture. The second clearly shows that the application is globalized, but is it still recognizable as currency? The decimal separator is “@” instead of “.”; the group separator is “instead of “,”; the group size is 1 instead of 3; the number of decimals is 4 instead of 2; the currency symbol is “~” instead of “$”; and the currency symbol is placed to the right instead of to the left. In terms of testing globalization, this scores a 10, but is the application still usable?

I have also taken the attitude that the day and month names used in the Date- TimeFormatInfo should not be pseudo-ized. For example:

dateTimeFormatInfo.DayNames

“*Sunday*” “*Thursday*” ,

,

“*Monday*” “*Friday*” ,

,

= new string[] { “*Tuesday*”, “*Wednesday*” “*Saturday*” };

,

(The names are delimited with asterisks, however.) You might have expected the names to have been “pseudo-ized,” like this:

dateTimeFormatInfo.DayNames = new string[]

{

,

,

,

,

,

” };

,

The reason behind this is that I want to be able to see clearly that day and month names are taken from the appropriate DateTimeFormatInfo object instead of from

a resource assembly. In other words, if the user is presented with

, you

can be sure that the application has been localized, but you don’t know how it has

29

Document info
Document views137
Page views137
Page last viewedFri Dec 02 20:20:51 UTC 2016
Pages67
Paragraphs859
Words13458

Comments