Should Microsoft avoid implementing a feature in .Net just because internationalising it is too difficult? [closed]

Question

I raised a request over at Microsoft Connect regarding the formatting of dates ("DateTime Formatting should caluclate the correct suffix for the day"). Basically I wanted to have a formatting string code for adding the suffix to the day number. So "1 Jan" would be formatted "1st Jan" and "2 Jan" formatted "2nd Jan" etc.

This is quite easy to do for the English case however Microsoft have rejected the idea on the grounds that it would be too hard to internationalise.

I was just wondering if people agree that it is reasonable for Microsoft to make life harder for English programmers writing solely for an English market, just because they can’t cater for the Non-English market?

Edit: Ok, I accept the argument that it is there framework to do what they want with. I was asking more out of an ideological sense. Also remember that there is an easy fallback for Non-English cultures which is to add nothing, which makes people no worse off than they are now.

Edit 2: For me this is more than an hours work. I need to support code that looks something like this:

        DateTime minDate = new DateTime(2003, 12, 10);
        string errorMessage = ValidationMessageResource.DateTooEarly;            
        Console.WriteLine(String.Format(errorMessage, minDate));

I have no control over the resource file's contents and the resource string is often something like this "The date should not be before {0:D}". To do this I would need to implement my own IFormatProvider class which would have to support all the different formatting strings Microsoft's formatter accepts. Microsoft doesn’t seem to have given an easy way to extend their formatter through inheritance.

Answer 1

1: It's their framework, anything they choose to do is by definition reasonable. They're not under any obligation to provide anything they don't feel like.

2: Features that can't be internationalized are basically useless. If they added it for english only, all they'd achieve is that the rest of the world would demand that it got internationalized, and suddenly, they'd look bad for giving the rest of the world inferior treatment.

3: It is hard to internationalize. You can't assume that every language simply adds a suffix. It might be a prefix, or it might change completely different parts of the sentence. (Or, as another poster pointed out, it may be "first" rather than 1st, so even in English, there are no hard and fast rules. Why should they implement your arbitrary rule, but not other, equally valid ones for English?)

3b: While you obviously don't care about that, Microsoft is marketing .NET as an internationalization-aware framework. Which means they can't just ignore 90% of the world to suit your needs.

4: It'd take you what, an hour to code the english-only version for yourself, wouldn't it? ;)

5: It has nothing to do with DateTime. It is a general property of string formatting of numbers in general.

6: Your assumption that "if they added the feature for english, no one else would be worse off than they are now" is incorrect. Developers generally rely on .NET to behave correctly. If your formatting suggestion was added, developers would naturally expect it to work for all languages and locales, and so, would generate invalid or unexpected output for all non-english languages when the developer expects no problem exists.

Answer 2

Completely agree that it's reasonable. There's nothing to prevent you from implementing the formatting you want yourself in your own reusable library.

Answer 3

"I was just wondering if people agree that it is reasonable for Microsoft to make life harder for English programmers writing solely for an English market, just because they can’t cater for the Non-English market?"

I think you're being a wee bit extreme and in my opinion it's really an edge case. This kind of date formatting is like asking microsoft for a post/zip code formatter or an Address class. Sure there's a convention for most countries for formatting postcodes and addresses but it doesn't mean MS have to implement it. You have the framework at your fingertips to build these types of data structures.