Crazy Foreigners
-
Ok this is something that has never occurred to me until I've had to recently deal with localized software. I've seen how some localizations in Europe will use comma/period delimitation differently in numbers compared to US/Canada, ie. we would have 12,500.34, and some countries would list it as 12.500,34 This may work well with displaying and parsing these numbers on say a WinForm, but what about text input? For example, I imagine that if I had a decimal type and displayed it in a label, that the ToString() method (or equiv in your language of choice) would use the localization settings and display it properly, and the various parsing str->number methods would probably work too. But what about text validation? Like where I would want a textbox to only allow 5 numbers, and then an optional decimal point, and then up to 4 more numbers? What is a common solution is this case, when you don't know what their delimiters will be? Obviously the hardcoded regex patterns i'm using now will fail, so I'm just wondering what some of you have done in these cases? thanks for any advice
-
Ok this is something that has never occurred to me until I've had to recently deal with localized software. I've seen how some localizations in Europe will use comma/period delimitation differently in numbers compared to US/Canada, ie. we would have 12,500.34, and some countries would list it as 12.500,34 This may work well with displaying and parsing these numbers on say a WinForm, but what about text input? For example, I imagine that if I had a decimal type and displayed it in a label, that the ToString() method (or equiv in your language of choice) would use the localization settings and display it properly, and the various parsing str->number methods would probably work too. But what about text validation? Like where I would want a textbox to only allow 5 numbers, and then an optional decimal point, and then up to 4 more numbers? What is a common solution is this case, when you don't know what their delimiters will be? Obviously the hardcoded regex patterns i'm using now will fail, so I'm just wondering what some of you have done in these cases? thanks for any advice
If you seperate the display and the data properly this becomes no problem. The input is a number and it is formated using the native styles - but it should be stored as a number. If you need to serialize then serialose the bytes if you can - don't convert to string unless you are going to ensure an application wide number formatting. BTW. A common European number format is "1 234,56", but windows should take care of the correct format.
Panic, Chaos, Destruction. My work here is done.
-
Ok this is something that has never occurred to me until I've had to recently deal with localized software. I've seen how some localizations in Europe will use comma/period delimitation differently in numbers compared to US/Canada, ie. we would have 12,500.34, and some countries would list it as 12.500,34 This may work well with displaying and parsing these numbers on say a WinForm, but what about text input? For example, I imagine that if I had a decimal type and displayed it in a label, that the ToString() method (or equiv in your language of choice) would use the localization settings and display it properly, and the various parsing str->number methods would probably work too. But what about text validation? Like where I would want a textbox to only allow 5 numbers, and then an optional decimal point, and then up to 4 more numbers? What is a common solution is this case, when you don't know what their delimiters will be? Obviously the hardcoded regex patterns i'm using now will fail, so I'm just wondering what some of you have done in these cases? thanks for any advice
IIRC there's a way to test input against the Culture defined as being in use by the OS install, or to use it take input in the local culture and convert it to the invariant culture which, again IIRC is the same as the one for the US.
It is a truth universally acknowledged that a zombie in possession of brains must be in want of more brains. -- Pride and Prejudice and Zombies
-
Ok this is something that has never occurred to me until I've had to recently deal with localized software. I've seen how some localizations in Europe will use comma/period delimitation differently in numbers compared to US/Canada, ie. we would have 12,500.34, and some countries would list it as 12.500,34 This may work well with displaying and parsing these numbers on say a WinForm, but what about text input? For example, I imagine that if I had a decimal type and displayed it in a label, that the ToString() method (or equiv in your language of choice) would use the localization settings and display it properly, and the various parsing str->number methods would probably work too. But what about text validation? Like where I would want a textbox to only allow 5 numbers, and then an optional decimal point, and then up to 4 more numbers? What is a common solution is this case, when you don't know what their delimiters will be? Obviously the hardcoded regex patterns i'm using now will fail, so I'm just wondering what some of you have done in these cases? thanks for any advice
DiscoJimmy wrote:
But what about text validation? Like where I would want a textbox to only allow 5 numbers, and then an optional decimal point, and then up to 4 more numbers? What is a common solution is this case, when you don't know what their delimiters will be?
Sourcecode (like most technical things) follows the rules from the US_English culture, regardless of your current locale. For example;
Console.WriteLine(1.0F); // = 1,0 as a number
but
Console.WriteLine(1, 0F); // doesn't compile :)SQL Server gives you (as a developer) the choice in what locale you're delivering your values, and this may differ from the locale on the operating system. Generally, anything that the end-user is likely to see is translated into the current culture. All other things remain in US_English. I can't imagine the problems one can expect when going to cultures where the sentences are written from right-to-left.
I are troll :)
-
DiscoJimmy wrote:
But what about text validation? Like where I would want a textbox to only allow 5 numbers, and then an optional decimal point, and then up to 4 more numbers? What is a common solution is this case, when you don't know what their delimiters will be?
Sourcecode (like most technical things) follows the rules from the US_English culture, regardless of your current locale. For example;
Console.WriteLine(1.0F); // = 1,0 as a number
but
Console.WriteLine(1, 0F); // doesn't compile :)SQL Server gives you (as a developer) the choice in what locale you're delivering your values, and this may differ from the locale on the operating system. Generally, anything that the end-user is likely to see is translated into the current culture. All other things remain in US_English. I can't imagine the problems one can expect when going to cultures where the sentences are written from right-to-left.
I are troll :)
The output isn't what concerns me at the moment. It seems like ToString() and decimal.Parse or float.Parse will take my localization settings into account and display the number properly. I'm more concerned with situations where I need to validate text at the point of entry. i could take the value of the textbox and do a decimal.TryParse on it, and then if I got a number back I could limit it to a certain maximum (left side of the decimal) and round it to a certain precision (right side), but i'm currently validating this text at entry. This means with each keystroke the textchanged event is firing and i'm hitting the text with a regex that makes sure the user doesn't try to enter letters, or more than one decimal point, etc. It's these types of tactics that seem to defy a general localization strategy.
-
The output isn't what concerns me at the moment. It seems like ToString() and decimal.Parse or float.Parse will take my localization settings into account and display the number properly. I'm more concerned with situations where I need to validate text at the point of entry. i could take the value of the textbox and do a decimal.TryParse on it, and then if I got a number back I could limit it to a certain maximum (left side of the decimal) and round it to a certain precision (right side), but i'm currently validating this text at entry. This means with each keystroke the textchanged event is firing and i'm hitting the text with a regex that makes sure the user doesn't try to enter letters, or more than one decimal point, etc. It's these types of tactics that seem to defy a general localization strategy.
DiscoJimmy wrote:
This means with each keystroke the textchanged event is firing and i'm hitting the text with a regex that makes sure the user doesn't try to enter letters, or more than one decimal point, etc. It's these types of tactics that seem to defy a general localization strategy.
Aw, I stopped with validating every letter, have moved to validating whenever the focus leaves the control (and end-edit operation, in effect). Seems to do the trick, and it's not like you loose a lot of critical functionality :)
I are troll :)
-
The output isn't what concerns me at the moment. It seems like ToString() and decimal.Parse or float.Parse will take my localization settings into account and display the number properly. I'm more concerned with situations where I need to validate text at the point of entry. i could take the value of the textbox and do a decimal.TryParse on it, and then if I got a number back I could limit it to a certain maximum (left side of the decimal) and round it to a certain precision (right side), but i'm currently validating this text at entry. This means with each keystroke the textchanged event is firing and i'm hitting the text with a regex that makes sure the user doesn't try to enter letters, or more than one decimal point, etc. It's these types of tactics that seem to defy a general localization strategy.
Ultimately, you could just hit TryParse from the textchanged rather than using a regex. Use the return from the regex to decide whether or not the text is valid.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
-
Ok this is something that has never occurred to me until I've had to recently deal with localized software. I've seen how some localizations in Europe will use comma/period delimitation differently in numbers compared to US/Canada, ie. we would have 12,500.34, and some countries would list it as 12.500,34 This may work well with displaying and parsing these numbers on say a WinForm, but what about text input? For example, I imagine that if I had a decimal type and displayed it in a label, that the ToString() method (or equiv in your language of choice) would use the localization settings and display it properly, and the various parsing str->number methods would probably work too. But what about text validation? Like where I would want a textbox to only allow 5 numbers, and then an optional decimal point, and then up to 4 more numbers? What is a common solution is this case, when you don't know what their delimiters will be? Obviously the hardcoded regex patterns i'm using now will fail, so I'm just wondering what some of you have done in these cases? thanks for any advice
-
devvvy wrote:
12.500,34? where?
Well, Luxembourg, France, ... take your pick. They use the comma as the decimal separator.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
-
devvvy wrote:
12.500,34? where?
Well, Luxembourg, France, ... take your pick. They use the comma as the decimal separator.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
-
AFAIK: 1. the entire European continent, exception being made for some islands that have insisted and to a decreasing extent still insist on doing a lot of things differently (remember "Splendid Isolation") 2. the other continents, as they mostly were at some point in time colonies of (1) to begin with (same exceptions apply) So who is the crazy foreigner? :)
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.