Loading...
 
Multi-Language Add-In for Visual Studio

Multi-Language Add-In for Visual Studio

Forum List Topic List

 
Thread actions
Print this page
  • Print all pages

    • How to rebuild the translation file

    Posted by JensBo on Fri 29 of Jan, 2010 17:44 GMT

    I have used ML for some years now in a single large project. Over time the translation file have become somewhat dirty containing unwanted items (as you have noticed before on seing it).

    Now to avoid negative side effects of this i would like to rebuild the translation from new.

    My procedure would be:

    1. Make sure that all current translations are in the global database.
    2. Delete the project xml-file.
    3. Perform a full scan of the project (source and controls) and benefit from the translations already in the global database.
    4. Go thru both grids to select/de-select and hide items as may fit.

    Would this be the correct way to proceed? Or is there a better way?

    And will i need to remove the string id's from the source files between step 3 and 4.

    Best regards,
    Jens Bo Frederiksen

    Reads: 28961
    Link
    Posted by Phil on Wed 03 of Feb, 2010 20:38 GMT Germany

    Hello Jens,

    there are two things which could be left as unused records in the project database:

    • string IDs and the associated texts
    • information about properties


    Neither of these is really bad, so you don't need to worry too much. smile

    The most obvious issue is, that the Add-In exports all strings to the resource file MultiLang.resx, even if they are not used. This could increase the size of the application unnecessarily.

    However, there is a command in the tools menu called "Remove unused String IDs" which you can use to remove these strings from the project database. It lists all of the unused IDs and lets you remove selected strings, or all of them.

    In earlier versions, unused Strings were included in the Excel export. This is no longer the case. Unused strings are not exported to Excel. This would be a more serious problem, because you might end up paying a translator to translate strings which are not even used!

    The project database may contain unused information about properties, if you have removed controls from forms, UserControls or web pages, or if you have removed any of these components completely.

    The Add-In does not have any build in way to remove this information. I could add a command to do this, but I'm not sure it is very important.

    With regard to you suggested procedure:

    If you are using source control, make sure that the previous version is checked in first. If not, then make a backup of the project. Then you are safe, even if it doesn't work as you expect.

    You would not need to remove the string IDs from the source code. On a large project, that would be crazy. If the Add-In finds unknown string IDs in the source code, it will add them to the database automatically.

    However, for this to work cleanly, the Add-In must scan the source code before is scans the controls. Otherwise it might assign the same IDs to some properties (which would presumably contain quite different texts). On the first scan, you should select the option "Do not initialise" for the Controls, so that it only scans the source code. After that you can rescan the controls.

    I think that this would work, but personally, I wouldn't do it.

    I would remove unused String IDs using the command in the tools menu. If I was bothered about the property information I would probably open the XML file in a text editor and remove the Properties records by hand. (No other records refer to the Properties records, so you won't harm the integrity of the database by removing any of them.)

    A middle way would be to remove all Properties records from the XML file. This is less radical than deleting the file completely. All of the translations would still be there. When you scan the project, the records would be regenerated. However, the details of exactly which properties are selected or hidden would be lost. On a small project that might not be serious, but on a large project it would be annoying.

    Phil

    Link