Multi-Language Software | Upgrade from 4.00 to 4.65

Multi-Language Add-In for Visual Studio

Forum List Topic List

Upgrade from 4.00 to 4.65

Posted by RobinSword on Thu 19 of Nov, 2009 14:15 GMT

Hi there!

Here's Robert from Germany.
Up to know I used the MultiLang-AddIn 4.00 in a project under VS2005.
Now we upgraded to VS2008. So I uninstalled VS2005 and the MultiLang-AddIn,
installed VS2008 + the current version 4.65 of the MultiLang-AddIn.

My problem is now that the MultiLang-AddIn seems not to read the project correctly because after the reading process, the strings for Source Code are present, but the strings in the "Controls"-section are not. The list is empty!
I know that the MultiLang-Database was changed to xml in the past so may this be the reason for my problem?
Do I have to convert the mlb-File somehow into the new format?

One more info: I use mainly Infragistics Controls in the project.

Best regards!
Robert

Reads: 35022

Link

Posted by Phil on Fri 20 of Nov, 2009 00:04 GMT Germany

Hi Robert,

There are some small changes to the project database, but they should be handled automatically.

The Add-In supports both the Access database and the new XML format. It will not convert to XML automatically. You can do this via the project properties dialog (there is now a second tab for the project database format), but it should not be necessary.

The latest version writes a bit more information into the log file, in particular which files it has detected and whether it can open the designer windows. This would help to diagnose the problem.

The first problem is to find the log file. On an English system it is in the directory
C:\Documents and Settings\(user name)\Application Data\MultiLang.Net
(or I think C:\Dokumente und Einstellungen\(user name)\Anwendungs Daten\MultiLang.Net in German)

On Vista it is something like
C:\User\(user name)\AppData\MultiLang.net
(or C:\Benutzer\(user name)\AppData\MultiLang.net)

Also, I think that the Application Data directory is marked as hidden. Sorry, this is a bit chaotic!

In the log file, there should be a fairly clear section

--------------------------------------------------------------------------------
Files collection
--------------------------------------------------------------------------------

and a section

--------------------------------------------------------------------------------
Forms and controls collection
--------------------------------------------------------------------------------

listing the files detected by the Add-In.

During the scan, there should be a text something like

Open the designer window

for each form and each usercontrol. If this fails, then there should be a error message.

I think that the most likely error is that the Add-In can't open the designer windows. If this is the case, make sure that the project can be compiled. One simple way around the problem is to open the designer windows yourself, before performing the scan. However, this is not a very satisfying solution.

Maybe you could send me the log file.

Best regards
Phil

Link

Posted by RobinSword on Fri 20 of Nov, 2009 10:42 GMT

Hi Phil!

It really seems as if the AddIn cannot open the Forms.
I do not get control strings, neither when selecting "via sourcecode" nor when selecting "via designer" from the startup dialog.

The AddIn starts with "Quelltext einlesen" and then, after some seconds, it stops, presenting the list. But the Control strings are missing.

I have attached the log file. Perhaps you can read something from it.

Best regards!
Robert

MultiLang.log (56.52 Kb)

Link

Posted by Phil on Fri 20 of Nov, 2009 20:47 GMT Germany

Hi Robert

In the log file, I see that there are some .xaml files. Is this a WPF project?

I understood, that you had used the Add-in on this project with Visual Studio 2005, so I assumed that it was not a WPF project. Is there some way to mix WPF and Windows Forms classes in the same project?

If the project contains Windows Forms components, my current guess is that they are not scanned, because the Add-In thinks that it is a WPF project.

I have started work on WPF support, but I haven't got very far. (Of course, with a bit of pressure, it might go faster biggrin .)

Phil

Link

Posted by RobinSword on Fri 20 of Nov, 2009 21:20 GMT

Hi Phil!

Yes, it's a mixture between Windows Forms and WPF.
But the project is 99% Windows Forms. Only a few forms are realized with WPF because it offered better features.
In VS2005 it was a mixture between .NET Framework 2.5 and 3.0.
Now since we migrated to VS2005 it is all Framework 3.5.

Is there a possibility to exclude the xaml-Files from the scan so that the AddIn treats the project as a pure Windows Forms project?

Link

Posted by Phil on Fri 20 of Nov, 2009 22:50 GMT Germany

OK, I'm sure that I can fix this. I will try to do it tomorrow.

Phil

Link

Posted by Phil on Sat 21 of Nov, 2009 16:21 GMT Germany

I have uploaded a new version (4.65.0039) which should now detect the forms.

(Actually I'm not quite sure what it will do will do with the WPF forms. I still have to test this.)

Phil

Link

Posted by RobinSword on Mon 23 of Nov, 2009 07:47 GMT

Hi Phil!

Thanks for the new version!
When reading via designer it works!
Only when reading via source code the tool starts reading InitializeComponent,
but after having read about 90%, an unhandled program error occors.
I have reported this error by email.
Perhaps you can have a look on it?

In my case: Would you suggest to read via designer or via source code?

One more questions: In the string list, some texts are red and some
have a blue background. What does this mean? Concerning the red color
I thought that these are the manually changed strings, but they are
already read directly after the AddIn has finished reading.

Thanks for your support!
RobinSword

Link

Posted by Phil on Mon 23 of Nov, 2009 23:38 GMT Germany

I have uploaded a new version (4.65.0040) which should not generate the error.
(It still doesn't scan the WPF forms, but I am working on that.)

I would favour the designer scan, unless you find the source code scan significantly faster.

The blue background indicates the original text. To be honest, this is pointless.

The red background indicates that the text was translated online with the Microsoft Translator. I think that this is really important, because you (or a translator) really have to check any text which has been translated automatically.

You can change the status via the context menu. If you set it to 'edited' the background colour will be white. Alternatively, you can use ALT-UP or ALT-DOWN, which does just the same. This is a quick way to accept the translation as OK.

There is more information on the background colours and using the Microsoft Translator in http://www.jollans.com/tiki/tiki-view_forum_thread.php?comments_parentId=339&topics_offset=7&topics_sort_mode=lastPost_desc&forumId=1.

Phil

Link

Posted by RobinSword on Tue 24 of Nov, 2009 10:29 GMT

Hi Phil!

Reading via source code is now working, too!
Thanks a lot!

Concerning the red color: I did not mean the background color -
some texts are written in red color (foreground color), what does this mean?

Best regards!
Robert

Link

Posted by Phil on Wed 25 of Nov, 2009 00:39 GMT Germany

The red foreground colour means that the current text in the project does not match the text stored for the original language. Effectively, this means that the original text has been changed.

If you have already translated the text, then you might have to modify the translation. This is why it is shown in red.

You can copy the current text into the column for the original text via the context menu: Copy from current text. (This might even work with multiple selection, but I am not sure.)

Phil

Link

Multi-Language Add-In for Visual Studio

Thread actions