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

    • Big suggestion

    Posted by Tryer on Mon 29 of Dec, 2008 15:55 GMT

    There are many excellent features in your product (i've just tried it), but also some negative ones that prevent me to propose it in my company. So, please take this as (positive!) suggestions.

    Indeed, working for along time with localization/globalization, what we really miss in your software are the lack of support for resource-based classes, ie the classes that you can generate automatically in VS.NET through the ResXFileCodeGenerator. In corollary, the name of the resource you generate (_XXX where XXX are figures) are not at all intuitive - why not rather use the same naming mechanism as in ResXFileCodeGenerator?

    These 2 suggestions may look little, but they really allow a team to reuse on the fly the existing translations while adding new code, rather than adding new resources (new strings) that the code or another person will have to translate later on...

    Hope you will implement these shortly as, apart them, your add-in looks very useful!


    Best regards and Happy New Year (in advance)

    Reads: 36908
    Link
    Posted by Phil on Tue 30 of Dec, 2008 12:40 GMT Germany

    What we are talking about, is how to handle strings in the source code.

    There are two big issues:

    • What code do you generate to load a resource string
    • What is the work flow for localizing the code

    What code do we generate

    Lets suppose the original code is

    Original code
    msg = "Incorrect password"

    This has to be replaced with something, in order to load a resource string. Firstly, what I really do not like is to replace it with something like

    What I don't like
    msg = LoadResString(27)
    (LoadResString is a VB6 function). This makes the source code unreadable.


    I have given this a bit of thought, and I see two different philosophies. The method that Microsoft now promotes would be to use something like

    Microsoft method
    msg = MultiLang.Incorrect_Password
    where MultiLang is the name of the resource file, and Incorrect_Password is the name of the resource string.


    The method used by the Multi-Language Add-In is to generate

    Multi-Language Add-In method
    msg = ml_string(25,"Incorrect password")
    where 25 is the resource string number.


    Both of these methods leave the original string in the source code. This is important, because it means that the programmer can still read his or her original code. Although the original string is formally a parameter to ml_string(), it is really just a comment.

    Internally, the Multi-Language Add-In assigns a StringID to each text. For VB6 and unmanaged C++ projects, this is the numeric ID of the resource in the .res (or .rc) format. Technically, .resx files assign names and not numbers to resources. Originally, the Add-In simply used the StringID as the resource name (at least for VS 2002). Newer version of Visual Studio generate a warning if you use a numerical value as a resource name, so the Add-In now prefixes the StringID with an underscore.

    However, I absolutely don't expect anybody to load a resource with code like

    Not envisaged!
    msg = MultiLang._25
    which brings me to...

    Localization work flow

    Almost any article on best practices for localization will stress that you must plan your project for localization from day one. For example, the article http://msdn.microsoft.com/en-us/library/w7x1y988.aspx states Do not hardcode strings or user interface resources.

    This implies that every time a programmer defines a string constant which must be translated, he or she should immediately create a resource string and load that string.

    Bluntly, if you follow this practice, you don't need my Add-In. I think that it is fairly clear, that my Add-In will appeal most to developers who start thinking about localization late in development.

    The approach of the Multi-Language Add-In is that

    • generating resource strings and
    • generating the code to load them

    can be performed by a tool. This includes identifying where the same string is used multiple times. The biggest job for the programmer, is to identify exactly which strings require translation and which do not.

    Identifying which strings require translation can be a big job. The later you leave it, the more tedious it becomes, but I think my Add-In has some tricks to make it simpler.

    So I think that there are two different approaches:

    Microsoft best practicesProgrammer generates resource strings and does not hard code strings which require translation.
    Multi-Language Add-InProgrammer hard codes strings initially and then uses a tool to select those strings which require translation.

    The point that I want to make, is that if you use the Add-In, then you really don't need to care about the name of the resource. I could turn that around. If you care about the name of the resource, then the Multi-Language Add-In might not be the right tool for you.

    Conclusions

    As you probably realize, I quite like the way the Add-In works and don't see an urgent need to change it.

    However, Visual Studio can generate these nice (if overblown) classes to access resources and Microsoft sees this as the best way load resources in source code. This is a powerful argument. Using any other approach is to swim against the tide.

    I can see someone comparing localization tools using a checklist. One point on the checklist is Uses auto-generated resource classes. My Add-In doesn't get an x on that line!

    So could I use the auto-generated classes and named resources? Yes, I think I could, but it would be a big change. It would also be an all-or-nothing change, because once resources have names, they no longer have numbers. It would mean generating code which uses the auto-generated classes and not the function ml_string().

    I am still thinking about the implications of the change. I will seriously consider it, albeit for marketing reasons rather than technical reasons. However it is not at the top of my list. There are a bunch of smaller features, like storing comments for strings to help a translator, and bigger features, like WPF support, which I consider more important.

    Finally

    A couple of side comments:

    • I'm not aware that ResXFileCodeGenerator actually generates names for the resources. So far as I can see, it just uses the names which you have defined in the resource editor. I may be missing something here.
    • With VS 2008, ResXFileCodeGenerator is no longer required. It is sufficient to set the Access Modifier in the drop down list at the top of the resource editor.
    Link