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

Multi-Language Add-In for Visual Studio


Can the add-in handle "other" strings?

I am hoping you can help me.

I am currently evaluating your software for use by our company. So far it has been able to handle everything we need it to except for 1 item.

Our application contains a considerable amount of configuration data. This data is held in XML format as resources. This XML contains many strings that get displayed to the user (menu items, input selection texts etc).

What we would like to be able to do is to replace the texts in our XML with a resource ID and have the text loaded in the correct language at run-time. However, we would like to maintain these texts within the same resource files produced by your add-in. Is there any way we can manually add new resources to the project database or (even better) is there a way this can be automated.

I had assumed that I might be able to simply add some code like this to our app:

menuitem.text = ml_string(cint(xmlnode.value), "menu caption")

but I can find no way to manually add resources to the application database... perhaps there could be a 'manual' section in addition to controls, source code and html?

We are also evaluating your solution and have a similar issue. Interested in the response to this one also.

Hello??? Anybody there?

I realise I can add my own string tables to the application but would really like to find a unified solution.

Germany

Hi,

I'm sorry that I didn't reply quickly. I accept that this is an important requirement and I want to add some support for it.

At present, I am making a change which may sound like a minor change, but which is turning out to be quite a major effort. I am replacing the grid component used in the two main tabs with a different grid. Up to now I have been using a COM component, which I originally used in the VB6 Add-In. Now I am replacing it with an extended version of the DataGridView.

I only mention that, because I really want to finish that change, before starting on a new feature. I think this change will still take me several weeks.

Nevertheless, I have been thinking about how to handle additional resources. Since they neither belong to controls nor to the source code, I think it would be appropriate to add a third tab with additional resources. Alternatively, I could add a third tab which simply showed all resource strings.

Apart from that, I have two big open questions:

  • should the Add-In support named resources?
  • should the Add-In handle resources in arbitrary resource files, or only in its own MultiLang.resx file.


From your point of view, I think that neither of these would be necessary. It would be enough just to add new resources to MultiLang.resx using numeric resource IDs.

From a more general stand point, I am actually sure that the Add-In should detect named resources in all resource files in a project. That way, if a (new) user scanned a project which already contained some resource strings, he/she would immediately see his/her resources in one of the grids.

I will continue to think about these issues, and I hope to start work on this feature in a few weeks time.

Phil

Hi Phil,

We are finally at a place to begin work on the next version of our application, and I notice also that you have released your new version that utilises the .NET grid component.

We are wondering then if you are now any closer to having a version to which we can add arbitrary string resources and their translations?

Darren

Germany

Hi Darren,

thanks for reminding me of this. I will give it some serious thought and try to implement it soon.

I think that:

  • allowing a user to add additional string and
  • scanning other resource files

are probably two separate features.

Adding additional strings ought not to be difficult.

Phil

Hi Phil,

Yes, my thoughts exactly. And without wanting to sound too selfish, the 'additional strings' functions is probably all we need.

Let me know how you get on.

Thanks

Hi Phil,

we have come up with our own solution for our XML files, so this feature is no longer on our 'needs' list.

Thanks

Darren


Hi Phil, thanks for the reply.

You are correct in your assertion that named resources and arbitrary resource files are not necessary for us. I can see where you are heading though with your ideas.

You may need to be a little careful if heading down the path of automatically handling such resources. Some resources, like our XML files, will contain a very large number of strings many of which must not be translated. It would be easy to say "the developer can hide those that do not need translation", but this is problematic if they are looking for a few dozen strings amongst hundreds or thousands. Just something to be thinking about.

Our tool evaluation continues, so time (and clients) permitting, we wait in anticipation of the new functionality.

I understand your current situation and can appreciate the complexity of changing grids having just completed conversion of a fairly large application from vb6 to vb.net ourselves. The grid components were amongst the more dificult to switch (but worth the effort).