TsiLangRT.StorageFile doesn't get TsiLangDispatcher.FileName

[Andrew Tweddle]

I have a TsiLangDispatcher on a data module shared by all forms in the application.

On each form I place a TsiLangRT component and set its LangDispatcher property.

But TsiLangRT.StorageFile doesn't "inherit" the TsiLangDispatcher's FileName (and so also doesn't get updated whenever the dispatcher's file name is changed).

I can work around this at run-time. I have an application-level event that traps Ctrl+T keypresses, searches Screen.ActiveForm for a component of type TsiLangRT and calls the following code on it:

StorageFile := siLangComp.LangDispatcher.FileName;
EditAll;

But what do I do at design time? I don't want to hard-code TsiLangRT.StorageFile on all of 600+ forms.

Our version control system is largely path independent, except for LangDispatcher.FileName and the ADO connection's file name for the UDL file.

It's okay to have to change those each time a new feature branch (and working copy) are created in the version control system. But not on 600+ forms!

Worse still, when the feature branch is merged back into the main line of development, those 600+ file names will be incorrect in the main line, and will have to be changed back again. Yuck.

Am I missing something? Is there some simple way of specifying the translation file in just one place?

[isiticov]

The best would be assigning StorageFile property at run-time. You can use OnLinkToDispatcher event of TsiLangDispatcher and set the StorageFile there. Something like this:

Code: Select all

procedure TMainForm.siLangDispatcher1LinkToDispatcher(Sender: TObject;
  ASiLang: TsiCustomLang);
begin
  if ASiLang is TsiLangRT then
    TsiLangRT(ASiLang).StorageFile := TsiLangDispatcher(Sender).FileName;
end;

So no any further changes for other forms and you always sure you use the same file as dispatcher does.

Best regards.

[Andrew Tweddle]

My work-around already solves the problem at run-time (although in a different, less elegant way).

But at design time I am adding const strings to the form and they aren't being saved to the sil file.

The only way I can get them to be saved is by choosing "File/Save To..." in the Translation Editor itself.

I'm just worried that developers will forget to save to the sil file for some of the forms.

Also, does this mean that the exe is being clogged with unnecessary strings which are being stored both in the dfm and in the sil file?

[isiticov]

But at design time I am adding const strings to the form and they aren't being saved to the sil file.
The only way I can get them to be saved is by choosing "File/Save To..." in the Translation Editor itself.

Also you can use TsiLang Expert for this.

I'm just worried that developers will forget to save to the sil file for some of the forms.

The good practice in such case would be to save SIL/SIB files before each release.

Also, does this mean that the exe is being clogged with unnecessary strings which are being stored both in the dfm and in the sil file?

Yes, in this case strings will be stored both in EXE and SIL. In order to remove translations from EXE you can remove them from DFMs by using Clear Translations from TsiLang Expert. But be sure to import Strings back if you will add more strings in source that need to be translated before translating them. Otherwise TsiLang will assign ID that are already stored in SIL file.
Another tip would be to use SIB file instead of SIL. It is much faster since holds translations in binary format.

[Andrew Tweddle]

Hmmm... I'll have to think this through.

Thanks for the rapid responses.