PDA

View Full Version : String Table Entries - Missing Or Not Missing?



Tim Owers
11-04-2005, 08:56 AM
In a basic MSI project, if an entry in the string table cannot be found anywhere in the project, does this mean it will never be used (ignoring ISScript entries)?
I ask because I have an old, upgraded project whose string table entries have meaningless id's, e.g. IDS_UITEXT_13 that in a newly created IS11 project (the same string) now has an id of IDS_UITEXT_FeatureLocal. Much better, but in both cases the string is not found anywhere in the project.
So, if it cannot be found, why did it get created by default in the new IS11 project, and if it is required, what is it that knows to look for whatever id is required.
And that leads on to - what happens if I change the id in the old project to that of it's counterpart in the new project?

Hope this makes sense!
Thanks,
Tim.

MichaelU
11-04-2005, 11:20 AM
The string table is primarily a pre-build cache of all the translatable strings in your project. At build all references are replaced with the translated contents, and the table ISString has no more semantic use and I believe it is discarded from the built MSI. Thus if there is no reference to a given string, its translation will replace nothing, and will be discarded. Does that answer your questions?

Tim Owers
11-07-2005, 04:38 AM
Thank you Michael, that does help but still leaves the question of why in a brand new project, the IDE creates a series of entries that are not referenced. I assumed there must be one or more IS ca dll's that require these entries and are therefore not directly used in the project file. If this is the case, how would I know which ones are ok to remove (I need to export the string table for our localisation dept. and don't want to give them the unnecessary overhead of translating text that would never be used).

Thanks,
Tim.

MichaelU
11-07-2005, 12:39 PM
Hmm. At the very least, but extremely tedious, would be right clicking on each Identifier and selecting Find String ID in Project. There might be some way to automate this, but probably not with our automation layer.

And there's a further problem with my description, and probably with this menu option if you're making use of String IDs in any InstallScript code - for those the full string table is dumped to a file that InstallScript uses.

I've submitted a feature request IOC-000042746 to add an option to clean the string tables. In it I suggest we handle the InstallScript usage correctly, although I'm not 100% sure it's possible for all potential code.

Tim Owers
11-08-2005, 05:41 AM
Another problem I've found is that when a string table that has entries from an earlier version is exported, then re-imported as a new language, the missing version 11 entries in the original table are added to both string tables. For example, if an upgraded IS7 project string table had a default entry of IDS_ERROR_999, exporting then re-importing would now include the missing version 11 version of the same string. In itself not too much of a problem just a bit messy. But when that default table is sent to the localization team, they now have a lots of duplicate entries to translate.
It would be trivial to make the whole import/export process intelligent, producing clean string tables that make sense to that installation.
As a start, an IDE method to clean the string table is a long overdue and would be very welcome.
Tim.

Steve_Coombes
11-14-2005, 04:11 PM
Hmm. At the very least, but extremely tedious, would be right clicking on each Identifier and selecting Find String ID in Project. There might be some way to automate this, but probably not with our automation layer.

And there's a further problem with my description, and probably with this menu option if you're making use of String IDs in any InstallScript code - for those the full string table is dumped to a file that InstallScript uses.

I've submitted a feature request IOC-000042746 to add an option to clean the string tables. In it I suggest we handle the InstallScript usage correctly, although I'm not 100% sure it's possible for all potential code.

I would certainly agree with the need for an easy method to clean up unused String IDs. I found this to be critically important after importing the wrong XML file once when using the XML File Changes "feature" (let's save that item for another post). After deleting the erronous XML file component, I realized that I also had around 100 or so new String IDs that had not been deleted which are used nowhere in my project - created by the import XML utility. Fortunately it was early in the project and I actually found it easier to just start over altogether rather than delete the added entries.

Perhaps another feature might be to have the option to associate String IDs with a specific Component, so that removing a Component would remove its associated String IDs at one go? :cool: