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

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

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 2

So the proper English for the 1st, 2nd, and 3rd items of a list isn't first, second, and third?

I can see what you mean, but its more of a supporting contractions "can't, won't, ain't" issue then a date time issue.

Answer 3

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 4

I think both MS and you made good points.

I tend to agree with MS. The issue is not making life harder for non-english software. The real problem would be that the new methods would not work on different languages, and that is not acceptable. One thing is not having a feature, another is having a feature that does not work on certain cases.

I suppose though that it would be possible to make language specific functions. Maybe something like localization.English.DateFormatter That would be a nice compromise, however it could lead to writing software more difficult to localize in the long term.

Answer 5

Microsoft is under no obligation to implement work for you. It will have to be one of those things you implement yourself on top of their framework.

Answer 6

Just to give you an idea of how hard this is.

1st January is only correct for British English. The correct form in US English is January 1st.

The Canadians probably compromise with 1er Janvier.

Answer 7

As Jalf said, it wouldn't take too long to rustle up something in English. You could then use this as an open source project (if it's not been done before). Developers who understand the formatting for other countries could contribute, so you wouldn't need to find out everything before you start.

Answer 8

"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.

Answer 9

The C function for formatting dates is strftime(). That takes a format string with '%x' notations to indicate the parts of the date to be formatted and how to format them. It would be feasible to add '%o' as a format item for the ordinal day number with digits (1st, 2nd, 3rd, ...), and an alternative (logically '%O' but I think that is already in user) for the spelled out version (first, second, ...). This could then be globalized just the same as any other part of the date formatting. The default result for '%o' could perfectly well be 'no suffix' if the locale has no information about how ordinal numbers are written; you might even use the number with no suffix for the 'spelled out'

The equivalent functionality exists in other language frameworks - it could be provided as easily in any of them.

(If someone wanted to ordinalize months - the first month of 2009 - then you'd need another symbol.)