DST is a nightmare

In my non-professional life, I'm a fan of Daylight Saving Time: I love longer evenings 7 month a year and frankly, I don't care when it's dark until 6:30AM instead of 5:30AM because I'm rarely up before 7:00AM anyway!

But as a software engineer, I've hated DST during most of my career. Before starting up appTrans Software, I was involved in industrial data logging and telemetry. You know: Recording pressures, flows, uptimes, downtimes, whatever, all day long (and other things such as automation, alarming and so on). A pretty simple job. If it weren't about DST.

The problem is that data logging devices record timestamps based on their internal clock, which knows nothing about DST. Why? Because the device doesn't know in which country it's sitting hence which rules it should apply.
Even if it knew, it wouldn't be happy anyway because it doesn't want to know how to store a yearly one-hour time hole in its table which is a simple array of numbers corresponding to 15-minutes recording intervals. Let's not even speak about the other yearly hour where the clocks rewinds to replay the last hour. Oh! and don't expect users to set the time after each transition: If they do it in the morning when showing up on duty, it's too late: There's already a few hours of mis-timestamped data. And I won't speak about the companies who have a policy for never setting DST in these devices for simplicity until someone notices a device is not on time and fixes it, using DST...

So it's up to the data analysis software running on a PC to figure out. And that's why I used to hate it: My team was in charge of writing such software!

UTC: The Ultimate Timestamp

Yeah, I know, there's Universal Time Coordinated: Time at Greenwich (the one in UK, not the one in NYC!), ignoring DST.
BTW, should be UCT, no? You won't believe it yet it's true: It's an IEC invention. IEC has two official languages: French and English. The committee couldn't decide between English UCT and French TUC. Hence the subtle(!) compromise: UTC. A bit like Mom who's fed up about you and your brother fighting for a toy: It will be for none of you!

That's true, UTC is a blessing. If the device knows it and nobody will change it (such as user reading incorrect time on the front panel). Or the device must display human-readable (a.k.a. local time, including possible DST) to passing-by human readers.
It's a blessing simply because we can now assume that the logged data uses a well-known time scale, based on an absolute reference. In C parlance, it's the amount of seconds between now and the moment where the Greenwhich people's watches said Jan 1st 1970, 12:00AM.

The idea is that DBs should contain UTC timestamps. All timestamped data providers must store UTC timestamps to the DB. All timestamped data consumers must convert UTC data from the DB back to their users' local time.
Sounds easy, doesn't it? Well, it should. If DST weren't in to make the convert UTC data from the DB back to their users' local time part a nightmare.

DST is a nightmare

