our delphi win32 app uses special characters like micro and copyright. we mostly use the arial. before delphi 2009, we had to provide a way to prevent the micro character from displaying since for some (many/most?) parts of the world, it was not displayed correctly. we'd replace micro with u, copyright with (C)...
now that we're in delphi 2009, can we leave out this option and display the micro & copyright symbols without needing to do this translation.
it would seem to me that this should work everywhere now without this lame replacement scheme now that our app is in unicode.
thank you!
Yes, as long as you're using Unicode strings and not ANSI strings, you can put in whatever extended characters you'd like, and they'll show up properly as long as the font you're displaying in supports them.
I'd test it in a few differnt languages first though. Unicode is not always as Universal as we sometimes believe.
Related
We have large commercial app that we want to convert from Delphi 6 to 2010. Approx 10 3rd party component sets, all with source code... I have heard warnings about Unicode with 2010 - Does anyone have experience and or suggestions?
There are many resources available that you can read and that you will assist in the migration from Delphi 6 to Delphi 2009/2010 (Unicode).
You can use these articles as a guide.
Unicode Migration Statistics Tool (This utility will hopefully assist you in collecting useful statistics
on how hard (or not) it would be to migrate your older applications to
Unicode.)
Delphi 2009 and Unicode
Delphi 2009 strings explained by example
Upgrading a major project to Delphi 2009
Delphi and Unicode
Dr. Bob Delphi 2009 Unicode
Delphi 2009 - Unicode in Type Libraries
On Strings and Unicode in Delphi 2009
Delphi in a Unicode World Part I: What is Unicode, Why do you need it, and How do you work with it in Delphi?
Delphi in a Unicode World Part II: New RTL Features and Classes to Support Unicode
Delphi in a Unicode World Part III: Unicodifying Your Code
CodeRage 4 : Using Unicode and Other Encodings in your Programs
Bye.
You'll find some useful answers in these StackOverflow questions:
Move project from Delphi 3 to Delphi 2010
When and Why Should I Use TStringBuilder?
Convert function to delphi 2009/2010 (unicode)
Unicode problems with Delphi 2009 / 2010 and windows API calls
Also, for what it is worth, I purchased Marco Cantu's Delphi 2009 Handbook. It was all I needed to make a relatively smooth converstion from Delphi 4 to Delphi 2009 in only a few weeks.
I do, however, recommend that you ensure your 3rd party packages have a Delphi 2009 upgrade, or you may have some real difficulties. Converting your own code is one thing. Converting someone else's is another.
I use two 3rd party packages, both with source code. Both had upgrades available, and the developer of one of them wrote that he had a lot of trouble upgrading his very complex component to the Unicode of Delphi 2009. It took him a few months, but he completed it. And as a result, I had little trouble with my implementation of his component when I did my upgrade.
i've been in the same circumstance recently. you mostly need to pay attention to the "edges" of the app. INI files, file I/O, log files, etc. win API calls from delphi work since they've now connected the unicode API calls instead. check each 3rd party component set to make sure they're at least ready for Delphi 2009...better yet 2010. even my use of databases simply wasn't an issue...nearly everything worked right away. it just wasn't a big deal. anything that relies on the size of a character should be reviewed.
really the transition of most concern is 2007_or_earlier --> 2009_or_later.
there are plenty of discussions/blog entries about it. you could read, read, read...or you could get started & see what happens. (i did some of both). i'm sure there are "stack overflow" issues discussing your question. i'm not pretending to give a detailed description of what could happen.
it's simply not as scary as it sounds.
Approx 10 3rd party component sets, all with source code.
One thing I'd add is if the component doesn't support Delphi 2009/2010, don't try to upgrade it by hacking the code.
Following is what I posted on How do the new string types work in Delphi 2009/2010?:
See Delphi and Unicode, a white paper written by Marco Cantù and I guess
The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!), written by Joel.
One pitfall is that the default Win32 API call has been mapped to use the W (wide string) version instead of the A (ANSI) version, for example ShellExecuteA If your code is doing tricky pointer code assuming internal layout of AnsiString, it will break. A fallback is to substitute PChar with PAnsiChar, Char with AnsiChar, string with AnsiString, and append A at the end of Win32 API call for that portion of code. After the code actually compiles and runs normally, you could refactor your code to use string (UnicodeString).
I must add this article from Carey Jensen to others mentioned. It is labeled: "Delphi Unicode Migration for Mere Mortals: Stories and Advice from the Front Lines" (in english).
http://www.danysoft.com/free/delphiunicodemigration.pdf
As you can see in the title of it, you will find many experiences and hints and tips. I think it is the answer to your question. After carefully read it, you will sure knows what to do next. :)
Found in: http://www.danysoft.com/productos/migrar-aplicaciones-a-delphi-xe-o-cbuilder-xe.html
Another point to take care of, is the usage of Variant types with strings and the VarType function testing for strings: one needs to use varUString instead of varString.
Assuming AValue is of type Variant and has being assigned a Unicode string value, the following won't work:
if VarType(AValue) = varString then ...
and needs to be changed to
if VarType(AValue) = varUString then ...
I develop a delphi7 webbroker multilanguage application for apache2,2. The application is using Oracle xe11 for data storage, and Devart's ODAC components to communicate with the Database. I set up the Orasession component as to use Unicode. The data inside the database was stored properly in Unicode capable data type columns. With another desktop application , also written in Delphi 7 we are able to store, retrieve and display correctly the same data of the database (I’m using Unicode capable components). My problem occurs when I want to display these data with the webbroker appl in html format. I’m using the default components provided by delphi 7 (TWebResponse). All text which are in Latin characters displaying correctly but all the others which are in different languages (not latin) not. Can you suggest me what have I do to solve the problem?
(How) do you encode the unicode output of your components to the non-unicode capable (Ansi)String of TWebResponse.Content?
I guess the system codepage does not contain Ü (probably the same as the German Umlaut Ü -> U+00DC) and you are using an implicit conversion to (Ansi)String that takes the best mapping it can.
At least in Delphi 2006 you can / have to use
function Utf8Encode(const WS: WideString): UTF8String;
in system.pas (utf8string is a string - defined in same unit). As far as I know that function was there also in in Delphi 7.
You can't but you can work around it.
Label1.Font.Charset := TURKISH_CHARSET;
Mess with the Charset property to get what you want.
we have a application written in vb6, we also have the multilingual support for this application, we provide all the user message along with the ID's in .LNG file but application is not supporting the Unicode language like Japanese, Chinese etc.,can anyone suggest how to proceed the minimum change in the code and make this work !!!
Thanks
Standard VB6 controls doesn't support UNICODE. It is possible to use MS Forms controls (FM20.DLL). INFO: Usage and Redistribution of FM20.DLL.
The problem is that old version i buggy and is updated by MS-Office. New version of office id 64-bit and doesn't contain 32-bit FM20.DLL. I think it it only 'simple' way of implementing UNICODE but still it is massive change to the application.
Howerer VB6 supports different languages at least European, but the texts have to be properly encoded (Code Page Identifiers). I suppose that usual Windows font such as MS-San Serif, Arial supports most of languages.
If the windows default language is set properly other language characters should work. See e.g. HOW TO:Change language settings in Windows XP or try Japanese windows direclty.
I have Delphi 2010.
XXX-component uses File_Path:AnsiString. A path can be written in XXX-language. If I set to use XXX-language for non-unicode programs in Windows settings then XXX-component recognize the path but if I set default Windows settings (English Windows-English for non-unicode programs) XXX-component can not recognize the path.
How to fix it?
Thank you!!!
To solve this problem you need to move away from ANSI strings and start using Unicode strings and the corresponding Unicode versions of the Windows API. At the moment you are reliant on the computer locale and that's an enormous world of pain.
Moving from AnsiString to string takes a little effort but the benefits make the effort well worthwhile.
Embrace Unicode and forget all about the bad old days!
I have developed about 300 Applications which I would like to provide with multi-language capabilities independent from the Operating System. I have written a just-in-time translator, but that is too slow in applications with many components. What would you suggest I do?
We are using TsiLang and are very happy with it.
One of the best points is that you can pretranslate the project with a dictionary (which you filled from existing translations).
I've heard that the TsiLang components are nice, but your looking at an inplace solution...
I've used GNU gettext for Delphi which does exactly the thing you want, it loads the translations from a text file and replaces the text in your components. It even has a pas/dfm scanner to automatically generate the English translation file.
It's also possible to automatically change your pascal source code to inject the gettext procedure inplace of your static strings. If I'm not mistaken it just adds a underscore as function to it, as below.
ShowMessage('Hello'); // before
ShowMessage(_('Hello')); // after
I must say it has been 2 years since I last used this method.
One thing will remain problematic, the Delphi components are not unicode enabled (D2009 fixes this), so when you don't change the components you'll still have limited support for other languages.
A good free solution would be GNU gettext for Delphi. It has some capabilities not present in TsiLang - for example, you can put the knowledge on how to count things (different endings for one, two, four, hundred and two, many ...) into the translation file so that you don't have to teach each program to know this stuff.
License for the Delphi part is very permissive but I'm not sure how much the included GNU stuff will affect your application.
Get Multilizer. It is made in Delphi and it can handle Delphi programs like no other with special support for VCL. You can even redo your screens easy for every language. With Multilizer you can use different techniques to translate and run your program.
Delphi 2009 has added an Integrated Translation Environment/External Translation Manager
ITE and ETM are now available for both Delphi and C++Builder.
In Codegear's article: What's New in Delphi and C++Builder 2009, they state:
The Integrated Translation Environment
(ITE) is a part of the IDE that
simplifies localizing your projects.
ITE can create a new localized project
from an existing project. ITE does not
automatically translate text, but
provides a dialog listing all text
that needs to be localized and fields
in which to enter the corresponding
translated text. Once you have entered
the translated text and built the
localized project, you can set another
language active and display a form in
the localized text; you don't have to
switch locales and reboot your system.
This allows you to perform
localization without requiring a
localized system.
The External Translation Manager (ETM)
is a standalone application that works
with DFM files and text strings in the
source code. Although ETM does not
allow you to create a new localized
project, it does provide a dialog
listing localized text and the
translated text, similarly to ITE.
This is what I plan to try first once I am at the point that I want to Internationalize my product.
However, to me the easy part is to translate the program. The hard part is to translate the help file.
I would say GNU gettext for Delphi in combination with TMS Unicode Component Pack (previously free under TntWare) to get unicode support in the components.
To work with, or have translators work with, the gettext files I recommend looking at the free cross-platform Poedit that may edit the .po files.
Just to mention cxLocalizer if you own DexExpress components.