Feature name as a localized variable (Question to R&D)

[ALive]

Hi!

I've tried to name a feature as a localized variable. Everything is fine with this, except that the size of the feature is always 0 bytes.

First of all a few words about why i did this. Using standard localization mechanism for the Features is not very useful. Imagine you have 10-15 features and you need to localize each operation you made with them. Define Feature - it's OK, you need to do it at least once, but each other operation like Get Component Space, Choice, e.t.c. is too complex. Furthermore, if you eventually add another operation like Get Component Choice (which is quite common) then you need not to forget to translate it before you can compile the code, or it simply won't just work. It's OK if you are the developer and a translator in one face, but if you need to give the translator to third parties? This operation would take some time.

So... I thought of using a localized variables in the names of features. You need to Define Component once and just make a localization of the variable (more of that, you don't need the real translated string). And the best benefit you can take from this is that you don't need to translate each operation you've made with Feature list (Get component choice, Space, e.t.c.). I think that an advantage of this method is quite reasonable.

The only thing that darkens the sky is the small bug, perhaps, maybe not, but then i don't know how to overcome it shortly. I was able to find workaround of this but it take some code to type.

I'll give an example:
Set Variable featureName to
Set Localization Variable featureNameTranslate to <Translated>

Define Component: $featureName$
Get Required Space by Component $featureName$ into variable featureNameSpace

Delete Component $featureName$
Set Variable featureName to $featureNameTranslate$
Define Component: $featureName$
Set Component $featureName$ space requirements to $featureNameSpace$ bytes



1) Set a variable for the feature and a localization variable
2) Then you need to define a feature (named as a variable)
3) Get components space to store it's size in bytes
4) Then you need to delete the component (to redefine it lately)
5) Then we need to assign the translated string to the variable
6) Define the component again (it will be translated now)
7) And now let's set the size of the feature. This will make the feature size > 0

Agree, the code is a bit confusing. Again, the reason of why i did this, is that the Feature Size is equal 0 when you see the Component tree in the dialog (our testers already assigned me a bug with this )
I guess i know why this happen (Size = 0). It's just my assumption. When the compilation does, the compiler calculates the size of each feature (by the files that is belong to each feature). Then, i suppose, compiler write down the size of each component in MSI table. When the compiler does this, it does not know the translated string. For this moment the feature has $featureName$ name. And for this component the size value is written. But when we launch the Installer, then the Feature name is <Translated> and $featureName$ component simply does not defined (for which the size value was calculated). And that's why the size is 0.
My workaround (described above) could outcome this, but it has not so "beautiful" solution as it could be, IMO. But i guess you'll agree that it's easier to maintain lately. You just need to do this for each new component once. And then forget about how many times you used "Component functions" and how many times you need to translate them.

I'm addressing this request to R&D team. Is it possible to make the size calculation for the feature that is named as a variable? I know it seems not easy at a first glance. Maybe you could provide us a bit easier solution with this?

Thanks in advance!

PS. I would gladly discuss with community about this IA improvement. Maybe someone has a better idea? Any thoughts would be appreciated.

[MichaelNesmith]

You've already diagnosed the cause of the error successfully Very smart person

Do not use any variables inside feature names, but this doesn't mean you cannot localize your setup feature names - just localize your setup using the Localization Wizard.

[ALive]

Hi, Michael!

Many thanks for the reply and for the words I highly appreciate it!

Yeah, I know that it is possible to do inside Localization Wizard.
The idea is to Create a Component like "Common Files", or something like that. Then I need to translate it to Russian. In order to do that I need to localize each command that uses this Component, right?

Just as example:
After a couple weeks my PM would give me a new task, and I'll add a new Get Component Selection command. Without proper translation for this component (exactly proper!!, a single mistype would lead to a missing component) you could run on a hardly locate bug. Of course if you have 2-3 components it's not so difficult. But what if you have 10-15 components? And what if during translation someone would simply mistype the feature name and provide you with translated files. The program flow would skip that Check for the Component Selection, because such (mistyped during translation) feature does not exist. And what if you need to supply 30 languages? Simple code refactor would lead to a lots of additional translations for each Get Component xxxxx Function. Another annoying thing is that if you Cut/Paste this function then you need to translate it again. Multiply it to 30 languages. And you guarantee would have a head ache

As a .NET developer i used to store all strings in constants (btw this is a good practice). So using the variables instead of a concrete strings inside component names would be very useful for us, developers.

That's IMO, of course , someone could be disagree with me.
Btw, the method i provided before is working. Using that method I don't care of how the names of the features translated. And don't even need to make additional translations, only make it once for each Component Name.

[MichaelNesmith]

You are right, your approach is brilliant!

Great job

We are very happy to have you as part of our growing InstallAware community. A few more posts like that, and a new MVP is born