First, you can't use that nice off-the-shelf charting package because it was designed to display calendar data. Hence its programmers didn't even figure they should display the time axis with a double 2:00AM - 3:00AM section some time in Spring (if you're in the Northern hemisphere) and without the said section some time in Autumn. So you have to re-implement the whole charting module yourself.
Also, converting historical data is everything but pleasant: The CRT functions will at best rely on the OS to perform the conversion. And Windows makes a bad job at converting historical timestamps: FileTimeToLocalFileTime() is wrong 50% of the time. It uses the current value of DST rather than computing the value for the given timestamp. (I don't agree with the rationale behind this behaviour).
So if you are really really serious about it, you craft your own function that converts UTC to local time, based on the GetTimeZoneInformation() info.
Until someone at the US Congress ruins your day (more than a single day actually) by changing the rule...

The very reason why MS waited until November 2006 to ship Vista :-)

I just learned from Scott Hanselman that the US will change DST switch dates as of next spring. Which introduces one more frustration: Windows does a very good job at keeping an accurate list of time zones and their switch dates rules. But it doesn't push the desire for precision up to keeping an history of rules changes. Which means that in late March 2007 (DST), when you'll want to give a look at the data from one year before (Late March 2006 - ), you'll wonder why the graphs are shifted by one hour :-(

A bad time for the guys at my previous company as well: Their devices are parameterized with the switch dates in the current time zone for the next 30 years. So they can both make UTC data logging AND use local times for the tasks that require it (Of course it's smart: It was my proposal :-)). Now, all US users will have to dial-in all their devices (they are usually used in the wild) and send new DST settings.
With Vista shipping after the 1st Sunday of Nov 2006 (DST switch date as of 2007), MS could simply make the change in the RTM version. Had it shipped before that date, they would have to keep the current DST switch date for now and post an update next year.

Oh my! I'm sooo glad I don't have to deal with these issues anymore...

Pseudo-Localization

You are about to make your program translated. But are you sure it will work well after translation? For example, does your program support accented characters as found in French or German? Can it display Japanese ideograms? Want to have an idea of the look in Russian (Cyrillic)? What will your German dialogs look like (most German texts are significantly wider than their English source) ?

Pseudo-Localization helps you answer these questions without having to wait for translators to complete their job: it builds a translated executable where untranslated texts are modified to use characteristics of the target language. For instance, pseudo-localization to French will randomly add accents on top of vowels, such as found in French. Pseudo-localization to Russian turns your Latin script-based texts to Cyrillic,...

e.g.: Hello world might become Héèllò wörlld in French pseudo-localization. The text remain fairly readable but it shows the reaction of your program to unusual characters.


appTranslator pseudo-localized itself to French (Enlarge)

And if your application is Unicode-based, appTranslator will randomly turn convert texts to other scripts such (Greek, Cyrillic and Japanese) to help you check that your app can simultaneously display texts in different scripts.


Unicode-aware pseudo-localization uses multiple scripts

Want to give it a try? Easy: Just download the beta demo version.
For more info, look up Pseudo-Localization in appTranslator's Help Index.

Important Notes

1. In this DEMO beta version, only the menus are pseudo-localized. (You are a registered appTranslator user and you'd like a non-limited beta version? please contact me.)

2. In order to prevent breaking the project file in this beta version, pseudo-localization settings are saved in a separate file: project.apt.ini.

3. Hint for your Document/View-based MFC apps: In the String Table, make sure you set your document template string(s) (usually string #128) as 'do not translate' (or you translate it manually): pseudo-localizing it is not a good idea since it contains not so localizable info such as your file extension and file type registry info.

4. If you take pseudo-localization very seriously, you'll want to test pseudo-localized input as well.

XPath Examples

I find XPath is great when it comes to programmatically look up data in an XML file. But since such queries are not part of my everyday job, I'm no expert and I love to have a list of examples to help me do the job.

If you're like me, you may find this XPath Examples page useful.

IntelliCAD chooses appTranslator

I'm just back from the ITC World Meeting in beautiful Kelowna (BC, Canada).

IntelliCAD, an AutoCAD alternative

The ITC is a company founded by former Visio employees to develop IntelliCAD, an alternative to AutoCAD. From what I could see, it's a huge piece of work and the IntelliCAD developers are doing an amazing job. I was very impressed by the effectiveness of their development process: They have few developers but all of them seem excellent, which is much rarer than one could think. These guys are spread all around the planet (yes, the company doesn't have offices!). Their development roadmap is very accurate with part of the team working on the next (not so) minor release and another part working on the next major release. And their QA dpmt... Wow! It's not just testers, it's professional QA. When was last time you saw professional QA in a small company! I'm not just speaking of testers playing with the product. Or developers executing predefined test cases and filling checkboxes on a result sheet. Boy, even customers can submit automated test scripts as part of their bug reports. As Development Director Dave Lorenzo says: It's the best way to get us fix bugs since we'll face them at least 5 times a day in result sheets!

ITC chooses appTranslator

I was invited to this World Meeting by MicroSurvey's CEO Darcy Detlor. Darcy happens to be the secretary & treasurer of the ITC. His company uses appTranslator to localize some of their products.
I presented appTranslator to the consortium members (they are basically the IntelliCAD distributors). These guys need to translate IntelliCAD (and their own add-ons and customizations of the product) to their own language in order to sell it on their domestic markets. The presentation was a big success. Both members and IntelliCAD developers were very impressed and showed great interest into the product.

The IntelliCAD lead developers told me they want to list appTranslator in their Recommended Tools and Procedures list. And it's not just a matter of demo: IntelliCAD member and appTranslator user Cedric Desbordes showed them their product in French and praised the ease of use (Showing someone their program in a language they don't understand is always the best way to impress people ;-).

This means that not only the members of the ITC will receive a pointer as to where to start translating IntelliCAD intheir own language, but also a community of users is created, thereby accelerating the appTranslator adoption momentum.

This is of course all good news for both IntelliCAD and appTranslator.

Globalization vs Localization

The ITC is the perfect type of organization to setup an i18n/l10n process:

• The IntelliCAD developers do the globalization job, in order to make sure their product can be easily localized.
• The members/distributors do the localization job, each in their own language.

In order to improve ITC's globalization effort, I'll add pseudo-localization capabilities to appTranslator. This will help them make pre-localization test and possibly solve problems before their distributors hit them. More about that soon.

Conclusion

I confess I somewhat hesitated when Darcy invited me: It's a 16-hours/8000 km trip to Kelowna, just to visit a few tenths of people. When the money comes out of your own pocket, you think twice about it. But there's no doubt the net result will be very positive. It was all worth the trouble of flying through the worst-airport-ever ;-)

Michel Daerden, roi de YouTube

Google a visiblement fait un bon investissement. Il est maintenant le promoteur de la nouvelle star mondiale que le monde nous envie: Michel Daerden.

Ah propos, Michel a gagné les élections. Il est content. Et il a fêté ça! Sacré Michel... J'avoue que si j'étais Ansois, moi aussi je ferais comme mes 4500 voisins et je voterais pour Michel. Rien que pour le plaisir de le voir si heureux:

http://www.youtube.com/watch?v=0dguKikz7Ec

Du pur bonheur!

New MUI Meat in Vista

Michael, you write faster than I can read! So I miss stuff. Such as 4 months ago when you mentioned the whole new SDK docs chapter about MUI support in Vista. I only found about it today through the links in your ultimate fallback post. Of course, feel free to setup a list of your writings on the subject that I've missed since then. And feel free to blame me. ;-)

MUI Functionality Exposed

Up to now, the way MUI was implemented was not very documented. Of course, it's easy to find out about the satellite DLLs in c:\Windows\MUI\FallBack. And there is GetUserDefaultUILanguage() which is probably the most important. But that's pretty much it.

I haven't read the new docs chapter yet but will do very soon: I'm curious to see how we can improve our apps by integrating them with Windows MUI.

Single Worldwide Binary: What's the Problem?

It is commonly accepted that the best strategy to provide support multiple languages with one single EXE is to use resource DLLs (a.k.a. Satellite DLLs). By the way, generating such resource DLLs with appTranslator is as easy as filling one checkbox!
But why do we have to bother playing with a whole set of DLLs? After all, several translations of one given resource (such as a string or a menu) can easily be stored in a single EXE. And if you call SetThreadLocale() to select your language, voilà, your resources will be loaded in the expected language. Not!

SetThreadLocale() is not the solution

Once upon a time, there was Windows NT4 (and even, 3.51, 3.5,...). In these times, the single worldwide binary was a realistic option... as long as you didn't have to target Win9x, under which SetThreadLocale() was a no-no!Then came Windows 2000 and its vastly improved support for internationalization. Paradoxically, the single worldwide binary was no longer an option. Because one could no longer rely on SetThreadLocale() to globally select the language for resources, as the docs say:

Windows 2000/XP: Do not use SetThreadLocale to select a UI language. To select the proper resource that is defined with a LANGUAGE statement, use FindResourceEx.

Docs say 'don't touch!' but they don't say why. And if you try to look further, you won't find much info. As always, Michel Kaplan's blog is a good place to look up, even if it's to get confirmation that there's not much to find out.

Well, there are a few lines somewhere: This article briefly explains that when MUI was first introduced back in Windows 2000, the Microsofties had to modify the way resources are loaded (If you know why, please let me know). Actually, they modified the default language selection algorithm used to load resources :

The catch here is that if the thread locale is the same as the currently selected user locale, system’s resource loader will by default use the language ID 0 (neutral). If the desired resource is defined as a neutral language, then this value will be returned. Otherwise, all of the language resources will be enumerated (in language ID order) and the first matching resource ID – regardless of its language – will be returned.

In other words, Windows will not load resources the way you expect if you happen to ask for the same language as the user preference (user default locale)! Yikes! You don't believe me? Fair enough, me neither! :-) Let's make a test.

The Sample Program

• The program contains a String Table with a string in German, French (Belgium) and English.
• The program selects German as its default UI language : SetThreadLocale(German)
• It then loads a string from the String Table(displayed in the message box title).

(Download source).

You expect the loaded string to be "German string". Play with you user locale and you'll see that the docs are unfortunately right.

Here is what I get with User Locale = French (Belgium): The german string is correctly loaded.

Then I modify my user locale and select German:

When I re-run the program, I still expect "German String" but I get something else :-(

What language does it pick then?

If you look carefully at the screenshots above, you might notice something weird: The docs (quoted above) say that in case of ThreadLocale==UserLocale, the language picked should be the first one in ID order, which for my program is... German! (German=0x407, French-Belgium =0x80C and English=0x409).So in this case, German should have been picked, as a side effect. But it was not: English was picked. How come?

I made further tests and it appears that when UserLocale==ThreadLocale, Windows tries to load the resources in its own UI language (even if it's different from User/Thread Locale). Anyway, this irrelevant since we just demonstrated that SetThreadLocale() cannot be trust to achieve the Single Worldwide Binary dream.

BTW, why would FindResourceEx help?

Remember the remark in the docs? Use resource DLLs or use FindResourceEx().

The reason FindResourceEx() would help is simply because it takes an explicit langiuage ID, as opposed to the most usual resource-loading APIs such as LoadString(), CreateDialog() et al. But it's not a realistic solution because it would mean that you must re-implement your own LoadString() et al using FindResourceEx().

No, you don't want to do that! So we'll keep with resource DLLs.

I want a Sony Reader

I spend so many evenings reading stuff on my computer monitor. You know, articles, books, feeds...

Readings on a monitor is just not comfortable

I already spent the whole day sitting on that office chair. And I'll tell you what: Spending the evening as well on it is not pleasant. I'd rather be sitting in my sofa or in my bed. And don't get me started about how my wife would find me more sociable!
Also, I never found long readings particularly comfortable (hence productive) on a computer screen. Therefore taking my laptop in my sofa or my bed is not a more satisfying experience. Not to mention using a laptop in a plane :-(

I want to read a book

What I want is to be able to read all that contents from a book.
Do you remember eBook Readers? These devices showed up a few years ago but vanished as soon as they appeared. The idea was that they are no computers, they are, well..., electronic books: Their screen is not LCD/TFT-like. They use so-called electronic ink, some new kind of display that make it look like a book: no backlight, black & white but as comfortable and readable as paper.

For some reason, everyone thinks these devices should be used only to download novels from a book library. Hell, no! I want to load them with all articles and contents available from my computer.

Sony tries again : Sony Reader PRS500

Even though all these devices seem to be stored on the deep shelves of electronics History, Sony is just about to try again: They will release a new eBook reader in a couple of weeks from now. The
All reviewers rave about the device's quality (including the PCMag video review):

• Wonderful screen
• ultra portable: 6" inch screen, 250g (9 ounce), thinner than a book.
• Battery lifetime... oh boy! 7500 pages. Yes, pages, not minutes or hours: The device consumes power only when you turn the pages!

Cons mostly consist in:

• Sony eBook catalog. WTF! I don't want to read novels, I want to transfer contents from my computer.
• Price: $350. To read novels. Nooo! not novels! Why are you obsessed with novels. You know, i'm not a gadget fan. Not at all. But I won't hesitate a single minute to shell out such an amount for a device that can get me unstuck from my computer.
• DRM constraints for purchased eBooks. Then again, if you want to read novels...
• Not many file formats supported. Ouch, that one is worrying: The device basically supports only PDF and BBeB (Sony's proprietary eBook format). But after all, converting any device to PDF is as easy as invoking the Print command. Also, they say that the device comes with software that makes documents conversion to BBeB very easy.
• Slashdot readers will of course not forget to mention rootkits ;-)

I'm impatient to get my hand of such a device. But before i buy, I'll want to make sure reading PDFs formatted in A4/letter size will be easy to read on a 6" inch screen. This is actually my only concern.

Oh! And if they could have added a true USB port to let me plug my USB memory key, rather than a Sony Memory Stick or SD card, it would be perfect (The device does have USB connection but only through a mini-USB plug).

More info (including picture and links) on Wikipedia.

[Edit: 250g. Not 4kg!]