This course will introduce you to SQL Server Core 2016, as well as teach you about SSMS, data tools, installation, server configuration, using Management Studio, and writing and executing queries.
How to deploy a Delphi localised application ?
With the help of EE experts, I suceeded to write a localised application.
My PC is originally in the belgian french locale
I localised my application with the Delphi IDE in english UK
Delphi created a ENG directory
After translating forms using the IDE tools, I recompiled everything and I have now a nice myApplication.exe and also a myApplication.ENG
As I understand, myApplication.ENG is a DLL containing the stuff necessary for the executable to "translate" the forms...
A couple of days ago, I found a trick to test it on my own development PC
I renamed the DLL into myApplication.FRB (FRB is for belgian french) and indeed running the application, the forms came translated.
Now today I continued with this application (there are many forms) to translate some forms.
Applying the same rename trick ... did not work anymore !
My PC is originally in the belgian french locale
I localised my application with the Delphi IDE in english UK
Delphi created a ENG directory
After translating forms using the IDE tools, I recompiled everything and I have now a nice myApplication.exe and also a myApplication.ENG
As I understand, myApplication.ENG is a DLL containing the stuff necessary for the executable to "translate" the forms...
A couple of days ago, I found a trick to test it on my own development PC
I renamed the DLL into myApplication.FRB (FRB is for belgian french) and indeed running the application, the forms came translated.
Now today I continued with this application (there are many forms) to translate some forms.
Applying the same rename trick ... did not work anymore !
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
so you are using the Delphi translation manager ?
what it does when you say 'doesn't work anymore' ? is it a regression (what was translated successfully before is now not translated) or just new ones that do not apply as they should ?
have you recompiled myApplication.ENG ?
what it does when you say 'doesn't work anymore' ? is it a regression (what was translated successfully before is now not translated) or just new ones that do not apply as they should ?
have you recompiled myApplication.ENG ?
What I mean is that none of the translated forms (use translation manager, yes) are coming in english on the screen. It is still all french that are there.
I recompiled of course, and moved the exe and dll in a test directory (renaming the dll into FRB on my computer)
When I run it and get the first form (not translated), I can see (process explorer) that the myApplication exe has a handle on the DLL so it opens it but it does NOT use it !
I stopped my application and had a look inside the DLL (hexa view and text) and I could see some english words from my translation ...
I recompiled of course, and moved the exe and dll in a test directory (renaming the dll into FRB on my computer)
When I run it and get the first form (not translated), I can see (process explorer) that the myApplication exe has a handle on the DLL so it opens it but it does NOT use it !
I stopped my application and had a look inside the DLL (hexa view and text) and I could see some english words from my translation ...
Well, what is strange on my PC is that it worked fine for several days
It is just right now that it doesn't ...
It is just right now that it doesn't ...
What I can do is to develop a simple form project with just on caption
I translate it in english UK and see what's happening
I keep you informed
I translate it in english UK and see what's happening
I keep you informed
Hello epasquier
I attach two files
First a small executable named essai.exe : it displays an empty form
The title is localised
The locale dll is essai.eng
If your locale is english UK it should display an english title (rename the DLL into .ENU for american english)
On my PC, right now, I renamed it into .FRB but the result is still french
Well, may be this is finally normal ?
I attach two files
First a small executable named essai.exe : it displays an empty form
The title is localised
The locale dll is essai.eng
If your locale is english UK it should display an english title (rename the DLL into .ENU for american english)
On my PC, right now, I renamed it into .FRB but the result is still french
Well, may be this is finally normal ?
hum. Doesn't work either. I have tried to change my OS settings to UK and USA without success (normal setting is FRA for me - right next door to you), with different extensions.
I'm trying on my own project and tell you if I find something
I'm trying on my own project and tell you if I find something
I can tell you that I've done the necessary work to localize a test project of mine, with ENG and FRA and it works. a bit.
It would seem that you have to recompile the application, selecting another language first ('Projet->Langues->Activer
So, either there is a way to force programmatically the application to select another file, or you'll have to recompile the application for all language anyway (which was one thing we wanted to avoid with a localization system), or to change the extension of files to the one that was activated when the app was compiled (that is working also).
So, my first impression of the language manager is consistent with what I've read on the subject : it helps, but is far from perfect. Maybe there are still a few things we don't master there...
It would seem that you have to recompile the application, selecting another language first ('Projet->Langues->Activer
So, either there is a way to force programmatically the application to select another file, or you'll have to recompile the application for all language anyway (which was one thing we wanted to avoid with a localization system), or to change the extension of files to the one that was activated when the app was compiled (that is working also).
So, my first impression of the language manager is consistent with what I've read on the subject : it helps, but is far from perfect. Maybe there are still a few things we don't master there...
I see that you are french (speaking)
I am from Belgium
Indeed I think that the OS is not the guilty.
I renamed the DLL with .FRB for french belgium but it does not work ANYMORE
As I wrote, it was working a few days ago
Surely something to see with activation ...
I will continue my investigations in that direction...
I am from Belgium
Indeed I think that the OS is not the guilty.
I renamed the DLL with .FRB for french belgium but it does not work ANYMORE
As I wrote, it was working a few days ago
Surely something to see with activation ...
I will continue my investigations in that direction...
I have again activate the english language and recompiled
When looking inside the produced DLL (ENG extension), I see that all text are the french ones !
When looking inside the produced DLL (ENG extension), I see that all text are the french ones !
I think "active language" is the one tee app should look for and load by default.
I think then that there is probably a way to switch the language by programming, but that is yet to be found.
As I said, it is kind of working for me, I can change language loaded as long as I do one of 2 solutions :
- change the desired dll extension to the one that is activated in the application settings
or
- change the application settings (active language) and recompile, it will the load the other dll
I think then that there is probably a way to switch the language by programming, but that is yet to be found.
As I said, it is kind of working for me, I can change language loaded as long as I do one of 2 solutions :
- change the desired dll extension to the one that is activated in the application settings
or
- change the application settings (active language) and recompile, it will the load the other dll
I think I am now close to the solution
Can you be more precise with your two solutions based on my current stuff because I think I am somewhere between these...
My locale is belgian french so are my form text in french
I added the language ENG and translated the form with the manager in Delphi
Now how can I compile the all stuff so that when I run the application with the resulting DLL (extension ENG), and run the application on my computer (or another with any type of locale), the forms are in english ?
Can you be more precise with your two solutions based on my current stuff because I think I am somewhere between these...
My locale is belgian french so are my form text in french
I added the language ENG and translated the form with the manager in Delphi
Now how can I compile the all stuff so that when I run the application with the resulting DLL (extension ENG), and run the application on my computer (or another with any type of locale), the forms are in english ?
PS : I have 'activated' the english and compiled : when looking inside the resulting DLL, all text are in french !
Now how can I compile the all stuff so that when I run the application with the resulting DLL (extension ENG), and run the application on my computer (or another with any type of locale), the forms are in english ?
No idea
When I look via the translation manager, english is there
Looking to the files, I see english in dfN files and when asking the translation manager to show me the form translated, it is english
When I look via the translation manager, english is there
Looking to the files, I see english in dfN files and when asking the translation manager to show me the form translated, it is english
Hello epasquier
I made a few additional tests, based on our conversation.
Indeed, activating a langage, for example ENG, means that when the application starts, it looks directly for the ENG DLL.
On the other hand, if that DLL is not there, it searches for the corresponding locale, here for me FRB
If I rename the DLL from ENG to FRB, indeed it uses it.
This is interesting because I will be able to distributed an english version to my "users" by defined ENG as the default and delivering that DLL as well, whatever the locale for my users is.
I succeded finally to do all that after creating a brand new project with one simple form
Now I come back on my "problem" for my large application
In the ENG directory, after translating a form, say F1, the F1.dfm should contain the translation.
In my case, it does NOT ! As you wrote, something is screwed on some way.
In the IDE however, when I open the DFM with the translation editor, the english words are there and when I click on the button to show the resulting form, it is OKAY
So the only thing that does not work is that the IDE, for that project, never create the right DFM (based on the DFN that contains all corresponding translation etc...)
I just need now to find a way the the IDE to force all these DFM to be created correclty...
I made a few additional tests, based on our conversation.
Indeed, activating a langage, for example ENG, means that when the application starts, it looks directly for the ENG DLL.
On the other hand, if that DLL is not there, it searches for the corresponding locale, here for me FRB
If I rename the DLL from ENG to FRB, indeed it uses it.
This is interesting because I will be able to distributed an english version to my "users" by defined ENG as the default and delivering that DLL as well, whatever the locale for my users is.
I succeded finally to do all that after creating a brand new project with one simple form
Now I come back on my "problem" for my large application
In the ENG directory, after translating a form, say F1, the F1.dfm should contain the translation.
In my case, it does NOT ! As you wrote, something is screwed on some way.
In the IDE however, when I open the DFM with the translation editor, the english words are there and when I click on the button to show the resulting form, it is OKAY
So the only thing that does not work is that the IDE, for that project, never create the right DFM (based on the DFN that contains all corresponding translation etc...)
I just need now to find a way the the IDE to force all these DFM to be created correclty...
Hello epasquier, I have some news
I tried this : in my project, I open a previously "translated" form with the translation editor and made a dummy change of one texte (already in english), saved it and had a look at the resulting DFM : this time is was okay so Delphi recreated it correctly based on the DFN
This is not related to the activated language (I tried ENG and the french)
Now what is stil strange is this : I define the ENG as activated language and compile the entire stuff
I get a DLL with extension ENG
Running the executable now, it does not use that ENG ...
I tried this : in my project, I open a previously "translated" form with the translation editor and made a dummy change of one texte (already in english), saved it and had a look at the resulting DFM : this time is was okay so Delphi recreated it correctly based on the DFN
This is not related to the activated language (I tried ENG and the french)
Now what is stil strange is this : I define the ENG as activated language and compile the entire stuff
I get a DLL with extension ENG
Running the executable now, it does not use that ENG ...
was okay so Delphi recreated it correctly based on the DFN
Running the executable now, it does not use that ENG ...
I suppose we have determined how that translation manager **should** work, and how developper should create the project and languages dll, and language activated.
But I have the feeling that all this is a bit strange (the activated language principle is a bit redundant with the default values in the normal .DFM/.EXE), not very stable or easy to deploy/change language at runtime, and yes prone to massive hair loosing.
Which is probably why there are lots of commercial tools to do so.
By the way, here is how I do that kind of 'multi language' feature on my small applications : I put all the languages in an INI file, like GUI.FRE or GUI.ENG , and this file is referenced in the application parameters .INI itself.
So the application loads its parameters, see what language is desired, if I have the corresponding GUI file, and load all my captions and other text resources from there.
in the Ini, it looks like this :
[frmMain]
CAPTION=Main Form
[frmMain.Label1]
CAPTION=Hello World
LEFT=10 // This is optional, don't have to reposition all elements
From the application code point of view, it looks like :
LoadGUI ( [ Label1, CheckBox1, Form2, Button1 ] ); <== open array of components
The LoadGUI knows what to load and how depending on the object type in the array.
I know this system is not as pretty as resources and dll, but at least it was quick and easy to maintain (for me and also for my customers)
Indeed, it looks like the current Delphi version is not very "stable" doing localisation !
At this point, and if do not find why the activated language is not the one used by the application, I will have to distribute the exe, the dll (.eng) and tell to my foreign users to rename the dll extension into their locale, for example ENU for english US etc...
But I am not there yet, I still need to translate around 12 forms and verify all my other utility units for french words to be translated.
Concerning translation of internal messages etc... my application will look it is directory if there is such "famous" DLL, one way or another the set a flag to true if english.
I then have a central function that manages returning the proper messages ...
At this point, and if do not find why the activated language is not the one used by the application, I will have to distribute the exe, the dll (.eng) and tell to my foreign users to rename the dll extension into their locale, for example ENU for english US etc...
But I am not there yet, I still need to translate around 12 forms and verify all my other utility units for french words to be translated.
Concerning translation of internal messages etc... my application will look it is directory if there is such "famous" DLL, one way or another the set a flag to true if english.
I then have a central function that manages returning the proper messages ...
Hello epasquier
A part of the mystery is resolved.
It is the one not originally related to my question.
I discovered that the DFM files located in the ENG directory, and that are updated when using the translation editor, these files keep the same date/time of modification than the originals !
I did not tell you but I developed on 2 PCs, and I used an intermediate external USB disk to move changes from one to the other, using xcopy and ad-hoc parameters.
I suspect that due to the fact that Delphi does not change those file dates, at a certain move moment, real original overwrote my changed DFM !
So oufff for this
But the stuff of "active" language question remains
I do not desesperate to fix this as well via this EE question ....
A part of the mystery is resolved.
It is the one not originally related to my question.
I discovered that the DFM files located in the ENG directory, and that are updated when using the translation editor, these files keep the same date/time of modification than the originals !
I did not tell you but I developed on 2 PCs, and I used an intermediate external USB disk to move changes from one to the other, using xcopy and ad-hoc parameters.
I suspect that due to the fact that Delphi does not change those file dates, at a certain move moment, real original overwrote my changed DFM !
So oufff for this
But the stuff of "active" language question remains
I do not desesperate to fix this as well via this EE question ....
I think the "active language" is just a design choice. They choose to set IN THE EXE the language for which it has been compiled, instead of having some mechanism that would load the right dll from, say, the systeme locale settings.
http://docwiki.embarcadero.com/RADStudio/en/Setting_the_Active_Language_for_a_Project
BUT ! As I suspected the thought about the possibility to switch language at runtime :
http://docwiki.embarcadero.com/RADStudio/en/Dynamic_Switching_of_Resource_DLLs
Isn't it great ?
http://docwiki.embarcadero.com/RADStudio/en/Setting_the_Active_Language_for_a_Project
BUT ! As I suspected the thought about the possibility to switch language at runtime :
http://docwiki.embarcadero.com/RADStudio/en/Dynamic_Switching_of_Resource_DLLs
Isn't it great ?
That design choice is excellent for me and I think for many other developers.
For myself, my application is originally written in french.
I just want one more language, english UK, available for all other potential users, whatever their locale settings are.
So the deployment for me is easy : to french speaking people I provide myApp.exe, and to others the same PLUS myApp.ENG
My current problem is apparently that it does not work like that for this application.
I will have a look at the links you provide...
For myself, my application is originally written in french.
I just want one more language, english UK, available for all other potential users, whatever their locale settings are.
So the deployment for me is easy : to french speaking people I provide myApp.exe, and to others the same PLUS myApp.ENG
My current problem is apparently that it does not work like that for this application.
I will have a look at the links you provide...
Well, the first link shows what I think I already do
The second has for me a major problem, that is explained in the final note : "Note: Any changes made to the form properties at runtime will be lost. Once the new DLL is loaded, default values are not reset. Avoid code that assumes that the form objects are reinitialized to the their startup state, apart from differences due to localization."
The second has for me a major problem, that is explained in the final note : "Note: Any changes made to the form properties at runtime will be lost. Once the new DLL is loaded, default values are not reset. Avoid code that assumes that the form objects are reinitialized to the their startup state, apart from differences due to localization."
well, simply put, when you create a form, the .DFM content is loaded into the objects properties.
If you change those properties after the Create (say in the onCreate event) AND you AFTER load a different language dll, then ALL the changes made will be lost.
That is well understandable, as the new DLL is also a DFM file that will overwrite all the initial properties of all the form's objects
by the way, here is the complete explanation of how Delphi loads language resources dll
http://docwiki.embarcadero.com/RADStudio/XE/en/Deploying_Localized_Applications
in this explanation, I am still unsure of what they mean by "UILocale is set to German - Germany". Could it be the system locale settings ? And I don't see the "active language" in that explanation...
If you change those properties after the Create (say in the onCreate event) AND you AFTER load a different language dll, then ALL the changes made will be lost.
That is well understandable, as the new DLL is also a DFM file that will overwrite all the initial properties of all the form's objects
by the way, here is the complete explanation of how Delphi loads language resources dll
http://docwiki.embarcadero.com/RADStudio/XE/en/Deploying_Localized_Applications
in this explanation, I am still unsure of what they mean by "UILocale is set to German - Germany". Could it be the system locale settings ? And I don't see the "active language" in that explanation...
Miracle !
Now it works, I just followed the first link and did it like that, despite the fact I already did it previously.
Why now and not yesterday, only God knows !
Thanks to you I understood the "active language" stuff and you gonna get the points
Many thanks again, epasquier
Now it works, I just followed the first link and did it like that, despite the fact I already did it previously.
Why now and not yesterday, only God knows !
Thanks to you I understood the "active language" stuff and you gonna get the points
Many thanks again, epasquier
It was my pleasure !
I too learned a great deal, and next time I really need to localize an application I might just use that stuff.
Only problem for me is that 50% of my work still need Delphi 5, and so I just can't rely on too modern things and have to do it "the old way" :-(
I too learned a great deal, and next time I really need to localize an application I might just use that stuff.
Only problem for me is that 50% of my work still need Delphi 5, and so I just can't rely on too modern things and have to do it "the old way" :-(
I have purchased XE a few month ago ! I love it, but I must stick to D5 for plugins projects (for a D5 application). Everything else I do now with XE (formerly, with D7). Fortunately, I have less and less of D5 plugins, as the new version of the application is relying on COM object for the plugins, not .BPL.
Only a couple years to wait until I can finally only look forward !
Only a couple years to wait until I can finally only look forward !
Premium Content
You need an Expert Office subscription to comment.Start Free Trial