Majarkeun: Localisation with VS2005 will slow you down

Tuesday, February 21, 2017

Localisation with VS2005 will slow you down

In my previous blog about a localisation that went sour, I mentioned that the time for building a localised application takes longer and longer for every language that is added. I have now quantified my feeling and found out that adding a language adds 15-20 seconds for each language. Now that doesnt sound that bad right? Wrong, If you develop an application that takes one minute to build and adding languages almost triples that time, then it becomes tedious very quickly.

This is what I found out (table and graph):

Default language took 69 seconds to build
With two languages it took 85 seconds to build (16 extra seconds)
With four languages it took 118 seconds to build (49 extra seconds)
With six languages it took 144 seconds to build (75 extra seconds)

If a normal developer compiles 10 times an hour to test something, he/she will waste 12 minutes, just sitting to wait for VS2005 to build. I meanthat is an outrageous extra time, and I wonder if we can send a invoice to Microsoft for those hours that we just wait for the build complete? And I guess we have to make the work day longer as we get much less done.

For this project, the solution was to remove all language resource files from the project file. This means that the only language that is supported in mid-development is "default" and nothing else. So fixing those too narrow labels for localised texts has to wait for another day. The tool do add/remove all those languages to/from the project file is developed in house and can not be shared unfortunately. The tool is very simple to create, but in my view unnecessary.

Here we have a grave problem with the localisation in Visual Studio 2005. If it is done as MS wants, the build time to a project can (and probably will) go up for every language added. What is the outcome of that? Either the developer will stop adding localisations, constrain the development by only showing the default or sit and do nothing while the project builds. This is not a good solution. I would rather have a one-file seperate from the GUI, which reads on the fly when the application is started. That way the language files does not affect the build at all, and it will be a minor load time added for the user which probably will not be noticed.

Measurement notes:

This is an observation of an application that has been under development for 3-4 years.
They have tried to follow MS design guidelines.
Clear case is used with dynamic views, which could have an impact on the result as it needs to access 200 new files for every added language.
The application is not divided up into more than 2 GUI projects. Perhaps adding more sub projects could make the build quicker?
I used a C# application to measure the time it took to execute a bat file containing "devenv app.sln /build debug"
I measured each language addition at least 4 times

Available link for download