International support as a developer 'tax' ?

by Michael S. Kaplan, published on 2005/08/22 12:30 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/08/22/454561.aspx

International support? To me it is not clear what you mean, if you meant making Unicode programs, I assume you would have said "multilingual support". You have a link for what all the other "taxes" are, what about one for International Support?

Hi Ben -- not sure fully what I mean, I was just realizing that it often the case that people look at what I do in the way of presentations, and they think it is totally fascinating but also not applicable to their immediate work.

So I wondered if in those situations support for internationalization (which is not just multilingual but also proper locale/collation support, etc.) would be considered a "tax".

After all if you only ever ship to one small place that speaks one language, it is hard to claim that use of GetDateFormat is really indicated, right?

I think it does qualify as a tax.

I would also say that such taxes might be best resolved as Windows Logo issues. For example, if you don't pay your internationalization tax, maybe you can't get a "Designed for Windows Vista" logo. Power Management would be an obvious necessity for a "Designed for Windows Mobile" logo. This would encourage companies to provide these features to commercial products.

It also might be nice to have warning message options in Visual Studio like "Warn about internationalization issues" or "Warn about power management issues". These could help developers remember to pay taxes.

I would tend to think that i18n support is one of those 'taxes' that should be paid by the developers.

I mean, your software may currently be targeted to ship to one small place that speaks one language for now, but what if that the software is a huge success and suddenly you have some other potential customers from some other part of the world? Putting proper i18n support as a requirement from the beginning would mean potentially less work would be needed later to get it working in another locale.

Even if the developer 100% certain that the software you are currently working on will only ever go to that "one small place that speaks one language", I would still think that she should make the effort to make sure it has i18n support. If she ensures proper i18n support is present in all of the software that she works on, she is developing a good habit which will (hopefully) carry on into other software she works on later that will ship to different locales.

I think Internationalisation is easy to think of as not a tax, but in doing so it just highlights more issues with regard to the taxes.
Internationalisation may appear to not be a tax because it is optional - you can simply say that your product doesn't support it and sit back.
But the same is true of all the other taxes, and the impact of doing so is that same for all of them - the user experience is worsened if they do not work in the same environment as the system was tested in.

In your example, if you only ever ship to one small customer that doesn't use roaming profiles it's hard to claim that testing for their correct behvaiour is justified.
But then some guy in a suit wants to expand their market, without investing in removing limitations, and customers suffer.

Developers develop features correctly once they've been impacted by them being incorrect.
Maybe we should all develop in Kanji.

(1) Management does not care about these "taxes" (features), and (2) some developers want to care about these taxes but don't know how.

I'm running into the "VB 6.0 does not really support Unicode" buzzsaw myself lately. I developed an application in VB 6.0, and now my boss wants to sell a version to Japanese and Korean customers. It's infuriating that VB 6.0 as a language claimed to support Unicode but that all of its UI controls -- the parts that actually make it "Visual" Basic -- do not.

It's things like this that make me understand why former Windows users really hate Microsoft. For the record, I don't blame you; in fact, I am appreciative of your work (the book you wrote about this subject). I would however like to find the person who thought it would be a good idea to sell VB 6.0 as a language that supports Unicode and do unfriendly sorts of things to that person.

It most absolutely is. Unless your program has precisely 0 text in it (ha, ha), international support must happen, or 2/3 of the people in the world can't use it.

But then, the readers of this blog are probably biased. :)

Vorn

shaunbed> End users don't give a hoot about logos. No company I've worked at has cared about a MS logo for more than 1 revision (they did the work at first to get the logo, then realized it had no effect at all on sales).
Telling a company "do XYZ or you won't get this new logo" will be met with "well bugger your logo then, we have better things to do."

The cool thing with internationalization support is that a lot of the verification can be automatic, using FxCop. I'm mostly thinking of stuff like "don't hard-code strings", "make sure you call the overload of String.Compare that takes a StringComparison parameter (or CultureInfo parameter)", etc.

But a lot of those other "taxes" can't be verified like that. FxCop can't tell if you're doing something that isn't multi-monitor friendly or that you're going to chew through the battery like nobody's business.

So the difference (as I see it) is that it's fairly easy to get things "mostly" right in terms of internationalization but it's harder, without specifically planning for it, to get those other "taxes" right. Mind you, just because it's "easy" doesn't mean most people end up doing it anyway!

Of course, until you actually go to localize your app you don't *really* know if you're doing everything right, but at least you can make sure you're most of the way there by following a couple of simple(ish) rules...

Maybe some automatic checks can be performed but on the other hand, you can't be really sure that you have proper i18n until you made at least one localization (and probably more than one), which is not part of the tax.

Anyway, I totally agree with i18n as a tax. As an additional question, I'd ask how these tasks are prioritized and where i18n should be in the list. Probably fairly close to the top. But of course, YMMV.

Of course internationalization is a tax, exactly like multi-monitor or LUA support. If you don't have good multi-mon support, you annoy multi-mon users and risk losing their business. Te same way, if you dont support (say) right-to-left scripts, you annoy RTL language users (Arabic, Hebrew, etc) and risk losing their business.

I'm not sure if it should qualify as a 'tax'. I think a tax is something that benefits the system as a whole, but are not visibly linked to the program.
I thought Raymond's power consumption example was a good one. The end user will not blame your app for eating up the battery- that seems to be a system problem or a battery problem. If you improve your app, you are doing it for the benefit of 'society'.
However, some things are just features. If your app is properly internationalized, that is a feature- more users can use it. If you fix it, you are helping yourself (and your users), not the system.

Hi Ari -- The thing is, if you do not properly internationalize, people tend to blame the platform. Thus even though the collation support in Jet and SQL Server has a smaller list that Windows, they assume that our claim of supporting new ELK locales on XP SP2 is false because they are not supported in the application.

So, since the OS often gets blamed, it looks like an OS problem (which it is not!).

I agree about the logo program.. I don't think it really accomplishes its purpose. Maybe it should be more like the trusted code process.

When a company gets logo, MS could issue a signature. On installation, a box could appear saying "This program is not certified to work with Windows X. Do you wish to install it anyway?"

The logo program is meant to allow MS to have some control over the quality of programs targetting their OS like licensing in the console market.