In the "global" market of today, with the Internet enabling you to sell you software everywhere in the world, you may think great care would be given to localization tools. Delphi ones reached a barely usable state in Delphi 7, and you may think BorCodeDero could only improve it since then. No. They did and still are doing the best to ensure Delphi can't localize applications by itself. Maybe Intersimone the Hippie thinks that globalization is bad - although he likes to travel all over the world-, and Delphi should just build application to be sold in your neighborhood, Maybe US Navy Hodges still thinks there are only enemies abroad - they do not deserve localized applications - just bombs and rockets until everybody speaks American!
Whatever it is, Delphi looks very much alike a chauvinist IDE. If it was developed in France, we could understand, but in multicultural California??
When tried to localize a Delphi application we were unable because the Resource DLL Wizard doesn't like some advanced form constructs like images into collections items, or some lines too long. First we used our Delphi 2007. Then we tried with a D2010 trial. Same errors. You get Unicode, but it's better if your GUI is in one language only. Like Ford Ts - you can choose any language if it is your IDE one.
I know there are several alternatives, from free open source ones (i.e. dxgettext) to commercial ones (i.e. Multilizer), but once again I don't understand why I am paying for features that do not work but in simple applications (those shown in demos...) - we made the "mistake" of using Developer Express controls in our applications, and noone at Embarcadero ever tried how localization tools behaves with widely used and complex third party controls - those who kept Delphi afloat while the VCL team was sleeping or building CLX/VCL.NET.
There have been several discussion about the expensive price of Delphi. Surely a tool where many of its features don't work as they should is expensive no matter how.