(my apologies in advance to the J. Geils Band)
Pierre Igot writes what I must politely describe as an impassioned discourse about my description of pseudo-localization, multi-lingual bundles in OS X, and MacBU testing. Pierre makes some good points, totally misses the idea of pseudo-loc in another, and generally castigates the MacBU for failing to fix a particular bug that is very important in French typography. He then invited me to comment.
Let me begin by saying what I am not. I am not the lead developer for Word, and I am not intimately familier with every bug that is entered against our products. I am also not a native French speaker, nor am I familiar with the rules of French typography. (In fact, my peers in high school often told me “Tu parles français comme une vache espagnole,” which, if my hazy memories of 1991 are correct, means “You speak French like a Spanish cow.”)
I do, however, know quite a lot about bundles in Carbon and Cocoa, how multi-lingual bundled apps should behave, and the benefits to users of software that takes advantage of them. Apple did indeed make them available to developers using Carbon in 2001 or so. Pierre is correct in saying that currently shipping Mac Office apps do not use them. (Well, Messenger does use them, and may have been the first major Microsoft app to do so.) I became a lead for Mac Office in June of 2002, well into the Office 2004 project and was not a part of the initial schedule planning that, for whatever reason, did not include moving Office to a bundled architecture. As the lead for localization, I understand and sympathize with users for whom this creates frustration. The reality is that for every user calling for a multi-lingual version of Office, there are at least two users who don’t care about that at all and want us to be working on something else. We can’t please everybody, unfortunately. As I said in the comments at the end of my localization post, I cannot comment on our plans for this aspect of the next version of Office, but please rest assured that I do understand and hear your request, Pierre.
Because I am not well-versed in French typography (or any real typography for that matter) I can only trust that Pierre’s assessment of the importance of the non-breaking space in French documents is indeed high. Assuming that is the case, then yes, this must be a very aggravating bug for anyone who uses Word 2004 to lay out text in French. I’m quite sorry, Pierre, that you have been so frustrated by this issue. I wish we had caught the bug and fixed it before shipping. Sadly, we did not.
Pierre then takes our non-use of bundles and conflates that with the existence of the non-breaking-space bug:
The fact that the language of the user interface in Office applications does not change depending on the user’s preferred language in Mac OS X is annoying enough. But that’s not the worst of it. The worst of it is that Microsoft’s process for fixing bugs is completely screwed. And there is no better example of this than the bug with non-breaking spaces and PostScript fonts in Word 2004.
He also implies that our use of pseudo-localization should have caught this ‘elementary’ bug:
The fact that Microsoft did not catch that bug in Word 2004 before they released the product is a clear illustration of how flawed their testing processes are. Whatever benefits this “œpseudo-localization” technique described by Erik Schwiebert provides, it is clearly not good enough to catch even such elementary bugs.
Here I must correct Pierre’s faulty assumption and say that the bug is not in any way connected to either of the other two items. Multi-lingual bundles are all about providing resources to the app, such as strings, dialogs, menus, windows, etc. Pseudo-localization is a method we use to test the localization of those resources and the code that uses them. It is intended to help find visual glitches, missed translations, improperly displayed dialogs, and similar items, and it does a pretty good job at optimizing our efforts for those issues. It is not designed nor intended to help with finding or fixing bugs related to the actual behavior of the application. Pseudo-localization in no way replaces good old-fashioned usage of the applications to uncover code defects.
In fact, the bug that Pierre is so frustrated with occurs in all languages that Word ships in — the faulty code is in no way connected to any localization. I can repro it in the English build. That doesn’t mean that our entire testing process is flawed, however. Every large software endeavor results in a product that has bugs. Microsoft is no better or worse than anyone else in this regard. Seen any OS X software updates lately? 🙂
Now, the fact that the bug is unrelated to our localized UI testing doesn’t address the issue that the bug is there, and is bad. Pierre blogged about the bug way back in September 2004. Unfortunately, the MacBU (and the rest of Microsoft, to my knowledge) has never had a good method for customers to report bugs to us. We’ve had the (now defunct) MSWish email address, and we do have the new direct feedback link on Mactopia, but we don’t have anything like Apple’s BugReporter tool. Interestingly enough Nathan Herring, another MacBU employee, just blogged about this specific issue and has some links you may want to read.
But let me continue with Pierre’s post. He finds it unjustifiable that we have not fixed this bug in the almost two years that have gone by:
Now what excuses does Erik Schwiebert have for this sorry state of affairs? I might find it acceptable (barely) that Microsoft is not able to catch such bugs in the hectic schedule that leads to the release of the initial versions of the product. But how can they justify not fixing the bugs in the next two years, even though the bugs are so obvious?
says it can be done on schedule:
it is perfectly possible to release multilingual software on schedule that automatically supports all of Mac OS X’s supported language without requiring the user to buy separate versions for each language and download separate updates for each language.
and casts shame on us:
And for all this, once more, all I can say is: Shame on Microsoft, and shame on the MacBU. They have absolutely no excuses here.
Ouch. That hurts. Me personally, as well as all of our hard-working employees. It’s a good thing I have a relatively thick skin.
I don’t think there is anything I can say that will appease Pierre. And I don’t mean that there’s something I know that I’m not allowed to post; I just don’t think that any insight I provide into MacBU’s bug process will soothe his wrath. However, I will try to shed some light on our processes because I think folks are interested in them anyway. I’m sure many people will individually disagree with many of of the decisions we make and the factors we weigh, but that’s part of the openness of blogging. Feel free to respond with your thoughts and comments — you may provide some insight that we’ve missed in all these years.
First of all, we do work darn hard to fix bugs in our products. Really darn hard. But, we’re not perfect. No developer team is. Not MacBU, not Microsoft, not Adobe, not Apple. Security defects? We’ve all got them. Software updates? Yep, them too. For OS X, we have 10.0.4, 10.1.5, 10.2.8, 10.3.9, 10.4.6 and counting. For Office we have 11.1.1, 11.2.4, etc. Updates are good, it means that we’re all working to make our products better, to fix the bugs and reduce the crashes.
However, not all bugs are fixed in dot-releases of products. Some bugs that we find are really obscure and don’t cause any real harm. For example, perhaps the File/Open menu item is grayed out when you hold down Cmd-Shift-Ctrl-Option and triple-click on the menu-bar. Not too many people will see that, and if they do, no real harm done. We can spend our engineering time and resources better elsewhere.
Some bugs are easier to hit, but fixing them may have a high risk of regression and may cause another bug that is even worse. One example might be a performance bug in Excel’s recalc engine. We could fix it and make things faster, but currently the code calculates correctly (albeit slowly) and any fix might totally break all function dependency analysis. It is sad but safer to leave things alone.
Other bugs are deemed worth fixing for a future release, but not worth back-porting to the current release. Every code change we make has to be tested around to make sure no regressions are caused, and that takes away from other work we could be doing. It may be more effective for us to take a bug that was reported against Office X and just fix it in Office 2004. And occasionally, some bugs are misclassified or accidentally forgotten. After all, we’re only human.
Here’s an example of an engineering decision. If you boot Mac RDC on a PowerBook and connect to a Windows server, try turning on Num Lock (the keyboard light should be on). Type something on the number pad in Excel. You get numbers, right? Good. Now, Cmd-tab back to the Finder and turn off num-lock. Cmd-Tab back to RDC. Type something on the number pad again. What, you still get numbers? Yes indeed you do. Geez, the MacBU really should have fixed that bug, right? We’d love to have fixed it, except that the bug is actually in the OS. The Carbon Event manager does not give you accurate information about the Num Lock state when you query for modifier key state after app activation and deactivation. I filed that bug with Apple in May 2002 against OS X 10.1.4, and they still haven’t fixed it. I wish they had, but I’m sure there is some reason (hardware? software complexity? who knows…) that the change is more expensive for them to make than to allow the bug to continue to exist. That decision is completely up to them, and I respect that.
In our move to Xcode, we’ve reported over 100 bugs to Apple. They’ve fixed the majority of them, and have postponed several to some later release. Some of the bugs they’ve postponed have been real bummers, but they’ve made the engineering justification to delay the fix and again, I respect that. After all, we have to do the same thing with regard to Office bugs too.
Second, the ability to meet a schedule or not has nothing to do with the ability to ship a bundled multi-lingual product. That is essentially a feature, and does not come for free with Carbon apps. (Yes, that is one aspect where Cocoa wins hands-down — it is impossible to create a monolithic Cocoa app. At the very least your app must be bundled, whether or not it has more than one locale for resources.) Perhaps Pierre would have preferred we have chosen a different schedule, moved Office to Mach and multi-lingual bundles, and shipped a product called Office 2005. We hit our internal schedule for Office 2004 with the features we planned for it.
Now, I’m not saying that any of this is an excuse. We’ve made lots of conscious decisions over the years about many many issues. Some of them, everybody likes. Some of them, everybody hates. Most of them are liked and hated simultaneously, and the overlap between the sets of people experiencing the two emotions is rarely the same from topic to topic.
The sad thing about this particular bug is that it falls into the category of ‘oops.’ The code was wrong in a very small way (an exception was made for the breaking-space character and accidentally forgotten for the non-breaking space character.) We actually found this bug in-house just a little while after Office 2004 shipped, and fixed it internally for the next major release of Office in August 2004. We even noted that it was important in the French market. Somehow, though, it was never flagged as a bug that should be migrated back to Office 2004. The tester for that area of Word (who found and opened the bug) left MacBU to go back to graduate school during that summer, and I think we probably just missed this one in the transition. A simple human mistake. Shameful? I personally don’t think so. Unfortunate and frustrating, I’ll certainly agree to that, but not shameful.
I’ve asked our Word team to take another look at this bug. I make no promises, but maybe we can get it fixed sooner than in the next major release of Mac Office. After all, the Windows team did that for a blogger recently.
So Pierre, we are listening. I think pseudo-localization has a greater value than you place on it, but for a different purpose. If you are ever in the Seattle area, please look us up. I’d be happy to take you out for coffee and a chat, and see if we can address some of your dissatisfaction with us. In the meantime, I’ll stand up proud and accept no shame, for I believe we work hard and produce a good product.