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

Multi-Language Add-In for Visual Studio

Forum List Topic List

Forums > Multi-Language Add-In for Visual Studio > Request: Localization of solution/several projects
 
Thread actions
Print this page
  • Print all pages

    • Request: Localization of solution/several projects

    Posted by nickniebling on Tue 24 of Aug, 2010 14:00 GMT

    It would be nice to have a "solution scope" of localization! So MLS can control several projects at the same time!

    We have several projects (10+) in a solution. Lets just say half of them (5+) has strings to be localized. Only 1 of the projects has a huge amount of strings (lets say 1.000) and the other projects only has a few (lets say less than 25).

    With a "solution scope" of MLS, the MLString class is located in a project for itself, so import and export can be done through 1 project. I get that this is not always the usecase - but for some it is!

    Today, we have to make a project to control localization for the "small projects" (25-), make a reference to this project manual and call our homemade MLString class where we place our strings for localization. Then we only have MLString in this project shared by "the small projects". The "large project" (1.000+) gets its own MLString and localization handling.

    For us the "large project" is either a ASP.NET Website/Webapplication or a Windows Forms Application.

    Hope you get the point and see the potential in letting the user choose between 2 scopes: project/solution.

    Reads: 32267
    Link
    Posted by Phil on Tue 24 of Aug, 2010 20:13 GMT Germany

    Basically, I agree with this.

    Restricting the localization to project scope was always a simplification for the Add-In, but not necessarily for the user.smile

    For example, if you export texts to Excel for translation, it would clearly be convenient to do this for all of the projects in a solution as one operation.

    There is one major structural question, which is how to handle the project database.

    I have already done the groundwork to separate the project database into two parts, which I call the translation store and the project info. The project info contains project specific information and should remain associated with each separate project. However, it would be possible to have a single translation store for all of the projects in a solution.

    If all projects shared a single translation store, then they would all use the same String-IDs. If you want to implement MLString in a single project, then this would be necessary.

    The other option would be for every project to have its own project database, exactly as at present. In this case, scanning the complete solution would be a user interface improvement, but not much more.

    I think that I probably want both these options, but I am not yet sure.

    By the way, if I make it possible for multiple projects to share a single translation store, then there is no fundamental reason why they should be in the same solution.

    I will have to analyze how difficult this change would really be. There would be a lot of minor code changes and quite a number of changes to the user interface.

    Phil

    Link

    Posted by nickniebling on Tue 24 of Aug, 2010 21:40 GMT

    By the way, if I make it possible for multiple projects to share a single translation store, then there is no fundamental reason why they should be in the same solution.

    Im aware that a project can be shared by more than one solution - that's one of the main reasons to have projects beside lowering dependencies.

    And my post was only a request for future improvements.. I know this will have an effect in many areas of the product. It was ment as a kind of feedback to you, so you know what gives me and my team problems.

    Actually a good start would be to just export several translated projects into 1 excel file and import it back again as one file.. That should be quite simple to implement for you (compared to my previous request) if you use the excel tabs to seperate the projects so ID's used more than once wont confuse on import. That change will actually make a big difference, but of course not as good as the first requested as this is also a more "clean" solution where the same logic aint placed as a class in every project.

    We want to make translating as easy and light as possible for the developer team. Translating the UI is difficult in most cases, but your software really helps simplify the process! Thats why we choose you.. Tahnk you for all..

    Link
    Posted by Phil on Sun 21 of Nov, 2010 23:22 GMT Germany

    It's time to give a bit more feedback on this question.

    I firmly want to support a solution scope for the Add-In, or allow you to select some, but not all projects in a solution.

    In the first version, I don't want to make any changes to the project database. If you are working with 5 projects, then each project will have its own completely independent project database (and therefore independent String-IDs). Obviously, it would be attractive to share identical translations between multiple projects, but I am going to leave that until a second stage.

    However, the assumption that the Add-In works with a single project has been deeply rooted in the structure of the Add-In. In the last three months, I have made a lot of internal changes, to remove this basic assumption.

    I have now reached a point where I can finally start to add real support for multiple projects. Once I get the basic mechanism working, the next priority will be the Excel export and import. With luck, I will have something working before the end of the year.

    Phil

    Link
    Posted by Phil on Mon 06 of Dec, 2010 21:23 GMT Germany

    I have just uploaded a new version (4.7x.0047) with a beta version of support for multiple projects.

    There is a new item in project list <Select projects - BETA VERSION> which opens a dialog, in which you can select one or more projects.

    This support is far from finished and certainly not fully tested. I can't recommend that anybody uses is productively at present.

    I have made a modified Excel format to export the strings from multiple projects in a single worksheet. This is one of the most important features.

    In this version, there is no change to the structure of the project database. The translations are stored independently for each project. Thus if you have the same text in two projects, it will be exported to the Excel file twice.

    In my opinion, this is not good enough. This will only be really good feature if projects actually share translations. However, I want to version with independent project databases working properly first.

    Phil

    Link
    Posted by nickniebling on Tue 07 of Dec, 2010 10:30 GMT

    Sounds good !!
    We will be awaiting your next version with the solution scope fully supported! :-)

    Link