I am working on a cross platform library that should compile in both desktop and mobile compilers supported by Delphi.
as we know strings in desktop is 1-based and mobile is 0-based.
is there any defines in Delphi that I can use to separate code that will compile in desktop and mobile and is backwards compatible at least down to XE2.
something more like if defines desktop do this else if mobile do this.
sorry for bad formatting. typing from Mobile.
Delphi version XE7 up 1.
The conditionals are documented here: http://docwiki.embarcadero.com/RADStudio/en/Conditional_compilation_(Delphi)
I think that the answer to the question that you asked is that you should switch on the NEXTGEN conditional.
However, just because you are compiling for mobile (i.e. NEXTGEN) does not mean that strings must zero based. Likewise there is no compulsion for desktop code to be one based. Zero based strings can be enabled/disabled with the $ZEROBASEDSTRINGS directive.
You really ought to try to avoid conditional compilation. Conditional compilation adds significant complexity, makes testing harder, and increases the risk off defects. I strongly recommend you try to avoid conditional compilation where possible.
So for each unit you should decide whether you are zero or one based and include the appropriate directive at the top of that unit. If you plan to use the one based RTL functions like Pos and Copy, be one based. Otherwise use the string helper (introduced in XE3) and be zero based. The decision isn't really related to whether or not your code targets desktop or mobile.
Finally, you say you want to support mobile on XE2, but the compiler there is FreePascal which uses one based strings. Supporting XE2 mobile is another layer of complexity.
Related
I need to translate an application on delphi. Now all strings in interface on Russian.
What are the tools for fast find, parcing all pas'es for string constants?
How people translate large applications?
GetText should be able to do, search for "extract" at http://dxgettext.po.dk/documentation/how-to
If all you need is to translate GUI and maybe resourcestring in sources, and the inline string constants in Pascal sources are not needed for translation, then you can try Delphi built-in method. However forums say that ITE is buggy. But at least that is official Delphi way.
http://edn.embarcadero.com/article/32974
http://docwiki.embarcadero.com/RADStudio/en/Creating_Resource_DLLs
To translate sources with ITM manual preparation is needed as shown in source sheets at http://www.gunsmoker.ru/2010/06/delphi-ite-integrated-translation.html
I remember i tranlsated Polaris texts for JediVCL team - so they did some extraction. But i think they just extracted all characters > #127 into a text file - there was no structure, there were constants and comments, all together.
Still, there is some component, though i doubt it can be used the way you need: http://wiki.delphi-jedi.org/wiki/JVCL_Help:TJvTranslator
There are also commercial tools. But i don't know if their features would help you on your initial extraction and translation tasks. They probably would be of much help when you need to mantain your large application translated to many languages, but not when you need to do one-time conversion. But maybe i am wrong, check their trial versions if you wish. By reviews those suites are considered among best of commercial ones:
TsiLang Suite http://www.tsilang.com/?siteid2=7
Korzh Localizer http://devtools.korzh.com/localization-delphi/
Firstly I'd recommend to move all localizable string constants into the resource string sections within their unit files. I.e.
raise Exception.Create('Error: что-то пошло не так (in Russian language)');
will be converted to
resourcestring
rsSomeErrorMessage = 'Error: что-то пошло не так (in Russian language)';
...
raise Exception.Create(rsSomeErrorMessage);
More about Resource Strings.
This process can be accelerated by using the corespondent Delphi IDE refactoring command, or with third-party utilities like as ModelMaker Tools.
Then you can use any available localizer to translate or even internationalize your program. I'd recommend my Delphi localizer - it's free.
Basically, you have two ways
Resource-based localization tools (Delphi ITE, Multilizer, ecc.)
Database-based localization tools (GetText, TsiLang, ecc.)
The former takes advantage of the Windows resource support, resource loading can be redirected to a different one stored into a DLL when the application is started. The advantages are that whole forms can be localized, including images, colors, control sizes, etc. and not only strings. Moreover, no code change is required. The disadvantages are that end-user localization is not usually possible, and changing language without restarting the application may be trickier. Microsoft applications, including Windows itself, use this technique. It will work with any Delphi libraries that stores strings into resources and dfms properly.
The latter stores strings in an external "database" (it could even be a text file...). The advantage is usually that users can add/modify translations, and switching language on the fly easier. The disadvantages are this technique is more intrusive (it has to hook string loading/display) and may require code changes, tools are usually limited to string localization and don't offer broader control (images, sizes, etc.), and may not work with unknown controls/libraries they could not hook correctly. Usually cross-platform application use this technique because Windows-like resource support is not available on all operating systems.
You should choose the technique that suits you and your application best. Moreover some tools ease the collaboration with an external translator, while others don't. I prefer the resource-based approach because it doesn't require code changes and don't tie me to a given library.
We are using dxgettext (GNUGettext for Delphi and C++ Builder) and Gorm (from the same author). Mind you, most tools require you to use English as the primary language and translate from that only. dxgettext allows other languages but there are bound to be unknown problems with that. Be prepared that internationalizing a large applicatin will be more work than you currently think.
I need to translate an application on delphi. Now all strings in interface on Russian.
What are the tools for fast find, parcing all pas'es for string constants?
How people translate large applications?
GetText should be able to do, search for "extract" at http://dxgettext.po.dk/documentation/how-to
If all you need is to translate GUI and maybe resourcestring in sources, and the inline string constants in Pascal sources are not needed for translation, then you can try Delphi built-in method. However forums say that ITE is buggy. But at least that is official Delphi way.
http://edn.embarcadero.com/article/32974
http://docwiki.embarcadero.com/RADStudio/en/Creating_Resource_DLLs
To translate sources with ITM manual preparation is needed as shown in source sheets at http://www.gunsmoker.ru/2010/06/delphi-ite-integrated-translation.html
I remember i tranlsated Polaris texts for JediVCL team - so they did some extraction. But i think they just extracted all characters > #127 into a text file - there was no structure, there were constants and comments, all together.
Still, there is some component, though i doubt it can be used the way you need: http://wiki.delphi-jedi.org/wiki/JVCL_Help:TJvTranslator
There are also commercial tools. But i don't know if their features would help you on your initial extraction and translation tasks. They probably would be of much help when you need to mantain your large application translated to many languages, but not when you need to do one-time conversion. But maybe i am wrong, check their trial versions if you wish. By reviews those suites are considered among best of commercial ones:
TsiLang Suite http://www.tsilang.com/?siteid2=7
Korzh Localizer http://devtools.korzh.com/localization-delphi/
Firstly I'd recommend to move all localizable string constants into the resource string sections within their unit files. I.e.
raise Exception.Create('Error: что-то пошло не так (in Russian language)');
will be converted to
resourcestring
rsSomeErrorMessage = 'Error: что-то пошло не так (in Russian language)';
...
raise Exception.Create(rsSomeErrorMessage);
More about Resource Strings.
This process can be accelerated by using the corespondent Delphi IDE refactoring command, or with third-party utilities like as ModelMaker Tools.
Then you can use any available localizer to translate or even internationalize your program. I'd recommend my Delphi localizer - it's free.
Basically, you have two ways
Resource-based localization tools (Delphi ITE, Multilizer, ecc.)
Database-based localization tools (GetText, TsiLang, ecc.)
The former takes advantage of the Windows resource support, resource loading can be redirected to a different one stored into a DLL when the application is started. The advantages are that whole forms can be localized, including images, colors, control sizes, etc. and not only strings. Moreover, no code change is required. The disadvantages are that end-user localization is not usually possible, and changing language without restarting the application may be trickier. Microsoft applications, including Windows itself, use this technique. It will work with any Delphi libraries that stores strings into resources and dfms properly.
The latter stores strings in an external "database" (it could even be a text file...). The advantage is usually that users can add/modify translations, and switching language on the fly easier. The disadvantages are this technique is more intrusive (it has to hook string loading/display) and may require code changes, tools are usually limited to string localization and don't offer broader control (images, sizes, etc.), and may not work with unknown controls/libraries they could not hook correctly. Usually cross-platform application use this technique because Windows-like resource support is not available on all operating systems.
You should choose the technique that suits you and your application best. Moreover some tools ease the collaboration with an external translator, while others don't. I prefer the resource-based approach because it doesn't require code changes and don't tie me to a given library.
We are using dxgettext (GNUGettext for Delphi and C++ Builder) and Gorm (from the same author). Mind you, most tools require you to use English as the primary language and translate from that only. dxgettext allows other languages but there are bound to be unknown problems with that. Be prepared that internationalizing a large applicatin will be more work than you currently think.
What are their differences? What can you do with one that you cannot with another?
At a high level
Addins must be installed and must be delivered in the form of a DLL. It can be written in any language which compiles to a compatible DLL format (any .Net language which supports COM interop).
Macros do not need to be installed but can only be written in VB.Net. This limitation only applies to the code directly in the Macro. It is still free to call code from .Net libraries written in any language.
In terms of raw power, there is not a whole lot of difference between the two. You can do practically anything with a macro that you can with an add-in (other than startup logic). It can be a bit more challenging with a macro but it's generally speaking possible.
Macros are also an interesting way to explore the API of Visual Studio. It is possible to use the Macro recorder to record user actions and spit out code which is close to the equivalent of those actions. You can analyze the resulting code to get a better handle on the Visual Studio object model.
I have a freeware scientific app that is used by thousands of people in nearly 100 countries. Many have offered to translate for free. Now that D2009 makes this easier (with integrated and external localization tools, plus native Unicode support) I'd like to make this happen for a few languages and steadily add as many as user energy will support.
I'm thinking that I'll distribute a spreadsheet with a list of strings (dozens but not hundreds) to be translated, have them return it, and compare submissions in the same language from 2-3 users then work to resolve discrepancies by consensus. Then I'll incorporate the localizations using the Integrated Translation Environment, and distribute localized updates.
Has anyone delegated translation to users? Any gotchas, D2009-specific or otherwise?
EDIT: Has anyone compared the localization support built into D2009 versus dxgettext?
I have never been a friend of proprietary localization tools for Freeware or Open Source applications. Using dxgettext, the Delphi port of GNU gettext looks like a much better option to me:
Integration into the program (even much later than its development) is easy.
Extraction of translatable strings can be done by command line programs and is therefore easily introduced into an automated build.
A new translation can be added simply by creating a new directory with the correct structure, copying the empty translation file into it, and starting to translate the strings. This is something each user can do for themselves, there's no need to involve the original author for creation of a new translation. There is also instant gratification with this process - once the program is restarted the new translations are shown immediately.
Changing an existing translation is even easier than creating a new one. Thus if a user finds spelling or other errors or needs for improvement in the translation they can correct them easily and send the changes to the author.
New program versions work with old translations, the system degrades very gracefully - new and untranslated strings are simply shown unmodified.
Translations can be made using only notepad, but there are several free tools for creating and managing translation files too; see the links on the dxgettext page. They are localized themselves, and have some advantages over a spreadsheet as well:
The location of the strings in the source code can be shown (makes sense only for Open Source apps, of course).
The percentage of translated strings is shown.
Modifications to already translated strings are highlighted too.
The whole system is mature and future-proof - I have used dxgettext for Delphi 4 programs, and there should be no changes necessary for Delphi 2009 even - translation files have always been UTF-8 encoded.
Using a spreadsheet for the translation doesn't seem a workable solution to me once you have more than a few languages. Suppose a new program version adds 2 new strings and changes 10 strings only slightly - wouldn't you need to add the new strings to and highlight the changed strings in all of the several dozen spreadsheet files and send them again to your translators? Using dxgettext you just mail the changed po file to all of them.
Edit:
There is an interesting comment about the problems there may be with dxgettext and libraries. I did never experience this, as I have stopped using resource strings altogether. The biggest part of our programs are in German, and only a few are in English or translated into several languages.
Our internal libraries use "_(...)" around all translatable strings. There are defines ENGLISH and USEGETTEXT that are set on a per-project basis. If ENGLISH or USEGETTEXT are defined, then the English texts are compiled into the DCUs, else the German text is compiled into the DCUs. If USEGETTEXT is not defined "_()" is compiled as a function that returns its parameter as-is, else the dxgettext translation lookup is used.
I have... There can be some challenges.
a string does not mean much in itself, it needs a context.
corollary, the same string can need to have more than one translation.
screen real estate: beware of varying length depending on the language, for instance, French tends to be more verbose than English.
unless you are proficient in a given language, you won't be able to evaluate the discrepancies.
I've used TsiLang Translation Suite for enabling end users to translate. I modified the code to allow encryption so that if someone does a really good job they can protect their name against a translation file, but in general the idea is that people can share their translations, and add/edit any small part they wish to. Given that it all happens within the app, and with instant visibility, it works really nicely.
As you have mentioned, D2009 comes with localization tools. Why not simply using them? AFAIK you can distribute the external translation manager (etm.exe). Do you need anything else?
Also, localization is more than just translating text. ETM also supports translation of .dfm resources.
For completeness, here is another Delphi localization tool called Delphi Localizer I recently found that looks to be well designed and polished. The tool is free for commercial use with the exception of Government projects (not exactly sure why the exception).
FWIW I have uses TsiLang Translation Suite in the past and am currently working on another project using the localization tools shipped with DevExpress VCL. The later integrates nicely with their components as well as third-party components.
Which tool/approach would you suggest to convert of a large 16bit Windows GUI application, written in old Borland Pascal 7 / OWL, to Delphi?
Understanding the pretty heavy differences between OWL and VCL, as well as the differences between the pointer manipulations in 16bit pascal and the state-of-art using of strings and objects in Delphi - are there any ways/tools which could help to avoid almost complete rewrite of the application?
I think you need to determine;
a) how much of the code is to do with business logic, data(base) manipulation and things like proprietary file structures, mathematical processing etc? This is stuff that might lift largely 'as-is' because it's more likely to be written in 'pascal' with much smaller, obvious elements of OWL/BP7. For instance, when I did this with an application I had a series of units that dealt with loading/saving proprietary files, stuff to calculate easter, stuff to do maths on arrays etc - all of this stuff went from BP7 to Delphi (1) with almost no changes.
b) how much of the code is to do with the GUI (and nothing else) - message loop handlers, dialog element constructors, properities of controls etc. This stuff will take a lot of work to port to Delphi and unless you can find someone with a nice line in .RES->.DFM (or similar), I think you'll be looking at building this bit from scratch. No bad thing because if it's a 16bit Windows app then you'll probably want to take the opportunity to at least make it look a bit more 'modern' anyway. I think this will be the most labour-intensive part of the project.
c) how much of the code is using stuff that you know can be done differently in Delphi, but that would work as it stands in pascal right now? This is where #BloodySmartie's point about migrating to an older version of Delphi makes sense to me. You ought to be able to port that project to something like Delphi 5/7 making obvious (and well-understood) changes to things like string manipulation. The more of this stuff that you can leave unported, the better in my view. Get something that runs and that you check basic behaviour with, and then embark on a process of refactoring/refining to make the most of Delphi as and when the resources allow it. You might have (as I did) arrays of pointers in BP7, where each pointer goes to an array of pointers which ultimately lead to an object - this was how we got around memory limitations in the 16bit Windows world. When I first ported my app, these arrays of pointers to arrays of pointers still worked fine in Delphi and I left them alone until I had the time to do something more 'Delphi-like' with the structures.
But before you do all of that - why are you porting the app? If you're porting it because you're about to make a reasonable number of changes to the app's functionality anyway, then it might really be the right time to rewrite the app. As you're rewriting in Delphi, you are still going to be able to use chunks of functions and procedures that are business-rule based anyway, so it's not necessarily a complete and total rewrite from scratch.
I guess there is no tool to support your migration but i'd try to start in an old Delphi Version like 1,2 or 3. This syntax should be much nearer on BP7 than the syntax of newer Delphi Versions.
At this time, you should first try to just bring your app logic to delphi, without any visual stuff. Then use the form designer to rebuild your GUI.
A important point you should pay attention to is that a DOS string is an ASCII-String, while the Delphi strings up to Delphi 2007 are ANSI-encoded. In Delphi 2009, the string keyword describes a unicode string.
Long-long time ago when I swapped OWL to VCL (in C++) it was just easier to write everything from scratch. There might be some code parts that don't deal with user interface and string manipulations, but otherwise it's totaly different.
In fact one of my biggest app is still in OWL, because I just don't bother to rewrite it. As long as it works, let it be.
we also had - and still have - tons of owl-applications.
so we did port the 16bit owl to 32bit owl and are therefor still developing and maintaining our owl-based applications (actually with Delphi 2007 for win32).
you may find this way easier and faster than switch to vcl.
cheers
Andrej
FrameworkPascal.com provides an effective solution with minimal changes to the original windows 3.1 code. We did it for a while but now we provide a rounded solution with 32 bit compatible OWL units. We also provide with it ODBC SQL units, MAC address based security technology and special units CRT like units which can handle code written for DOS text and graphic modes mode, mixed, with and new 32 bit graphics and targeted at Windows 32/64 GUI applications. Legacy code can be which can be compiled with OWL Windows MDI starting with model applications demos which can be quickly modified.