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.
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.
Edit: Just to clarify, I didn't intend to suggest it might be impossible to write an IDE for dynamic languages. /edit
In my specific experience I'm thinking about years of conversations/comments about JavaScript, many of them on stack, but every now and then somebody says this, that the reason JS doesn't have a decent IDE is because dynamic types make it too hard to do.
I've thought about this in terms of writing a parser for JS and I don't understand where the types have anything to do with features like auto-complete or going straight to the definitions of stuff. If anything I would imagine scope and availability through passed params in a dynamic language would be considerably easier to establish without the type-checking concern. Especially in JS where the rules are actually pretty simple in most cases.
Until I started hearing people cite dynamic types as if it were a technical blocking issue, I just assumed that in most dynamic scripting languages you can run from a console, reduced verbosity and the ease of testing in a live execution environment makes debug easier, thereby reducing demand for IDEs.
So which is it? Something about static types that makes it easier to parse code for establishing scope/availability or am I right about reduced demand?
IDEs were invented in dynamic languages. Refactoring was invented in dynamic languages. Automated Refactoring Tools were invented in dynamic languages.
Dynamic languages had graphical IDEs with builtin support for pair programming over the network when static languages didn't even have graphics. Or IDEs. Or networking support.
Smalltalk and Lisp IDEs still are ahead of what's available for Java or C#, for example. In fact, Eclipse was a Smalltalk IDE once!
The quality of an IDE is dependent on how much effort is spent making it good. The Smalltalk and Lisp communities spent decades of research, dozens of PhDs and truckloads of money building powerful IDEs. So did the Java community. (Actually, they spent truckloads of money buying Smalltalk companies …)
The JavaScript community didn't. That's the whole difference.
There are some things that need a different approach between the two. Take something like IntelliSense / Content Assist / Autocompletion, for example. Statically trying to determine what identifiers are in scope in a dynamic language is basically equivalent to solving the Halting Problem, so you can't do that. Your IDE needs to be dynamic as well, then it doesn't need to do static analysis, it can just look at the running code and see what identifiers are in scope.
Smalltalk is a dynamic language and had one of the earliest graphic based IDEs including support for refactoring. Also look at Jetbrain's RubyMine for an example of a more modern IDE for a dynamic language.
It's not impossible. It's more difficult...but then again so is writing tools for developers in general.
Although it is comparatively hard to write in C++ than in Pascal I'm really attracted by multi-platform support of Qt. I can connect to an MSSQL server running on Win2003 server from Linux or I can connect to a PostGreSQL server running on Linux. That made a plus when comparing with Delphi.
I'm trying to write sample programs to get used to the Qt and C++. So far I'm comfortable with the layouts and signals-and-slots mechanism (still double clicking the buttons to write event code though :) ). I wish I was using the SQL data in my programs as easily as in Delphi.
Is there any way that I can put some connection object, a DataSource, a DBGrid and a DBNavigator on to a form and go on without writing code? (For some forms it is really a time saver, a project with 300+ forms can be made faster)
I would like to hear from people using Qt with data from SQL servers.
You would have to write your own designer plugins to achieve that and make your widgets invisible, as there is no direct support for non gui components in Qt Designer.
However, writing explicit code in Qt (which is really a lot less work than in most other programming environments) helps the program to stay readable. Delphi projects with a lot of forms and components tend to become readable to the author alone, because dependencies jump across files a lot. If you store your forms in binary format, you are lost anyway, because you then cannot search your project textually to find dependencies.
Good design, which causes your code to become small and easily readable is necessary in any programming environment and makes aspects like invisible components in forms less important (though you will miss them for a while to come like I do).
So, unfortunately, you are on your own for the moment.
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.
Does anyone know any good library (free or commercial) for Delphi that can read/parse/modify MS Word documents (preferably with Word 2007 support) without MS Word OLE Automation? I've found some for .Net, but none for Delphi.
For example, here are two .Net/Java libraries - Aspose, Word.net
I don't want to add .Net dependencies in my application. A library that compiles right inside the exe will be most preferable, but any ActiveX will also work.
Thank you.
I know (a simple non-commercial) variant for Excel, but not for Word. And not for very new ones.
DR: the problem is that that needs Word installed. The options above don't. Moreover OLE can get slow, e.g. when you want to make umpteen personal letters for a mailing in it.
The only other routine I can imagine is automating Open Office. But that has the same speed problems (or worse) probably, so that would depend on why you exactly want this.
The Office format is horribly complicated, and nearly every solution will be more expensive (in either vast time or money) than just coughing up a copy of word. (and with OOo you could even avoid that)
Scalabium has TSMWordDocument component that can extract the plain text and is entirely in native code. It doesn't support modifying them or extracting graphics/styles though. Their SM Export component set allows generating Word documents, but I don't think it supports reading them. We use the TSMWordDocument one and it's ridiculously fast compared to COM automation. The only downside we've hit is that it even though it's Delphi 2009 compatible, it still doesn't handle international text unless the system codepage matches (so Japanese on a Japanese system is ok, but not on an English one).
You could use the .NET library and create an ActiveX/COM wrapper for it, which you can use from Delphi.
This article describes the interop possibilities between COM and .NET. Look at "Using .NET Objects from COM"
Microsoft's formats are so complex that it is a lot of work to write, and keep up to date, a set of components to do what you want without automation.
There is Winsoft's Office Component Suite, but you'll see that hasn't been updated to work with the latest version of Office, or with Delphi 2009+.